>Under this point-of-view, then, extension block is "not" soft fork.
>It is "evil" soft fork since older nodes are forced to upgrade as their
>intended functionality becomes impossible.
>In this point-of-view, it is no better than a hard fork, which at least is
>very noisy about how older fullnod
Hello all,
This might be another proto-BIP similar to the post about using a card
shuffle as a wallet seed that was posted here a few weeks back:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-February/016645.html
This is an idea I had to deriving a wallet seed from the lucky number
take-out the other day. :)
On Tue, Mar 5, 2019 at 8:06 PM James MacWhyte wrote:
>
> On Tue, Mar 5, 2019 at 4:39 PM Trey Del Bonis via bitcoin-dev
> wrote:
>>
>> Keeping 20 around is a little excessive but it gives 390700800 possible
>> wallets. So security can be t
Part of the aversion to using bech32 may be that the BCH code used in
bech32 for error detection doesn't hold up for messages longer than some
length (that I can't remember off the top of my head). It still encodes
and decodes perfectly well but a decoder won't be guaranteed to detect
potential er
Hi all, I figured I could answer some of these rollup questions,
There's a few different possibilities to make rollups work that have
different tradeoffs. The core construction I worked out in [1] involves
a quine-ish recursive covenant that stores some persistent "state" as
part of the beginning
