Wladimir [ARCHIVE] on Nostr: 📅 Original date posted:2014-07-19 📝 Original message:On Fri, Jul 18, 2014 at ...
📅 Original date posted:2014-07-19
📝 Original message:On Fri, Jul 18, 2014 at 4:53 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> Two more half-baked thoughts:
>
> We should be able to assume that the majority of transaction data (except
> for coinbase) has already been propagated. As Jeff said, incentivizing nodes
> to propagate transactions is a very good thing (the signature cache already
> gives a small incentive to miners to propagate and not 'hoard'
> transactions).
Maybe a stupid idea - but couldn't we make that assumption a surety by
starting the 'set synchronization process' as soon as the miner starts
crunching on a certain block, instead of when it broadcasts it? So the
peers are prepared, and the actual block broadcast is just the header
+ coinbase tx.
Wladimir
📝 Original message:On Fri, Jul 18, 2014 at 4:53 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> Two more half-baked thoughts:
>
> We should be able to assume that the majority of transaction data (except
> for coinbase) has already been propagated. As Jeff said, incentivizing nodes
> to propagate transactions is a very good thing (the signature cache already
> gives a small incentive to miners to propagate and not 'hoard'
> transactions).
Maybe a stupid idea - but couldn't we make that assumption a surety by
starting the 'set synchronization process' as soon as the miner starts
crunching on a certain block, instead of when it broadcasts it? So the
peers are prepared, and the actual block broadcast is just the header
+ coinbase tx.
Wladimir