Re: [Bitcoin-development] Cut-through propagation of blocks

> > it: I'd be much more likely to run an experimental gateway in another > process on a node than experimental p2p code inside my production > bitcoinds themselves. > Yes, it's certainly better to do that during the development phase. However if it does turn out to be good and valuable then it'd

Re: [Bitcoin-development] Cut-through propagation of blocks

On Sun, May 25, 2014 at 2:36 AM, Mike Hearn wrote: > Although this is a somewhat appealing notion, would it really improve > feature velocity? I don't think the current p2p protocol is holding anything > back, and having to implement features twice in two protocols would slow > things down quite a

Re: [Bitcoin-development] Cut-through propagation of blocks

> > There > is no need to have Bitcoin transport all using a single protocol, and > we can get better robustness and feature velocity if there are a > couple protocols in use (you could just run a block-transport-protocol > daemon that connects to your local node via the classic protocol). Althou

Re: [Bitcoin-development] Cut-through propagation of blocks

I have done some work on incentives arising from block propagation times and it turns out that Bitcoin is already quite good at establishing the primacy of blocks by time despite what people think. Part of the reason for this is the way that partitions on the network evolve as a block is propaga

Re: [Bitcoin-development] Cut-through propagation of blocks

On 05/24/2014 08:14 PM, Gregory Maxwell wrote: > On Sat, May 24, 2014 at 5:04 PM, Alan Reiner wrote: >> I think the most important change is modifying the way Bitcoin Core >> prioritizes blocks. Right now it uses the first full block verified. >> Instead, it should consider the first valid header

Re: [Bitcoin-development] Cut-through propagation of blocks

On Sat, May 24, 2014 at 5:04 PM, Alan Reiner wrote: > I think the most important change is modifying the way Bitcoin Core > prioritizes blocks. Right now it uses the first full block verified. > Instead, it should consider the first valid header received as highest > priority, but only mine on it

Re: [Bitcoin-development] Cut-through propagation of blocks

On 05/24/2014 07:41 PM, Ashley Holman wrote: > On Sun, May 25, 2014 at 8:29 AM, Bernd > Jendrissek > wrote: > > The difference is that with cut-through forwarding of blocks, a > sufficiently motivated attacker (being willing to blow 25BTC's worth > of ele

Re: [Bitcoin-development] Cut-through propagation of blocks

On Sun, May 25, 2014 at 8:29 AM, Bernd Jendrissek wrote: > > The difference is that with cut-through forwarding of blocks, a > sufficiently motivated attacker (being willing to blow 25BTC's worth > of electricity on the effort) can subjugate the entire Bitcoin network > to its DoS attack, rather

Re: [Bitcoin-development] Cut-through propagation of blocks

On Fri, May 23, 2014 at 8:57 PM, Ashley Holman wrote: > Hi, > On this list there has been some discussion around techniques to speed up > block propagation, with a particular focus on reducing the extra orphan risk > carried by larger blocks. > The current store-and-forward method means that large

Re: [Bitcoin-development] Cut-through propagation of blocks

On Sat, May 24, 2014 at 5:57 AM, Ashley Holman wrote: > * As far as I can tell, this shouldn't change any game theory or incentives > because nodes still receive blocks exactly as they do now, just sooner. The > difference is, invalid blocks that meet the PoW will be broadcast to > everyone, but

Re: [Bitcoin-development] Cut-through propagation of blocks

On Sat, May 24, 2014 at 1:27 PM, Ashley Holman wrote: > > * Skip the inv/getdata sequence for new blocks - just push them out > directly to save 1 roundtrip per hop > Upon further reflection, I remove this from my proposal. It's an unrelated optimisation that probably distracts from the main poi

[Bitcoin-development] Cut-through propagation of blocks

Hi, On this list there has been some discussion around techniques to speed up block propagation, with a particular focus on reducing the extra orphan risk carried by larger blocks. The current store-and-forward method means that larger blocks will propagate with higher latency. One proposed solu