Re: [bitcoin-dev] BIP process friction

Perhaps a BIP 3 is in order, but most of the real issue is simply a matter of volunteer time. AJ's attempt to conflate that with his own personal disagreements with how BIPs have always worked, is unrelated. Luke On 1/17/24 01:55, Christopher Allen via bitcoin-dev wrote: On Tue, Jan 16,

Re: [bitcoin-dev] Swift Activation - CTV

This IS INDEED an attack on Bitcoin. It does not activate CTV - it would (if users are fooled into using it) give MINERS the OPTION to activate CTV. Nobody should run this, and if it gets any traction, it would behoove the community to develop and run a "URSF" making blocks signalling for it

Re: [bitcoin-dev] Ordinals BIP PR

oo difficult to find a workable scheme. Thoughts? -- Laolu On Mon, Oct 23, 2023 at 11:35 AM Luke Dashjr via bitcoin-dev wrote: Everything standardized between Bitcoin software is eligible to be and should be a BIP. I completely disagree with the claim that it's used for

Re: [bitcoin-dev] Ordinals BIP PR

Everything standardized between Bitcoin software is eligible to be and should be a BIP. I completely disagree with the claim that it's used for too many things. SLIPs exist for altcoin stuff. They shouldn't be used for things related to Bitcoin. BOLTs also shouldn't have ever been a

Re: [bitcoin-dev] Concern about "Inscriptions"

Storage is not and never has been the trouble with block sizes. Please, before participating in discussions of this topic, at least get a basic understanding of it. Here's a talk I did a few years ago to get you started: https://www.youtube.com/watch?v=CqNEQS80-h4=7s Luke On 8/2/23 07:07,

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

Action should have been taken months ago. Spam filtration has been a standard part of Bitcoin Core since day 1. It's a mistake that the existing filters weren't extended to Taproot transactions. We can address that, or try a more narrow approach like OP_RETURN (ie, what "Ordisrespector" does).

Re: [bitcoin-dev] BIP for OP_VAULT

heers, Greg On Sat, Mar 11, 2023 at 3:53 PM Luke Dashjr via bitcoin-dev wrote: I started reviewing the BIP, but stopped part way through, as it seems to have a number of conceptual issues. I left several comments on the PR (https://github.c

Re: [bitcoin-dev] BIP for OP_VAULT

I started reviewing the BIP, but stopped part way through, as it seems to have a number of conceptual issues. I left several comments on the PR (https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575), but ultimately I think it isn't simplified enough for day-to-day use, and

Re: [bitcoin-dev] Using service bit 24 for utreexo signaling in testnet and signet

This sounds like something that should be written up as a BIP and use a normal service bit assignment...? Luke On 3/2/23 01:55, kcalvinalvin via bitcoin-dev wrote: Hello all, Wanted to tell the mailing list that I'll be using service bit 24 (1 << 24) to signal that nodes are Utreexo

Re: [bitcoin-dev] On mempool policy consistency

More generally, some of the arguments against full RBF seem like debatable reasons (though not fully convincing) to possibly leave it off, and/or disabled by default, but definitely NOT reasons to remove the option and prevent users from deciding for themselves. On Thursday 27 October 2022

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

On Friday 07 October 2022 16:20:49 Dario Sneidermanis via bitcoin-dev wrote: > At the time, we understood we had at least a year from the initial opt-in > deployment until opt-out was deployed, giving us enough time to adapt Muun > to the new policies. Policies are a per-node decision, and cannot

Re: [bitcoin-dev] BIP-notatether-signedmessage

On Friday 05 August 2022 04:05:56 Ali Sherief wrote: > Yeah, I have a specific reason to advance this first (emphasis on the word > first). > > I briefly mentioned in the BIP that BIP322 has superior message > verification capabilities. This is true, but it suffers from the drawback > that wallets

Re: [bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs

Policy is a subjective per-node, not systemic, not enforcable or expectable, and generally not eligible for standardization. The reason BIP125 is an exception, is because it is more than just policy. It is a way for wallets and nodes to communicate. The wallet is saying "this is the policy I

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

Bitcoin Knots still uses this service bit, FWIW (though due to a bug in some older versions, it wasn't signalled by default). There are probably at least 100 nodes with full RBF already. On Wednesday 15 June 2022 02:27:20 Peter Todd via bitcoin-dev wrote: > On Mon, Jun 13, 2022 at 08:25:11PM

[bitcoin-dev] Bitcoin Knots 23.0.knots20220529 released

Bitcoin Knots version 23.0.knots20220529 is now available from: https://bitcoinknots.org/files/23.x/23.0.knots20220529/ This release includes new features, various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at GitHub:

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

There's no reason for before/after/in place. We have version bits specifically so we can have multiple deployments in parallel. But none of this ST nonsense, please. That alone is a reason to oppose it. Luke On Friday 22 April 2022 11:11:41 darosior via bitcoin-dev wrote: > I would like to

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

On Thursday 21 April 2022 06:20:15 Jeremy Rubin wrote: > > While reverting Segwit wouldn't be possible, it IS entirely possible to > > do an additional softfork to either weigh witness data at the full 4 > > WU/Byte rate (same as other data), or to reduce the total weight limit so > > as to extend

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

On Thursday 21 April 2022 03:10:02 alicexbt wrote: > @DavidHarding > > Interesting proposal to revert consensus changes. Is it possible to do this > for soft forks that are already activated? Generally, no. Reverting a softfork without a built-in expiry would be a hardfork. > Example: Some

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

1-2 can be mitigated to some extent by encoding an expiry height in the address (and pubkey?), and honouring CTV for UTXOs during the active period. It might take longer to remove CTV code post-deactivation, but that's simply a tradeoff to consider. The bigger issue with CTV is the

Re: [bitcoin-dev] Speedy Trial

On Friday 11 March 2022 00:12:19 Russell O'Connor via bitcoin-dev wrote: > The "no-miner-veto" concerns are, to an extent, addressed by the short > timeline of Speedy Trial. No more waiting 2 years on the miners dragging > their feet. It's still a miner veto. The only way this works is if the

Re: [bitcoin-dev] CTV BIP review

On Tuesday 18 January 2022 22:02:24 e...@voskuil.org wrote: > The only material distinction between BIP9 and BIP8 is that the latter may > activate without signaled support of hash power enforcement. > > As unenforced soft forks are not "backward compatible" they produce a chain > split.

[bitcoin-dev] CTV BIP review

tl;dr: I don't think CTV is ready yet (but probably close), and in any case definitely not worth reviving BIP 9 with its known flaws and vulnerability. My review here is based solely on the BIP, with no outside context (aside from current consensus rules, of course). In particular, I have _not_

[bitcoin-dev] Bitcoin Knots "Steel Rope" LTS 21.2.knots20210629 released

Bitcoin Knots version 21.2.knots20210629 is now available from: https://bitcoinknots.org/files/21.x/21.2.knots20210629/ This Long Term Support (LTS) "Steel Rope" release is based on the unchanged Bitcoin Knots feature set from 2021 June 29th, with only bug fixes and updated translations.

[bitcoin-dev] Bitcoin Knots 22.0.knots20211108 released

Bitcoin Knots version 22.0.knots20211108 is now available from: https://bitcoinknots.org/files/22.x/22.0.knots20211108/ This release includes new features, various bug fixes and performance improvements, as well as updated translations. Note that I also plan to release a Long-Term Support

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

All attempts are harmful, no matter the intent, in that they waste contributors' time that could be better spent on actual development. However, I do also see the value in studying and improving the review process to harden it against such inevitable attacks. The fact that we know the NSA

Re: [bitcoin-dev] Clarification on the use of getblocktemplate RPC method.

https://github.com/bitcoin/libblkmaker/blob/master/blkmaker.c#L172 On Thursday 09 September 2021 12:54:18 Mike Rosset via bitcoin-dev wrote: > Hello all, > > I recently went down the bitcoin protocol rabbit hole. I wanted to use > GNU guile scheme to experiment with bitcoin. I initially started

[bitcoin-dev] Bitcoin Knots 0.21.1.knots20210629 released

Bitcoin Knots version 0.21.1.knots20210629 is now available from: https://bitcoinknots.org/files/0.21.x/0.21.1.knots20210629/ This release includes new features, various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

that there is no collective “we”, those wants differ. Bitcoin > >>> >> resolves this question of conflicting wants, but it is not a > >>> >> democracy, it’s a market. One votes by trading. > >>> >> > >>> >> If one wants to enforce a

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can still slow it down. It also already has the trinary state you seem to be describing (although perhaps this could be better documented in the BIP): users who oppose the softfork can and should treat the successful

Re: [bitcoin-dev] Additional BIPs related to other proposals

On Friday 21 May 2021 07:56:51 Billy Tetrud via bitcoin-dev wrote: > These look like relatively well put together documents. However, they seem > relatively orthogonal to Bitcoin in that they look like protocols that > build on top of the bitcoin platform but aren't directly related to > changing

Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy

On Friday 14 May 2021 21:41:23 Michael Fuhrmann via bitcoin-dev wrote: > Bitcoin should create blocks every 10 minutes in average. So why do > miners need to mine the 9 minutes after the last block was found? It's > not necessary. It increases security, and is unavoidable anyway. > Problem: How

Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic

Is there a list of software impacted by this CVE, and the versions it is fixed in? (Note this isn't a vulnerability in Bitcoin Core; BIP125 is strictly a policy matter, not part of the consensus rules and never safe to rely on in any case...) On Thursday 06 May 2021 13:55:53 Antoine Riard

Re: [bitcoin-dev] Reminder on the Purpose of BIPs

On Sunday 25 April 2021 21:14:08 Matt Corallo wrote: > On 4/25/21 17:00, Luke Dashjr wrote: > > I will not become an accomplice to this deception by giving special > > treatment, and will process the BIP PR neutrally according to the > > currently-defined BIP process. > > Again, please don't play

Re: [bitcoin-dev] Reminder on the Purpose of BIPs

On Sunday 25 April 2021 20:29:44 Matt Corallo wrote: > If the BIP editor is deliberately refusing to accept changes which the > author's approval (which appears to be occurring here), It isn't. I am triaging BIPs PRs the same as I have for years, and will get to them all in due time, likely

Re: [bitcoin-dev] BIPs - notarization protocol and decentralized storage

On Wednesday 21 April 2021 04:26:26 Prayank via bitcoin-dev wrote: > Also since this involves LN, maybe it can just be a LN project instead of > BIP? Not the best person to comment on what can be a BIP. Anything that Bitcoin software would benefit in collaboration with other projects on

[bitcoin-dev] Proposed BIP editor: Kalle Alm

Unless there are objections, I intend to add Kalle Alm as a BIP editor to assist in merging PRs into the bips git repo. Since there is no explicit process to adding BIP editors, IMO it should be fine to use BIP 2's Process BIP progression: > A process BIP may change status from Draft to Active

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

(To reiterate: I do not intend any of this as a NACK of Taproot.) On Monday 15 March 2021 22:05:45 Matt Corallo wrote: > > First, so long as we have hash-based addresses as a best practice, we can > > continue to shrink the percentage of bitcoins affected through social > > efforts discouraging

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

I do not personally see this as a reason to NACK Taproot, but it has become clear to me over the past week or so that many others are unaware of this tradeoff, so I am sharing it here to ensure the wider community is aware of it and can make their own judgements. Mark Friedenbach explains on

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

eek but a precedent of 24 hour notice > > > meetings for non urgent changes is very negative. > > > > > > (This isn't any comment on if ST is OK or not -- the schedules proposed > > > > for > > > > > ST thus far seem acceptable to me) > > &g

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

e to me) > > Best, > > Jeremy > -- > @JeremyRubin <https://twitter.com/JeremyRubin> > <https://twitter.com/JeremyRubin> > > > On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > At th

[bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

At the previous meeting, there was consensus for BIP8 activation parameters except for LOT, assuming a release around this time. Since then, a release has not occurred, and the new idea of Speedy Trial has been proposed to preempt the original/main activation plan. It's probably a good idea to

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

The last period before timeoutheight here overlaps with the current BIP8(True) deployment plan. So if this period specifically were to reach 90% signalling, nodes would activate Taproot at height 697536, but ST-only nodes would still wait until 709632 instead. Probably the best solution is to

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

On Friday 05 March 2021 14:51:12 Ryan Grant via bitcoin-dev wrote: > 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

Re: [bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel

On Tuesday 02 March 2021 18:22:35 Ariel Lorenzo-Luaces via bitcoin-dev wrote: > I'm realizing that a clear advantage of LOT=false is that it can happen > without the need for a social movement. All that is really needed is the > convincing of 95% miners. Apathetic users will never notice any kind

Re: [bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC

Answering the F1-F7 arguments for LOT=False... > F1) The probability of Taproot not being activated by miners is small. This > is not 2017, this is not SegWit, there is no need to worry. While we believe miners have no reason to sabotage Taproot activation, this was also the belief leading up

[bitcoin-dev] LOT=False is dangerous and shouldn't be used

(Note: I am writing this as a general case against LOT=False, but using Taproot simply as an example softfork. Note that this is addressing activation under the assumption that the softfork is ethical and has sufficient community support. If those criteria have not been met, no activation

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

On Sunday 28 February 2021 16:45:22 Matt Corallo via bitcoin-dev wrote: > many individuals are committing themselves to running > incompatible consensus rules. Yet that is exactly what you propose herein... > Given this, it seems one way to keep the network in consensus would be to > simply

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

This has the same problems BIP149 did: since there is no signalling, it is ambiguous whether the softfork has activated at all. Both anti-SF and pro-SF nodes will remain on the same chain, with conflicting perceptions of the rules, and resolution (if ever) will be chaotic. Absent resolution,

[bitcoin-dev] Bitcoin Knots 0.21.0.knots20210130 released

Bitcoin Knots version 0.21.0.knots20210130 is now available from: https://bitcoinknots.org/files/0.21.x/0.21.0.knots20210130/ This release includes new features, various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at

Re: [bitcoin-dev] BIP Proposal: Wallet Interface

1) People should not be encouraged to write or use web browsers for their wallet. 2) You may want to look over earlier work in this area. On Tuesday 22 December 2020 14:43:11 monokh via bitcoin-dev wrote: > Hi > > This is a first draft of a BIP we intend to submit. The main intention is > to

Re: [bitcoin-dev] bip48 proposal

Thanks for explaining where instructions are lacking. How does this look? https://github.com/bitcoin/bips/pull/1046/files On Friday 18 December 2020 01:44:27 dentondevelopment wrote: > Hi Luke, > > It looks to have the same motivations and be compatible with >

Re: [bitcoin-dev] bip48 proposal

BIP number 48 has not been assigned. Do not self-assign BIP numbers. Is this intended to be compatible with https://github.com/bitcoin/bips/pull/253 ? Luke On Wednesday 16 December 2020 14:10:28 dentondevelopment via bitcoin-dev wrote: > Here is the repo instead of a static link: >

Re: [bitcoin-dev] BIP - Automated and Secure Communication

Anything that makes sense to coordinate between different programs is BIP material, not just core Bitcoin protocol... On Sunday 06 December 2020 19:14:13 yanmaani--- via bitcoin-dev wrote: > The reason Samourai did not propose a BIP is that that was not a > proposal to improve the Bitcoin

[bitcoin-dev] Bitcoin Knots 0.20.1.knots20200815 released

Bitcoin Knots version 0.20.1.knots20200815 is now available from: https://bitcoinknots.org/files/0.20.x/0.20.1.knots20200815/ This release includes new features, various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at

[bitcoin-dev] Bitcoin Knots 0.20.0.knots20200614 released

Bitcoin Knots version 0.20.0.knots20200614 is now available from: https://bitcoinknots.org/files/0.20.x/0.20.0.knots20200614/ This release includes new features, various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at

Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote: > Trust-minimization of Bitcoin security model has always relied first and > above on running a full-node. This current paradigm may be shifted by LN > where fast, affordable, confidential, censorship-resistant payment services >

[bitcoin-dev] Bitcoin Knots 0.19.1.knots20200304 released

Bitcoin Knots version 0.19.1.knots20200304 is now available from: https://bitcoinknots.org/files/0.19.x/0.19.1.knots20200304/ This release includes new features, various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at

Re: [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion

In addition to starting with proof-of-funds instead of proof-of-receiver, it would be nice to integrate with Taproot somehow or another. Perhaps OP_MESSAGEONLY is the most straightforward way to do this? It might be a good idea to have a message type after the opcode too. On Wednesday 04 March

[bitcoin-dev] Bitcoin Knots 0.19.0.1.knots20200104 released

Bitcoin Knots version 0.19.0.1.knots20200104 is now available from: https://bitcoinknots.org/files/0.19.x/0.19.0.1.knots20200104/ This release includes new features, various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at

Re: [bitcoin-dev] Modern Soft Fork Activation

On Saturday 11 January 2020 14:42:07 Anthony Towns wrote: > the UASF approach had significant potential technical problems >        (potential for long reorgs, p2p network splits) that weren't >        resolved by the time it became active. Long reorgs, only for old nodes, were a possibility,

Re: [bitcoin-dev] Modern Soft Fork Activation

I think BIP 9 is a proven failure, and flag day softforks have their own problems: A) There is no way to unambiguously say "the rules for this chain are ". It leaves the chain in a kind of "quantum state" where the rules could be one thing, or could be another. Until the new rules are

[bitcoin-dev] CVE-2018-20586 disclosure (log injection vulnerability)

CVE-2018-20586 is a log injection vulnerability which allows any software with access to the RPC port to create fake or confusing entries in the debug log. Valid authentication (username/password/cookie) for the RPC service is NOT required to exploit this vulnerability, only the ability to

Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution

On Monday 11 November 2019 17:10:16 Hampus Sjöberg wrote: > > It ISN'T low right now... > > I agree, but I don't think it's a good idea to softfork it to lower than 4M > WU though, and I don't think we need to; > hopefully when exchanges start using Lightning or Liquid, avg blocksize > will go

Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution

On Monday 11 November 2019 16:08:43 Hampus Sjöberg via bitcoin-dev wrote: > I am advocating to keep the blocksize low right now, It ISN'T low right now... > but I don't leave out > in increasing it in the future when we have a need for it, preferably via > an extension block (softfork).

[bitcoin-dev] CVE-2017-18350 disclosure

CVE-2017-18350 is a buffer overflow vulnerability which allows a malicious SOCKS proxy server to overwrite the program stack on systems with a signed `char` type (including common 32-bit and 64-bit x86 PCs). The vulnerability was introduced in 60a87bce873ce1f76a80b7b8546e83a0cd4e07a5 (SOCKS5

Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'

On Saturday 05 October 2019 21:57:48 Emil Engler via bitcoin-dev wrote: > Hello dear mailing list subscribers. > Before I'll explain my idea here, I need to define a term first > > 'address': > When I use the terms address, pubkey, etc., I mean the same: The Base58 > string But a pubkey is not a

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

On Tuesday 23 July 2019 14:47:18 Andreas Schildbach via bitcoin-dev wrote: > 3) Afaik, it enforces/encourages address re-use. This stems from the > fact that the server decides on the filter and in particular on the > false positive rate. On wallets with many addresses, a hardcoded filter > will

Re: [bitcoin-dev] Absent authors and BIP updates

On Tuesday 23 July 2019 15:09:02 Karl-Johan Alm via bitcoin-dev wrote: > People come in as Bitcoin developers all the time, but sometimes > people also leave permanently. In the case of BIP authors, when a user > leaves and does not respond to (reasonable) requests to change their > BIPs, we are

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

On Tuesday 23 July 2019 14:47:18 Andreas Schildbach via bitcoin-dev wrote: > > the DNS seed infrastructure among others can easily direct > > wallets to those nodes > > Last I checked none of the seeds did. But I agree this would be nice to > have. It's supported by default in sipa's

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

On Monday 22 July 2019 18:52:10 Peter via bitcoin-dev wrote: > Privacy is a matter of individual choice in the current protocol. Why not > let people provide this network service? I don't see why it should be > end-of-life if it provides value. It's not EOL, just disabled by default. Anyone can

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

On Sunday 21 July 2019 22:56:33 Andreas Schildbach via bitcoin-dev wrote: > An estimated 10+ million wallets depend on that NODE_BLOOM to be > updated. Where do you see this number? I think it would be useful to chart. > So far, I haven't heard of an alternative, except reading all >

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

On Monday 22 July 2019 13:25:25 Jonas Schnelli via bitcoin-dev wrote: > > I also think as long as we don't have an alternative, we should improve > > the current filtering for segwit. E.g. testing the scripts themselves > > and each scriptPubKey spent by any input against the filter would do, > >

[bitcoin-dev] PSA: Upcoming disclosure of pre-v0.17.1 vulnerabilities

Two relatively minor vulnerabilities will likely be disclosed sometime soon. The first vulnerability, CVE-2017-18350, was introduced in v0.7.0 (released in 2012 September), and affects all versions released until the fix was included in v0.15.1 (released in 2017 November). No versions prior to

Re: [bitcoin-dev] Taproot proposal

On Monday 06 May 2019 20:17:09 Luke Dashjr via bitcoin-dev wrote: > Some way to sign an additional script (not committed to by the witness > program) seems like it could be a trivial addition. This would be especially useful for things like OP_CHECKBLOCKATHEIGHT: https://github.com/bitcoi

Re: [bitcoin-dev] Taproot proposal

There are multiple references to "space savings", but no rationale for treating "space" as something to save or even define. The costs are in CPU time and I/O (which "space saving" doesn't necessarily reduce) and bandwidth (which can often be reduced without "space saving" in commitments). The

[bitcoin-dev] Bitcoin Knots 0.18.0.knots20190502 released

Bitcoin Knots version *0.18.0.knots20190502* is now available from: This is a new major version release, including new features, various bug fixes and performance improvements, as well as updated translations. Please report bugs

Re: [bitcoin-dev] IsStandard

On Saturday 27 April 2019 10:37:29 Aymeric Vitte via bitcoin-dev wrote: > Maybe trivial question but asking here because I can't find anything > clear (or updated) about it: is somewhere explained in details what txs > are considered standard and non standard today without having to read > the

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

On Wednesday 03 April 2019 21:39:32 Dave Scotese via bitcoin-dev wrote: > Luke's comment that it could "lead to users trusting third parties (like > developers) way too much" is pertinent too, but I think an honest abatement > of that concern is impossible without teaching everyone C++. Learning

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

On Wednesday 03 April 2019 15:39:29 Ethan Scruples via bitcoin-dev wrote: > If we can get mandatory UTXO commitments soft forked into Bitcoin, we get > the advantage of a non-growing IBD, No, we don't. This is exactly the danger. UTXO snapshots are NOT an alternative to a real IBD. There are

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

This would lead to users trusting third parties (like developers) way too much. Furthermore, removing the ability for users to easily set it removes the one reasonable use case: where the user has already verified the state at some point previously, and saved the hash (ie, as backup of the

[bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC

Certain parts of the community have been selling bitcoins for unreasonably low prices. This has halted Bitcoin's valuation at $20k and even driven the price down below $15k! However, clearly Bitcoin is worth much more than that, and there is widespread support for higher prices. In light of this,

Re: [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup

On Wednesday 06 March 2019 21:39:15 Matt Corallo wrote: > I'd like to ask the BIP editor to assign a BIP number. Needs a Backward Compatibility section, and should have a bips repo PR opened after discussion on the ML. > * The 4th change (making non-standard signature hash types invalid) >

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Even besides NOINPUT, such a wallet would simply never show a second payment to the same address (or at least never show it as confirmed, until successfully spent). At least if tx versions are used, it isn't possible to indicate this requirement in current Bitcoin L1 addresses. scriptPubKey

Re: [bitcoin-dev] Safer NOINPUT with output tagging

On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-dev wrote: > While this seems fully compatible with eltoo, is there any other proposals > require NOINPUT, and is adversely affected by either way of tagging? Yes, this seems to break the situation where a wallet wants to use NOINPUT

Re: [bitcoin-dev] [BIP Proposal] Simple Proof-of-Reserves Transactions

On Tuesday 29 January 2019 22:03:04 Steven Roose via bitcoin-dev wrote: > The existence of the first input (which is just a commitment hash) ensures > that this transaction is invalid and can never be confirmed. But nodes can never prove the transaction is invalid, thus if sent it, they will

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

On Thursday 16 August 2018 02:22:21 Lautaro Dragan wrote: > > Choosing not to mine transactions is not censorship. > > Is it not, if for political rather than economical reasons? These > transactions pay fees like any other. Miners have always chosen transaction on "political" basises, and doing

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

On Wednesday 15 August 2018 21:54:50 Christopher Allen via bitcoin-dev wrote: > On Wed, Aug 15, 2018 at 2:24 PM Jude Nelson via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Can a miner identify which transactions came from your software simply by > > running a copy themselves?

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

Are you doing coloured coins or storing data? If the former, you should probably collaborate with the authors of BIP 160 (yet to be added to the main repo), and/or write a new BIP if BIP 160 is insufficient for some reason. If the latter, you just shouldn't do it at all. Note that BIPs need

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

On Monday 02 July 2018 18:11:54 Gregory Maxwell wrote: > I know it seems kind of silly, but I think it's somewhat important > that the formal name of this flag is something like > "SIGHASH_REPLAY_VULNERABLE" or likewise or at least > "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially

Re: [bitcoin-dev] Making OP_TRUE standard?

You'd send 0 satoshis to OP_TRUE, creating a UTXO. Then you spend that 0-value UTXO in another transaction with a normal fee. The idea is that to get the latter fee, the miner needs to confirm the original tranaction with the 0-value OP_TRUE. (Aside, in case it wasn't clear on my previous

Re: [bitcoin-dev] Making OP_TRUE standard?

An OP_TRUE-only script with a low value seems like a good example of where the weight doesn't reflect the true cost: it uses a UTXO forever, while only costing a weight of 4. I like Johnson's idea to have some template (perhaps OP_2-only, to preserve expected behaviour of OP_TRUE-only) that

Re: [bitcoin-dev] BloomFilter issue with segwit addresses

As I understand it, the plan is to deprecated and remove BIP37 entirely once BIP158 is implemented and deployed. In the meantime, Bitcoin Knots supports the MSG_FILTERED_WITNESS_BLOCK extension to download witness data. (Note that light clients currently have no way to verify the witness data

Re: [bitcoin-dev] {sign|verify}message replacement

On Thursday 15 March 2018 7:36:48 AM Karl Johan Alm wrote: > On Wed, Mar 14, 2018 at 12:36 PM, Luke Dashjr wrote: > > Ideally, it should support not only just "proof I receive at this > > address", but also "proof of funds" (as a separate feature) since this > > is a popular

Re: [bitcoin-dev] {sign|verify}message replacement

I don't see a need for a new RPC interface, just a new signature format. Ideally, it should support not only just "proof I receive at this address", but also "proof of funds" (as a separate feature) since this is a popular misuse of the current message signing (which doesn't actually prove

Re: [bitcoin-dev] BIP proposal: Reserved nversion bits in blockheader - stratum mining.configure

undefined, simply defining that would have been a better solution than to reinvent it incompatibly for no reason. (Although version rolling does not actually require a response at all.) > > > On Wed, 7 Mar 2018 14:43:11 +0000 Luke Dashjr via bitcoin-dev > > <bitcoin-dev@lists

Re: [bitcoin-dev] BIP proposal: Reserved nversion bits in blockheader

Why are you posting this obsolete draft? You've already received review in private, and been given useful suggestions. There's even a shared Google Doc with the current draft: https://docs.google.com/document/d/1GedKia78NUAtylCzeRD3lMlLrpPVBFg9TV9LRqvStak/edit?usp=sharing Again: * This

Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments

On Wednesday 14 February 2018 10:01:46 PM Marco Falke via bitcoin-dev wrote: > BIP 123 suggests that BIPs in the consensus layer should be assigned a > label "soft fork" or "hard fork". However, I think the differentiation > into soft fork or hard fork should not be made for BIPs that document >

Re: [bitcoin-dev] Possible change to the MIT license

This would give too much power to Bitcoin Core, and implies falsely that Bitcoin and Bitcoin Core are the same thing. On Tuesday 13 February 2018 12:25:53 PM JOSE FEMENIAS CAÑUELO via bitcoin-dev wrote: > Hi, > > Bitcoin is licensed under the MIT license >

Re: [bitcoin-dev] BIP 117 Feedback

On Tuesday 16 January 2018 1:06:14 AM Rusty Russell via bitcoin-dev wrote: > "Russell O'Connor" writes: > > However, if I understand correctly, the situation for BIP 117 is entirely > > different. As far as I understand there is currently no restrictions > > about

Re: [bitcoin-dev] Bech32 and P2SH²

I've posted an initial draft of a possible Bech32 revision/replacement here: https://github.com/luke-jr/bips/blob/new_bech32_p2sh2/bip-bech32-p2sh2.mediawiki On Thursday 04 January 2018 2:23:05 PM Luke Dashjr via bitcoin-dev wrote: > I know I'm super-late to bring this up, but was there a rea

  1   2   3   >