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

[Billy Tetrud via bitcoin-dev]

@Zman
> if two people are perfectly rational and start from the same information,
they *will* agree

I take issue with this. I view the word "rational" to mean basically
logical. Someone is rational if they advocate for things that are best for
them. Two humans are not the same people. They have different circumstances
and as a result different goals. Two actors with different goals will
inevitably have things they rationally and logically disagree about. There
is no universal rationality. Even an AI from outside space and time is
incredibly likely to experience at least some value drift from its peers.

> 3.  Can we actually have the goals of all humans discussing this topic
all laid out, *accurately*?

I think this would be a very useful exercise to do on a regular basis. This
conversation is a good example, but conversations like this are rare. I
tried to discuss some goals
 we
might want bitcoin to have in a paper I wrote about throughput bottlenecks.
Coming to a consensus around goals, or at very least identifying various
competing groupings of goals would be quite useful to streamline
conversations and to more effectively share ideas.

@Nadav
> 1. There's a real cost attached to voting

This is IMO a huge downside. It prevents many from participating at all.
And it also give a big advantage to those who have a large monetary
consequence. It exacerbates the common problem in votes where special
interests spend lots of time and money to get something passed that is bad
overall, while its not bad enough for most people to spend time and money
opposing it.

> 3. Custodians don't get disproportionate voting power with their
customers' funds (not without getting themselves into fractional reserve,
at least).

I disagree. A. they already have fractional reserve most likely, but you're
right that it would cut into their normal rehypothication. But B.
custodians would definitely have an advantage because of holding people's
funds. They can use those funds however they want. If they think this vote
is more valuable to them then their normal rehypothication, they can direct
a lot of funds.

> 5. Selling your vote if you're disinterested in the outcome isn't a
no-brainer like in the naive scheme.

This is a good point, and is something I missed above when I was talking
about coin-weighted polling. However, literally all signaling of any kind
is subject to this kind of thing, unless you do something like blind voting
(where the voter can't prove how they voted to a would be vote buyer). Not
sure how you'd do blind voting in a way people can trust. Then again, if
these things aren't actually voting, and its quite likely that people would
talk about any significant vote buying effort, its possible that such an
effort could be adjusted for.

On Thu, Apr 28, 2022 at 11:09 AM Billy Tetrud 
wrote:

> @Keagan
> > we have to have a way (formalized or not) of deciding when the "lesser
> experts" in aggregate have better judgement.
>
> I agree. Its certainly convenient for development speed to limit the
> number of cooks in the kitchen. But for the largest cryptocurrency in the
> world, we're going to have to face the reality that the number of
> stakeholders has grown vastly larger than the developer community and those
> who implicitly trust the developer community, or any particular part of the
> dev community working on any particular upgrade.
>
> > Perhaps it warrants zooming out beyond even what my proposal aims to
> solve
>
> I very much like the way you framed the question, and I think these are
> important, potentially existential questions we should urge the bitcoin
> community to think deeply about.
>
> > 1. ...  what would be the threshold for saying "this consensus change is
> ready for activation"?
>
> This is indeed the basic question.
>
> > 1a. Does that threshold change based on the nature of the consensus
> change
>
> I don't think the threshold of consensus changes should depend on the type
> of consensus change. Any consensus change, no matter how small, introduces
> risk, can cause bugs, can open a back door. Naturally, simpler changes
> should be able to *reach* consensus faster, because presumably it would
> take less analysis, and be easier to explain and convince people of. But
> that doesn't mean the bar of consensus should be lower. I think it should
> not. A change may look small and innocuous when it is in fact not, and it
> would be less than ideal for people to try to pretend there's sufficient
> consensus by insisting that a change is so "small" that no more is needed.
>
> > 1b. Do different constituencies (end users, wallets, exchanges, coinjoin
> coordinators, layer2 protocols, miners) have a desired minimum or maximum
> representation in this "threshold"?
>
> There is a lot to say about this simple question. I think it should be
> recognized that the "say" anyone or any group has depends on their total
> future (or 

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

[Billy Tetrud via bitcoin-dev]

@Keagan
> we have to have a way (formalized or not) of deciding when the "lesser
experts" in aggregate have better judgement.

I agree. Its certainly convenient for development speed to limit the number
of cooks in the kitchen. But for the largest cryptocurrency in the world,
we're going to have to face the reality that the number of stakeholders has
grown vastly larger than the developer community and those who implicitly
trust the developer community, or any particular part of the dev community
working on any particular upgrade.

> Perhaps it warrants zooming out beyond even what my proposal aims to solve

I very much like the way you framed the question, and I think these are
important, potentially existential questions we should urge the bitcoin
community to think deeply about.

> 1. ...  what would be the threshold for saying "this consensus change is
ready for activation"?

This is indeed the basic question.

> 1a. Does that threshold change based on the nature of the consensus change

I don't think the threshold of consensus changes should depend on the type
of consensus change. Any consensus change, no matter how small, introduces
risk, can cause bugs, can open a back door. Naturally, simpler changes
should be able to *reach* consensus faster, because presumably it would
take less analysis, and be easier to explain and convince people of. But
that doesn't mean the bar of consensus should be lower. I think it should
not. A change may look small and innocuous when it is in fact not, and it
would be less than ideal for people to try to pretend there's sufficient
consensus by insisting that a change is so "small" that no more is needed.

> 1b. Do different constituencies (end users, wallets, exchanges, coinjoin
coordinators, layer2 protocols, miners) have a desired minimum or maximum
representation in this "threshold"?

There is a lot to say about this simple question. I think it should be
recognized that the "say" anyone or any group has depends on their total
future (or perhaps only total near-term) economic influence on the network.
This is related to the concept of the "economic majority". What is the
"economic majority"? We could say this depends exactly on the proportion of
bitcoin you own, but I don't think that would be quite right. For example,
a miner that (hypothetically) keeps no bitcoin except for what is being
changed into fiat has an important role and significant economic influence
on bitcoin. Miners provide a service. Their livelihood depends on
bitcoiners, and the livelihood of bitcoin depends in part on miners.
Similarly, a vendor who accepts bitcoin directly but converts it all to
fiat provides a service as well. They expand the network of where bitcoin
is directly useful. People willing to pay for things in bitcoin also
similarly expand bitcoin's network.

I think it only makes sense to align incentives and attempt to match the
amount of representation a group gets to the amount of economic influence
they have on the network. To do otherwise would invite a schism.

Based on the above, I'm thinking that there are only really two components
of what should comprise the weight of any person or group's say: 1. the
stake they have in bitcoin, and 2. the value they provide to bitcoin. Let
me elaborate:

Bitcoin has a purpose. That purpose is as a currency. The directly valuable
aspects of that are as a store of value and as a means of exchange. The
properties of bitcoin lead to benefits to using it as both of those things.
Therefore, the stake people have in holding bitcoin should count heavily
because the value of holding is a major purpose of bitcoin. But at the same
time the ability to transact bitcoin should also count pretty heavily
because its also a major purpose of bitcoin and at the same time accepting
or spending bitcoin expands the network. If we were able to economically
equate those two things, we might get closer to a way to figure out how to
ideally distribute representation. Similarly, we could add miners and
developers into this mix, comparing them based on the value they provide to
the network.

So let:
holdAmount = the value of bitcoin they're holding over a given period of
time T
transactionVolume = the volume of transaction value over a given period of
time T
miningVolume = the value of bitcoin they mined over time period T
technologyValue = the value of new technological developments produced over
time period T

A group's representation should =
(holdAmount*A + transactionVolume*B + miningVolume*C + technologyValue*D)
/
(totalLiveBitcoin*A + totalTransactionVolume*B + totalMiningVolume*C +
totalTechnologyValue*D)

where A through D are constants that relate the value of holding vs the
value of transacting vs the value of mining vs the value of building
bitcoin technology. We could split this up so that eg the representation
that holders in total should have just by holding is: A/(A+B+C+D)

For example, an equivalence could be: how much value does holding bitcoin

Re: [bitcoin-dev] MuSig2 BIP

[Jonas Nick via bitcoin-dev]

Happy to hear that the BIP draft is already useful and thank you, Laolu, for
extracting the test vectors.

> an implementation must make the _pre tweaked_ combined key available to the 
caller

To apply the Taproot tweak with the key aggregation algorithm as specified you
would have to do the following (slightly simplified):

P := KeyAgg(pk_1, ..., pk_n, tweaks = [])
t := hash_TapTweak(P, root)
Q := KeyAgg(pk_1, ..., pk_n, tweaks = [t])

This unnecessarily recomputes the pre-tweaked key aggregate. In the BIP, there
are more places where the specified algorithms unnecessarily recompute certain
values. I believe this is justified if it makes the spec significantly easier to
understand. In this case, however, it's clear that calling KeyAgg multiple times
for the same set of public keys is not intuitive at all. This is something I had
not fully considered before. Thanks for bringing it up.

The approach you're taking in btcd makes a lot of sense to me. But in the
specification, we want to avoid specifying how exactly the tweaks are derived.
In the libsecp256k1-zkp implementation, key aggregation and tweaking are
separated into different functions. But this requires keeping state between key
aggregation and tweaking, which is why we had not chosen this approach for the
BIP. I will investigate how in the BIP, we can also split key aggregation and
tweaking and minimize complexity.

> My reading here is that [...] last party doesn't (?) need to worry about their
> nonces

Your reading is mostly right. Brandon describes correctly how and why to modify
the nonce generation algorithm. I opened a PR that replaces the description of
this signing mode with a precise specification. Indeed, the result is that the
last party doesn't need to worry about their nonce (even if the other parties
use bad randomness).

[0] https://github.com/jonasnick/bips/pull/11
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] MuSig2 BIP

[Brandon Black via bitcoin-dev]

Hi Laolu,

> Finally, can you elaborate a bit on this fragment of the BIP that
describes
> a "short cut" when a specific signers is meant to send their nonces last:
>
> > Second, if there is a unique signer who is supposed to send the pubnonce
> > last, it is possible to modify nonce generation for this single signer
to
> > not require high-quality randomness
>
> My reading here is that if there's a signer that will always send their
> nonce last (possibly the responder to an LN funding attempt or a server
for
> a non-custodial service like Loop), then they don't actually need to
> generate real randomness, and can just fully specify all the new optional
> arguments? If so then this may end up really simplifying the
implementation
> of certain protocols since that last party doesn't (?) need to worry about
> their nonces as long as all the other (?) parties are using strong
> randomness?

I believe this was added in response to an email that a co-worker and I
sent to Jonas. The idea originated because one of our signers would have a
difficult time tracking, restoring, and securely deleting secret nonces
across a signing session, so what was important was that the signer not
have to retain state, rather than that they not have to provide their own
randomness. The result is that the signer also doesn't need to provide
randomness though.

The important property of the last signer's nonce is that any variation in
any other party's nonce, or other values that contribute to the challenge,
must uniformly randomize the last signer's nonce. The sentences following
the one you quote describe exactly how achieve this, particularly:

* Optional arguments become required
* extra_in argument must be composed of all other parties' nonces

These modifications ensure that if and only if the partial signature will
be exactly equal will the same nonce be used in a subsequent signing
session.

Best,

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

[bitcoin-dev] Conjectures on solving the high interactivity issue in payment pools and channel factories

[Antoine Riard via bitcoin-dev]

Hi,

This post recalls the noticeable interactivity issue encumbering payment
pools and channel factories in the context of a high number of
participants, describes how the problem can be understood and proposes few
solutions with diverse trust-minizations and efficiency assumptions. It is
intended to capture the theoretical bounds of the "interactivity issue",
where technical completeness of the solutions is exposed in future works.

The post assumes a familiarity with the CoinPool paper concepts and
terminology [0].

# The interactivity requirement grieving payment pools/channel factories

Payment pools and channel factories are multi-party constructions enabling
to share the ownership of a single on-chain UTXO among many
off-chain/promised balances. Payment pool improves on the channel factory
construction fault-tolerance by reducing the number of balance outputs
disclosed  on-chain to a single one in case of unilateral user exits.

However, those constructions require all the users to be online and
exchange rounds of signatures to update the balance distribution. Those
liveliness/interactivity requirements are increasing with the number of
users, as there are higher odds of *one* lazzy/buggy/offline user stalling
the pool/factory updates.

In echo, the design of LN was envisioned for a network of
always-online/self-hosted participants, the early deployment of LN showed
the resort to delegated channel hosting solutions, relieving users from the
liveliness requirement. While the trust trade-offs of those solutions are
significant, they answer the reality of a world made of unreliable networks
and mobile devices.

Minding that observation, the attractiveness of pools/factories might be
questioned.

# The interactivity requirement palliatives and their limits

Relatively straightforward solutions to lower the interactivity
requirement, or its encumbered costs, can be drawn out. Pools/factories
users could own (absolute) timelocked kick-out abilities to evict offline
users who are not present before expiration.

E.g, let's say you have Alice, Bob, Caroll and Dave as pool participants.
Each of them owns a Withdraw transaction to exit their individual balances
at any time. Each user should have received the pre-signed components from
the others guaranteeing the unilateral ability to publish the Withdraw.

A kick-out ability playable by any pool user could be provided by
generating a second set of Withdraw transactions, with the difference of
the nLocktime field setup to an absolute height T + X, where T is the
height at which the corresponding Update transaction is generated and X the
kick-out delay.  For this set of kick-out transactions, the complete
witnesses should be fully shared among Alice, Bob, Caroll and Dave. That
way, if Caroll is unresponsive to move the pool state forward after X, any
one of Alice, Bob or Dave can publish the Caroll kick-out Withdraw
transaction, and pursue operations without that unresponsive party.

While decreasing the interactivity requirement to the timelock delay, this
solution is constraining the kicked user to fallback on-chain encumbering
the UTXO set with one more entry.

Another solution could be to assume the widespread usage of node towers
among the pool participants. Those towers would host the full logic and key
state necessary to receive an update request and produce a user's approval
of it. As long as one tower instance is online per-user, the pool/factory
can move forward. Yet this is forcing the pool/factory user to share their
key materials with potentially lower trusted entities, if they don't
self-host the tower instances.

Ideally, I think we would like a trust-minimized solution enabling
non-interactive, off-chain updates of the pool/factory, with no or minimal
consumption of blockspace.

For the remainder of this post, only the pool use-case will be mentioned.
Though, I think the observations/implications can be extended to factories
as well.

# Non-interactive Off-chain Pool Partitions

If a pool update fails because of lack of online unanimity, a partition
request could be exchanged among the online subset of users ("the
actives"). They decide to partition the pool by introducing a new layer of
transactions gathering the promised/off-chain outputs of the actives. The
set of outputs belonging to the passive users remains unchanged.

The actives spend their Withdraw transactions `user_balance` outputs back
to a new intermediate Update transaction. This "intermediate" Update
transaction is free to re-distribute the pool balances among the active
users. To guarantee the unilateral withdraw ability of a partitioned-up
balance, the private components of the partitioned Withdraw transactions
should be revealed among the set of active users.

E.g, let's say you have Alice, Bob, Caroll and Dave as pool participants.
Pool is at state N, Bob and Dave are offline. Alice and Caroll agree to
partition the pool, each of them owns a Withdraw transaction

Re: [bitcoin-dev] CTV Signet Parameters

[Jeremy Rubin via bitcoin-dev]

Sorry I didn't see this snippet fully earlier, but I caught it in Optech
(cc harding)


> *(I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte*
> *hash on the stack evaluate as true? I guess that means everyone's 
> using**sapio to
> construct the txs?)*


Not quite: it would mean that everyone is using *sapio-miniscript**, *which
may or may not be in Sapio, or they are using a different miniscript
implementation that is compatible with sapio-miniscript's CTV fragment
(which is sort of the most obvious way to implement it), or they are hand
writing the script and are still using that fragment.

E.g., you can see
https://min.sc/nextc/#gist=001cf1fcb0e24ca9f3614c4db9bfe57d:2 or
https://min.sc/nextc/#gist=001cf1fcb0e24ca9f3614c4db9bfe57d:0 both of these
might "look" like sapio, but are built using minsc.

The underlying point might still stand, but using miniscript seems
different than using Sapio.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

[Peter Todd via bitcoin-dev]

On Sun, Apr 17, 2022 at 01:57:28PM -0700, Jeremy Rubin wrote:
> the 'lots of people' stuff (get confused, can't figure out what i'm
> quoting, actually are reading this conversation) is an appeal to an
> authority that doesn't exist. If something is unclear to you, let me know.
> If it's unclear to a supposed existential person or set of persons, they
> can let me know.

It's pretty simple: bitcoin-dev is read by hundreds of people. This has nothing
to do with authority. It's about not wasting the time of those people.

> concretely, I am confused by how OTS can both support RBF for updating to
> larger commitments (the reason you're arguing with me) and not have an
> epoch based re-comittings scheme and still be correct. My assumption now,
> short of a coherent spec that's not just 'read the code', is that OTS
> probably is not formally correct and has some holes in what is
> committed to, or relies on clients re-requesting proofs if they fail to be
> committed. in any case, you would be greatly aided by having an actual spec
> for OTS since i'm not interested in the specifics of OTS software, but I'm
> willing to look at the protocol. So if you do that, maybe we can talk more
> about the issue you see with how sponsors works.

OpenTimestamps is, as the name suggests, for cryptographic timestamping. As is
obvious to anyone with a good knowledge of cryptography, a cryptographic
timestamp proves that data existed prior to some point in time. That's it.

> further, I think that if there is something that sponsors does that could
> make a hypothetical OTS-like service work better, in a way that would be
> opaque (read: soft-fork like wrt compatibility) to clients, then we should
> just change what OTS is rather than committing ourselves to a worse design
> in service of some unstated design goals. In particular, it seems that
> OTS's servers can be linearized and because old clients aren't looking for
> linearization, then the new linearization won't be a breaking change for
> old clients, just calendar servers. And new clients can benefit from
> linearization.

The fact you keep bringing up linearization for a timestmaping service makes me
think something is missing in your understanding of cryptography. Tell me, how
exactly do you think linearization would help in an example use-case? More
specifically, what attack would be prevented?

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


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

[bitcoin-dev] Multiple ways to do bitcoin covenants

[alicexbt via bitcoin-dev]

CTV and other covenant proposals, tradeoffs, and overlapping features are among 
the topics being explored recently. I had some views and questions on this 
subject.:

a) Does bitcoin already have opcodes with overlapping features? Yes

b) Can we have multiple ways with some overlapping features to do bitcoin 
covenants with some tradeoffs? Yes
_
c) What are these tradeoffs if we compare CTV, APO, TLUV and TXHASH+CSFS?

I am sure about a) because it was already answered in CTV chat by Jeremy and 
sheshek. Example: CHECKSIG and CHECKSIGADD is redundant with OP_IF and OP_ADD

Not sure if we have "consensus" on b) but I don't see anything wrong with it.

For c) I would prefer CTV because:

- Simpler
- Blockspace effient
- Can be used even without taproot

Covering bare script, as in segwit v0, is necessary. Exposing a pubkey in case 
of an EC break will be a disaster, and vaults imply very long lived storage. 
Root CA offline certificates can often have shelf life measured in decades. 
However, NSA has issued warnings, NIST has issued guidelines, and executive 
order to prepare for the quantum shift. As a result, forcing everyone into a 
quantum-unsafe position is unsustainable.

Other developers might use a different way to do bitcoin covenant for other 
reasons. Example: Russel O'Connor would prefer general OP_TXHASH design
/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Felipe Micaroni Lalli via bitcoin-dev]

Hi Keagan,

The worst case scenario is: no new proposals are accepted and the Bitcoin
remains the same. This is not so bad. I think a bad actor will usually want
to *add* (or remove) something that breaks. I don't know if the boycott of
new proposals is as effective in breaking Bitcoin. It means the more
important devs are not in full control, but they have the (kind of) power
of veto if they have really rational arguments. The most harm they can do
is delay things a little.

But remember: after all, everyone is free to fork the code, try to change
something and perhaps create undesirable splits in the network.


Felipe.


On Wed, Apr 27, 2022 at 3:32 PM Keagan McClelland <
keagan.mcclell...@gmail.com> wrote:

> 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 means
> that there are not at least two or three important people opposing the idea
> with solid arguments. Is it very subjective and difficult? Yes. For sure.
> We all yearn for objective answers or methods. However, any method would
> fail. At the end, after numerous discussions and an apparent consensus, the
> objective answer and the real consensus will be obtained in the network, in
> the nodes upgrading. If there is a big war, the network will end up
> splitting in two, as it has in the past. To avoid any unwanted splits we
> discuss for exhaustion here in the list.
>
> This is essentially an admission that devs have control over the protocol.
> Users "having control" but deferring their judgement to devs is not
> meaningfully different than devs "having control". Many people have
> asserted, quite strongly, that this ought not be how Bitcoin governs
> itself. I myself am on the fence about what is practically possible or not.
> However, let's say that your supposition is correct. How would we protect
> against a corollary scenario where a dev has a proposal that looks great
> but has dark ends that no one notices yet, if the process for evaluation
> more or less is to defer to "the most important devs" expertise? Presumably
> we hash this out in forums like this, but in order to "override" the "most
> important devs" we have to have a way (formalized or not) of deciding when
> the "lesser experts" in aggregate have better judgement.
>
> Erik,
>
> > There are many challenges with on-chain voting, here are a few:
>
> This may be hair-splitting but I feel it important to clarify that my
> proposal isn't voting per se. Calling it that doesn't bug me, but the
> mechanics are meaningfully different than a simple tally vote which is the
> intuition that I think that term conveys. As Billy mentions this proposal
> actually requires that miners block signals from inclusion in the block if
> they themselves do not signal. I'm not necessarily claiming this is a
> superior design overall, however the "flaw" you point out is by design in
> this case. My goal in the proposal was really to give users a means of
> applying direct economic pressure to miners, who do inevitably play a role
> in BIP8/BIP9 activation procedure.
>
> Ryan,
>
> > - you're feeding the Chainalysis beasts, when hodlers move their UTXOs;
>
> Definitely a frightening proposition I hadn't considered. It does open up
> the possibility of tracking individual preferences and targeting of
> political opponents.
>
> >   - yuk, it's voting.
>
> I don't think the process of collecting information on user preference is
> in and of itself bad. Where I think Bitcoiners really want to avoid voting
> is this notion that 51% of the constituency can bully the other 49% into
> whatever they want. No part of my proposal suggests this, nor is it
> something I would want.
>
> -
>
> 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, assuming we could, with perfect certainty, know
> anything we wanted about the preferences of the user base, what would be
> the threshold for saying "this consensus change is ready for activation"?
> 1a. Does that threshold change based on the nature of the consensus
> change (new script type/opcode vs. block size reduction vs. blacklisting
> UTXOs)?
> 1b. Do different constituencies (end users, wallets, exchanges,
> coinjoin coordinators, layer2 protocols, miners) have a desired minimum or
> maximum representation in this "threshold"?
> 2. Given an answer from #1, what tests can we devise to measure those
> levels of support directly? If we can't measure it directly, can we measure
> different indicators that would help us infer or solve for the knowledge we
> want?
> 3. Can any of the answers to #2 be 

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

[Billy Tetrud via bitcoin-dev]

  @Felipe
> 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

We have up til this point been miraculously lucky that the vast majority of
prominent bitcoin developers are in relative alignment on the big picture
philosophy and have all seemed to be honest and open in general. However,
we cannot rely on this era of philosopher kings to continue. Relying on
experts in this way is an enormous attack vector. It should not be the
"most important" devs who carry the most weight, but weight should be
carried by the logic of what is being said. The speaker should ideally not
matter in consensus building. So I agree with Keagan's implication that
this is not how bitcoin should govern itself. We should move away from
appeals to authority towards something more amorphous and difficult to
control.

@Jeremy
> if there were a way to sign with a NUMS point for ring signature purposes

Do you have any link you could point to about NUMS points? I assume this
would be a way to aggregate coin-weighted signals in a way that helps hide
who signaled in what direction?

> if NUMS points are common these ring signatures protocols might not be
too useful for collecting signals

I'm curious: why is it better if its less common? I'm used to privacy
properties increasing as the privacy technique used becomes more common.

@Erik
> it doesn't address the "what about people who don't know there's a vote
going on"
> how nonexperts can "have a say" when they simply don't understand the
relevant issues.

I think a useful way to think about this is in terms of preferences and
representation, rather than in the terms of coming to the best technical
solution. The fact of the matter is that value is subjective and therefore
there is no "best" technical solution all the time. Sometimes the
preferences of stakeholders must be weighed and a compromise come to.
Hopefully most of these kinds of compromises can happen in the free market
on upper layers. But certainly some of them happen on the consensus layer.

An expert with deep knowledge can deeply understand a design or change well
enough to come to a full opinion about it according to their preferences.
But even other experts might not have read enough about a thing, or just
don't have time to delve deeply into that particular aspect. They'll have
to rely partly on their ability to make a determination from partial
knowledge and their ability to evaluate the trustworthiness and skill of
those who have deeper knowledge than them. Nonexperts and non-technical
people have to rely on those kinds of things even more so. Many people only
have social signals to rely on. What do the people they trust say?

I believe that the truth gets out eventually. Those who have deep knowledge
will eventually convince those who don't, tho that may take a long time to
play out. As annoying as the twitterati is, I think we should get used to
needing to give their opinions a bit of weight in terms of measuring
consensus. Of course, we shouldn't be making technical decisions based on
what nontechnical people want or think, however, what we should do is make
sure that we are explaining the changes we propose to make clearly enough
that a certainly level of comfort diffuses into the social circles of
people who care about bitcoin but don't understand it at a technical enough
level to participate in technical decision making. At a certain point, if
not enough people are comfortable with a change, the change shouldn't be
made yet until enough people are convinced its probably safe and probably
good. Think of the large set of non-technical people to be a glue that
connects together otherwise unconnected pockets of wisdom.

Doing things this way would almost certainly lead to slower development.
But development of the consensus layer slowing over time should be what we
all expect, and I daresay what we should all want eventually.

> it will just be a poll of "people who pay attention to the dev list and
maybe some irc rooms"

Maybe. But if there were mechanisms for broader consensus measuring,
perhaps more would pay attention. Perhaps some way to affect change would
lead more to have discussions and participate.

Even if its a small group at first, I think it would be very useful
information to see both who explicitly supports something, who explicitly
is against something, and also who is paying attention but neutral (maybe
even actively signaling as "neutral').

> unless there's a great ux around the tooling my guess is that it won't
garner a lot of meaningful data:

I agree. Tooling would be very important here.







On Wed, Apr 27, 2022 at 3:13 PM Erik Aronesty  wrote:

>
>>
>> Have you taken a look at my proposal
>> ?
>> The proposal is, to be clear, *not* "voting" but rather polling that 

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

[Nadav Ivgi via bitcoin-dev]

Back in the 2017 block size wars I brought up the idea [0] of using
time-locked-weighted voting as a mechanism to gauge community/hodler
sentiment (lived on testnet for awhile at https://hodl.voting [1]).

Basically, the user locks up some bitcoins with an OP_CSV while committing
to some statement (using a pay-to-contract-hash construct in my
implementation[2]). Votes are then weighted as  x .

This has some interesting advantages over the more naive coin weighting
scheme used at the time (Bitcoinocracy [3]):

1. There's a real cost attached to voting, in the form of lost liquidity
and losing the ability to sell. The handicap principle suggests that this
makes for more reliable signaling, getting people to put more thought and
consideration into their vote (and whether they really care/know enough
about the issue to vote on it at all).
2. It shows that the voter has a long-term interest in the value of bitcoin
(and stands to lose if bitcoin is harmed), and gives more influence to
long-term hodlers that possess strong confidence in bitcoin.
3. Custodians don't get disproportionate voting power with their customers'
funds (not without getting themselves into fractional reserve, at least).
5. Selling your vote if you're disinterested in the outcome isn't a
no-brainer like in the naive scheme.

A drawback is that in a chain-split scenario, you cannot use these bitcoins
to influence the markets (participate in futures markets, sell the side of
the split you want to see die off etc). But some people might not agree to
lose self-custody over their coins in order to do that, while with
time-weighted voting they can retain full self-custody. Or maybe they're
only willing to risk some X% on centralized futures markets, and still have
aside some Y% to allocate for timelocking.

To clarify, I don't really see this as 'voting' despite calling it that.
I'm definitely not advocating to use this as some authoritative
decision-making voting mechanism or as part of an activation mechanism,
only possibly as one more market signal to look at among many.

As for the proposal in the OP, it could be argued that mining fees are not
a highly reliable signal because users have to pay them anyway when
transacting, which makes the voting itself zero-cost (perhaps except for
waiting some more time to get it confirmed?). And as others have mentioned,
this gives influence primarily to transactors (the tx volume by exchanges
and payment processors easily eclipses that of end users) and not to
hodlers (while my idea does the exact opposite, so maybe makes sense to use
both?).

shesek

[0]
https://bitcoinmagazine.com/markets/hodlvoting-voting-your-bitcoins-better
[1] http://web.archive.org/web/20170710161455/https://hodl.voting/
[2] https://github.com/shesek/proof-of-hodl (hackathon grade code)
[3] Seems like a version of it now lives at
https://bitcoinocracy.herokuapp.com/

On Tue, Apr 26, 2022 at 11: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