Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

Good morning Keagan, et al, > I think there are a few questions surrounding the issue of soft fork > activation. Perhaps it warrants zooming out beyond even what my proposal aims > to solve. In my mind the most important questions surrounding this process > are: > > 1. In an ideal world, assu

Re: [bitcoin-dev] MuSig2 BIP

Stating the taproot interaction more plainly: the taproot tweak is defined as a function of the internal key itself h_tapTeak(internalKey || rootHash), which means that the full tweak can't be known ahead of time. Instead, one must aggregate the keys to obtain the internal key _then_ apply the twea

Re: [bitcoin-dev] MuSig2 BIP

Hi Jonas, Great work on this BIP! Props to you and the other co-authors for putting together such an excellent technical specification. I'm sure I'm not the only developer stoked to see the much anticipated musig2 BIP published! I made a PR earlier today to add some JSON test vectors [1], which'l

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

> > > > Have you taken a look at my proposal > ? > The proposal is, to be clear, *not* "voting" but rather polling that isn't > programmatically connected to activation. The intention is for people > (developers) to loo

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

Felipe, > For me, the consensus should follow the current line: discussions and tests carried out by experts. We all know that the most important devs have the most weight in discussions. And that's how it should be, because they understand far better than any other lowly mortal. Consensus simply

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

Generally speaking, I'm not too fond of these mechanisms, for reasons others have expounded upon, but I will point out the following: Taproot means that top-level keys can be used in a ring signature scheme to collect coin votes from, e.g., all individual coins above a certain value at a certain t

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

The idea seems interesting at first glance, but soon we see several problems. The biggest problem with votes of this type is that they can be easily manipulated. Imagine a powerful attacker who impersonates someone in good faith and arrives with a proposal that looks great but has dark ends behind

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

@Erik > Miners can block votes from the chain This would seem to not realistically ever happen in Keagan's proposal, since miners can only include transactions that signal the same way they're signaling. So yes, they could block those transactions, but it would be very much against their interest

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

We had a UTXO proof-of-stake website at some point during the blocksize wars. A few people signed with a few thousand bitcoins, but it was clear that most were not participating. I don't have a link. Another old discussion link: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-June

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

There are many challenges with on-chain voting, here are a few: - We may not want votes on-chain, because it creates miner incentives for contentious BIP's to drive up fees - Miners can block votes from the chain - Cold storage votes are probably the most important for certain proposals (like vaul

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

>> we should not let the wealthy make consensus decisions. >We shouldn't let the wealthy continue to control our governments. However, bitcoin is not a government. Its a financial network. >The fact of the matter is that fundamentally, the economic majority controls where the chain goes. Its very

[bitcoin-dev] Transcript: Sydney Socratic on FROST w/ Jesse Posner

Hi I thought this transcript might be of interest to the mailing list. https://btctranscripts.com/sydney-bitcoin-meetup/2022-03-29-socratic-seminar/ Jesse Posner joined the online Sydney Socratic [1] last month to discuss his work on FROST. There is a video [2] too. As Jesse states [3] "With th

Re: [bitcoin-dev] What to expect in the next few weeks

Hi Michael, > Doesn't sound to me that this was being "offered up for discussion". A week > from April 17th would have been Sunday April 24th (2 days ago). Readers of > this mailing list would have had no idea of these plans. I'm quoting 5 points from the blog post and putting some words in cap

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

> A transaction signaling in the affirmative MUST NOT be included in a block that does not signal in the affirmative I feel like I've heard this idea somewhere before. Its an interesting idea. It should be noted that there is a consequence of this: holders wouldn't have much say. People that tr

Re: [bitcoin-dev] Speedy Trial

@Erik > can we all agree that this verbal and social wrangling and chest pounding seems, right now, to remain the best system of achieving consensus? or can we do better? I would love to see more people interested in discussing this. Social wrangling is certainly the best we have, but is it the

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") > soft forks)

> the hot wallet can only spend a certain amount from the hot wallet spend and the rest would .. be sent back That would definitely be the way to do it. The ability to steal from the hot wallet in my opinion shouldn't really be a "concern" about CTV, but rather an understood tradeoff of a CTV wal

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

@Russell > OP_PUBKEY, and OP_PUBKEYHASH as wildcards Ah I see. Very interesting. Thanks for clarifying. @Nadav > You can have a CTV vault where the hot key signer is a multisig to get the advantages of both. Yes, you can create a CTV vault setup where you unvault to a multisig wallet, but you do