Last week I attended Scaling Bitcoin in Hong Kong. I will try to summarize my main takeaways from that.
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):
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:
See my and Rusty Russell's talk on IBLT and weak blocks.
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:
I don't understand why 3 is needed if 2 is implemented?
Last but not least, a bad-ass Bitcoin powered anti-spam system that failed miserably. Ladies and gentlemen, I give you Elephant Grass