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
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 distra
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
There is a relevant post from Satoshi on this:
https://bitcointalk.org/index.php?topic=191.msg1585#msg1585
Quote:
"If SHA-256 became completely broken, I think we could come to some
agreement about what the honest block chain was before the trouble started,
lock that in and continue from there w
Economic policy sounds like a dirty word in the context of Bitcoin, but as
Jeff Garzik said, choosing a block size cap is unfortunately an economic
policy that has to be chosen somehow. Enabling users to incentivise the
voting process is an interesting tool to have in the toolbox, but I think
it w
On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd wrote:
>
> That is mistaken: you can't mine on top of just a block header, leaving
> small miners disadvantaged as they are earning no profit while they wait
> for the information to validate the block and update their UTXO sets. This
> results in the sa
6 matches
Mail list logo
