📅 Original date posted:2015-12-11
📝 Original message:Segregated IBLT
I was just wondering if it would make sense when we have SW to also make
Segregated IBLT? Segregating transactions from signatures and then tune the
parameters such that transactions have a slightly higher guarantee and save
a bit of space on the signatures side.
IBLT should of course, most of the time, convey all transactions _and_ all
signatures. However, in suboptimal situations, at least the receiving miner
will be more likely to have all the transactions, just possibly not all the
signatures.
Assuming the miner was already planning on SPV mining anyway, at least now
she knows which transactions to remove from her mempool, taking away an
excuse to mine an empty block. And she can still verify most of the
signatures too (whatever % could be recovered from the IBLT).
I guess this does not improve the worst adversarial case for IBLT block
propagation, but it should improve the effectiveness in cases where the
"normal" IBLT would fail to deliver all transactions. Transactions without
signatures is better than no transactions at all, for a miner that's eager
to start on the next block, right? In "optimal" cases it would reduce the
size of the IBLT.
Sorry if this was already suggested.
--
Jannes
On 10 December 2015 at 13:54, Tamas Blummer via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Note that the unused space in coin base input script allows us to
> soft-fork an additional SW Merkle tree root into the design,
> therefore please make sure the new SW data structure also has a new slot
> for future extension.
>
> Tamas Blummer
>
> _______________________________________________
> 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/20151212/80703517/attachment.html>;
Jannes Faber [ARCHIVE] /
npub17p…dwqxx
2023-06-07 17:46:10
in reply to nevent1q…usa0
Author Public Key
npub17ptfn7hft8a4s25t6449tdsnht7krskz8xsqh302vma0pjm6925qcdwqxxPublished at
2023-06-07 17:46:10Event JSON
{
"id": "d83ee2796bef2115040cb6e9d87dfe9389f5cc59e0d42236842b2d2266f14a3c",
"pubkey": "f05699fae959fb582a8bd56a55b613bafd61c2c239a00bc5ea66faf0cb7a2aa8",
"created_at": 1686159970,
"kind": 1,
"tags": [
[
"e",
"12a84dc161497f5ec3fbb3e9fb726708fb1bb0268a8834c07e1f631c1bbca295",
"",
"root"
],
[
"e",
"ee2ac4d8b165203aaead038ee00fc13b537d2af8b40cbc40efd326ab8c6416d1",
"",
"reply"
],
[
"p",
"c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7"
]
],
"content": "📅 Original date posted:2015-12-11\n📝 Original message:Segregated IBLT\n\nI was just wondering if it would make sense when we have SW to also make\nSegregated IBLT? Segregating transactions from signatures and then tune the\nparameters such that transactions have a slightly higher guarantee and save\na bit of space on the signatures side.\n\nIBLT should of course, most of the time, convey all transactions _and_ all\nsignatures. However, in suboptimal situations, at least the receiving miner\nwill be more likely to have all the transactions, just possibly not all the\nsignatures.\n\nAssuming the miner was already planning on SPV mining anyway, at least now\nshe knows which transactions to remove from her mempool, taking away an\nexcuse to mine an empty block. And she can still verify most of the\nsignatures too (whatever % could be recovered from the IBLT).\n\nI guess this does not improve the worst adversarial case for IBLT block\npropagation, but it should improve the effectiveness in cases where the\n\"normal\" IBLT would fail to deliver all transactions. Transactions without\nsignatures is better than no transactions at all, for a miner that's eager\nto start on the next block, right? In \"optimal\" cases it would reduce the\nsize of the IBLT.\n\nSorry if this was already suggested.\n\n\n--\nJannes\n\nOn 10 December 2015 at 13:54, Tamas Blummer via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Note that the unused space in coin base input script allows us to\n\u003e soft-fork an additional SW Merkle tree root into the design,\n\u003e therefore please make sure the new SW data structure also has a new slot\n\u003e for future extension.\n\u003e\n\u003e Tamas Blummer\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151212/80703517/attachment.html\u003e",
"sig": "ec32843f82c7dbc3690fce6b80d9b2bef50a55eab366dd951add53cdc65926ffd32d91b5208786e6e5201d04dfc7169a1486a97f5901ec999803007112c5381f"
}