Tier Nolan [ARCHIVE] on Nostr: š Original date posted:2015-05-29 š Original message:On Fri, May 29, 2015 at ...
š
Original date posted:2015-05-29
š Original message:On Fri, May 29, 2015 at 12:26 PM, Mike Hearn <mike at plan99.net> wrote:
> IMO it's not even clear there needs to be a size limit at all. Currently
> the 32mb message cap imposes one anyway
>
If the plan is a fix once and for all, then that should be changed too. It
could be set so that it is at least some multiple of the max block size
allowed.
Alternatively, the merkle block message already incorporates the required
functionality.
Send
- headers message (with 1 header)
- merkleblock messages (max 1MB per message)
The transactions for each merkleblock could be sent directly before each
merkleblock, as is currently the case.
That system can send a block of any size. It would require a change to the
processing of any merkleblocks received.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/21895008/attachment.html>
š Original message:On Fri, May 29, 2015 at 12:26 PM, Mike Hearn <mike at plan99.net> wrote:
> IMO it's not even clear there needs to be a size limit at all. Currently
> the 32mb message cap imposes one anyway
>
If the plan is a fix once and for all, then that should be changed too. It
could be set so that it is at least some multiple of the max block size
allowed.
Alternatively, the merkle block message already incorporates the required
functionality.
Send
- headers message (with 1 header)
- merkleblock messages (max 1MB per message)
The transactions for each merkleblock could be sent directly before each
merkleblock, as is currently the case.
That system can send a block of any size. It would require a change to the
processing of any merkleblocks received.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/21895008/attachment.html>