From: Jannes Faber <jannes.faber@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness features wish list
Date: Sat, 12 Dec 2015 01:43:11 +0100 [thread overview]
Message-ID: <CABeL=0hzQeOPcVgRcdM6Q_hqTNevHBOs7d2HMd6yh0o5Du9yAw@mail.gmail.com> (raw)
In-Reply-To: <7D7416E3-0038-484D-BBA9-35FA4C2AE3DC@bitsofproof.com>
[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]
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@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2534 bytes --]
next prev parent reply other threads:[~2015-12-12 0:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 6:47 jl2012
2015-12-10 8:26 ` Gregory Maxwell
2015-12-10 8:28 ` Bryan Bishop
2015-12-10 9:51 ` Gregory Maxwell
2015-12-13 15:25 ` jl2012
2015-12-13 18:07 ` Pieter Wuille
2015-12-13 18:41 ` jl2012
2015-12-10 12:54 ` Tamas Blummer
2015-12-12 0:43 ` Jannes Faber [this message]
2015-12-13 20:34 ` Rusty Russell
2015-12-14 11:44 ` Jonathan Toomim
2015-12-14 12:32 Adam Back
2015-12-14 12:50 ` Jonathan Toomim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABeL=0hzQeOPcVgRcdM6Q_hqTNevHBOs7d2HMd6yh0o5Du9yAw@mail.gmail.com' \
--to=jannes.faber@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox