On Wed, Nov 21, 2018 at 12:07:30PM -0500, Russell O'Connor via bitcoin-dev
wrote:
> Given that we want to move away from OP_CODESEPARATOR, because each call to
> this operation effectively takes O(script-size) time, we need a replacement
> for
> the functionality it currently provides. While per
On Thu, Nov 22, 2018 at 3:53 PM Johnson Lau wrote:
> Assuming a script size of 128 bytes (including SHA256 padding), 2^20
> scripts is 134MB. Double it to 268MB for the merkle branch hashes. With
> roughly 100MB/s, this should take 2.5s (or 42min for 30 levels). However,
> memory use is not consi
Assuming a script size of 128 bytes (including SHA256 padding), 2^20 scripts is
134MB. Double it to 268MB for the merkle branch hashes. With roughly 100MB/s,
this should take 2.5s (or 42min for 30 levels). However, memory use is not
considered.
>each call to this operation effectively takes O(s
Hi Everyone,
Thank you very much in this thanks giving day for the detailed and well
thought out responses. :)
Steven Hatzakis via bitcoin-dev https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>:
>* *Option 2*: Perhaps a revision is needed to how the BIP39 seed is
*>* generated in t
I see, so your suggestion is that a sequence of OP_IF ... OP_ENDIF can be
replaced by a Merklized Script tree of that depth in practice.
I'm concerned that at script creation time it takes exponential time to
complete a Merkle root of depth 'n'. Can anyone provide benchmarks or
estimates of how l
With MAST in taproot, OP_IF etc become mostly redundant, with worse privacy. To
maximise fungibility, we should encourage people to use MAST, instead of
improve the functionality of OP_IF and further complicate the protocol.
> On 22 Nov 2018, at 1:07 AM, Russell O'Connor via bitcoin-dev
> wro
