Good morning list,
> It was pointed out to me that this discussion is largely moot as the software
> complexity for Bitcoin Core to ship an
> option like this is likely not practical/what people would wish to see.
>
> Bitcoin Core does not have infrastructure to handle switching consensus rules
On Fri, Feb 19, 2021 at 5:31 PM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> (off-list)
>
> Your email client didn't thread correctly, so I'm not sure if you saw my
> responses to Adam's email, but note that there
That was not off-list; by the way, as a reminder
(off-list)
Your email client didn't thread correctly, so I'm not sure if you saw my responses to Adam's email, but note that there
is no such thing as "All that must be done" here - supporting multiple, different, consensus rules for a given chain is
a nontrivial undertaking in Bitcoin Core fro
Good day all, this is my first post to this mailing list. Per Adam's
comment below:
> given there are clearly people of both views, or for now don't care
but might later, it would minimally be friendly and useful if
bitcoin-core has a LOT=true option - and that IMO goes some way to
avoid the assum
It was pointed out to me that this discussion is largely moot as the software complexity for Bitcoin Core to ship an
option like this is likely not practical/what people would wish to see.
Bitcoin Core does not have infrastructure to handle switching consensus rules with the same datadir - after
(Also in response to ZMN...)
Bitcoin Core has a long-standing policy of not shipping options which shoot
yourself in the foot. I’d be very disappointed if that changed now. People are
of course more than welcome to run such software themselves, but I anticipate
the loud minority on Twitter and
Hi Thomas,
I am working on an experimental implementation [1] of a new payment request
format in Trezor T. In some respects it's similar to BIP-70. The main
differences are:
1. There is no reliance on X.509, since that seems to have been the main
reason for BIP-70's downfall. The signature is man
Personally I don't really have much of a view and think either
LOT=true or false is better in the context, they both seem safe given
the current context, where basically everyone is saying "are we there
yet", including pools (88.7% going out of their way to say YES
https://taprootactivation.com).
Hi Michael
I think you're right, sorry for getting a little apocalyptic at the
end there lol.
> On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev
>
> Thanks for your response Ariel. It would be useful if you responded to
> specific points I have made in the mailing list post or at
Hi, Thomas,
I developed a URL signing scheme for use with LNURL as a method for
authorizing payments on behalf of offline devices /applications. It's
not specifically off-chain or on-chain related, but could be repurposed.
The gist of the scheme is as follows:
Before any signing is done:
0)
Good morning list,
> This is absolutely the case, however note that the activation method itself
> is consensus code which executes as a part
> of a fork, and one which deserves as much scrutiny as anything else. While
> taproot is a model of how a soft-fork should
> be designed, this doesn't im
I never liked BIP70. It was too complex, had too many features, and when
people discuss it, they do not even agree on what the main feature was.
Nevertheless, there is ONE feature of BIP70 that I find useful: the fact
that payment requests were signed. I am making this post to discuss this.
When
12 matches
Mail list logo
