Ryan Grant [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-10-07 to 2022-09-13
💬 Posted a total of 45 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub19a2m7qm80t7mzhgqfgunswhm5c3q4fkqt89057ugy7u8jdxncf2q06mwcl

Profile Code

nprofile1qqsz74dlqdnh4ld3t5qy5wfc8ta6vgs25mq9njh60wyz0wrexnfuy4qeudpsz

Author Public Key

npub19a2m7qm80t7mzhgqfgunswhm5c3q4fkqt89057ugy7u8jdxncf2q06mwcl

Show more details

Last Notes

2023-06-09 13:02:33

- reply

📅 Original date posted:2021-06-12
📝 Original message:
Hi,
I have detected some definite confusion among people who are not aware
of the most recent updates to the bip118 draft. I don't know if
that's common among readers of these lists.
Substantial edits to the bip118 draft were made through May 2019,
including changing its official name to SIGHASH_ANYPREVOUT. The
internal heading "Revisions" discusses these changes.
https://github.com/ajtowns/bips/blob/c7c6a58b7a66a5dc5f4435319577d26a34082a79/bip-0118.mediawiki#Revisions
https://github.com/ajtowns/bips/compare/master...ajtowns:bip-anyprevout
https://github.com/ajtowns/bips/blob/c7c6a58b7a66a5dc5f4435319577d26a34082a79/bip-0118.mediawiki
The version in bitcoin/bips was not modified since 2018, until it
diverged by collecting a minor fix two months ago. It still uses
SIGHASH_NOINPUT terminology.
https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
AFAICT, with taproot activating, the preferred method to ease
lightning network client state requirements will now definitely be
SIGHASH_ANYPREVOUT.
I am not aware of reasons for bip118's updated draft to sit on the
sidelines before consideration by a wider audience.

2023-06-09 13:02:33

- reply

📅 Original date posted:2021-06-12
📝 Original message:
Apologies, I found the discussion going on here:
https://github.com/bitcoin/bips/pull/943
On Sat, Jun 12, 2021 at 7:52 PM Ryan Grant <bitcoin-dev at rgrant.org> wrote:
>
> Hi,
>
> I have detected some definite confusion among people who are not aware
> of the most recent updates to the bip118 draft. I don't know if
> that's common among readers of these lists.
>
> Substantial edits to the bip118 draft were made through May 2019,
> including changing its official name to SIGHASH_ANYPREVOUT. The
> internal heading "Revisions" discusses these changes.
>
> https://github.com/ajtowns/bips/blob/c7c6a58b7a66a5dc5f4435319577d26a34082a79/bip-0118.mediawiki#Revisions
> https://github.com/ajtowns/bips/compare/master...ajtowns:bip-anyprevout
> https://github.com/ajtowns/bips/blob/c7c6a58b7a66a5dc5f4435319577d26a34082a79/bip-0118.mediawiki
>
> The version in bitcoin/bips was not modified since 2018, until it
> diverged by collecting a minor fix two months ago. It still uses
> SIGHASH_NOINPUT terminology.
>
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
>
> AFAICT, with taproot activating, the preferred method to ease
> lightning network client state requirements will now definitely be
> SIGHASH_ANYPREVOUT.
>
> I am not aware of reasons for bip118's updated draft to sit on the
> sidelines before consideration by a wider audience.

2023-06-09 12:46:44

- reply

📅 Original date posted:2016-09-11
📝 Original message:
Oops, I see my mistake. Hold onto the r-hash longer.

2023-06-09 12:46:43

- reply

📅 Original date posted:2016-09-10
📝 Original message:
Payments unexpectedly fragmented into multiple LN channels are
trickier than transactions spending multiple UTXOs. If Alice pays Bob
using multiple channels to fund one payment, then Bob's accounting
procedures might need time-based heuristics to join separate LN
transactions.
Wherever payments might fragment, some reassembly protocol support,
like BIP 70's merchant_data field, should be available. Every wallet
should be assisting with this accounting.
Since it's a low-level protocol, a varint should suffice.
Since we didn't need to bring in X.509 yet, call it payment_id.
Lack of a payment_id could, if tolerated at all, be considered a
"don't fragment" request.

2023-06-09 12:46:43

- reply

📅 Original date posted:2016-09-11
📝 Original message:
On Sat, Sep 10, 2016 at 4:36 PM, Christian Decker
<decker.christian at gmail.com> wrote:
> At least for the implementation using the r-hash to condition the
> release of funds there is nothing special about splitting a
> payment. As long as the recipient knows the total amount it should be
> receiving it can delay the release of the secret until it is
> guaranteed all funds. Collating the partial payments is done with the
> r-hash. I'm pretty sure that the private key release would also work
> the same way.
I understand how to collect partial payments on one channel this way, but
my reading was that the same r-hash cannot be used safely across
multiple channels. Once one channel completes, exposure of the r-hash
to a colluding intermediary in the other channel could allow pulling
funds before sending them onward.

2023-06-09 12:45:12

- reply

📅 Original date posted:2015-11-23
📝 Original message:
Alice intends to pledge to Bob's crowdfunded project, and will
create a one-input, one-output, anyone-can-pay transaction, valid
for one month. Bob publicized his address, anchored to an open
channel on the Lightning Network. Alice has already received
Bob's hashed preimage R. They plan to use an intermediary node
run by Hubab.
/ the problem /
Alice needs some special Lightning protocol option to indicate
that only the final hop should be rewritten and signed as
anyone-can-pay.
All other anyone-can-pay donors need to pay to the same output.
However, Lightning does not normally reuse public keys for fresh
Commitment Transactions.
Bob's Lightning software needs to leave all anyone-can-pay
fragments alone until they are valid together.
Crowdsourcing initiatives usually deal in larger amounts of money
than the initiators can raise beforehand, which would preclude
matching the amount in an initial Funding Transaction.
/ routed option /
Alice sends Hubab a normal channel transaction, using the HTLC,
to cover the cost plus fees. Alice can then send Hubab special
instructions on how to create a SIGHASH_ANYONE_CAN_PAY for Bob,
using the HTLC. Hubab does so.
Bob can receive transactions of arbitrary complexity. Once Bob
receives the pledge transaction from Alice, it should not be
revoked, as in normal bidirectional use of Lightning channels.
It should lie out-of-band until the anyone-can-pay output is
claimed. Bob does not update any related Commitment
Transactions, until the anyone-can-pay is fulfilled.
Hubab will be able to spend her normal channel transaction when
Bob reaches his goal. Bob's crowdfunding software will
concatenate scriptPubKeys of the pledges delivered by Hubab, with
their HTLCs, to claim the anyone-can-pay output, releasing R.
/ other issues /
Crowdfunding events could lock up money for a long time, since
execution is not handed over to the network when the HTLC
commitment is initiated. Lightning Network nodes will price
their fees accordingly. When fee discovery comes about, it
should be aware of the different transaction types.
Pledges have longer lives than payments, and it's not an error to
change one's mind about them. The protocol needs an
update_revoke_pledge_htlc, to revoke accepted pledges that have
not yet expired or caused other errors.
Hubab may need to route further, to Carol. Hubab needs to be
aware of more in the route than her handoff address, such as
whether the next destination is final.
Hubab (or Carol), when signing the SIGHASH_ANYONE_CAN_PAY
transaction, needs to select an input matching the exact amount.
Did I get this right?
Is there a simpler way to do crowdfunding with the Lightning
Network?

2023-06-09 12:45:12

- reply

📅 Original date posted:2015-11-23
📝 Original message:
This was an interesting thought experiment for me, but upon reflection
there's no point in trying to do this in Lightning.
Everyone considering a pledge can sign their part of the transaction,
for free, if they hold any coins on the Bitcoin blockchain. Only the
initiator needs to pay any transaction fee.

2023-06-09 12:40:10

- reply

2023-06-09 12:40:10

- reply

2023-06-07 23:13:23

- reply

📅 Original date posted:2022-09-13
📝 Original message:On Mon, Sep 12, 2022 at 2:47 AM Buck O Perley via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> First just wanted to thank you
for taking the initiative to
> put this together. I think that as the community and
> ecosystem continue to grow, it's going to be an important
> part of the process to have groups like this develop. Hopefully
> they allow us to resist the "Tyranny of Structurelessness" without
> resorting to formalized governance processes and systems.
Huh, lots of reading material behind that phrase. I'd heard it
before, but hadn't looked it up.
> > Defining a communication channel is still an open question: IRC, Slack,
> Discord, Discourse, ...
>
> I would vote against Slack. IRC is probably the best but maybe too
> high a barrier to entry? Publishing logs at least would counter
> concerns of it being exclusive. Maybe discord as an alternative.
I found Discord immediately wanted a phone number from me. I think
IRC remains the lowest bar for participants to contribute.
> > About the starting point for regular meetings, I think the good timing is
> somewhere in November, after the upcoming cycle of Bitcoin conferences,
+1
> Maybe as a way to keep these topics separate, it would make sense
> for activation to have its own WG. As norms develop around this one,
> they could inform creating a separate space focused on forwarding
> research and discussion around how to introduce upgrades to bitcoin.
I'd participate in this.
> In general it would be nice to have multiple of these groups
> happening at once, and finding a way that they can operate separate
> from centralized companies. To my mind, there's no good reason why
> a supposedly decentralized protocol should have to be focusing on only
> one set of protocol advancements at a time. The linear way that
> discussions post-Taproot activation took shape ("What do you think the
> next bitcoin softfork should be?") is a sign of weakness in my opinion.
> Definitely a big red flag that we should be concerned with.
Yes.
> * Any thoughts on starting to commit to an in-person meetup to happen
> ~6 months - 1 year after the start of the regular online meetings?
I think that sounds reasonable.

2023-06-07 23:12:39

- reply

📅 Original date posted:2022-08-10
📝 Original message:>> TODO: A way for the initial signer to delegate to another
>> scriptPubKey; needed for better privacy and CoinJoin/Lightning
>> compatibility
I need more documentation to understand this motivation.
On Tue, Aug 9, 2022 at 8:46 PM Ali Sherief via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> In the case of the last TODO, related to delegation to another
> scriptPubKey, I am not quite sure at the moment what to do about
> it - perhaps you guys can place a MAST (two Merkle branches, to be
> specific) - the first branch has the original signer's scriptPubKey,
> the second branch contains the delegated signer's scriptPubKey.
I don't understand this requirement, but it seems that whatever
parties are involved can make signatures on the delegating and
delegated keys.

2023-06-07 23:12:02

- reply

📅 Original date posted:2022-07-23
📝 Original message:+1 I'd participate.
Certain human/organizational limitations prevent things being said in
logged channels that sometimes can be shared in person. Sometimes
people break through misunderstandings in person, through either
informal mingling or the use of Chatham House rules. So I would also
advocate restarting the Scaling Bitcoin conferences, twice a year.
One request for the agenda:
I perceived a lot of "Oh, well it's also fine to just wait and see
what comes" in the prior discussions. The idea that we should reopen
this discussion presumes that it is better to not wait, because having
even imperfect covenant designs will cause the ecosystem to explore
what use cases to allocate developer interest in (as long as the fees
are not too far off - yeah I'm looking at you, CSFS). Because of
this, I also propose asking some of the more advanced scripting
technologists to reveal what of their work is currently science, what
is engineering, and what is product-oriented with understandable
delivery dates. I think that if more people understood the answers to
these questions then there would be more room for incremental
exploration of the space.

2023-06-07 23:12:00

- reply

📅 Original date posted:2022-07-23
📝 Original message:On Wed, Jul 20, 2022 at 9:46 PM Peter (Coinkite Inc) via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> [...] the various BIP-322 proposals never gained wide acceptance.
There's renewed interest in using BIP322 to validate signatures
related to work upgrading the Bitcoin-native Decentralized Identifier
Method (did:btcr) beyond its current specification, to version 2.0.
https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/bip322-signature-suite.md
https://www.w3.org/TR/did-core/

2023-06-07 23:11:47

- reply

📅 Original date posted:2022-07-12
📝 Original message:BIP119, OP_CTV, allows value to be assigned in a predetermined tree
of payments that confirms with a single output.
This allows batched transactions in the predetermined tree (e.g.
withdrawals from a centralized exchange) to be anchored in a way that
disallows double-spending of the inputs, yet allows the recipients to
smooth out mining fees for their withdrawal outputs, at their leisure.
It's a perfect design for a world where there are always more
transactions to be made than block space allows, yet only some of them
are urgent. As it applies to concerns mentioned in this thread, it
can be used to shift transaction fees to later blocks. Whenever
smoothing transaction fees would be a nice-to-have, this is one way to
have it.
https://utxos.org/uses/scaling/
https://utxos.org/analysis/bip_simulation/
On Tue, Jul 12, 2022 at 9:49 AM Peter <dizzle at pointbiz.com> wrote:
> With 3000 Lightning open/ close tx per block and 6 billion adults
> it's 38 years of backlog to onboard the entire adult
> population. That's not including corporations.
Separately, OP_CTV also allows slightly different payment channels
from the existing Lightning Network, that allow non-interactive
batched opens. Using this technique, onboarding 6 billion adults to
payment channels would be limited only by their willingness to
participate.
https://utxos.org/uses/non-interactive-channels/

2023-06-07 23:10:15

- reply

📅 Original date posted:2022-06-08
📝 Original message:I think Jorge's request for specifics is reasonable. I agree that we
can raise the level of discussion. Each claim about how good or bad a
specific BIP is should say why on the technical merits. Comments on
prior claims may expose misinformation, expose "trust me" authority,
or point out other fallacies. They should include a citation of the
original source, a fair restatement of the problematic claim for
current readers, and a short explanation of why it doesn't advance
understanding technical consensus.
There have been lots of mean comments. Some "Truth and
Reconciliation" will come due, and it will be a huge amount of work.
Another history book?

2023-06-07 23:08:40

- reply

📅 Original date posted:2022-05-03
📝 Original message:On Sun, May 1, 2022 at 8:49 PM Jorge Timón via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sun, May 1, 2022, 09:22 alicexbt via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> [...] Andreas is clueless about BIP 119 and other covenant
>> proposals. He is spreading misinformation and [...]
> Clueless and spreading disinformation, you say? What
> misinformation, could you explain?
First, OP_CTV covenants cannot restrict any address that the sender
does not control. OP_CTV just delivers auditable presigned
transactions. That's it! OP_CTV's primary design constraint is to
NOT empower new ways to do blacklists (which are already possible
using unwanted-multisig). That's not a statement about what Bitcoin
should ultimately become, but rather what Bitcoin is likely ready for.
Much like Bitcoin's design, the simplest possible covenant solution
was chosen, so that it would be "dirt simple" to audit that the code
does only what it should, and no more.
Andreas used a few words of indecision to make excuses for not
code-reviewing BIP119 or the pull request, while using a lot of words
talking about: how dangerous any change is; conservative consensus
process; and GovCoin blacklists. This gave the strong impression that
the change was dangerous and could easily lead to the creation of
blacklists enforced by L1 consensus itself (rather than enforced by
other signers in a sidechain or unwanted-multisig).
Andreas also didn't look into the reason that the proposed client was
safe and would not cause a chain split. Speedy Trials by themselves
don't risk chain splits, they poll. There was no UASF in the planned
executable. Some devs hate ST because it puts the initiative in
miner's hands to gauge **user support and readiness** - which those
devs feel the miners have no reason to be good at - but that expires
speedily. If everyone loved the change and the trial was about to
pass, except ornery users - who we love when UASF is needed, of
course - were going to cause a chain split of their own to block it,
then ST offers miners the capability to - very quickly, faster than a
release can be pushed out - change their signaling to again prevent a
chain split.
Russell O'Connor wrote the definitive explanation for how ST arose in
the consensus process and how it was designed to make everyone
unhappy. It's a great explanation of what we went through last year.
https://r6.ca/blog/20210615T191422Z.html
"On Building Consensus and Speedy Trial"
on | 2021-06-15T19:14:22Z
by | Russell O'Connor
Andreas also didn't look for a non-attack reason for a separate binary
release. (Here I feel like I should be naming a lot of devs as well,
hmm.) Let's go back to O'Connor, who reminds us of a faction from the
last consensus change:
> The "devs-do-not-decide" faction's concern is regarding the
> appearance of Bitcoin developers deciding the rules of Bitcoin.
> [...] This faction would be fine with users building their own
> alternative client for forced activation, or a configuration flag
> for enabling some kind of forced activation that is not enabled by
> default.
Maintainers of the repository and "Big Name" devs have very personal
reasons to take this stance. Meanwhile, devs who want to form an
opinion on some given matter but who do not want to do their own code
reviews typically look to Big Name code reviewers for guidance, in a
"Consensus Beauty Contest" [note_kbc]. Contrast this with everyone
who restricts their opinion-formation to their own review of the code;
they are "Doing Consensus Right", rather than being stuck in the
Beauty Contest. Now, if a "devs-do-not-decide" dev wrote some code,
they implicitly reviewed their own code, right? But! If they did not
write that code, then they **must avoid it** ...in proportion to how
much it affects consensus. According to this theory of Bitcoin's
consensus, we would **expect** Big Names to be partly missing from the
OP_CTV code reviews. This confuses people who are used to playing the
Consensus Beauty Contest.
[note_kbc:] for another game about what everybody else thinks,
see Keynesian beauty contest:
https://en.wikipedia.org/wiki/Keynesian_beauty_contest
(The connection is funny to me because we all have to individually
play this game when deciding what money is, and in so doing pay a
last homage to Keynes, during our multi-generational exit from his
eponymous economics of manipulated interest rates.)
Jimmy Song, in a video best fitting the advocacy referred to by
Michael (who did not give any specific link), claims that the OP_CTV
review process is "routing around" some Big Names. Jimmy is seemingly
unaware that some Big Names are explicitly not participating in
guiding what Bitcoin's consensus should be, and that some are even
using strategic ambiguity to do so. With the context above, we have a
much less nefarious interpretation of motive for releasing a
binary - one that is part of the consensus process.
https://www.youtube.com/watch?v=i5VNiiCYnIg
"Bitcoin Brief - BIP119, Mexico CBDC & Bitcoin's Role in Russia vs
Ukraine!"
on | Apr 25, 2022
(mark 1:13:52.0) Jimmy Song
(mark 1:18:00.0) "routing around"
An alternative client must, by necessity, offer both its consensus
feature and its activation. Releasing an alternative client is not a
decision made from impatience and disrespect. It’s the result of
asking everyone, getting literal non-responses, and intuiting that the
landscape has changed, so something on this path must be different
from last time. While the alternative client route surprised me when
I heard about it, I cannot say that I personally knew of any other way
to advance what has clearly been a blocked discussion, and so I did
not disassociate myself from the effort. People do not understand how
blocked up consensus is, and no dev has verbalized a better solution
for maintainers than strategic ambiguity, which is most confusing when
it is delivering only silence.
The typical alternative offered by other devs is, "Wait." Well, this
"Wait" has almost always meant "Never." Take a look at CSFS and APO.
They've been waiting, but for what? What's the bug that BIP authors
can't fix? Where's the concrete pull request? Who is going to anoint
them as done? OP_CTV has made its rite of passage and transcended
these questions. Its only competition is whether something better can
be imagined, but those arguments need to explain why learning from a
good opcode in the meantime is worth waiting years to work through new
safety concerns. If any of this matters, then timing matters, too.
OP_CTV is sitting at the front of the bus.
Personally, I suspect that the "something better" crowd wants
recursive covenants, yet recognizes the argument is difficult and
would have put it off in a sense of misplaced priorities, but we'll
find out soon. If there were some kind of assurance that could be
offered, something that would result in a less contentious soft fork,
instead of stonewalling resistance that makes all soft forks more
contentious, then a later "epsilon" upgrade to covenants would be
easier instead of harder. This is because everyone who believes that
recursive covenants are not a new threat to Bitcoin could argue
towards a common purpose and resolve that in a binding consensus
agreement. One such binding mechanism could be parties committing
matched coins locked under a future opcode, although this would be an
extreme departure from typical development and incur massive risk to
the parties if for other reasons phase two of the initiative fails.
It's too bad the game theory isn't simpler.
Finally, Andreas summarized the conservatism in his position as
basically, "If you want scripting and contracts, go buy ETH." Which
is offensive to everyone trying to make bitcoins more protective of
individual freedom and thus more valuable; whether you're working on
scaling and privacy, the Lightning Network, Discreet Log Contracts,
CoinPool covenants, self-custody vault covenants, building out Taproot
capabilities, or working on other infrastructure. What a clueless
shitcoiner!
https://www.youtube.com/watch?v=vAE5fOZ2Luw
"BIP119, EU regulatory attack, El Salvador, and much more in Q&A
with aantonop (April 2022)"
on | Apr 24, 2022
by | aantonop
(mark 30:34.0) "if you want to do smart contracts..."
The path to redemption in the Bitcoin community is to unequivocally
help Bitcoin.
Jeremy wasn't always Bitcoin-only, but his efforts have been sincere
and he works in the concrete realm where anyone can judge how pure his
contributions are. Even if OP_CTV is never activated, or if no
covenant opcode is ever activated, Bitcoin is much more secure due to
the critical bug fixes that Jeremy has already seen merged just
planning ahead for a mempool that could handle dependent transactions.
Bitcoin was never under attack or at risk of harm from Jeremy's
actions to advance the covenants discussion.
Andreas is welcome to research technical merits better before
communicating, and to discover how a vision of powerful contract
covenants - in the most decentralized money that exists - can affect
people's freedom. In so doing, join us.

2023-06-07 23:08:29

- reply

📅 Original date posted:2022-04-27
📝 Original message: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/002731.html
Erik Aronesty listed good issues, a few minutes ago.
Other issues:
- you're feeding the Chainalysis beasts, when hodlers move their UTXOs;
- signalling should be weighted by Bitcoin Days Destroyed [ref_bdd];
- Coinbase.com's interests are not sufficiently aligned to poll them; and
- yuk, it's voting.
Without supporting voting, I wish to note there is also one more way
to de-Sybil, via network analysis, historically labeled the Web of
Trust. It can be algorithmically blinded so as not to fit strongly
into your "KYC" category, despite using assertions about people that
do know each other as a ground truth.
[ref_bdd:]
https://en.bitcoin.it/wiki/Bitcoin_Days_Destroyed

2023-06-07 23:07:56

- reply

📅 Original date posted:2022-04-24
📝 Original message:On Sun, Apr 24, 2022 at 1:12 PM Jorge Timón <jtimon at jtimon.cc> wrote:
> [...all context chopped, mid-sentence...]
> I think it is against the spirit of the project to trust ideas based on who they come from.
On this we agree!

2023-06-07 23:07:55

- reply

📅 Original date posted:2022-04-24
📝 Original message:Michael and Jorge,
It is ethically inappropriate to make personal attacks on the
trustworthiness of participants on this list, on such vague grounds as
disliking an activation proposal!
https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
It is against the spirit of the project to base your judgements of a
technical solution on who presents them! You should not be so
technically adrift that you only have reputation left to speak about.
If you disagree with ideas, then shoot them down on the technical merits.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011457.html
If you disagree with people, then take it to smuttier sections of the Internet.

2023-06-07 22:59:45

- reply

📅 Original date posted:2021-10-01
📝 Original message:Due to the uneven reputation factor of various devs, and uneven review
attention for new pull requests, this exercise would work best as a
secret sortition.
Sortition would encourage everyone to always be on their toes rather
than only when dealing with new github accounts or declared Red Team
devs. The ceremonial aspects would encourage more devs to participate
without harming their reputation.
https://en.wikipedia.org/wiki/Sortition
https://en.wikipedia.org/wiki/Red_team
The scheme should include public precommitments collected at
ceremonial intervals.
where:
hash1 /* sortition ticket */ = double-sha256(secret)
hash2 /* public precommitment */ = double-sha256(hash1)
The random oracle could be block hashes. They could be matched to
hash1, the sortition ticket. A red-team-concurrency difficulty
parameter could control how many least-significant bits must match to
be secretly selected. The difficulty parameter could be a matter of
group consensus at the ceremonial intervals, based on a group decision
on how much positive effect the Red Team exercise is providing.
Upon assignment, the dev would have community approval to
opportunistically insert a security flaw; which, when either caught,
merged, or on timeout, they would reveal along with the sortition
ticket that hashes to their public precommitment.
Sortition Precommitment Day might be once or twice a year.

2023-06-07 22:54:42

- reply

📅 Original date posted:2021-06-12
📝 Original message:Hi,
I have detected some definite confusion among people who are not aware
of the most recent updates to the bip118 draft. I don't know if
that's common among readers of these lists.
Substantial edits to the bip118 draft were made through May 2019,
including changing its official name to SIGHASH_ANYPREVOUT. The
internal heading "Revisions" discusses these changes.
https://github.com/ajtowns/bips/blob/c7c6a58b7a66a5dc5f4435319577d26a34082a79/bip-0118.mediawiki#Revisions
https://github.com/ajtowns/bips/compare/master...ajtowns:bip-anyprevout
https://github.com/ajtowns/bips/blob/c7c6a58b7a66a5dc5f4435319577d26a34082a79/bip-0118.mediawiki
The version in bitcoin/bips was not modified since 2018, until it
diverged by collecting a minor fix two months ago. It still uses
SIGHASH_NOINPUT terminology.
https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
AFAICT, with taproot activating, the preferred method to ease
lightning network client state requirements will now definitely be
SIGHASH_ANYPREVOUT.
I am not aware of reasons for bip118's updated draft to sit on the
sidelines before consideration by a wider audience.

2023-06-07 22:54:42

- reply

📅 Original date posted:2021-06-12
📝 Original message:Apologies, I found the discussion going on here:
https://github.com/bitcoin/bips/pull/943
On Sat, Jun 12, 2021 at 7:52 PM Ryan Grant <bitcoin-dev at rgrant.org> wrote:
>
> Hi,
>
> I have detected some definite confusion among people who are not aware
> of the most recent updates to the bip118 draft. I don't know if
> that's common among readers of these lists.
>
> Substantial edits to the bip118 draft were made through May 2019,
> including changing its official name to SIGHASH_ANYPREVOUT. The
> internal heading "Revisions" discusses these changes.
>
> https://github.com/ajtowns/bips/blob/c7c6a58b7a66a5dc5f4435319577d26a34082a79/bip-0118.mediawiki#Revisions
> https://github.com/ajtowns/bips/compare/master...ajtowns:bip-anyprevout
> https://github.com/ajtowns/bips/blob/c7c6a58b7a66a5dc5f4435319577d26a34082a79/bip-0118.mediawiki
>
> The version in bitcoin/bips was not modified since 2018, until it
> diverged by collecting a minor fix two months ago. It still uses
> SIGHASH_NOINPUT terminology.
>
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
>
> AFAICT, with taproot activating, the preferred method to ease
> lightning network client state requirements will now definitely be
> SIGHASH_ANYPREVOUT.
>
> I am not aware of reasons for bip118's updated draft to sit on the
> sidelines before consideration by a wider audience.

2023-06-07 22:51:25

- reply

📅 Original date posted:2021-04-06
📝 Original message:On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The core question always was: what do we do if miners fail to activate?
>
> [...] Speedy Trial takes the approach that "let's pretend we didn't
> *actually* ask [miners]".
What ST is saying is that a strategy of avoiding unnecessary risk is
stronger than a strategy of brinkmanship when brinkmanship wasn't
our only option. Having deescalation in the strategy toolkit makes
Bitcoin stronger.
> It's totally a political approach, to avoid facing the awkward question.
> Since I believe that such prevaricating makes a future crisis less
> predictable, I am forced to conclude that it makes bitcoin less robust.
LOT=true does face the awkward question, but there are downsides:
- in the requirement to drop blocks from apathetic miners (although
as Luke-Jr pointed out in a previous reply on this list they have
no contract under which to raise a complaint); and
- in the risk of a chain split, should gauging economic majority
support - which there is zero intrinsic tooling for - go poorly.
> Personally, I think the compromise position is using LOT=false and
> having those such as Luke and myself continue working on a LOT=true
> branch for future consideration. It's less than optimal, but I
> appreciate that people want Taproot activated more than they want
> the groundwork future upgrades.
Another way of viewing the current situation is that should
brinkmanship be necessary, then better tooling to resolve a situation
that requires brinkmanship will be invaluable. But:
- we do not need to normalize brinkmanship;
- designing brinkmanship tooling well before the next crisis does
not require selecting conveniently completed host features to
strap the tooling onto for testing; and
- it's already the case that a UASF branch can be prepared along
with ST (ie. without requiring LOT=false), although the code is a
bit more complex and the appropriate stopheight a few blocks later.
Although your NACK is well explained, for the reasons above I am
prepared to run code that overrides it.

2023-06-07 18:31:20

- reply

2023-06-07 18:30:55

- reply

📅 Original date posted:2021-03-16
📝 Original message:I enjoyed the reindexing using a distinct subject and I appreciate the
new clarifications by those whose instinct was to put effort into a
response. Although I try to keep up, some of the taproot QC
mitigations that are possible had escaped my attention thus far.

2023-06-07 18:30:06

- reply

📅 Original date posted:2021-03-05
📝 Original message:On Fri, Mar 5, 2021 at 9:39 AM Lonero Foundation via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello, I want to start a new BIP proposal aiming to tackle some of
> the energy efficiency issues w/ Bitcoin mining. Excuse my ignorance
> given this is my first time making a BIP proposal, but is there a
> specific format I need to follow?
Hi Andrew,
I would like to discourage you from writing a BIP on this topic, as
any such proposal is guaranteed to be rejected based on prior
discussions in the community.
Please update your priors with the following:
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki
BIP: 2
Title: BIP process, revised
https://www.truthcoin.info/blog/pow-cheapest/
"Nothing is Cheaper than Proof of Work"
on | 04 Aug 2015
Your topic brings up an interesting edge case, which is whether the
BIP repository is an open forum for all possible arguments that are
technically well constructed. Obviously: no; but by what
non-arbitrary process do we decide?
I propose that the BIP Editor's role should include preserving signal
in the table of contents generated from our proposal repository, by
unilaterally rejecting - without any fuhrer comment - technically well
constructed proposals which are guaranteed to be rejected based on
prior discussions in the community, as spam. I think this is already
how it works, but we haven't actually written down this part of the
norms.
Since censorship is always a concern, it would be appropriate to
maintain a moderation log of spam BIPs, so that observers could judge
whether the BIP Editor is misusing the BIP assignment process to
censor proposals with some merit. Since one of the requirements for
submitting a BIP is to notify bitcoin-dev, the log is already
maintained. Since bitcoin-dev is moderated, the moderators take on a
low level of responsibility for gauging spam proposals (and they are
pretty relaxed about it, since it is better to err on the side of
inclusion for new developers, except for obvious patent bombing).
Since the bitcoin-dev moderation log is public and anyone can
subscribe to it, protective transparency is again achieved.
https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/

2023-06-07 18:29:59

- reply

📅 Original date posted:2021-03-05
📝 Original message:On Thu, Mar 4, 2021 at 7:32 PM Keagan McClelland via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> So that leads me to believe here that the folks who oppose LOT=true
> primarily have an issue with forced signaling, which personally I
> don't care about as much, not the idea of committing to a UASF from
> the get go.
The biggest disconnect is between two goals: modern soft-fork
activation's "Don't (needlessly) lose hashpower to un-upgraded
miners"; and UASF's must-signal strategy to prevent inaction.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
This question dives to the heart of Bitcoin's far-out future.
Of two important principles, which principle is more important:
- to allow everyone (even miners) to operate on the contract they
accepted when entering the system; or
- to protect against protocol sclerosis for the project as a whole?
Do miners have a higher obligation to evaluate upgrades than economic
nodes implementing cold storage and infrequent spends? If they do,
then so far it has been implicit. LOT=true would make that obligation
explicit.

2023-06-07 18:29:28

- reply

📅 Original date posted:2021-03-05
📝 Original message:On Thu, Mar 4, 2021 at 8:48 PM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> My concern was that the more complex scripts allow obfuscation of the Pay To address
This is no different from options available in P2SH, or from the
obfuscation achieved by generating a new address for a payment.

2023-06-07 18:29:13

- reply

📅 Original date posted:2021-02-28
📝 Original message:On Sat, Feb 27, 2021 at 5:55 PM Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> This has the same problems BIP149 did: since there is no signalling, it is
> ambiguous whether the softfork has activated at all.
You only need to see one block in the heaviest valid chain to dissolve
that ambiguity. There are a lot of volunteers in this space who would
(collectively) commit a few block's worth of hashrate, to know.
> Additionally, it loses the flexibility of BIP 8 to, after the initial
> deployment, move the timeoutheight sooner.
It doesn't interfere with concurrent UASFs using any combination of
timeoutheights.

2023-06-07 18:29:11

- reply

📅 Original date posted:2021-02-26
📝 Original message:Huh.
I like the mechanism.
I like the honesty that once a feature with high demand and safety is
ready, activation pressure will keep increasing.
The gradual march of time in this Decreasing Threshold proposal is
predictable and incremental in ways that help avoid brinkmanship.
Avoiding the hard fork dynamic (that LOT=true requires) prevents some
chain splits, but activation under political opposition may then still
depend on a UASF. If I thought the time had come to line up a UASF
for a feature, I'd first want to have nodes out there running this
softer Decreasing Threshold activation (maybe before it fails).
It's also not as unresponsive to miner wisdom as LOT=true.
Conceptually, it asks miners to arbitrate both version adoption as
well as whether nodes which haven't upgraded face risks in an early
activation. Should miners find themselves in dramatic unanimity, they
even have enough influence to technically fail any activation.

2023-06-07 18:27:42

- reply

📅 Original date posted:2020-12-08
📝 Original message:It looks like a good strategy for a bech32 library that is external to
Bitcoin Core would be:
- Default to the new M, under the same bech32 brand.
- Provide an interface to explicitly use both M=1 and M=0x2bc830a3.
- If decoding fails, throw an error; but in constructing that error
inform whether the other M would have succeeded.
- Provide an interface for a BIP173 implementation to peek at the
witness version byte of the data part, which may also involve
sanity-checking that byte for errors using a BIP173-specific
understanding of the appropriate checksum.
Return values for this special interface might currently be:
"it's version zero, based on a clean decoding",
"it's version one, based on a clean decoding",
"it's version zero, based on an auto-corrected byte",
"it's version one, based on an auto-corrected byte",
"no result, due to a decoding error on this byte", and
"too many errors to say anything more about decoding".
Although the reasoning is clear for doing so, looking into the data
that is supposed to be checksummed to determine which checksum to use
is not very elegant. There are two trips into a bech32 library for a
BIP173 decoding, and an indeterminate result on the version byte would
require heuristics for deciding what to do with the rest of the data
part to even advise the user on the error. Because of this, as a
library writer I would be tempted to auto-correct the witness version
byte (against the "SHOULD NOT" advice of BIP173's current version), if
it were the only one corrupted, as per the example return values
above. Please advise.
Some of the libraries that will be contemplating these steps include:
https://github.com/topics/bech32?o=desc&s=stars
Here are three existing uses of bech32 that are external to Bitcoin Core:
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md
https://github.com/btcontract/lnurl-rfc
https://github.com/bitcoin/bips/blob/master/bip-0136.mediawiki
Of the above, I think BIP136 can be unconditionally moved to
M=0x2bc830a3 due to having little legacy burden.

2023-06-07 18:14:02

- reply

📅 Original date posted:2018-08-16
📝 Original message:On Wed, Aug 15, 2018 at 8:40 PM, Jude Nelson via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Can a miner identify which transactions came from your software simply by
> running a copy themselves? If so, then they can censor your transactions no
> matter how you encode them.
The hash of the file is deterministic and `ipfs add` tells us what it
is whether the network is connected or disconnected. We don't upload
files to IPFS until the transaction has settled with several
confirmations.

2023-06-07 18:10:30

- reply

📅 Original date posted:2018-02-22
📝 Original message:On Fri, Feb 9, 2018 at 7:29 AM, Jeremy <jlrubin at mit.edu> wrote:
> utility of this construction can be improved if we introduce functionality
> that makes a script invalid after a certain time
Tagging this thread with "nExpiryTime". Search archives for more.

2023-06-07 18:10:29

- reply

📅 Original date posted:2018-02-05
📝 Original message:Am I reading correctly that this allows unilateral key rotation (to a
previously unknown key), without invalidating the interests of other
parties in the existing multisig (or even requiring any on-chain
transaction), at the cost of storing the signed delegation?

2023-06-07 18:09:11

- reply

📅 Original date posted:2018-01-02
📝 Original message:On Mon, Jan 1, 2018 at 1:50 PM, James Hilliard via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I propose that we move the BIP70 protocol implementation into a
> browser extension that can communicate with wallets over a simple IPC
> mechanism [...]
As a reminder, there is a W3C Payments API, currently proceeding along
the W3C Recommendation track, which registers "payment handlers" in
the browser, and selects one to complete a transaction:
https://w3c.github.io/payment-handler/
The purpose of the payments API is to automate all data entry and
handle choices related to common transactions on the Web. Payment
requests will often ask for information that Bitcoin wallets have no
current need to provide, such as a shipping address. If shipping
options or other personally identifying information (such as an email
address and a return payment address) are involved, then it is the
chosen payment type's *handler* that is tasked with negotiating with
the user how to reveal the supposedly necessary information.
https://www.w3.org/TR/payment-request/#the-options-argument
Although it may seem early for wallet makers to consider integration
with a mere W3C Recommendation, it would not be early to choose the
right architecture to build code on, given that this is in the works
for the major browsers. Development can proceed even in browsers that
have not implemented anything, through an HTML5 Javascript polyfill.
A demonstration which includes payment in bitcoins is already
available, although it leaves as an exercise for the reader exactly
how the txid would be made known to the handler (whether manually
input by paste buffer after copying from an external app, or returned
through IPC):
https://web-payments.io/
https://github.com/digitalbazaar/payment-handler-polyfill
>From my brief inspection: not bad. I don't see anything in this spec
that would preclude the workflow of a Bitcoin transaction, whether
on-chain (with the seller's backend marking off confirmations) or
using the Lightning Network. It even allows the seller to offer a
discount on certain payment methods:
https://www.w3.org/TR/payment-request/#dom-paymentdetailsmodifier

2023-06-07 18:03:06

- reply

📅 Original date posted:2017-06-11
📝 Original message:This[1] idea from April would assist in a BIP149-like segwit
activation on November 16th.
Its goal is to be incredibly easy to test and deploy, right now, even
before a decision on revisions to BIP149 is made, and well before such
"BIP149ish" testing is itself complete.
UASFs don't need time for most legacy nodes to upgrade - that's the
point of a soft fork. UASFs simply need to have inevitability,
which is provided by some nodes more than others. But for the node
less instrumental in that inevitability, and more relaxed about
scheduling upgrade work, being moved to a miner-protected consensus
ruleset is not as desirable a position as the opportunity to
participate fully. As a courtesy, the plan for soft forks has
always been to allow legacy nodes time to upgrade to full
participation. How much time should rollouts allow for this
courtesy?
Extended BIP9 activation of segwit (for legacy nodes) separates
concerns between intending to activate segwit and its method of
deployment, allowing "semi-legacy" nodes that have upgraded to
include this proposal to participate immediately in a successful
segwit activation, without needing any courtesy time to upgrade to
the particular deployment logic.
Code for deployment is included in the original email[1]. There's
nothing missing from the logic shown. The whole intent of the
proposal is that other deployment specifics are left to be defined
by future proposals. In the same block that THRESHOLD_ACTIVE is
reached for segwit, require Consensus::DEPLOYMENT_SEGWIT_ALT1 to
also reach THRESHOLD_ACTIVE, and the burden of the future proposal
is fulfilled.
If the idea proves broken or of no benefit, when actually
implementing and testing future deployments, then we can avoid using
DEPLOYMENT_SEGWIT_ALT1 until it expires, and zero nodes get hurt.
Let's look at how this affects options for how to deploy segwit...
/ BIP149ish UASF, without this proposal /
roadmap:
- BIP149ish debated (handles BIP141 success, unlike BIP149)
- BIP149ish tested
- BIP149ish courtesy timeout debated
- BIP148 fails
- BIP149ish released
- BIP141 fails
- BIP149ish courtesy timeout expires
- BIP149ish activates
- segwit activates
- legacy nodes must upgrade before recognizing BIP149 activation
If we try to restrict ourselves to only the original service bit, we
see a tension between activating soon and leaving legacy nodes on a
miner-protected consensus. We also see a tension between *planning*
how long it will take to debate and test UASF logic, and setting
expectations for when a reasonable activation date is.
These seemingly small tensions complicate the solution, and push it
out of developer's visions of what is feasible. It's not clear how
soon it can happen, so it doesn't get started in an urgent manner.
It doesn't get started in an urgent manner, so it's not clear how
soon it can happen.
/ BIP149ish UASF, with this proposal /
roadmap:
- this proposal debated
- this proposal tested
- this proposal released (courtesy begins)
- BIP149ish debated (handles BIP141 success, unlike BIP149)
- BIP149ish tested
- BIP148 fails
- BIP149ish released
- BIP141 fails
- BIP149ish activates
- segwit activates
- semi-legacy nodes *immediately* use segwit, via this proposal
We can remove the courtesy timeout problem, because the courtesy
begins as soon as this proposal goes live. This simplifies debate on
how BIP149ish should deploy, and helps make reasonable a much quicker
segwit activation should BIP141 fail.
With a clear route to quick activation for semi-legacy nodes, the
UASF can be planned for activation in as short a window as the key
nodes can upgrade. Not even all the key nodes need to upgrade: it's
still a soft fork, and UASFs simply need to have inevitability.
These differences can help us aim for activating segwit on November
16th, if BIP141 and BIP148 do not succeed earlier. Since BIP149 as
originally conceived is slow as molasses, BIP149ish still needs
debate, BIP141 has steadfast enemies, and the community is slow to
adapt to BIP148's complicated commitment requirements, it is prudent
to take this intermediate step allowing quicker BIP149ish activation.
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014160.html

2023-06-07 18:03:05

- reply

📅 Original date posted:2017-06-11
📝 Original message:Is there any reason that BIP149 activation on November 16th would
cause a problem?

2023-06-07 18:01:18

- reply

📅 Original date posted:2017-05-18
📝 Original message:On Thu, May 18, 2017 at 9:44 AM, Cameron Garnham via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> 3. We should assign a CVE to the vulnerability exploited by ‘ASICBOOST’.
>
> ‘ASICBOOST’ is an attack on this Bitcoin’s security assumptions and
> should be considered an exploit of the Bitcoin Proof-of-Work
> Function.
On Thu, May 18, 2017 at 10:59 AM, Tier Nolan via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Arguably as long as the effort to find a block is proportional to the block
> difficulty parameter, then it isn't an exploit. It is just an optimisation.
One principled way to proceed would be to fault not the exploit, but
the protocol design.
Bits in the block header have been discovered which could be used for
dual meanings, and at least one meaning does not preserve the
incentive balances intended and assumed by others. This unexpectedly
creates an incentive to block protocol improvements. The protocol
must be repaired.
In this view, which focuses on covert-ASICBOOST, how work is done is
up to the implementation. But if the hashing work specified possibly
could gain from blocking development work, then we have a
vulnerability.
I believe this is clear grounds for taking action without any delay.

2023-06-07 18:00:13

- reply

📅 Original date posted:2017-04-14
📝 Original message:Segwit has proven more contentious to activate than anticipated
(although my read has long been that the technical consensus is clear,
despite noisy objections). No matter which method is used to
eventually activate segwit, or on what timeline, it would be
beneficial if validating nodes already capable of supporting segwit
could, without further upgrades, eventually participate to their
fullest capacity.
BIP9 assignments should reserve a backward compatibility bit which all
yet-unknown segwit-compatible proposals may utilize. These future
proposals must be consensus compatible with BIPs 141, 143, & 147,
except that they may use different deployment logic.
The motivation is so that any validating node software released after
this BIP9 assignment can eventually understand if segwit is activated
by alternate means, even when the node is itself a legacy version.
This is important because the realities of system administration on
the Bitcoin network are that upgrades occur slowly (which is inherent
in the security choice of not presenting an auto-upgrade feature).
Even though segwit in particular is backwards compatible with old
validating nodes, there are still distinct advantages to validating
and generating segregated witness transactions.
For example, future BIP9-compatible deployment attempts might
additionally include a date-dependent UASF fallback. If, either
during or after activation, deployment rules also require signaling
for segwit using the backwards-compatible bit here proposed, then
(after 95% of recent blocks signal for the alternate segwit
deployment) more legacy nodes would understand and validate
transactions using segregated witnesses.
An expiration time of five years seems conservative:
// Alternate Deployment 1 of SegWit (BIP141, BIP143, and BIP147)
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].bit = 2;
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].nStartTime
= 1510704000; // November 15th, 2017.
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].nTimeout =
1668470400; // November 15th, 2022.
Segwit deployment logic would then look like:
bool IsWitnessEnabled(const CBlockIndex* pindexPrev,
const Consensus::Params& params)
{
LOCK(cs_main);
return (VersionBitsState(pindexPrev,
params,
Consensus::DEPLOYMENT_SEGWIT,
versionbitscache)
== THRESHOLD_ACTIVE)
|| (VersionBitsState(pindexPrev,
params,
Consensus::DEPLOYMENT_SEGWIT_ALT1,
versionbitscache)
== THRESHOLD_ACTIVE);
}

2023-06-07 18:00:12

- reply

📅 Original date posted:2017-04-15
📝 Original message:On Sat, Apr 15, 2017 at 8:42 AM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The alternative [Greg presents] (new BIP bit) has the clear downside
> of not triggering BIP141 activation, and therefore not enabling the
> new consensus rules on already deployed full nodes. BIP148 is making
> an explicit choice to favor dragging along those users which have
> upgraded to BIP141 support over those miners who have failed to
> upgrade.
A proposal from yesterday would separate this concern; though not
retroactively. One way to name this proposal would be "Catch-All
Segwit Activation".
"extended BIP9 activation of segwit, for legacy nodes"
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014160.html
If this release valve exists, then discussions (such as this thread)
can get back to focusing on finding the safest incentive-compatible
transitions, with time improving the situation instead of making it worse.

2023-06-07 17:59:32

- reply

📅 Original date posted:2017-04-08
📝 Original message:Praxeology Guy,
On Fri, Apr 7, 2017 at 12:56 PM, praxeology_guy
<praxeology_guy at protonmail.com> wrote:
> TLDR Unless I'm missing something, your claim that a
> misconfiguration would result in a stop chain is wrong because BIP9
> only works on soft forks.
If our rule change timing is different from changes on the chain with
most work, then (extending Johnson Lau's terminology a bit) we may
experience subjective hardfork-ness; due to miners creating blocks
which the economic majority goes on to accept, though they have a less
restrictive ruleset than ours.
> The user would have to adopt a soft fork at a time where no miner
> has also done the same, and where someone creates a contradictory
> block (which normally wouldn't happen unless someone was being
> malicious).
Correct for the segwit soft fork, which is narrowing the definition
of a nonstandard transaction. It's safe to say that if a block with a
tx violating cleanstack were to occur on a non-segwit chain, that it
was for malicious reasons.
However, some future forks - that a full node experiences as
low subjective hardfork-ness (i.e. soft forks) - might restrict
more common things.
> Never the less, I kind of like the idea of the user being notified
> when a newly activated more stringent soft fork rule caused a block
> to be rejected. The first time it happens, a message could come up,
> and then for some time after maybe it would be logged somewhere
> easily accessible.
Sure, a nice-to-have would be a SetfLargeWorkInvalidChainFound() that
was aware as well, though clients can make these decisions themselves.

2023-06-07 17:59:31

- reply

📅 Original date posted:2017-04-07
📝 Original message:The primary failure mode of a user's misconfiguration of nTimeout will
be a stopped chain.
If less-sophisticated users are offered these configuration settings
then chaintip progress failures that result from them should be
prominently displayed.

2023-06-07 17:54:14

- reply

📅 Original date posted:2016-11-03
📝 Original message:On Wed, Nov 2, 2016 at 1:30 PM, Russell O'Connor via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'm interested in collecting and implementing other useful covenants, so if
> people have ideas, please post them.
I know of a good business case that could benefit from two nice
features.
As an example:
Two parties have initiated a transaction designed with
counterparty-minimization in mind. It uses MAST and has many
different payout distributions. Both parties enter expecting to
gain from the transaction, but both take on risk due to external
factors.
Because of the risks involved, there exist possible times when one
party may wish to renegotiate the exit distribution, and might
threaten to block any exit. Or, either party might get hit by the
proverbial bus. During such times, the other party's eventual exit
is protected by using a multisig which includes an oracle
determination. The oracle's trusted role is bound to this example's
unstated "external factors" in a very limited sense, and does not
include broader concerns, such as determining whether a party to the
transaction is of "sound mind and body".
The singular term "oracle" hides a set of entities participating in
m-of-n multisig, which we can name the "oracle-set".
Transaction terms include a CLTV lasting perhaps several years,
applied whenever the exit requires the oracle-set's signatures.
Both parties may mutually select and sign one of the payout
distributions, to exit early.
The example, as I've described it so far, doesn't need anything other
than MAST. It isn't a covenant, because it doesn't impose any forward
restrictions when satisfied; despite the contractual complications of
executing the oracle-set's signatures. As covenant features are
considered across updated instances of what is otherwise a singular
transaction, it's important that none carry into the final payout
distribution, and that this is easy to verify.
Features desired:
- One party would like to unilaterally sell their participation in
the transaction, to a previously unknown recipient, before the
CLTV becomes valid.
The other originating party's stored MAST should either continue
to function, or require minimal replacements that can be
deterministically applied using data visible on the blockchain.
It should not be necessary to ask permission from - or coordinate
online communication with - the other originating party.
(This can also be viewed as a key rotation problem for any
long-lasting multisig transaction.)
- Both parties would like to mutually revoke rouge oracle-entities
from the oracle-set, without exposing each other to any possible
renegotiation of other terms.
Note that these features affect each other, since if one party sells
their participation after any oracle-entities have been revoked, then
the revocations should not reset, but rather remain in effect, until a
proper payout executes the final agreement in the contract.
Of course, if there's a way to achieve these features with less risk
than evaluating covenant logic, I would very much like to hear how to
do so.

2023-06-07 17:53:50

- reply

📅 Original date posted:2016-10-09
📝 Original message:Maybe bitcoin-discuss should have been opt-out rather than opt-in.
Dear moderators, what is the subscription count to bitcoin-discuss,
and bitcoin-dev?

2023-06-07 17:48:24

- reply

📅 Original date posted:2016-02-02
📝 Original message:On Mon, Feb 1, 2016 at 6:53 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Please provide any
> objections now, so I can try to address them now and enable consensus to be
> reached.
For section "Formally defining consensus",
Where objections were not deemed substantiated by the community, clear
reasoning must be offered.
For section "BIP Comments",
Comments should be solicited on the bitcoin-dev mailing list, and
summarized fairly in the wiki; with notice of summarization and time
for suggesting edits on the mailing list. Wiki registration and
monitoring should not be a required hurdle to participation.

2023-06-07 17:48:24

- reply

📅 Original date posted:2016-02-04
📝 Original message:On Thu, Feb 4, 2016 at 5:17 PM, Luke Dashjr <luke at dashjr.org> wrote:
> All review itself ought to remain on the ML.
> the author-chosen forum may only be *in addition
> to* the Bitcoin Wiki?
Ahh, much better. Thank you.
FWIW, this is the phrase that confused me:
[BIP 2:] If a BIP is not yet completed, reviewers should [...]

2023-06-07 17:48:23

- reply

📅 Original date posted:2016-02-04
📝 Original message:On Thu, Feb 4, 2016 at 12:15 AM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Various changes have been made based on initial input.
> Further review and re-review is of course welcome.
These recent edits definitely guide us towards less hard feelings when
comments are offered, without excessive policy structure.
[BIP 2:]
> A process BIP may change status from Draft to Active when it
> achieves rough consensus on the mailing list.
Is this mix of wiki and mailing list intentional? If so, the wiki
talk page is meant to be a self-curated permanent record of support
and dissent, but second-order reply commentary might fall either on
the wiki or the mailing list?
Mediawiki offers watchlists on a polling model, and there is some
email support [1], but it would be nice of a BIP author to at least
gather new/edited comment titles and report them to bitcoin-dev once a
week, during review. Someone has to stare at the diffs.
[1] https://www.mediawiki.org/wiki/Manual:Page_change_notification
BIP 2 should ask that all current and future forums that BIP authors
might choose for review have indisputable records of moderation and
user edits.
Is dump.bitcoin.it a sufficient public record of contentious
moderation or user cross-comment editing? It seems like as long as
the wiki as a whole is verifiable, it would suffice.

2023-06-07 17:42:58

- reply

📅 Original date posted:2015-10-07
📝 Original message:Bitcoin's participants can improve their ability to stay on a valuable
and censorship resistant blockchain by individually and informally
absorbing cultural wisdom regarding "rough consensus". This does not
require writing any formal rules about what rough consensus is. It is
a matter of participation with an understanding.
https://www.ietf.org/tao.html#rfc.section.2
In many ways, the IETF runs on the beliefs of its participants.
One of the "founding beliefs" is embodied in an early quote about
the IETF from David Clark: "We reject kings, presidents and
voting. We believe in rough consensus and running code".
A June 2015 bitcoin-dev thread, arguing about consensus, included the
usual range of responses; ranging from claims that any objection must
block consensus to a definition based on US Justice Stewart's "I'll
know it when I see it". (It's funny because it's true. We can
explain it better, though.)
"Concerns Regarding Threats by a Developer to Remove Commit Access
from Other Developers"
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008772.html
An August 2015 cryptography-list thread presents the idea that rough
consensus can be used as a tool for hindering progress. The specific
threat was that two protocol options could be made to seem equally
good. To solve this example, identify that as the problem, then
engage a judgement to pick one solution "good enough" (but that does
not lead to a dead-end for other goals of the project), and go with
it. There is room, within "rough consensus", for such action to
defend against the attack; as you can see from other excerpts in this
message.
"[Cryptography] asymmetric attacks on crypto-protocols - the rough
consensus attack"
http://www.metzdowd.com/pipermail/cryptography/2015-August/026151.html
To learn about forming a useful "rough consensus", see the very
readable "Tao of the IETF", and RFC 7282.
"The Tao of the IETF"
https://www.ietf.org/tao.html
(previously RFC 4677)
RFC 7282
"On Consensus and Humming in the IETF"
https://tools.ietf.org/html/rfc7282
Strong objections don't block rough consensus:
https://www.ietf.org/tao.html#getting.things.done
Rough consensus has been defined in many ways; a simple version is
that it means that strongly held objections must be debated until
most people are satisfied that these objections are wrong.
https://tools.ietf.org/html/rfc7282
Having full consensus, or unanimity, would be ideal, but we don't
require it: Requiring full consensus allows a single intransigent
person who simply keeps saying "No!" to stop the process cold. We
only require rough consensus: If the chair of a working group
determines that a technical issue brought forward by an objector
has been truly considered by the working group, and the working
group has made an informed decision that the objection has been
answered or is not enough of a technical problem to prevent moving
forward, the chair can declare that there is rough consensus to go
forward, the objection notwithstanding.
The working group chair's responsibility is different from that of
either a vote counter or a benign dictator:
http://tools.ietf.org/html/rfc2418
Note that 51% of the working group does not qualify as "rough
consensus" and 99% is better than rough. It is up to the Chair to
determine if rough consensus has been reached.
https://tools.ietf.org/html/rfc7282
3. Rough consensus is achieved when all issues are addressed, but
not necessarily accommodated
[...]
If the chair finds, in their technical judgement, that the issue
has truly been considered, and that the vast majority of the
working group has come to the conclusion that the tradeoff is
worth making, even in the face of continued objection from the
person(s) who raised the issue, the chair can declare that the
group has come to rough consensus. (And even though this is
framed in terms of a "vast majority", even that is not
necessarily true. This point is discussed in more detail in
Sections 6 and 7.)
[...]
The chair of a working group who is about to find that there is
only rough consensus is going to have to decide that not only
has the working group taken the objection seriously, but that it
has **fully examined the ramifications** of not making a change
to accommodate it, and that the outcome does not constitute a
failure to meet the technical requirements of the work.
[...]
6. One hundred people for and five people against might not be
rough consensus
[...] one of the great strengths of using consensus over voting:
It isn't possible to use "vote stuffing" (simply recruiting a
large number of people to support a particular side, even people
who have never participated in a working group or the IETF at
all) to change the outcome of a consensus call. As long as the
chair is looking for outstanding technical objections and not
counting heads, vote stuffing shouldn't affect the outcome of
the consensus call.
7. Five people for and one hundred people against might still be
rough consensus
[...Sybil attack] it is within bounds for the chair to say, "We
have objections, but the objections have been sufficiently
answered, and the objectors seem uninterested in participating
in the discussion. Albeit rough in the extreme, there is rough
consensus to go with the current solution."
[...] it is likely that if a working group got this
dysfunctional, it would put the whole concept of coming to rough
consensus at risk. But still, the correct outcome in this case
is to look at the very weak signal against the huge background
noise in order to find the rough consensus.
Working group chairs can help direct discussion:
https://www.ietf.org/tao.html#rfc.section.4.1
Sometimes discussions get stuck on contentious points and the
chair may need to steer people toward productive interaction and
then declare when rough consensus has been met and the discussion
is over.
Some working groups segregate the role of forming a consensus from
communicating the consensus:
https://www.ietf.org/tao.html#rfc.section.4.2
Another method that some Working Groups adopt is to have a Working
Group "secretary" to handle the juggling of the documents and the
changes. The secretary can run the issue tracker if there is one,
or can simply be in charge of watching that all of the decisions
that are made on the mailing list are reflected in newer versions
of the documents.
Bitcoin Core is neither an IETF working group, nor should it aim to
curate its network protocol ruleset as one. The IETF uses a steering
group, formal variance procedures, an appeals board, and a director
(to send even higher appeals to). All of those positions could become
points of attack, if Bitcoin were to attempt to use or copy them.
That said, most IETF appeal routes are merely authorized to undo a
prior ruling of consensus, opening for reconsideration prior dismissed
points of argument (on their technical merits). In Bitcoin, if
developers know what to work on, and can speak clearly enough to the
economic majority, then the system is working; regardless of whether
any role exists taking all the responsibility that an IETF working
group chair would take.
It is absolutely the case that resolving excessive roughness in shared
consensus takes more work than either votes or dictatorship. It is
also the case that rough consensus is a good defense against
committing to decisions with subtle undesirable long-term effects.
That is why the IETF cares about it, and that same long-term threat is
important in Bitcoin's ecosystem as well.
/// References and Selected IETF Excerpts ///
"The Tao of the IETF"
https://www.ietf.org/tao.html
A 2012 continuation of 2006's RFC 4677, itself first published in
1994.
BCP 25
http://tools.ietf.org/html/rfc2418
(1998)
3.3. Session management
Working groups make decisions through a "rough consensus"
process. IETF consensus does not require that all participants
agree although this is, of course, preferred. In general, the
dominant view of the working group shall prevail. (However, it
must be noted that "dominance" is not to be determined on the
basis of volume or persistence, but rather a more general sense
of agreement.) Consensus can be determined by a show of hands,
humming, or any other means on which the WG agrees (by rough
consensus, of course). Note that 51% of the working group does
not qualify as "rough consensus" and 99% is better than rough.
It is up to the Chair to determine if rough consensus has been
reached.
In the case where a consensus, which has been reached during a
face-to-face meeting, is being **verified on a mailing list**,
the people who were in the meeting and expressed agreement must
be taken into account. If there were 100 people in a meeting
and only a few people on the mailing list disagree with the
consensus of the meeting then the consensus should be seen as
being verified. Note that enough time should be given to the
verification process for the mailing list readers to understand
and consider any objections that may be raised on the list. The
normal two week last-call period should be sufficient for this.
[...]
To facilitate making forward progress, a Working Group Chair may
wish to decide to reject or defer the input from a member, based
upon the following criteria:
- Old
The input pertains to a topic that already has been resolved
and is redundant with information previously available;
- Minor
The input is new and pertains to a topic that has already
been resolved, but it is felt to be of minor import to the
existing decision;
- Timing
The input pertains to a topic that the working group has not
yet opened for discussion; or
- Scope
The input is outside of the scope of the working group
charter.
[...]
RFC 2026
"The Internet Standards Process -- Revision 3"
http://tools.ietf.org/html/rfc2026#section-6.5
6.5 Conflict Resolution and Appeals
[...]
RFC 7282
"On Consensus and Humming in the IETF"
https://tools.ietf.org/html/rfc7282
1. Introduction
[...] our credo is that we don't let a single individual dictate
decisions (a king or president), nor should decisions be made by
a vote, nor do we want decisions to be made in a vacuum without
practical experience. Instead, we strive to make our decisions
by the consent of all participants, though allowing for some
dissent (rough consensus), and to have the actual products of
engineering (running code) trump theoretical designs.
Having full consensus, or unanimity, would be ideal, but we
don't require it: Requiring full consensus allows a single
intransigent person who simply keeps saying "No!" to stop the
process cold. We only require rough consensus: If the chair of
a working group determines that a technical issue brought
forward by an objector has been truly considered by the working
group, and the working group has made an informed decision that
the objection has been answered or is not enough of a technical
problem to prevent moving forward, the chair can declare that
there is rough consensus to go forward, the objection
notwithstanding.
2. Lack of disagreement is more important than agreement
[...] **determining** consensus and **coming to** consensus are
different things than **having** consensus [emphasis in
original].
[...]If at the end of the discussion some people have not gotten
the choice that they prefer, but they have become convinced that
the chosen solution is acceptable, albeit less appealing, they
have still come to consensus. Consensus doesn't require that
everyone is happy and agrees that the chosen solution is the
best one. Consensus is when everyone is sufficiently satisfied
with the chosen solution, such that they **no longer have
specific objections** to it.
[...] "Can anyone not live with choice A?" is more likely to
only hear from folks who think that choice A is impossible to
engineer given some constraints. Following up with, "What are
the reasons you object to choice A?" is also essential.
[...]
There is also an important point to be made about reaching
consensus and "compromising": Unfortunately, the word
"compromise" gets used in two different ways, and though one
sort of compromising to come to consensus is good (and
important), the other sort of compromising in order to achieve
consensus can actually be harmful. As mentioned earlier,
engineering always involves balancing tradeoffs, and figuring
out whether one engineering decision makes more sense on balance
compared to another involves making engineering "compromises":
We might have to compromise processor speed for lower power
consumption, or compromise throughput for congestion resistance.
Those sorts of compromises are among **engineering choices**,
and they are **expected and essential**. We always want to be
weighing tradeoffs and collectively choosing the set that best
meets the full set of requirements.
However, there is another sense of "compromise" that involves
compromising between people, not engineering principles. For
example, a minority of a group might object to a particular
proposal, and even after discussion still think the proposal is
deeply problematic, but decide that they don't have the energy
to argue against it and say, "Forget it, do what you want".
That surely can be called a compromise, but a chair might
mistakenly take this to mean that they agree, and have therefore
come to consensus. But really all that they've done is
capitulated; they've simply given up by trying to appease the
others. That's not coming to consensus; there still exists an
outstanding unaddressed objection. Again, if the objection is
only that the choice is not ideal but is otherwise acceptable,
such a compromise is fine. But **conceding** when there is a
real outstanding technical objection **is not coming to
consensus**.
[...]
Coming to consensus is when everyone (including the person
making the objection) comes to the conclusion that either the
objections are valid, and therefore make a change to address the
objection, or that the objection was not really a matter of
importance, but **merely a matter of taste**. Of course, coming
to full consensus like that does not always happen. That's why
in the IETF, we talk about "rough consensus".
3. Rough consensus is achieved when all issues are addressed, but
not necessarily accommodated
[...]
If the chair finds, in their technical judgement, that the issue
has truly been considered, and that the vast majority of the
working group has come to the conclusion that the tradeoff is
worth making, even in the face of continued objection from the
person(s) who raised the issue, the chair can declare that the
group has come to rough consensus. (And even though this is
framed in terms of a "vast majority", even that is not
necessarily true. This point is discussed in more detail in
Sections 6 and 7.)
[...]
The chair of a working group who is about to find that there is
only rough consensus is going to have to decide that not only
has the working group taken the objection seriously, but that it
has **fully examined the ramifications** of not making a change
to accommodate it, and that the outcome does not constitute a
failure to meet the technical requirements of the work.
In order to do this, the chair will need to have a good idea of
the purpose and architecture of the work being done, perhaps
referring to the charter of the working group or a previously
published requirements document, or even consulting with other
experts on the topic, and then the chair will use **their own
technical judgement** to make sure that the solution meets those
requirements. It is possible that the chair can come to the
wrong conclusion, and the chair's conclusion is always
appealable should that occur, but the chair must use their
judgement in these cases. What can't happen is that the chair
bases their decision solely on hearing a large number of voices
simply saying, "The objection isn't valid." That would simply
be to take a vote. A **valid justification needs to me made**.
[...] Indeed, RFC 2418 adds on to [old talk of balloting] by
stating, "Note that 51% of the working group does not qualify as
'rough consensus' and 99% is better than rough." This document
actually disagrees with the idea that simply balloting or
otherwise looking at percentages can "determine" consensus.
While counting heads might give a good guess as to what the
rough consensus will be, doing so can allow important minority
views to get lost in the noise. One of the strengths of a
consensus model is that minority views are addressed, and using
a rough consensus model should not take away from that. That is
why this document talks a great deal about looking at open
issues rather than just counting the number of people who do or
do not support any given issue. Doing so has some interesting
and surprising implications that are discussed in subsequent
sections.
Any finding of rough consensus needs, at some level, to provide
a **reasoned explanation** to the person(s) raising the issue of
why their concern is not going to be accommodated. A good
outcome is for the objector to **understand the decision taken
and accept the outcome**, even though their particular issue is
not being accommodated in the final product.
Remember, if the objector feels that the issue is so essential
that it must be attended to, they always have the option to file
an appeal. A technical error is always a valid basis for an
appeal. [...]
4. Humming should be the start of a conversation, not the end
[...] a show of hands might leave the impression that the number
of people matters in some formal way.
5. Consensus is the path, not the destination
We don't try to reach consensus in the IETF as an end in itself.
We use consensus-building as a tool to get to the best technical
(and sometimes procedural) outcome when we make decisions.
Experience has shown us that traditional voting leads to gaming
of the system, "compromises" of the wrong sort as described
earlier, important minority views being ignored, and, in the
end, worse technical outcomes.
6. One hundred people for and five people against might not be
rough consensus
[...] one of the great strengths of using consensus over voting:
It isn't possible to use "vote stuffing" (simply recruiting a
large number of people to support a particular side, even people
who have never participated in a working group or the IETF at
all) to change the outcome of a consensus call. As long as the
chair is looking for outstanding technical objections and not
counting heads, vote stuffing shouldn't affect the outcome of
the consensus call.
[...]
Even if no particular person is still standing up for an issue,
that doesn't mean an issue can be ignored. As discussed
earlier, simple capitulation on an issue is not coming to
consensus. But even in a case where someone who is not an
active participant, who might not care much about the fate of
the work, raises a substantive issue and subsequently
disappears, the issue needs to be addressed before the chair can
claim that rough consensus exists.
7. Five people for and one hundred people against might still be
rough consensus
[...Sybil attack] it is within bounds for the chair to say, "We
have objections, but the objections have been sufficiently
answered, and the objectors seem uninterested in participating
in the discussion. Albeit rough in the extreme, there is rough
consensus to go with the current solution."
[...] it is likely that if a working group got this
dysfunctional, it would put the whole concept of coming to rough
consensus at risk. But still, the correct outcome in this case
is to look at the very weak signal against the huge background
noise in order to find the rough consensus.
9. Security Considerations
"He who defends with love will be secure." -- Lao Tzu