Tier Nolan [ARCHIVE] on Nostr: š Original date posted:2015-09-23 š Original message:On Wed, Sep 23, 2015 at ...
š
Original date posted:2015-09-23
š Original message:On Wed, Sep 23, 2015 at 4:43 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at 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-- basically, as fast as a single packet can be relayed across
> the network the whole network could be mining on the new block.
>
> I don't see any barrier to making accepting the full-difficulty block and
> CreateNewBlock() insanely fast, and if those operations take just a
> microsecond or three, miners will have an incentive to create blocks with
> fee-paying transactions that weren't in the last block, rather than mining
> empty blocks.
>
You can create these blocks in advance too.
- receive weak block
- validate
- create child block
It becomes a pure array lookup to get the new header that builds on top of
that block. The child blocks would need to be updated as the memory pool
changes though.
> 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 validating miners, though, because they WOULD have to mine empty
> blocks between the time a full block is found and a fully-validating miner
> announced their next weak block.
>
This also speeds up propagation for the miner. The first weak block that
is broadcast could end up being copied by many other miners.
A miner who is copying a block could send coinbase + original header if he
hits a block. Weak blocks that are just coinbase + header could have lower
POW requirements, since they use up much less bandwidth.
Miners would mostly copy other miners once they had verified their blocks.
The IBLT system works well here. A miner could pick a weak block that is
close to what it actually wants to broadcast.
> Weak block announcements are great for the network; they give transaction
> creators a pretty good idea of whether or not their transactions are likely
> to be confirmed in the next block.
>
Aggregator nodes could offer a service to show/prove how many weak blocks
that the transaction has been accepted in.
> And if we're smart about implementing them, they shouldn't increase
> bandwidth or CPU usage significantly, because all the weak blocks at a
> given point in time are likely to contain the same transactions.
>
This assumes other compression systems for handling block propagation.
>
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150923/3004f4bf/attachment.html>;
š Original message:On Wed, Sep 23, 2015 at 4:43 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at 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-- basically, as fast as a single packet can be relayed across
> the network the whole network could be mining on the new block.
>
> I don't see any barrier to making accepting the full-difficulty block and
> CreateNewBlock() insanely fast, and if those operations take just a
> microsecond or three, miners will have an incentive to create blocks with
> fee-paying transactions that weren't in the last block, rather than mining
> empty blocks.
>
You can create these blocks in advance too.
- receive weak block
- validate
- create child block
It becomes a pure array lookup to get the new header that builds on top of
that block. The child blocks would need to be updated as the memory pool
changes though.
> 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 validating miners, though, because they WOULD have to mine empty
> blocks between the time a full block is found and a fully-validating miner
> announced their next weak block.
>
This also speeds up propagation for the miner. The first weak block that
is broadcast could end up being copied by many other miners.
A miner who is copying a block could send coinbase + original header if he
hits a block. Weak blocks that are just coinbase + header could have lower
POW requirements, since they use up much less bandwidth.
Miners would mostly copy other miners once they had verified their blocks.
The IBLT system works well here. A miner could pick a weak block that is
close to what it actually wants to broadcast.
> Weak block announcements are great for the network; they give transaction
> creators a pretty good idea of whether or not their transactions are likely
> to be confirmed in the next block.
>
Aggregator nodes could offer a service to show/prove how many weak blocks
that the transaction has been accepted in.
> And if we're smart about implementing them, they shouldn't increase
> bandwidth or CPU usage significantly, because all the weak blocks at a
> given point in time are likely to contain the same transactions.
>
This assumes other compression systems for handling block propagation.
>
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150923/3004f4bf/attachment.html>;