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

[Bryan Bishop via bitcoin-dev]

You may be interested in these posts on transaction signalling:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014202.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.html


On Tue, Apr 26, 2022 at 3:12 PM Keagan McClelland via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Alongside the debate with CTV right now there's a second debate that was
> not fully hashed out in the activation of Taproot. There is a lot of
> argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
> etc. A significant reason for the breakdown in civility around this debate
> is that because we don't have a means of measuring user support for
> proposed sof-fork changes, it invariably devolves into people claiming that
> their circles support/reject a proposal, AND that their circles are more
> broadly representative of the set of Bitcoin users as a whole.
>
> It seems everyone in this forum has at one point or another said "I would
> support activation of  if there was consensus on it, but there isn't".
> This statement, in order to be true, requires that there exist a set of
> conditions that would convince you that there is consensus. People have
> tried to dodge this question by saying "it's obvious", but the reality is
> that it fundamentally isn't. My bubble has a different "obvious" answer
> than any of yours.
>
> Secondly, due to the trauma of the block size wars, no one wants to utter
> a statement that could imply that miners have any influence over what
> rulesets get activated or don't. As such "miner signaling" is consistently
> devalued as a signal for market demand. I don't think this is reasonable
> since following the events of '17  miners are aware that they have the
> strong incentive that they understand market demand. Nevertheless, as it
> stands right now the only signal we have to work with is miner signaling,
> which I think is rightly frustrating to a lot of people.
>
> So how can we measure User Support for a proposed rule change?
>
> I've had this idea floating around in the back of my head for a while, and
> I'd like to solicit some feedback here. Currently, all forms of activation
> that are under consideration involve miner signaling in one form or
> another. What if we could make it such that users could more directly
> pressure miners to act on their behalf? After all, if miners are but the
> humble servants of user demands, this should be in alignment with how
> people want Bitcoin to behave.
>
> Currently, the only means users have of influencing miner decisions are A.
> rejection of blocks that don't follow rules and B. paying fees for
> transaction inclusion. I suggest we combine these in such a way that
> transactions themselves can signal for upgrade. I believe (though am not
> certain) that there are "free" bits in the version field of a transaction
> that are presently ignored. If we could devise a mapping between some of
> those free bits, and the signaling bits in the block header, it would be
> possible to have rules as follows:
>
> - A transaction signaling in the affirmative MUST NOT be included in a
> block that does not signal in the affirmative
> - A transaction that is NOT signaling MAY be included in a block
> regardless of that block's signaling vector
> - (Optional) A transaction signaling in the negative MUST NOT be included
> in a block that signals in the affirmative
>
> Under this set of conditions, a user has the means of sybil-resistant
> influence over miner decisions. If a miner cannot collect the fees for a
> transaction without signaling, the user's fee becomes active economic
> pressure for the miner to signal (or not, if we include some variant of the
> negative clause). In this environment, miners could have a better view into
> what users do want, as would the Bitcoin network at large.
>
> Some may take issue with the idea that people can pay for the outcome they
> want and may try to compare a method like this to Proof of Stake, but there
> are only 3 sybil resistant mechanisms I am aware of, and any "real" view
> into what social consensus looks like MUST be sybil resistant:
>
> - Hashpower
> - Proof of personhood (KYC)
> - Capital burn/risk
>
> Letting hashpower decide this is the thing that is currently contentious,
> KYC is dead on arrival both on technical and social grounds, which really
> just leaves some means of getting capital into the process of consensus
> measurement. This mechanism I'm proposing is measurable completely
> en-protocol and doesn't require trust in institutions that fork futures
> would. Additionally it could be an auxiliary feature of the soft fork
> deployment scheme chosen making it something you could neatly package all
> together with the deployment itself.
>
> There are many potential tweaks to the design I propose above:
> 1. Do we include a notion of negative

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Jeremy Rubin via bitcoin-dev]

I can't find all of my earlier references around this, I thought I made a
thread on it, but as a reminder, my thoughts for mild tweaks to APO that
make it a bit less hacky are as follows:

- Remove OP_1 key punning and replace it with OP_GENERATOR and
OP_INTERNALKEY (maybe OP_EXTERNALKEY too?). The key punning is useful
generically, because I may want to reuse the internal key in conjunction
with a script path in some circumstances.
- Add an additional sequence field that is specific to a signature with no
other consensus meaning, so APO can be used with absolute timelocks. For
example, this makes it impossible for more than one ratchet to be
aggregated within a single transaction under any circumstance if their
sequences differ (not sure this is a good example, but an example
nonetheless).
- Replace tagged keys for APO with either a Checksig2 or a separate feature
flag that enables or disables APO behavior so that we can have programmatic
control over if APO is allowed for a given key (e..g., OP_IF  CSV DROP
CHECKSIG2 OP_ELSE CHECKSIG OP_ENDIF enables APO to be turned on after a
certain time, perhaps for a pre-approved backup transaction).

Overall, this would make eltoo ratchets look something like this:

  OP_1 OP_INTERNALKEY OP_CHECKSIG2VERIFY  OP_GREATERTHAN

where checksig2 leaves seq on the stack which can be used to enforce the
ratchet.

and covenants like:

 OP_1 OP_1 OP_GENERATOR OP_CHECKSIG2VERIFY







On Fri, Apr 22, 2022 at 4:23 AM darosior via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I would like to know people's sentiment about doing (a very slightly
> tweaked version of) BIP118 in place of
> (or before doing) BIP119.
>
> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
> over 6 years. It presents proven and
> implemented usecases, that are demanded and (please someone correct me if
> i'm wrong) more widely accepted than
> CTV's.
>
> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
> optional [0], can emulate CTV just fine.
> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
> expensive to use. But we can consider CTV
> an optimization of APO-AS covenants.
>
> CTV advocates have been presenting vaults as the flagship usecase.
> Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
> nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual
> bytes that are going to matter for
> a potential vault user.
>
> If after some time all of us who are currently dubious about CTV's stated
> usecases are proven wrong by onchain
> usage of a less efficient construction to achieve the same goal, we could
> roll-out CTV as an optimization.  In
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>
>
> Given the interest in, and demand for, both simple covenants and better
> offchain protocols it seems to me that
> BIP118 is a soft fork candidate that could benefit more (if not most of)
> Bitcoin users.
> Actually i'd also be interested in knowing if people would oppose the
> APO-AS part of BIP118, since it enables
> CTV's features, for the same reason they'd oppose BIP119.
>
>
> [0] That is, to not commit to the other inputs of the transaction (via
> `sha_sequences` and maybe also
> `sha_amounts`). Cf
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> .
>
> [1] https://anyprevout.xyz/ "Use Cases" section
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Keagan McClelland via bitcoin-dev]

Hi all,

Alongside the debate with CTV right now there's a second debate that was
not fully hashed out in the activation of Taproot. There is a lot of
argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
etc. A significant reason for the breakdown in civility around this debate
is that because we don't have a means of measuring user support for
proposed sof-fork changes, it invariably devolves into people claiming that
their circles support/reject a proposal, AND that their circles are more
broadly representative of the set of Bitcoin users as a whole.

It seems everyone in this forum has at one point or another said "I would
support activation of  if there was consensus on it, but there isn't".
This statement, in order to be true, requires that there exist a set of
conditions that would convince you that there is consensus. People have
tried to dodge this question by saying "it's obvious", but the reality is
that it fundamentally isn't. My bubble has a different "obvious" answer
than any of yours.

Secondly, due to the trauma of the block size wars, no one wants to utter a
statement that could imply that miners have any influence over what
rulesets get activated or don't. As such "miner signaling" is consistently
devalued as a signal for market demand. I don't think this is reasonable
since following the events of '17  miners are aware that they have the
strong incentive that they understand market demand. Nevertheless, as it
stands right now the only signal we have to work with is miner signaling,
which I think is rightly frustrating to a lot of people.

So how can we measure User Support for a proposed rule change?

I've had this idea floating around in the back of my head for a while, and
I'd like to solicit some feedback here. Currently, all forms of activation
that are under consideration involve miner signaling in one form or
another. What if we could make it such that users could more directly
pressure miners to act on their behalf? After all, if miners are but the
humble servants of user demands, this should be in alignment with how
people want Bitcoin to behave.

Currently, the only means users have of influencing miner decisions are A.
rejection of blocks that don't follow rules and B. paying fees for
transaction inclusion. I suggest we combine these in such a way that
transactions themselves can signal for upgrade. I believe (though am not
certain) that there are "free" bits in the version field of a transaction
that are presently ignored. If we could devise a mapping between some of
those free bits, and the signaling bits in the block header, it would be
possible to have rules as follows:

- A transaction signaling in the affirmative MUST NOT be included in a
block that does not signal in the affirmative
- A transaction that is NOT signaling MAY be included in a block regardless
of that block's signaling vector
- (Optional) A transaction signaling in the negative MUST NOT be included
in a block that signals in the affirmative

Under this set of conditions, a user has the means of sybil-resistant
influence over miner decisions. If a miner cannot collect the fees for a
transaction without signaling, the user's fee becomes active economic
pressure for the miner to signal (or not, if we include some variant of the
negative clause). In this environment, miners could have a better view into
what users do want, as would the Bitcoin network at large.

Some may take issue with the idea that people can pay for the outcome they
want and may try to compare a method like this to Proof of Stake, but there
are only 3 sybil resistant mechanisms I am aware of, and any "real" view
into what social consensus looks like MUST be sybil resistant:

- Hashpower
- Proof of personhood (KYC)
- Capital burn/risk

Letting hashpower decide this is the thing that is currently contentious,
KYC is dead on arrival both on technical and social grounds, which really
just leaves some means of getting capital into the process of consensus
measurement. This mechanism I'm proposing is measurable completely
en-protocol and doesn't require trust in institutions that fork futures
would. Additionally it could be an auxiliary feature of the soft fork
deployment scheme chosen making it something you could neatly package all
together with the deployment itself.

There are many potential tweaks to the design I propose above:
1. Do we include a notion of negative signaling (allowing for the
possibility of rejection)
2. Do we make it such that miner signaling must be congruent with >X% of
transactions, where congruence is that the signal must match any
non-neutral signal of transaction.

Some anticipated objections:

1. signaling isn't voting, no deployment should be made without consensus
first.
- yeah well we can't currently measure consensus right now, so that's not a
super helpful thing to say and is breeding ground for abuse in the form of
certain people making the unsubstantiated claim that consensus does or does

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

[Michael Folkson via bitcoin-dev]

Jeremy

> The reason there was not a mailing list post is because that's not a 
> committed plan, it was offered up for discussion to a public working group 
> for feedback as a potential plan.

In the interests of posterity from your personal blog on April 17th [1]:

"Within a week from today, you’ll find software builds for a CTV Bitcoin Client 
for all platforms linked here:

- Mac OSX TODO:
- Windows TODO:
- Linux TODO:

These will be built using GUIX, which are reproducible for verification."

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.

​> You've inaccurately informed the list on something no one has communicated 
committed intent for.

I'll let readers assess from the above who is accurately informing the mailing 
list and who is using personal blog posts and messaging apps to give a 
completely different impression to one set of people versus readers of this 
mailing list.

I like to give people the benefit of the doubt and assume incompetence rather 
than malice but when it comes to potential chain splits it doesn't really 
matter which it is. It has the same effect and poses the same network risk. If 
and when you try something like this again I hope this is remembered.

The Binance hack rollback suggestion, the NACKing then coin flip suggestion on 
Taproot activation and now this. It seems like this trillion dollar industry is 
a joke to you. I know we aren't supposed to get personal on this mailing list 
but honestly if you are going to continue with these stunts I'd rather you do 
them on a different blockchain.

[1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

--- Original Message ---
On Tuesday, April 26th, 2022 at 6:48 AM, Jeremy Rubin 
 wrote:

> The reason there was not a mailing list post is because that's not a 
> committed plan, it was offered up for discussion to a public working group 
> for feedback as a potential plan. You've inaccurately informed the list on 
> something no one has communicated committed intent for. This was an 
> alternative discussed in the telegram messaging app but did not seem to 
> strike the correct balance so was not furthered.
>
> I was hoping to be able to share something back to this list sooner rather 
> than later, but I have not been able to get, among those interested to 
> discuss in that venue, coherence on a best next step. I communicated inasmuch 
> on the bird app https://twitter.com/JeremyRubin/status/1518347793903017984 
> https://twitter.com/JeremyRubin/status/1518477022439247872, but do not have a 
> clear next step and am pouring over all the fantastic feedback I received so 
> far.
>
> Further, you're representing the state of affairs as if there's a great need 
> to scramble to generate software for this, whereas there already are scripts 
> to support a URSF that work with the source code I pointed to from my blog. 
> This approach is a decent one, even though it requires two things, because it 
> is simple. I think it's important that people keep this in mind because that 
> is not a joke, the intention was that the correct set of check and balance 
> tools were made available. I'd be eager to learn what, specifically, you 
> think the advantages are of a separate binary release rather than a binary + 
> script that can handle both cases? I'm asking sincerely because I would make 
> the modifications to the release I prepared to support that as well, if they 
> do not entail substantial technical risk. Personally, were I aligned with 
> your preferences, I'd be testing the forkd script and making sure it is easy 
> to use as the simplest and most effective way to achieve your ends.
>
> regards,
>
> Jeremy
>
> --
> [@JeremyRubin](https://twitter.com/JeremyRubin)
>
> On Mon, Apr 25, 2022 at 3:44 PM Michael Folkson via bitcoin-dev 
>  wrote:
>
>> The latest I'm hearing (this mailing list appears to be being bypassed in 
>> favor of personal blogs and messaging apps) is that Speedy Trial miner 
>> signaling for the contentious CTV soft fork is no longer going to start on 
>> May 5th (as previously communicated [1]) and may instead now start around 
>> August 1st 2022.
>>
>> Hence for now the drama seems to have been averted. I am deeply skeptical 
>> that in the next 3 months this soft fork activation attempt will obtain 
>> community consensus and will no longer be contentious (although I guess 
>> theoretically it is possible). As a result I suspect we'll be in the exact 
>> same situation with a URSF effort required 2-3 months down the line.
>>
>> If we are I'll try to keep the mailing list informed. It is important there 
>> is transparency and ample time to research and prepare before makin

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

[Erik Aronesty via bitcoin-dev]

>
>
> I would comment on this point, but I'm not sure I'm "technical enough". I
> have to admit: I've never played tennis.
>

You are technicial enough to read the nacks... everyone is:
https://github.com/JeremyRubin/utxos.org/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc

I can give a summary of the nack arguments here on one sentence:"I am
resisting a consensus change because we don't have consensus"

It's lovely recursive logic

--

The most cogent *technical* arguments against ctv seem fall into 3 camps:

1. APO is better for eltoo:
https://twitter.com/rusty_twit/status/1518007923896578048?s=20&t=8IUgni_i5jcfSlJ1Gy7T1A

2. CTV doesn't have recursion, but i want recursion... which are swiftly
followed by arguments against recursion:
https://bitcoinops.org/en/newsletters/2022/03/09/#limiting-script-language-expressiveness

(I usually ignore this one)

3. TLUV is super cool for vaults, so why are we even talking about CTV when
TLUV is better?

I like this (positive vibes) summary:

https://raymonddurk.medium.com/bitcoin-after-taproot-86c93fe5cc0c

Nowhere in there would anyone say CTV is "bad".

Just that other opcodes will wind up being used more because they are more
purpose-fit for 

If only we had unlimited resources we could have APO/TLUV;/CTV all ready to
go and be able to evaluate them on a level playing field / signet.

Does this sound about right?   Am I missing something?


- Erik
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Erik Aronesty via bitcoin-dev]

- it occurs to me that the real problem we have isn't whether miners lead
or users lead.   we know that users lead, we just need miners to be "ready"
and have time to upgrade their software

 - in the case of "evil" forks, i also don't need or want miners to
"defend" bitcoin... (if bitcoin is so broken that a bad fork gets past all
of the users, the miners have lost their purpose, so that is a fallacy of
reification and should be ignored)

 - we cannot measure user consensus in any systematic way, or else we
resort to gaming the system or centralization

- wallet votes (sign a message signalling... ), can cause
centralization pressures
- node signals (node published signal) will be sybil attacked
- eyeballs... (lol)

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










On Tue, Apr 26, 2022 at 1:42 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Apr 25, 2022 at 11:26:09AM -0600, Keagan McClelland via
> bitcoin-dev wrote:
> > > Semi-mandatory in that only "threshold" blocks must signal, so if
> > only 4% or 9% of miners aren't signalling and the threshold is set
> > at 95% or 90%, no blocks will be orphaned.
> > How do nodes decide on which blocks are orphaned if only some of them
> have
> > to signal, and others don't? Is it just any block that would cause the
> > whole threshold period to fail?
>
> Yes, exactly those. See [0] or [1].
>
> [0]
> https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#Mandatory_signalling
>
> [1] https://github.com/bitcoin/bips/pull/1021
> (err, you apparently acked that PR)
>
> Cheers,
> aj
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jeremy Rubin via bitcoin-dev]

Thanks, this is good feedback.

I think the main thing then to add to forkd would be some sort of seed
nodes set that you can peer with of other forkd runners? And have forkd be
responsible for making sure you addnode them?

wrt the generation of other problems, my understanding of the *summons
rusty's bat signal i wonder if he'll see this* triumvirate in this context
is that it's essentially, in this case:

- Dev proposes
- Miners may signal
- Users may credibly threaten that if signal, Miners will lose consensus
with sufficient portion of economy.


And that it's really, AFAIU, the *threat* of the outcome that ensures that
miners don't signal, and the followthrough is intentionally messy. If it's
*not* messy, then it is actually less effective and people just 'go their
separate ways', but if the intent is to drive consensus, it must be messy.

This is similar to Nuclear Deterrence game theory, whereby it's clearly not
the right call to use nukes, but paired with an irrational leader, the
credible threat serves to force a system of more relative peace. So the
pairing of ST + Users able to reject, albeit messily, does form a
relatively stable configuration.

Kudos to NVK for explaining the nuance to me.
--
@JeremyRubin 


On Tue, Apr 26, 2022 at 3:47 AM Anthony Towns  wrote:

> On Mon, Apr 25, 2022 at 10:48:20PM -0700, Jeremy Rubin via bitcoin-dev
> wrote:
> > Further, you're representing the state of affairs as if there's a great
> > need to scramble to generate software for this, whereas there already are
> > scripts to support a URSF that work with the source code I pointed to
> from
> > my blog. This approach is a decent one, even though it requires two
> things,
> > because it is simple. I think it's important that people keep this in
> mind
> > because that is not a joke, the intention was that the correct set of
> check
> > and balance tools were made available. I'd be eager to learn what,
> > specifically, you think the advantages are of a separate binary release
> > rather than a binary + script that can handle both cases?
>
> The point of running a client with a validation requirement of "blocks
> must (not) signal" is to handle the possiblity of there being a chain
> split, where your preferred ruleset ends up on the less-work side.
>
> Ideally that will be a temporary situation and other people will come to
> your side, switch their miners over etc, and your chain will go back to
> having the most work, and anyone who wasn't running a client with the
> opposite signalling requirement will reorg to your chain and ruleset.
>
> But forkd isn't quite enough to do that reliably -- instead, you'll
> start disconnecting nodes who forward blocks to you that were built on
> the block you disconnected, and you'll risk ending up isolated: that's
> why bip8 recommends clients "should either use parameters that do not
> risk there being a higher work alternative chain, or specify a mechanism
> for implementations that support the deployment to preferentially peer
> with each other".
>
> Also, in order to have other nodes reorg to your chain when it has
> more work, you don't want to exclusively connect to likeminded peers.
> That's less of a big deal though, since you only need one peer to
> forward the new chain to the compatible network to trigger all of them
> to reorg.
>
> Being able to see the other chain has more work might be valuable in
> order to add some sort of user warning signal though: "the other chain
> appears to have maintained 3x as much hash power as the chain your are
> following".
>
> In theory, using the `BLOCK_RECENT_CONSENSUS_CHANGE` flag to indicate
> unwanted signalling might make sense; then you could theoretically
> trigger on that to avoid disconnecting inbound peers that are following
> the wrong chain. There's already some code along those lines; but while I
> haven't checked recently, I think it ends up failing relatively quickly
> once an invalid chain has been extended by a few blocks, since they'll
> result in `BLOCK_INVALID_PREV` errors instead. The segwit UASF client
> took some care to try to make this work, fwiw.
>
> (As it stands, I think RECENT_CONSENSUS_CHANGE only really helps with
> avoiding disconnections if there's one or maybe two invalid blocks in
> a row from a random miner that's doing strange things, rather than if
> there's an active conflict resulting in a deliberate chain split).
>
> On the other hand, if there is a non-trivial chain split, then everyone
> has to deal with splitting their coins across the different chains,
> presuming they don't want to just consider one or the other a complete
> write-off. That's already annoying; but for lightning funds I think it
> means the automation breaks down, and every channel in the network would
> need to be immediately closed on chain, as otherwise accepting state
> updates risks losing the value of your channel balance on whichever
> chain you're lightning node is not followi

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

[Jeremy Rubin via bitcoin-dev]

I'm a bit confused here. The "personal blog" in question was sent to this
list with an archive link and you saw an replied to it.

The proposal to make an alternative path hadn't gotten buy in sufficient
from those iterating, and given the propensity of people to blow things out
of proportion in this list, I wanted to be sure a follow up plan carried
some buy before wider dissemination.

On Tue, Apr 26, 2022, 6:53 AM Michael Folkson 
wrote:

> Jeremy
>
> > The reason there was not a mailing list post is because that's not a
> committed plan, it was offered up for discussion to a public working group
> for feedback as a potential plan.
>
> In the interests of posterity from your personal blog on April 17th [1]:
>
> "Within a week from today, you’ll find software builds for a CTV Bitcoin
> Client for all platforms linked here:
>
>- Mac OSX TODO:
>- Windows TODO:
>- Linux TODO:
>
> These will be built using GUIX, which are reproducible for verification."
>
> 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.
>
> ​> You've inaccurately informed the list on something no one has
> communicated committed intent for.
>
> I'll let readers assess from the above who is accurately informing the
> mailing list and who is using personal blog posts and messaging apps to
> give a completely different impression to one set of people versus readers
> of this mailing list.
>
> I like to give people the benefit of the doubt and assume incompetence
> rather than malice but when it comes to potential chain splits it doesn't
> really matter which it is. It has the same effect and poses the same
> network risk. If and when you try something like this again I hope this is
> remembered.
>
> The Binance hack rollback suggestion, the NACKing then coin flip
> suggestion on Taproot activation and now this. It seems like this trillion
> dollar industry is a joke to you. I know we aren't supposed to get personal
> on this mailing list but honestly if you are going to continue with these
> stunts I'd rather you do them on a different blockchain.
>
> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message ---
> On Tuesday, April 26th, 2022 at 6:48 AM, Jeremy Rubin <
> jeremy.l.ru...@gmail.com> wrote:
>
> The reason there was not a mailing list post is because that's not a
> committed plan, it was offered up for discussion to a public working group
> for feedback as a potential plan. You've inaccurately informed the list on
> something no one has communicated committed intent for. This was an
> alternative discussed in the telegram messaging app but did not seem to
> strike the correct balance so was not furthered.
>
> I was hoping to be able to share something back to this list sooner rather
> than later, but I have not been able to get, among those interested to
> discuss in that venue, coherence on a best next step. I communicated
> inasmuch on the bird app
> https://twitter.com/JeremyRubin/status/1518347793903017984
> https://twitter.com/JeremyRubin/status/1518477022439247872, but do not
> have a clear next step and am pouring over all the fantastic feedback I
> received so far.
>
> Further, you're representing the state of affairs as if there's a great
> need to scramble to generate software for this, whereas there already are
> scripts to support a URSF that work with the source code I pointed to from
> my blog. This approach is a decent one, even though it requires two things,
> because it is simple. I think it's important that people keep this in mind
> because that is not a joke, the intention was that the correct set of check
> and balance tools were made available. I'd be eager to learn what,
> specifically, you think the advantages are of a separate binary release
> rather than a binary + script that can handle both cases? I'm asking
> sincerely because I would make the modifications to the release I prepared
> to support that as well, if they do not entail substantial technical risk.
> Personally, were I aligned with your preferences, I'd be testing the forkd
> script and making sure it is easy to use as the simplest and most effective
> way to achieve your ends.
>
> regards,
>
> Jeremy
>
> --
> @JeremyRubin 
>
> On Mon, Apr 25, 2022 at 3:44 PM Michael Folkson via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> The latest I'm hearing (this mailing list appears to be being bypassed in
>> favor of personal blogs and messaging apps) is that Speedy Trial miner
>> signaling for the contentious CTV soft fork is no longer going to start on
>> May 5th (as previously communicated [1]) and may instead now start around
>> August 1st 2

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

[Jorge Timón via bitcoin-dev]

"The only 3 nacks"...I would not call that an accurate "collection of
feedback". Feedback is always more positive when you laregely chose to
ignore any negative feedback, isn't it?

"Largely, the formal critiques of CTV (the 3 NACKs) are based on topics of
whether or not to swing the racquet, not if we should be at the ball. "

I would comment on this point, but I'm not sure I'm "technical enough". I
have to admit: I've never played tennis.
Besides, I'm pretty sure any feedback I give would be ignored.
Following the tennis analogy, one could think Jeremy is trying to win this
match the way Nadal won Djokovich in Australia in 2021 (ie by doing
everything in his hand to make sure his opponent wasn't even allowed to
play, ie not by playing fair nor by playing better than the opppnent).

"Activation parameters like in taproot".
If this was a tennis match, then I would have some sort of ability to slow
time down or something, because I've been seeing this ball slowly coming
since taproot's activation parameters were discussed.

It feels a little bit "deja vu" too. Was ever a controversial hardfork
attempted "just with the same activation mechanism as the last softfork"?
I should look for the exact words, I guess.


On Mon, Apr 25, 2022, 23:45 Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The latest I'm hearing (this mailing list appears to be being bypassed in
> favor of personal blogs and messaging apps) is that Speedy Trial miner
> signaling for the contentious CTV soft fork is no longer going to start on
> May 5th (as previously communicated [1]) and may instead now start around
> August 1st 2022.
>
> Hence for now the drama seems to have been averted. I am deeply skeptical
> that in the next 3 months this soft fork activation attempt will obtain
> community consensus and will no longer be contentious (although I guess
> theoretically it is possible). As a result I suspect we'll be in the exact
> same situation with a URSF effort required 2-3 months down the line.
>
> If we are I'll try to keep the mailing list informed. It is important
> there is transparency and ample time to research and prepare before making
> decisions on what software to run. Obviously I have no control over what
> others choose to do. Please don't be rushed into running things you don't
> understand the implications of and please only signal for a soft fork if
> you are convinced it has community consensus (what should precede signaling
> as it did for Taproot) and you are ready to activate a soft fork.
>
> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message ---
> On Saturday, April 23rd, 2022 at 11:03 AM, Michael Folkson via bitcoin-dev
>  wrote:
>
> As I said in my post:
>
> "If you care about Bitcoin's consensus rules I'd request you pay
> attention so you can make an informed view on what to run and what to
> support."
>
> Ideally everyone would come to an informed view independently.
> Unfortunately many people don't have the time to follow Bitcoin drama 24/7
> and hence struggle to separate noise from signal. In this case simple
> heuristics are better than nothing. One heuristic is to listen to those in
> the past who showed good judgment and didn't seek to misinform. Of course
> it is an imperfect heuristic. Ideally the community would be given
> sufficient time to come to an informed view independently on what software
> to run and not be rushed into making decisions. But it appears they are not
> being afforded that luxury.
>
> >  I fear you risk losing respect in the community
>
> I appreciate your concern.
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message ---
> On Saturday, April 23rd, 2022 at 6:10 AM, Billy Tetrud <
> billy.tet...@gmail.com> wrote:
>
> > assuming people pay attention and listen to the individuals who were
> trusted during that period
>
> Bitcoin is not run by a group of authorities of olde. By asking people to
> trust "those.. around in 2015-2017" you're asking people to blindly trust
> authorities. This, in my strong opinion, goes against the bitcoin ethos,
> and is an incredibly harmful way to push for your agenda. I'd very much
> recommend you reassess the way you're going about what you're trying to do.
> I fear you risk losing respect in the community by implying without any
> evidence that certain people are "taking advantage" of some situation and
> attempting "to confuse".
>
> On Fri, Apr 22, 2022 at 12:33 PM Michael Folkson via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> If the next few weeks go how I fear they will it could get messy. If you
>> care about Bitcoin's consensus rules I'd request you pay attention so you
>

[bitcoin-dev] CTV, covenants and vaults (was: : Re: ANYPREVOUT in place of CTV)

[darosior via bitcoin-dev]

> > i doubt CTV is necessary nor sufficient for this

> I would be interested to hear more on this.

A lot of people have been conflating vaults and covenants, especially lately. I 
believe we should
differentiate more Bitcoin vaults, a scheme that defines a "staged transaction 
process" [0], and Bitcoin
covenants. I find that there was a lot of confusion spread around that. 
Everything was a vault, from the
marketing of a mobile wallet with a 2of3 account to a covenant scheme. ( :)
It led to the confusion that a Bitcoin covenant would be necessary in order to 
have a Bitcoin vault. It's
incorrect: 
https://github.com/revault/practical-revault/blob/master/introduction.md (or 
[1], but albeit pretty
clever, i don't think it's practical).

Now, CTV is useful for Bitcoin vaults. For instance i believe it's useful to 
pre-commit to a Cancel
transaction directly in the Unvault Script. This matters a lot as today you 
need to be sure that your
watchtowers (or any other network monitor) have had the Cancel transaction 
signature of all participants in
the vault before you sign the Unvault transaction.
A covenant, as simple as CTV, fixes this. It makes sure that not only any 
Unvault you sign can be Canceled,
but also that when you spin up a new watchtower you don't need to send to it 
all the signatures for all the
current vaults. Of course you'd want to add some secret here to avoid the 
annoyance of all your Unvaults being
able to be canceled by some rando on the network. But you can derive them from 
a secret shared only once.
Also on the topic of reducing interactivity, i think that CTV or another more 
powerful covenants that allows
to commit to all parts of a transaction (for malleability) can be useful for 
the complicated issue of fee
bumping [2].

However, it's not sufficient. You are not going to be able to receive coins on 
a CTV that commits to the
Unvault (whose output would commit to either the Cancel immediately, or 
something else after a delay). It
would be an enormous footgun. For this, i believe something like TLUV with 
IN_OUT_AMOUNT [3] is a much more
interesting direction.
Furthermore, committing entirely to the withdrawal amounts in advance is very 
impractical. It is the one
largest UX barrier in my opinion. Users don't think in coins, but in amount to 
transfer. In order to have an
almost decent UX you would have to prepare a first stage transaction that 
creates a nice (what is nice? It's
very hard to reason about) distribution of coin amounts. This is a big tradeoff 
between usability and cost
(granularity). Of course it's not new to CTV, It's an issue today with Revault. 
It's just a problem faced by
today's implementation(s) (i don't know of any other "real" vault 
implementation) of Bitcoin vaults that CTV
does not solve.
I realise that you might not care to receive coins on a single-sig Script and 
have a vaulting step in a
single-party situation. I guess i just think vaults are more interesting in 
organisational situations, where a
set of participants only marginally trust another one (that may be a subset) 
and want to both limit the amount
they have access to and apply policies on how they would use the funds.

Antoine

[0] All vaults architectures i know of are characterized by the necessity to 
unlock the funds in multiple
stages, one of which is timelocked.
[1] https://arxiv.org/abs/2005.11776
[2] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020122.html[3]
 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html

--- Original Message ---
Le lundi 25 avril 2022 à 6:57 PM, Nadav Ivgi  a écrit :

> darosior via bitcoin-dev wrote:> i doubt CTV is necessary nor sufficient for 
> this
>
> I would be interested to hear more on this.
>
> Is it not necessary because you can exchange and store pre-signed 
> transactions instead?
>
> What purpose is it not sufficient for? There are some vault designs out there 
> that are able to achieve interesting properties with CTV, like James 
> O'Beirne's simple-ctv-vault:
>
> https://github.com/jamesob/simple-ctv-vault
> (the basic design expressed in Minsc: 
> https://min.sc/nextc/#gist=001cf1fcb0e24ca9f3614c4db9bfe57d:4)
>
> On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev 
>  wrote:
>
>> I would like to know people's sentiment about doing (a very slightly tweaked 
>> version of) BIP118 in place of
>> (or before doing) BIP119.
>>
>> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for over 
>> 6 years. It presents proven and
>> implemented usecases, that are demanded and (please someone correct me if 
>> i'm wrong) more widely accepted than
>> CTV's.
>>
>> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made 
>> optional [0], can emulate CTV just fine.
>> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more 
>> expensive to use. But we can consider CTV
>> an optimization of APO-AS covenants.
>>
>> CTV advocates have been presenti

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

[Melvin Carvalho via bitcoin-dev]

On Fri, Apr 22, 2022 at 7:33 PM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If the next few weeks go how I fear they will it could get messy. If you
> care about Bitcoin's consensus rules I'd request you pay attention so you
> can make an informed view on what to run and what to support. For those of
> you who were around in 2015-2017 you'll know what to expect. The right
> outcome endured in 2017 and I'm sure the right outcome will endure here
> assuming people pay attention and listen to the individuals who were
> trusted during that period. There are always a large number of motivated
> parties who are incentivized to break nodes off from Bitcoin and may seek
> to take advantage of a contentious soft fork activation attempt.
>
> Remember that if all the information is presented to users in a clear way
> well ahead of time then they can make their own mind up. I fear that things
> will be made as convoluted as possible in a way intended to confuse and
> information will be withheld until the last minute. When in doubt it is
> generally better to rely on the status quo and tried and trusted. In this
> case that would be Bitcoin Core. Alternative releases such as those seeking
> to attempt to activate CTV or indeed those seeking to resist the activation
> of CTV really should only be considered if you are informed on exactly what
> you are running.
>
> If you are interested in the effort to resist the contentious soft fork
> activation attempt of CTV please join ##ursf on Libera IRC.
>
> Have a good weekend. Hopefully those behind this contentious soft fork
> activation attempt will see sense and we can go back to more productive
> things than resisting contentious soft forks.
>

Thanks for raising this

Remembering 2017 quite well, it's often characterized as small block(ers)
vs big block(ers).  While that was certainly the case, I see it slightly
differently.

I think the bigger argument of 2017 was around a network split.  Splitting
the network is problematic because one or other of the split chains may
experience a hash death (without mitigating difficulty adjustment
algorithms), or the so-called "famine and feast" minority hash behaviour,
experienced on testnet, and disruptive to users

Any proposed changes should factor in network splits as a potential risk.
Or perhaps through another lens, you could see a network split as an
attack, on a par with a 51% attack, in terms of user disruption.  It may in
fact, be more potent, since we've never had a serious 51% attack, but we
have had network splits

I do think the conversation here is MUCH better tempered than 2017.
Hopefully we can try and avoid perceptions of gate keeping and railroading,
and keep the network together, as we did back then


>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Anthony Towns via bitcoin-dev]

On Mon, Apr 25, 2022 at 10:48:20PM -0700, Jeremy Rubin via bitcoin-dev wrote:
> Further, you're representing the state of affairs as if there's a great
> need to scramble to generate software for this, whereas there already are
> scripts to support a URSF that work with the source code I pointed to from
> my blog. This approach is a decent one, even though it requires two things,
> because it is simple. I think it's important that people keep this in mind
> because that is not a joke, the intention was that the correct set of check
> and balance tools were made available. I'd be eager to learn what,
> specifically, you think the advantages are of a separate binary release
> rather than a binary + script that can handle both cases?

The point of running a client with a validation requirement of "blocks
must (not) signal" is to handle the possiblity of there being a chain
split, where your preferred ruleset ends up on the less-work side.

Ideally that will be a temporary situation and other people will come to
your side, switch their miners over etc, and your chain will go back to
having the most work, and anyone who wasn't running a client with the
opposite signalling requirement will reorg to your chain and ruleset.

But forkd isn't quite enough to do that reliably -- instead, you'll
start disconnecting nodes who forward blocks to you that were built on
the block you disconnected, and you'll risk ending up isolated: that's
why bip8 recommends clients "should either use parameters that do not
risk there being a higher work alternative chain, or specify a mechanism
for implementations that support the deployment to preferentially peer
with each other".

Also, in order to have other nodes reorg to your chain when it has
more work, you don't want to exclusively connect to likeminded peers.
That's less of a big deal though, since you only need one peer to
forward the new chain to the compatible network to trigger all of them
to reorg.

Being able to see the other chain has more work might be valuable in
order to add some sort of user warning signal though: "the other chain
appears to have maintained 3x as much hash power as the chain your are
following".

In theory, using the `BLOCK_RECENT_CONSENSUS_CHANGE` flag to indicate
unwanted signalling might make sense; then you could theoretically
trigger on that to avoid disconnecting inbound peers that are following
the wrong chain. There's already some code along those lines; but while I
haven't checked recently, I think it ends up failing relatively quickly
once an invalid chain has been extended by a few blocks, since they'll
result in `BLOCK_INVALID_PREV` errors instead. The segwit UASF client
took some care to try to make this work, fwiw.

(As it stands, I think RECENT_CONSENSUS_CHANGE only really helps with
avoiding disconnections if there's one or maybe two invalid blocks in
a row from a random miner that's doing strange things, rather than if
there's an active conflict resulting in a deliberate chain split).

On the other hand, if there is a non-trivial chain split, then everyone
has to deal with splitting their coins across the different chains,
presuming they don't want to just consider one or the other a complete
write-off. That's already annoying; but for lightning funds I think it
means the automation breaks down, and every channel in the network would
need to be immediately closed on chain, as otherwise accepting state
updates risks losing the value of your channel balance on whichever
chain you're lightning node is not following.

So to your original question: I think it's pretty hard to do all that
stuff in a separate script, without updating the node software itself.

More generally, while I think forkd *is* pretty much state of the art;
I don't think it comes close to addressing all the problems that a chain
split would create.  Maybe it's still worthwhile despite those problems
if there's some existential threat to bitcoin, but (not) activating CTV
doesn't seem to rise to that level to me.

Just my opinion, but: without some sort of existential threat, it
seems better to take things slowly and hold off on changes until either
pretty much everyone who cares is convinced that the change is a good
idea and ready to go; or until someone has done the rest of the work to
smooth over all the disruption a non-trivial chain split could cause.
Of course, the latter option is a _lot_ of work, and probably requires
consensus changes itself...

Cheers,
aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev