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
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).
Although
On Sun, May 25, 2014 at 2:36 AM, Mike Hearn m...@plan99.net 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
On Sat, May 24, 2014 at 5:57 AM, Ashley Holman dsc...@gmail.com 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
On Fri, May 23, 2014 at 8:57 PM, Ashley Holman dsc...@gmail.com 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
On Sun, May 25, 2014 at 8:29 AM, Bernd Jendrissek bitc...@bpj-code.co.za
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
On 05/24/2014 07:41 PM, Ashley Holman wrote:
On Sun, May 25, 2014 at 8:29 AM, Bernd
Jendrissek bitc...@bpj-code.co.za
mailto:bitc...@bpj-code.co.za wrote:
The difference is that with cut-through forwarding of blocks, a
sufficiently motivated attacker (being willing to blow 25BTC's
On Sat, May 24, 2014 at 5:04 PM, Alan Reiner etothe...@gmail.com 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
On 05/24/2014 08:14 PM, Gregory Maxwell wrote:
On Sat, May 24, 2014 at 5:04 PM, Alan Reiner etothe...@gmail.com 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
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
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
On Sat, May 24, 2014 at 1:27 PM, Ashley Holman dsc...@gmail.com 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
12 matches
Mail list logo
