š
Original date posted:2015-09-23
š Original message:On Sep 23, 2015, at 2:37 PM, Gavin Andresen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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.
>
> I'm assuming the optimized protocol would be forward-error-coded (e.g. using IBLTs) and NOT require the full solution (or follow-on weak blocks) to be exactly the same.
>
One possible improvement on this is to cache Merkle nodes/subtrees. When a weak block is created, nodes could cache the hashes for the Merkle nodes along with each node's children. A miner could then describe their block in terms of Merkle nodes (describing groups of 2^n transactions), which would give them the ability to copy e.g. 87.5% or 96.875% or whatever of their new block from someone else's weak block but with a few modifications (e.g. new transactions) in the remaining non-prespecified portion. This gives small miners the ability to trade off versatility (do I specify all of the transactions with my own Merkle structure?) versus propagation speed (do I copy all of my Merkle tree from another miner's weak block?) with all steps in between.
I've got a proposal for a block propagation protocol inspired by bittorrent applied to the Merkle tree instead of chunks of a file. Weak blocks would fit in with this blocktorrent protocol quite nicely by caching and pre-transmitting Merkle nodes. I don't want to hijack this thread, so I'll post it under a separate subject in an hour or so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150923/3edaab92/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150923/3edaab92/attachment.sig>;
Jonathan Toomim (Toomim Bros) [ARCHIVE] /
npub156ā¦9r5gn
2023-06-07 17:41:06
in reply to nevent1qā¦8eh6
Author Public Key
npub156vplpc5zjxk79ttdc320xhwq385tchgryp90hyzna9pju8yhn8s69r5gnPublished at
2023-06-07 17:41:06Event JSON
{
"id": "9db51f5b351841cf3e6badaaf1dd248ee07fe53c9559d7aae4349553f8b49a7e",
"pubkey": "a6981f8714148d6f156b6e22a79aee044f45e2e8190257dc829f4a1970e4bccf",
"created_at": 1686159666,
"kind": 1,
"tags": [
[
"e",
"47e992d8066a798c3fec58fb87e76f9362fea651b87542b83f6a85adc1e96982",
"",
"root"
],
[
"e",
"544dfe499bb337718c8f047c816042ce488ac493fab74d753291f12e495b8dbd",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "š
Original date posted:2015-09-23\nš Original message:On Sep 23, 2015, at 2:37 PM, Gavin Andresen via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Take care, here-- if a scheme is used where e.g. the full solution had\n\u003e to be exactly identical to a prior weak block then the result would be\n\u003e making mining not progress free because bigger miners would have\n\u003e disproportionately more access to the weak/strong one/two punch. I\n\u003e think what you're thinking here is okay, but it wasn't clear to me if\n\u003e you'd caught that particular potential issue.\n\u003e \n\u003e I'm assuming the optimized protocol would be forward-error-coded (e.g. using IBLTs) and NOT require the full solution (or follow-on weak blocks) to be exactly the same.\n\u003e \n\nOne possible improvement on this is to cache Merkle nodes/subtrees. When a weak block is created, nodes could cache the hashes for the Merkle nodes along with each node's children. A miner could then describe their block in terms of Merkle nodes (describing groups of 2^n transactions), which would give them the ability to copy e.g. 87.5% or 96.875% or whatever of their new block from someone else's weak block but with a few modifications (e.g. new transactions) in the remaining non-prespecified portion. This gives small miners the ability to trade off versatility (do I specify all of the transactions with my own Merkle structure?) versus propagation speed (do I copy all of my Merkle tree from another miner's weak block?) with all steps in between.\n\nI've got a proposal for a block propagation protocol inspired by bittorrent applied to the Merkle tree instead of chunks of a file. Weak blocks would fit in with this blocktorrent protocol quite nicely by caching and pre-transmitting Merkle nodes. I don't want to hijack this thread, so I'll post it under a separate subject in an hour or so.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150923/3edaab92/attachment.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150923/3edaab92/attachment.sig\u003e",
"sig": "22f7c63fb79b2fca740dd63b7981db73ba6addd052c275cdfc82b3798f6d7254ea560ef8458a19cb8b33e7be6b46c33d95185dc26c1a9b88e2dd37ca7519bc0f"
}