Bitcoin-NG

[Brice Buronfosse]

Hi,

I would greatly appreciate to know what Mike and/or Gavin think about Bitcoin-NG.

Thank you,

[Jonathan Toomim]

On Nov 10, 2015, at 1:18 AM, Brice Buronfosse <bric...@gmail.com> wrote:

> I would greatly appreciate to know what Mike and/or Gavin think about Bitcoin-NG.

If it works, it would be almost as awesome as cold fusion.

[Gavin Andresen]

It's an interesting idea, but it isn't a scaling solution-- the same amount of transaction data has to get to every fully-validating node, it doesn't matter if it is sent in the microblocks of the Bitcoin-NG proposal or the blocks we have now.

And it would require a very hard fork-- every piece of SPV wallet software would have to change (at least a little bit) to understand microblocks between key blocks.

--

--
Gavin Andresen

[Brice Buronfosse]

Thank you Gavin, appreciated.

[Yogh]

Hey Gavin,

(The following is all assuming the fee structure in NG functions correctly, which I'm doubtful of)

NG is a scaling solution in the sense that it allows the network to scale up further while getting away with it. Similar to the way weak blocks aswell as IBLTs accomplish this.

In NG, the information describing a full block / key block may propagate the network at constant time, reducing orphan rates to factors unrelating to the block size. The problem where scaling up by increasing the block size limit is thought to lead to miner centralization as a result of an increase in orphan rate, is solved by NG. Consequently, NG would allow the network to scale up without with no such miner centralization objection in mind; it is a scaling solution, at least in this sense.

As a rather trivial sidenote:

I believe it can be implemented as a (complex) soft fork. By placing microblocks in the next keyblock (enforced through consensus), and the next miner paying 60% of the fees back to the previous block's coinbase output(s) would make for a structure that is completely backward compatible. Including for SPV wallets. The microblock's ordering in the next keyblock is deterministic (as they reference their parent), which would allow a key-block announce to retain its constant-size, and constant-time propagation. A keyblock propagation message would include a standard 80 byte header message, along with a 32 byte last-microblock-generated header, which would allow any peer to deterministically reconstruct the full standard block, by plugging in the microblocks they should have already received.

Key-block / micro-block propagation may happen on top-layered p2p messages and enjoy the highly optimized NG protocol advantages, while still offering full backward compatibility to the existing infrastructure.

(There's some caveats still, but a soft fork is - I believe - perfectly possible)

On Tuesday, November 10, 2015 at 4:37:02 PM UTC+1, Gavin Andresen wrote:

[Emin Gün Sirer]

Hi Gavin,

Just came across this thread today. Let me chime in with my 0.02 BTC on the two issues you raise about NG:

>[NG] isn't a scaling solution-- the same amount of transaction data has to get to every fully-validating node, it doesn't matter if it is sent in the microblocks of the Bitcoin-NG proposal or the blocks we have now.

This is incorrect. The current throughput bottleneck in Bitcoin lies in block propagation, and NG breaks through the (block-size / block-interval) barrier with its slightly reversed mode of operation. This is what enables throughput gains of a few orders of magnitude over Core and XT.

Your comment points out another bottleneck, one that is far from the one faced by Core or XT today; namely, we could break a second scalability bottleneck by sharding transactions. Because of the way bottlenecks work, worrying about the higher bottleneck in the presence of a much more imminent lower bottleneck does not make sense. 

And it would require a very hard fork-- every piece of SPV wallet software would have to change (at least a little bit) to understand microblocks between key blocks.

Agreed, wallet software would have to be updated for NG. Wallets have to be updated for any blocksize increase as well. I agree that the NG changes are more complex than just changing a constant, but then again, the qualitative & quantitative improvements in the system are much larger as well. 

One interesting exercise for readers of the forum is to imagine how Satoshi would build Bitcoin if he/she were to build it from scratch today. I am pretty sure that the resulting system would look like NG. NG makes absolutely identical security assumptions, and improves throughput, improves 0-conf transactions, provides protection from fluctuations in mining power, provides stronger incentives for transaction propagation and is generally more fair to the smaller miners.

- egs

[Mike Hearn]

Hi Emin,

This is incorrect. The current throughput bottleneck in Bitcoin lies in block propagation, and NG breaks through the (block-size / block-interval) barrier with its slightly reversed mode of operation. This is what enables throughput gains of a few orders of magnitude over Core and XT.

I think Gavin's point is that optimising the current block propagation protocol is easier but hasn't actually been done (well, I posted the thin blocks patch recently, but I doubt miners will use it).

It's hard to consider propagation as a serious bottleneck when miners only poll getblocktemplate every 30 secs due to the design of their ASICs, when blocks propagate everywhere pretty fast except through the chinese firewall, etc. These issues wouldn't be addressed by NG. 

 

Agreed, wallet software would have to be updated for NG. Wallets have to be updated for any blocksize increase as well.

Most wallets are either web wallets (one node upgrade), or SPV wallets which do not need to be modified when the block size changes, as they don't check the limit anyway.