Developers,
I know that some of you may be interested in hearing my perspective on what
happened and why. I still do not know exactly what happened and why.
However, I can offer a brief explanation of what I perceived my main
actions to be and the response to them:
1. I published and shared to
Developers,
There is much to say about the events of the last two weeks and the
response to them. I've been searching for the right words to share here,
but I think it best that short of a more thoughtful writeup I start with a
timely small step with the below comments.
First, let me be clear: I
+1 alicexbt
We of course want knowledgeable bitcoiners who aren't knowledgeable about a
certain proposal to be skeptical. But what we don't want is for that
natural skepticism-from-ignorance to be interpreted as opposition, or
really a strong signal of any kind. Any thoughts from ignorance,
On Sun, May 1, 2022, 09:22 alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Michael,
>
> Maybe the whole thing worked as designed. Some users identified what was
> going on, well known Bitcoin educators such as Andreas Antonopoulos, Jimmy
> Song etc brought additional
It seems that Taproot allows us to protect each individual public key with a
password. It could work in this way: we have some normal, Taproot-based public
key, that is generated in a secure and random way, as it is today in Bitcoin
Core wallet. Then, we can create another public key, just by
> via `sha_sequences`
Since you cannot expect txid stability with >1 inputs either way[0], it
should be sufficient to commit just to the current input's
nSequence/scriptSig to get txid stability for single input transactions. I
chatted with Jeremy about this and he appears to agree.
Not
Good morning again Chris,
I wonder if there would be an incentive to *rent* out a fidelity bond, i.e. I
am interested in application A, you are interested in application B, and you
rent my fidelity bond for application B.
We can use a pay-for-signature protocol now that Taproot is available, so
Hello ZmnSCPxj,
This is an intended feature. I'm thinking that the same fidelity bond
can be used to running a JoinMarket maker as well as a Teleport
(Coinswap) maker.
I don't believe it's abusable. It would be a problem if the same
fidelity bond is used by two makers in the _same_
Good morning Chris,
Excellent BIP!
>From a quick read-over, it seems to me that the fidelity bond does not commit
>to any particular scheme or application.
This means (as I understand it) that the same fidelity bond can be used to
prove existence across multiple applications.
I am uncertain
See
https://gist.github.com/chris-belcher/7257763cedcc014de2cd4239857cd36e
for the latest version of this BIP.
BIP: TBD. Preferably a two-digit number to match the bip44, bip49,
bip84, bip86 family of bips
Layer: Applications
Title: Derivation scheme for storing timelocked address
Hi Michael,
> Maybe the whole thing worked as designed. Some users identified what was
> going on, well known Bitcoin educators such as Andreas Antonopoulos, Jimmy
> Song etc brought additional attention to the dangers, a URSF movement started
> to gain momentum and those attempting a
11 matches
Mail list logo
