Last week I attended Scaling Bitcoin in Hong Kong. I will try to summarize my main takeaways from that.

Segregated witness

The talk that caused most buzz was Pieter Wuille on segregated witness. This is a really interesting idea that's actually implemented (sort of) into bitcoin core. It's moving the sigScript (basically the signatures) out of the actual transaction data and makes it more like an attachment when sending transactions over the network. I still have some catching up to do here, but this has a few important implications, as I understood it (please correct me where I'm wrong by commenting at the bottom of this page):

1. It fixes most malleability issues, because the txid is not including signature data anymore. Most malleability attacks are due to tampering with signatures in some non-destructive way.
2. Sending transaction data to non-validating node does not have to include signature data. Roughly 60% bandwidth savings on those links.
3. The signature data does not go into a block, but the block will commit to the signatures by including them in a merkle tree. The root of the tree is proposed to go into the coinbase of the block. This makes it possible to deploy as a soft fork. 60% storage savings.
4. Initial block download will improve significantly because blocks don't contain signatures anymore. This is actually a combo of 2 and 3, but it needs to be emphasized in it's own bullet I think.
5. This enables simpler fraud proofs for invalid output amount in coinbases and for spending of non-existent output. Need to learn more here...

See Pieter's talk on segregated witness

IBLT and weak blocks

This is of course my baby, well, at least the IBLT part. For details on IBLT I suggest reading part I-V of my IBLT series on this blog. The results presented in this talk are:

1. Using IBLT can decrease total block data sent from 825 MB to 20 MB in today's network. That's a whopping 2.4%. Also, that percentage is projected to improve further as transaction rate grows.
2. Using weak blocks we can decrease the stong block total data sent to 35 MB. However, the overall total data sent will about double but we will offload the critical time when a block is found by distributing the bandwidth more evenly in time.
3. By combining IBLT and weak blocks we can squeeze it further down to 15 MB for the strong blocks (with overall total data sent of 233MB).

See my and Rusty Russell's talk on IBLT and weak blocks.

Blinding attacks

Here's an interesting talk by Arthur Gervais. He demostates how double spending attacks can be made more reliably by blinding the victim from the double spend transactions. He also shows how to delay block propagation by using similar blinding techniques. It's based on the way Bitcoin Core handles timeouts. For transactions it's simple: Be first to send an inv to the victim, and then don't send the tx when requested. The victim will timeout after 2 minutes. Also instead of sending just a single inv to the victim, sending multiple inv messages for the tx will cause the victim to retry fetching of that tx from your evil node multiple times. This means you can hide a tx from a node an arbitrary time.

For blocks, it's a bit of more work. First of all, you need to be the first one sending an inv to the victim, after which the victim will ask you for the block header. You will not send it, so the victim will wait for 20 (!) minutes. This delay time can be extended by also being the first to announce the next block, causing the victim to request the next block from you, which you won't send. Second, you must make sure that the victim cannot create new connections. Otherwise he will detect that there are new blocks out there due to headers first synchronization when exchanging the version messages with the chain tip with each other. If he detects a tip higher than its own he will start requesting it from other peers.

Gervais proposes a few things to mitigate this:

1. That a dynamic timeout based on data size, network bandwidth, latency etc.
2. That a node requests data from a random peer that has sent an inv. Not necessarily the first inv-sender.
3. Instead of traditional inv, send the actual block header unsolicited. So that the peer can request the block data from any peer. As stated above, giving the block header to the victim will make the attack fail.

I don't understand why 3 is needed if 2 is implemented?

See the talk: Tampering with the delivery of blocks and transactions in Bitcoin.

Comic relief

Last but not least, a bad-ass Bitcoin powered anti-spam system that failed miserably. Ladies and gentlemen, I give you Elephant Grass