Towards faster block propagation: jtoomim's blocktorrent proposal

[seweso]

I gained the impression from Jonathan's write-ups so far that a more robust p2p data distribution would be beneficial in many ways, and could - if designed right - serve as a transport layer for things like weak blocks.

If you have weak blocks you already solved latency where it matters. Latency for weak blocks themselves isn't terribly important. Weak block orphans don't have an associated cost.

 

[freetrader]

@theZerg

The other, an engineering BUIP, is meant to be used when there is a concrete proposal. It doesn't have to have code or all the details ironed out. But more than "we should help jtoomim with his idea" or "like bittorrent". The problem with "like bittorrent" is that this is an analogy and the analogy will be mapped differently by different people.

Agreed and understood.

Finally, feel free to ignore this and just submit your BUIP. You have that right. I just think that we need more details ironed out. After submission, the Developer has 2 weeks (or more if you let him) to personally work with you on this. During that time, I would take your proposal and work with you on it specifically and mostly without other people's input, saying: "why don't we add a underlying transport plugin", or "why don't we add MST", to create a polished proposal

But I think that right now we don't have a concrete proposal and we WANT other people's input...

Ok, I submitted a rough draft:

BUIP006: Blocktorrent – a torrent-style block data transport

As anyone will notice it has a lot of disclaimers and to-be-completed sections because quite simply I am not yet in a position to make it more detailed.

It also does not follow Standard BIP structure, although I do plan to bring it into that format once much more of the meat is there.

I definitely want everyone's input so we can make it more concrete.

I have stated to @jtoomim that in the next 3-4 weeks I will have a somewhat reduced amount of spare time for this, with some stretches of absence, but I will endeavour to check in as often as I can to refine the BUIP based on suggestions received and prepare myself for taking part in its implementation.

 

[jtoomim]

It seems to me that IBLT + Weak blocks is far superior to this proposal. You should not do any round trips at all if you want to solve latency.

Weak blocks and IBLTs both fail completely in the case of blocks that contain unnanounced transactions. In those cases, you need a fall-back option. Ultimately, you have to limit the blocksize to whatever level is safe with your fall-back option.

Blocktorrent is designed to be fast in the worst case (adversarial conditions), and faster in the best case. I think that's more important than being the absolute fastest possible in the best case at the cost of being slow in the worst case.

Also, most of the round-trips in blocktorrent can be masked or avoided by using volunteered data. The initial steps of filling in the header and internal Merkle nodes take so little bandwidth (typically under 3 kB) that you can just send the data to your peers without waiting for them to ask for it. Often, you can guess what transactions each peer has or is missing (e.g. using bloom filters) and volunteer those as well. If not (or if the peer has a low limit for volunteered data), then it's just one round-trip to request all of those transactions. Total is about 1.5 round trips for a typical medium-sized block. That's actually the same as the current protocol.

I expect that all of the round-trips will add less than 1 second of latency total to the block propagation from the first miner to the last peer, or 0.18% to the orphan rate. I consider that to be an acceptable cost for the ability to handle very large adversarial blocks quickly. In contrast, an IBLT-only system would probably have 0.4 seconds of round trip latency when it works. That's better, yes, but I don't think the difference between 1 second and 0.4 seconds is a deal-breaker for large blocks. I think the adversarial case potentially is.

It's worth noting that Blocktorrent works well in conjunction with weak blocks. Blocktorrent makes it easy to pull data from caches for reconstructing a block, and weak blocks are one such example of a cache. IBLTs can be faster than weak blocks in non-adversarial cases, so when we can try an IBLT encoding, and if it works, we use it, and if it doesn't, we fall back to Blocktorrent.

 

[seweso]

Weak blocks and IBLTs both fail completely in the case of blocks that contain unnanounced transactions.

IBLT is specifically created so it doesn't fail on unannounced transactions, because it is able to reconstruct the missing transactions.

It's like parity bits on steroid

 

[jtoomim]

> IBLT is specifically created so it doesn't fail on unannounced transactions, because it is able to reconstruct the missing transactions.

If there are only a couple of unannounced transactions, that's true. If the block has too many unannounced transactions, or if there otherwise are too many differences (i.e. more than a couple percent?) between the mempools of the sender and recipient, then the IBLT fails and provides no useful information to the recipient. If the block is 100% unannounced transactions, then the IBLT does nothing except waste a little bit of time.

 

[solex]

My view is that blocktorrent is the No.1 scaling solution for BU for the simple reason that it has two highly qualified people ready to work on it.

Leave aside that is it technically much more efficient than thin blocks, better than the RN service and approaches the efficiency of IBLT in some respects. This year there is an urgency which did not exist last year. I hope that it can be done, and will provide a tipping-point that will see serious mining-power move to BU, and XT too.

 

[seweso]

If there are only a couple of unannounced transactions, that's true. If the block has too many unannounced transactions, or if there otherwise are too many differences (i.e. more than a couple percent?) between the mempools of the sender and recipient, then the IBLT fails

There should not be a lot of unannounced transactions in a block. Or else a miner would be shooting himself in his foot and IBLT indeed becomes useless. The incentives are there for miners to want it to work.
[doublepost=1452416669,1452415669][/doublepost]We must be carefull not to fall for the "Not invented here" fallacy. Being already constrained in terms of resources.

I think a simple but radical solutions like officially allowing mining on top of headers only, to be a perfect solution suitable for BU. I created a thread about that here.

 

[jtoomim]

> There should not be a lot of unannounced transactions in a block. Or else a miner would be shooting himself in his foot and IBLT indeed becomes useless. The incentives are there for miners to want it to work.

Unfortunately, selfish mining is a thing, and some pools or miners may want to use block propagation delays to divide the network into SPV-mining groups and non-SPV-mining groups or slow-and-fast groups in order to make their selfish mining attack more effective. Some men just want to watch the slower half of the mining world burn.

The main purpose of the blocksize limit is to protect pools and miners against these types of attacks.

 

[theZerg]

Why is blocksize limit protective given spv mining?

 

[Peter R]

@jtoomim

Do you have math that quantifies this effect? (I've read the selfish mining paper and "The Bitcoin Backbone Protocol" [re. chain quality] but I've never seen anyone convincingly demonstrate with numbers that the advantage significantly increases with a greater block size limit.)

Also, have you read Andrew Stone's paper?

 

[seweso]

Unfortunately, selfish mining is a thing

I thought selfish mining was just a theoretical attack. Are any miners seriously considering such an attack?

 

[jtoomim]

If everyone is using SPV mining, then the scenario changes a little bit, but the net result is mostly the same.

Assume transaction fees are eventually going to be significant. In order to include transactions in a block, you need to first download and second verify the previous block. If you don't, you risk including a double-spend transaction and making your block invalid.

If transaction fees make the difference between profitable and unprofitable mining, then a rational miner will chose to idle their miners during that time. This means that you can effectively deny your enemies the ability to mine by making blocks that are hard for them to download and verify.

In some ways, selfish mining is even more powerful in this scenario, because in between the header arriving and the rest of the block download/verification/CNB finishing, the other miners know of your block and will usually choose not to try to orphan it (which would be expected to cost 100% as much as normal but would earn less than 50% as much).


Note: I personally don't think these selfish mining risks are a big problem. I'm mostly channeling Peter Todd and some of the other developers of Core on this.

Edit/Note2: I'm falling behind on correspondence. This message was supposed to be posted a couple of days ago. Sorry.
[doublepost=1452629321][/doublepost]> I thought selfish mining was just a theoretical attack. Are any miners seriously considering such an attack?

Nobody is doing it intentionally yet as far as I know. Many devs think that fixing it after it happens is too late. Some Core developers believe that Antpool already performed a selfish mining attack accidentally about 10 days ago, probably due to connectivity issues. (Matt mentioned that Patrick mentioned it, or something.)

Matt is also discussing eliminating the Relay Network altogether.

https://bitcointalk.org/index.php?topic=766190.msg13510513#msg13510513

 

[theZerg]

Jtoomim I feel that you just rehashed the non spvmining case. Currently txn fees are .5 to 1.6 pct of revenue and will likely remain small for another decade. I think mining 1 txn blocks is the great equalizer right now and is an important argument to help miners that may have placed their mines in an unfortunate location wrt connectivity choose to allow larger blocks. What do u think about this?

 

[Peter R]

@theZerg; @jtoomim

I was going to make a similar comment regarding the size of fees relevant to the block reward right now. I agree with what jtoomim said, but recognize that that only becomes a potential problem decades from now. The advantage is presently tiny and probably negligible compared to other factors like the cost of electricity or access to high-performance ASICs.

But decades from now, I suspect we'll have techniques like subchains to further ameliorate mining fairness, and with the benefit of hindsight all this will seem like worrying-for-nothing!

 

[jtoomim]

>but recognize that that only becomes a potential problem decades from now.

I expect more like 5 years, actually. (Once the block reward is 6.25 BTC in 2020, mining is going to be very different.)

If demand doubles every year (like it has been), demand will be 32x larger in 5 years. On the other hand, the block reward will be 4x smaller. That means fees/subsidy will be about 128x larger.

Yes, it's an issue for the future, but it's not way far away in forever-land.

There are other problems with SPV mining, of course, like issues with the average blocksize getting dragged down by miners who mine 1-tx blocks. They increase the difficulty but don't include transactions, so they reduce the capacity of the network for a given blocksize limit. They also increase confirmation time variance.

Then there's the risk for BIP66-deployment-style forks.

Not saying that an all-SPV scenario is the worst scenario ever and shouldn't be considered. I'm just saying it has a lot of issues, and the best solution would be if we could transmit large adversarial blocks quickly.
[doublepost=1452652270][/doublepost]I'm afraid I can't give answers to this question that are as good as I'd like because (a) I'm way too busy right now with the Classic launch and (b) these are not my arguments that I'm presenting. I'm probably going to fall off of this thread for a few days. Sorry.

 

[Peter R]

"I expect more like 5 years, actually. (Once the block reward is 6.25 BTC in 2020, mining is going to be very different.)" -- @jtoomim

Could be, but my bet is we don't see total fees ~= block reward till at least the 2030s and probably later, assuming that the block size limit is free to float above demand. [Regardless, techniques like subchains ameliorate the issue with the selfish mining anyways.]

"If demand doubles every year (like it has been), demand will be 32x larger in 5 years. On the other hand, the block reward will be 4x smaller. That means fees/subsidy will be about 128x larger."

Strongly disagree (with the bolded sentence only). The transaction fee market theory that I'm aware of (which includes Houy's paper, to a certain extent Stone's paper, and my paper) would suggest something quite different. To a first-order approximation, the total fees in a block (M) assuming a perfectly competitive market (and no fee pressure from an artificial block size limit) is

M = z (R / T) Q

where z is the propagation/verification impedance (sec / MB), R is the block reward, T is the block time (10 min) and Q is the size of the block.

In your example, Q is 32x larger, but R is 4x smaller. The total fees (M) would then only be 8x larger (or a 32x increase in the ratio). But if we assume (very reasonable) that there's been a 4X reduction in the propagation/verification impedance, then the total fees would only be 2x greater (or a 8x increase in the fee-to-reward ratio).

This is good!

Otherwise the fees per transaction in $ terms would be huge!! A 32x increase in transactions would probably correlate to a price per coin between $12,800 (linear model) and $400,000 (Metcalfe model). If the fee per byte didn't fall, it would mean the real cost of a single transaction would be somewhere between $1.25 and $40!!

However, if the fees/byte measured in BTC fall like I described above, the price per transaction would then be between $0.08 and $2.50. To me, this seems a lot more reasonable for the cost of a transaction in 2020.


"I'm probably going to fall off of this thread for a few days. Sorry."

No need to apologize. I view these threads as sort of half talking to each other, and half speaking into the aether and seeing what comes back. Always love to have you stop by when you get a chance!

 

[Zangelbert Bingledack]

Re: block reward falling

Assuming the BTC price doesn't continue its exponential increase over the next few years makes no sense. If that were to happen, Bitcoin would be dead anyway.

 

[jtoomim]

"If demand doubles every year (like it has been), demand will be 32x larger in 5 years. On the other hand, the block reward will be 4x smaller. That means fees/subsidy will be about 128x larger."

Strongly disagree (with the bolded sentence only). The transaction fee market theory that I'm aware of (which includes Houy's paper, to a certain extent Stone's paper, and my paper) would suggest something quite different.

The problem with these theories is that they assume that the actors are rational. They're not. Humans are lazy.

Transaction market theory predicts that fees should have been zero for most of Bitcoin's history. They haven't been. Fees so far have been determined by the default settings of common bitcoin clients, including bitcoin-qt and Core.

The average transaction fee per kB peaked in 2013 when blocks were around 150 kB in size. Transaction fees dropped again when 0.8.2 was released and dropped the default fee by a factor of 5.

Basically, we have a fee floor due to the fact that people don't care about the cost of a transaction and are too lazy to change the defaults to a theoretically more optimal point. When you have a price floor like this, then the revenue is essentially proportional to transaction volume.

But if we assume (very reasonable) that there's been a 4X reduction in the propagation/verification impedance, then the total fees would only be 2x greater (or a 8x increase in the fee-to-reward ratio).

This is good!

No, it's not good. Bitcoin's future security depends on miners getting paid.

We can't just turn off hashrate and still have Bitcoin be secure. Bitcoin's security proposition depends on the capital cost of acquiring miners being large (currently about $200 per TH/s) relative to the benefit of performing double-spends or other attacks. If more than about 50% of the network hashrate goes offline due to unprofitability, then we have a problem. That mining hardware won't just disappear. It will probably stay plugged in but not active. Eventually, someone will come along and say, "Hey, I'll pay you 1.2x as much as you'd normally earn if you turn those miners on and mine into my special pool for 4 hours!" Using current prices, that might cost $0.38 per TH/s. This means that you've suddenly dropped the cost of performing an attack by a factor of 500.

If we want Bitcoin to not die in 2020, we need to either get the price to increase a bunch right when the halving occurs (+/- 3 months, the time it will take to equilibrate with new hardware), or we need to get transaction fees to be a substantial portion of total miner revenue.

Mining currently costs about $3000 per block in electricity. The sooner we can start paying that amount with transaction fees, the safer Bitcoin will be.

A 32x increase in transactions would probably correlate to a price per coin between $12,800 (linear model) and $400,000 (Metcalfe model).

I prefer to not assume increases in the exchange rate when reasoning about mining revenue. Everything gets easier if the exchange rate rises and the subsidy is larger in real terms, so I think it's more interesting to think of what could go wrong if it stays flat or goes down. Plan for the worst.

However, if the fees/byte measured in BTC fall like I described above, the price per transaction would then be between $0.08 and $2.50. To me, this seems a lot more reasonable for the cost of a transaction in 2020.

The default fees generally are set in real terms. That means that the real fees should be more predictable on a long time scale than the subsidy is.