On Friday 05 August 2022 04:05:56 Ali Sherief wrote:
> Yeah, I have a specific reason to advance this first (emphasis on the word
> first).
>
> I briefly mentioned in the BIP that BIP322 has superior message
> verification capabilities. This is true, but it suffers from the drawback
> that wallets
Thanks for this Luke.
> Since BIP125 is widely implemented, it should not be changed except for
> corrections to things which are errors deviating from the original intent.
In this example the BIP125/RBF rules implemented in Core are (and always have
been) different to the rules as described in
Policy is a subjective per-node, not systemic, not enforcable or expectable,
and generally not eligible for standardization.
The reason BIP125 is an exception, is because it is more than just policy.
It is a way for wallets and nodes to communicate. The wallet is saying "this
is the policy I wou
Thanks for doing this, it looks great Ali!
COLDCARD and other Coinkite products will conform to this spec, if we don't
already.
On Thu, Aug 04, 2022 at 12:18:56PM +, Ali Sherief wrote:
> Hi,
>
> I have created a new BIP, called notatether-signedmessage. It can be viewed
> at
> https://git
My sincere apologies, the link returns a 404 (trailing dot). The correct link
to the BIP is
https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmessage.mediawiki
-Ali
--- Original Message ---
On Thursday, August 4th, 2022 at 3:18 PM, Ali Sherief
wrote:
> Hi,
>
> I h
Hi,
I have created a new BIP, called notatether-signedmessage. It can be viewed at
https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmessage.mediawiki.
For those who want a quick summary, it defines a step-by-step process for
signing and verifying messages from legacy, native
A short history of RBF and BIP125
The history of BIP125 is as far as I’m aware this. RBF rules were merged into
Bitcoin Core in November 2015 [0]. Following that merge David Harding and Peter
Todd drafted a BIP (BIP125 [1]) outlining the RBF rules that had been
implemented in Bitcoin Core. The
В Wed, 3 Aug 2022 20:16:52 -0500
Billy Tetrud wrote:
> A descriptor format is simply defining a space of address
> derivation paths. It is not describing in any way what each path is
> intended for - those are conventions outside the scope of this BIP
> IMO. Defining the conventions of derivation
I agree with Peter, it seems like we don't need a dust limit with full
blocks. And we should expect blocks to remain full indefinitely.
However, if we were to still have a dust limit, it shouldn't be a simple
constant. It should be determined by the mempool environment. Eg one could
define the dus
@Dmitry
> various software might start to use extra indexes in a tuple for their
own non-standard purposes
This will be true regardless of whether the spec allows or doesn't allow
tuples of length more than 2. In fact, any other tuple other than <1;2>
will be nonstandard. We can't prevent people
10 matches
Mail list logo
