Clients "inspecting and modifying the transactions" is explicitly *not*
supported. There should be more than enough features for clients to get
bitcoind to generate the exact block they want already available via
Bitcoin Core. The only reason transactions are exposed over the work
protocol at all,
On Wed, Jun 6, 2018 at 5:48 AM, Tim Ruffing via bitcoin-dev
wrote:
> On Thu, 2018-05-31 at 17:25 -0700, Pieter Wuille via bitcoin-dev wrote:
>> The best argument for why Graftroot does not need to be optional I
>> think was how Greg put it: "since the signer(s) could have signed an
>> arbitrary
Sorry if I continue on the subject even if
custom filter types are considered in BIP 157/158
.
I am doing it
because
:
1)
with a fixed target FP=2^-20 (or 1/784931)
and the multi layer filtering maybe it's reasonable to consider less than
~20 bits for the golomb encoding of the per-block
I haven't read the original Graftroot thread, so maybe all of this has
b
een discussed already or is just wrong... Please correct me if this
is
the case.
On Thu, 2018-05-31 at 17:25 -0700, Pieter Wuille via bitcoin-dev wrote:
> The best argument for why Graftroot does not need to be optional I
>
