On Wed, Sep 23, 2015 at 4:07 PM, Bryan Bishop via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > more recently: > http://gnusha.org/bitcoin-wizards/2015-09-20.log > http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/ > http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/
See also my response to Peter R's paper that was republished to the list at http://pastebin.com/jFgkk8M3 (See sections at "For example, imagine if miners only include transactions that were previously committed" and especially "Miners volutarily participate in a fast consensus mechenism which commits to transactions") On Wed, Sep 23, 2015 at 3:43 PM, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > Imagine miners always pre-announce the blocks they're working on to their > peers, and peers validate those 'weak blocks' as quickly as they are able. > > Because weak blocks are pre-validated, when a full-difficulty block based on > a previously announced weak block is found, block propagation should be > insanely fast-- [...] > A miner could try to avoid validation work by just taking a weak block > announced by somebody else, replacing the coinbase and re-computing the > merkle root, and then mining. They will be at a slight disadvantage to fully Take care, here-- if a scheme is used where e.g. the full solution had to be exactly identical to a prior weak block then the result would be making mining not progress free because bigger miners would have disproportionately more access to the weak/strong one/two punch. I think what you're thinking here is okay, but it wasn't clear to me if you'd caught that particular potential issue. Avoiding this is why I've always previously described this idea as merged mined block DAG (with blocks of arbitrary strength) which are always efficiently deferentially coded against prior state. A new solution (regardless of who creates it) can still be efficiently transmitted even if it differs in arbitrary ways (though the efficiency is less the more different it is). There is a cost to these schemes-- additional overhead from communicating the efficiently encoded weak blocks. But participation in this overhead is optional and doesn't impact the history. I'm unsure of what approach to take for incentive compatibility analysis. In the worst case this approach class has no better delays (and higher bandwidth); but it doesn't seem to me to give rise to any immediate incrementally strategic behavior (or at least none worse than you'd get from just privately using the same scheme). On Wed, Sep 23, 2015 at 4:28 PM, Peter R via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > Shouldn't mining pools and miners be paying you guys for coding solutions > that improve their profitability? The income to miners as a whole doesn't depend on these sorts of optimizations, competitive advantages do... so better common open infrastructure helps mostly in the case of putting propagation disadvantaged miners on an equal playing field. You'll note that none of them are exactly sharing their SPV mining source code right now.... in any case, there are simple, expedient, and low risk ways to improve their equality in that respect: centralize (e.g. use bigger pools). _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
