Re: [bitcoin-dev] ossification and misaligned incentive concerns

On Fri, Nov 3, 2023 at 8:59 PM Erik Aronesty via bitcoin-dev wrote: > is anyone else worried about this? Yes. +1 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed BIP for OP_CAT

I support OP_CAT, along with reasonable resource-consumption limiters. Implementation as a UASF would help build confidence in that method. I also support moving forward on other opcodes as soon as they are known to be safe and maintainable; whether for introspection, tx unpinning, or vaults.

Re: [bitcoin-dev] On a new community process to specify covenants

On Mon, Sep 12, 2022 at 2:47 AM Buck O Perley via bitcoin-dev 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.

Re: [bitcoin-dev] Regarding BIP322 edge cases

>> 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 wrote: > In the case of the last

Re: [bitcoin-dev] On a new community process to specify covenants

+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

Re: [bitcoin-dev] Trying all address types in message signing verification (BIP)

On Wed, Jul 20, 2022 at 9:46 PM Peter (Coinkite Inc) via bitcoin-dev 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)

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

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

Re: [bitcoin-dev] Bitcoin covenants are inevitable

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

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

On Sun, May 1, 2022 at 8:49 PM Jorge Timón via bitcoin-dev wrote: > On Sun, May 1, 2022, 09:22 alicexbt via bitcoin-dev > wrote: >> [...] Andreas is clueless about BIP 119 and other covenant >> proposals. He is spreading misinformation and [...] > Clueless and spreading disinformation, you

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

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

On Sun, Apr 24, 2022 at 1:12 PM Jorge Timón 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! ___ bitcoin-dev mailing list

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

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

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

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

Re: [bitcoin-dev] BIP118 confusion / SIGHASH_NOINPUT is now SIGHASH_ANYPREVOUT (i think)

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

[bitcoin-dev] BIP118 confusion / SIGHASH_NOINPUT is now SIGHASH_ANYPREVOUT (i think)

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

Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev 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

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

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.

Re: [bitcoin-dev] Making the case for flag day activation of taproot

On Thu, Mar 4, 2021 at 7:32 PM Keagan McClelland via bitcoin-dev 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.

Re: [bitcoin-dev] Taproot NACK

On Thu, Mar 4, 2021 at 8:48 PM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev 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

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

On Fri, Mar 5, 2021 at 9:39 AM Lonero Foundation via bitcoin-dev 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

Re: [bitcoin-dev] Exploring alternative activation mechanisms: decreasing threshold

On Sat, Feb 27, 2021 at 5:55 PM Luke Dashjr via bitcoin-dev 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

Re: [bitcoin-dev] Exploring alternative activation mechanisms: decreasing threshold

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

Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)

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

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

On Wed, Aug 15, 2018 at 8:40 PM, Jude Nelson via bitcoin-dev 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

Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

On Fri, Feb 9, 2018 at 7:29 AM, Jeremy 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.

Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

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?

Re: [bitcoin-dev] Decoupling BIP70 Payment Protocol from Wallets

On Mon, Jan 1, 2018 at 1:50 PM, James Hilliard via bitcoin-dev 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

Re: [bitcoin-dev] extended BIP9 activation of segwit, for legacy nodes

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

Re: [bitcoin-dev] BIP149 timeout-- why so far in the future?

Is there any reason that BIP149 activation on November 16th would cause a problem? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Treating ‘ASICBOOST’ as a Security Vulnerability

On Thu, May 18, 2017 at 9:44 AM, Cameron Garnham via bitcoin-dev 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

[bitcoin-dev] extended BIP9 activation of segwit, for legacy nodes

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

Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in

Praxeology Guy, On Fri, Apr 7, 2017 at 12:56 PM, praxeology_guy 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

Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in

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. ___

Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY

On Wed, Nov 2, 2016 at 1:30 PM, Russell O'Connor via bitcoin-dev 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

Re: [bitcoin-dev] 1 Year bitcoin-dev Moderation Review

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? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses

On Thu, Feb 4, 2016 at 5:17 PM, Luke Dashjr 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

Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses

On Mon, Feb 1, 2016 at 6:53 PM, Luke Dashjr via bitcoin-dev 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