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
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
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
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
>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
