[bitcoin-dev] BIP status updates & BIP 2 activation

To conclude discussion on BIP 2, I have opened a pull request to implement it and mark it active. Note this implies activation and implementation of BIP 123 as well: https://github.com/bitcoin/bips/pull/478 I plan to merge this on December 14th. If there are any hard objections to this change,

Re: [bitcoin-dev] New BIP: Hardfork warning system

On Thursday, December 01, 2016 5:20:31 PM Johnson Lau via bitcoin-dev wrote: > Any bitcoin implementation (full nodes and light nodes) supporting this > softfork should also implement a hardfork warning system described below. I think this "should" needs to be a "must" be make this useful. > Hard

Re: [bitcoin-dev] New BIP: Hardfork warning system

On Friday, December 02, 2016 1:42:46 AM Jorge Timón via bitcoin-dev wrote: > We can already warn users of a hardfork when a block is invalid (at > least) because of the highest bit in nVersion (as you say, because it > is forbidden since bip34 was deployed). The difference is that right now, full

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev wrote: > On Sun, Dec 4, 2016 at 7:34 PM, Johnson Lau via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Something not yet done: > > 1. The new merkle root algorithm described in the MMHF BIP > > Any new merkle

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

On Wednesday, December 14, 2016 11:01:58 AM Johnson Lau via bitcoin-dev wrote: > There is no reason to use a timestamp beyond 4 bytes. Actually, there is: lock times... my overflow solution doesn't have a solution to that. :x ___ bitcoin-dev mailing lis

Re: [bitcoin-dev] BIP - Block75 - Managing max block size as we do difficulty

Please use ASCII quotes in the Title. It is also too long (max size 44 characters). Add missing headers: Layer: Consensus (hard fork) Comments-Summary: No comments yet. Comments-URI: TBD Status: Draft Type: Standards Track License: PD It must be made at least technically sound. The B

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

On Monday, January 02, 2017 6:04:37 PM t. khan via bitcoin-dev wrote: > Thoughts? For any predictions as to how this would behave, please provide > the numbers used to arrive at any conclusions. It would probably behave as an ever-increasing block size limit. Spam has typically filled blocks to t

[bitcoin-dev] [Meta] Re: Bitcoin Core 0.13.2 released

I don't think release announcements are really appropriate for the bitcoin-dev mailing list. People who want these can subscribe to the bitcoin-core-dev list and/or the Core announce mailing list. Maybe sending to bitcoin-discuss would also make sense, but not bitcoin-dev... Luke On Tuesday,

Re: [bitcoin-dev] Mutli-push op_return

On Monday, January 09, 2017 2:09:09 AM Chris via bitcoin-dev wrote: > Would there be an objection to making op_return outputs with two > pushdatas standard (same max data size)? Standards (BIPs) need to describe a specific use case and protocol for doing it. As you note, the default policy on mo

[bitcoin-dev] Three hardfork-related BIPs

I've put together three hardfork-related BIPs. This is parallel to the ongoing research into the MMHF/SHF WIP BIP, which might still be best long-term. 1) The first is a block size limit protocol change. It also addresses three criticisms of segwit: 1) segwit increases the block size limit which

Re: [bitcoin-dev] Three hardfork-related BIPs

On Friday, January 27, 2017 3:04:50 AM Andrew Johnson wrote: > Comment on #1. You're dropping the blocksize limit to 300KB and only > reaching the limit that we have in place today 7 years later? The limit only drops all the way to 300k if it activates before 2017 April. Considering that this re

Re: [bitcoin-dev] Three hardfork-related BIPs

On Friday, January 27, 2017 11:53:02 PM Andrew Johnson via bitcoin-dev wrote: > I don't think that the 17% yearly increase is too far off base considering > current global trends(although I still don't particularly like the idea of > centrally planning the limit, especially not that far into the fu

Re: [bitcoin-dev] Three hardfork-related BIPs

On Saturday, January 28, 2017 10:36:16 AM Natanael wrote: > Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org>: > > Satoshi envisioned a system where full nodes could publish proofs of > > invalid blocks that woul

Re: [bitcoin-dev] [Pre-BIP] Community Consensus Voting System

Strongly disagree with buying "votes", or portraying open standards as a voting process. Also, this depends on address reuse, so it's fundamentally flawed in design. Some way for people to express their support weighed by coins (without losing/spending them), and possibly weighed by running a f

Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP

My BIP draft didn't make progress because the community opposes any block size increase hardfork ever. Your version doesn't address the current block size issues (ie, the blocks being too large). So you've retained the only certain- DOA parts of my proposal, and removed the most useful part... I'

[bitcoin-dev] Bitcoin Knots 0.14.0 release candidate 1 available

Release candidate 1 of a new major Bitcoin Knots release, version 0.14.0, has been made available. This is a release candidate for a new major version release, including new features, various bugfixes and performance improvements. Preliminary release notes for the release can be found here:

[bitcoin-dev] Bitcoin Knots 0.14.0 release candidate 2 available

Release candidate 2 of a new major Bitcoin Knots release, version 0.14.0, has been made available. This is a release candidate for a new major version release, including new features, various bugfixes and performance improvements. Preliminary release notes for the release can be found here:

Re: [bitcoin-dev] Moving towards user activated soft fork activation

Without at least a majority hashrate validating blocks, it is possible just a single invalid block could split the chain such that the majority continue building a most-work on that invalid block. This failure to validate a softfork is similar in some respects to a hardfork, but with one critic

[bitcoin-dev] Currency/exchange rate information API

Investigating what it would take to add fiat currency information to Bitcoin Knots, I noticed Electrum currently has many implementations, one for each exchange rate provider, due to lack of a common format for such data. Therefore, I put together an initial draft of a BIP that could standardise

Re: [bitcoin-dev] Currency/exchange rate information API

On Monday, March 06, 2017 5:37:24 AM Tim Ruffing via bitcoin-dev wrote: > But ignoring this, the server should be authenticated at a > minimum. Otherwise manipulating exchange rates seems to be a nice > way for the attacker on the wire to make money... HTTPS would be used for that. It's not someth

Re: [bitcoin-dev] Currency/exchange rate information API

On Monday, March 06, 2017 9:54:16 PM Tim Ruffing wrote: > Having the rate at the time of payment is indeed very useful, yes. > However that requires just a single value per payment, and there is no > query that tells the server "give me the value closest to timestamp t" > or similar. > Of course th

Re: [bitcoin-dev] Currency/exchange rate information API

On Monday, March 06, 2017 10:02:53 PM Tim Ruffing via bitcoin-dev wrote: > For longpolling, maybe we would like to have the possibility to request > some periodic message from the server. Otherwise clients cannot > distinguish between the situations 1. "value is still in the requested > bounds (min

Re: [bitcoin-dev] Flag day activation of segwit

On Sunday, March 12, 2017 3:50:27 PM shaolinfry via bitcoin-dev wrote: > // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 > inclusive if (pindex->GetMedianTimePast() >= 1538352000 && > pindex->GetMedianTimePast() <= 1510704000 && > !IsWitnessEnabled(pindex->pprev, chainparams.G

[bitcoin-dev] Payment address tokens

I've put together a fairly incomplete BIP draft for a new stateless address format that aims to address the many shortcomings of current addresses, including: - Current addresses special-case specific transaction types, and have needed sender-side upgrades for new types. - Outputs are produced

Re: [bitcoin-dev] Requirement for pseudonymous BIP submissions

On Saturday, March 18, 2017 3:23:16 PM Chris Stewart via bitcoin-dev wrote: > There is inconvenience added here. You need to make a new email address, > you need to make a new github account to submit the BIP. GitHub doesn't allow people to have multiple accounts last I checked. Luke ___

[bitcoin-dev] Fraud proofs for block size/weight

Despite the generalised case of fraud proofs being likely impossible, there have recently been regular active proposals of miners attacking with simply oversized blocks in an attempt to force a hardfork. This specific attack can be proven, and reliably so, since the proof cannot be broken withou

Re: [bitcoin-dev] Fraud proofs for block size/weight

On Thursday, March 23, 2017 6:27:39 PM Jorge Timón via bitcoin-dev wrote: > I think it would be clearer to put the "Creation of proofs" section > before "Proof verification", maybe even before "Proof format" if a > high level defintion of "full tx size proof" is provided before. Creation of proofs

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

On Tuesday, March 28, 2017 5:34:23 PM Johnson Lau via bitcoin-dev wrote: > You are probably not the first one nor last one with such idea. Actually, > Luke wrote up a BIP with similar idea in mind: > > https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki >

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

On Tuesday, March 28, 2017 8:53:30 PM Alphonse Pace via bitcoin-dev wrote: > His demand (not suggestion) allows it without any safeguards. > > >This patch must be in the immediate next release of Bitcoin Core. > > That is not a suggestion. I think it was probably a design requirement more than a

Re: [bitcoin-dev] Strong Anti-Replay via Coinbase Transactions

On Saturday, March 25, 2017 3:30:22 AM Cameron Garnham via bitcoin-dev wrote: > ==Definitions== It's blank? > ==Specification== > > Upon activation of the soft-fork (activation methodology undefined in this > proposal), the following new rules become activated on the Bitcoin > Network. The acti

Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool)

On Thursday, March 30, 2017 9:34:31 AM Natanael via bitcoin-dev wrote: > You want to really make sure your transaction gets processed quickly? > Transactions could have a second fee type, a specially labeled > anyone-can-spend output with an op_return value defining a "best-before" > block number a

Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)

On Monday, April 03, 2017 9:06:02 AM Sancho Panza via bitcoin-dev wrote: > While BIP9 has served the community reasonably well until now, the > author remarks several shortcomings in its approach: > > - it limits itself to backward-compatible changes, precluding its > applicability to hard forks

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

Recently there has been some discussion of an apparent work-in-progress extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor Indutny, and Steven Pair. Since this hasn't been formally posted on the ML yet, perhaps it is still in pre-draft stages and not quite ready for review, but

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

On Wednesday, April 05, 2017 9:37:45 PM Gregory Maxwell via bitcoin-dev wrote: > Beginning block X and until block Y the coinbase transaction of > each block MUST either contain a BIP-141 segwit commitment or a > correct WTXID commitment with ID 0xaa21a9ef. Why not simply require the BIP-141 commi

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

On Wednesday, April 05, 2017 4:54:05 PM Christopher Jeffrey via bitcoin-dev wrote: > There's understandable confusion about this, but this proposal is not > meant to be a BIP. Oh? If this was not meant to be a Bitcoin Improvement Proposal, perhaps you should clarify somewhere what altcoin you ar

Re: [bitcoin-dev] A Small Modification to Segwit

I think it might be important that the mandatory commitment expire as in Greg's proposal - when we do eventually hardfork, it will be simpler to do in a safe manner if such a commitment in the fake "old block" is not required. I don't like your proposal because it allows ASICBoost. ASICBoost eff

Re: [bitcoin-dev] A Small Modification to Segwit

On Saturday, April 08, 2017 3:17:47 PM Jimmy Song wrote: > Overt ASICBoost is allowed on the network already. Until a proposal > explicitly blocking overt ASICBoost as a soft fork is activated, this seems > to be better than the current state which is that overt ASICBoost is > allowed, but at a cos

[bitcoin-dev] Segwit v2

Since BIP 141's version bit assignment will timeout soon, and needing renewal, I was thinking it might make sense to make some minor tweaks to the spec for the next deployment. These aren't critical, so it's perfectly fine if BIP 141 activates as-is (potentially with BIP 148), but IMO would be a

Re: [bitcoin-dev] I do not support the BIP 148 UASF

On Tuesday 25 April 2017 6:28:14 PM Gregory Maxwell via bitcoin-dev wrote: > > https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-f > > lagday > > > > I believe this approach would satisfy the more measured approach expected > > for Bitcoin and does not have the issues you bro

Re: [bitcoin-dev] Draft BIP: Segwit deployment with versionbits and guaranteed lock-in

See Segwit v2 thread. Maybe we can collaborate on combining these. On Wednesday 26 April 2017 6:15:26 PM shaolinfry via bitcoin-dev wrote: > This is a draft BIP proposal to redeploy segwit using BIP-8, from the day > after the current BIP9 segwit times out. > > This BIP could be deployed long bef

Re: [bitcoin-dev] Segwit v2

On Wednesday 26 April 2017 7:31:38 PM Johnson Lau wrote: > I prefer not to do anything that requires pools software upgrade or wallet > upgrade. So I prefer to keep the dummy marker, and not change the > commitment structure as suggested by another post. Fair enough, I guess. Although I think the

Re: [bitcoin-dev] Full node "tip" function

I think paying for services is in general a great idea, but one that Bitcoin can much better serve once Lightning is in production. Not only does it enable cost-effective micro-transactions, it also should allow nodes to initiate payments before they have a synced node (which is something imprac

Re: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits

> A peer signaling NODE_NETWORK_LIMITED_LOW & NODE_NETWORK_LIMITED_HIGH MUST > be capable of serving at least the last 7'056 blocks (~49 days) > (NODE_NETWORK_LIMITED_HIGH's value ^2). Is 49 days particularly useful? Would it be a problem to instead leave both- bits undefined? I'm thinking this mi

[bitcoin-dev] BIP: Block signal enforcement via tx fees

I've written a new BIP draft for OP_CHECKBLOCKVERSION to allow the community to put economic pressure on miners to deploy softforks without the extreme of a UASF. https://github.com/luke-jr/bips/blob/bip-cbv/bip-cbv.mediawiki Due to the potential for miners to maliciously block this softfor

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

On Friday 12 May 2017 10:22:14 PM Peter Todd wrote: > nVersion signaling is already technically unenforceable, in the sense that > we don't have good ways of ensuring miners actually adopt the rules > they're claiming to signal. Equally, it's users who ultimately adopt > rules, not miners, and atte

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

On Saturday 13 May 2017 4:23:41 AM Russell O'Connor wrote: > I recall chatting about this idea recently and my conclusion was the same > as Peter Todd's conclusion: this will just encourage miners to false signal > readiness with undermines both BIP 9 and BIP 8. I already explained why this isn't

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

On Saturday 13 May 2017 3:26:08 AM Eric Voskuil wrote: > If people want to influence the decisions of miners, all they need to > do is mine. Most people cannot mine except at a huge expense (profit is limited to few people via monopoly and electric costs). But more importantly, the profits from

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

On Saturday 13 May 2017 12:48:48 PM Peter Todd wrote: > > You assume users will pay for signalling of softforks prematurely. So > > long as it waits until deployment of the softfork is widespread, this > > risk is minimal. At worst, it creates risks similar to a UASF. So long > > as UASF is the alt

Re: [bitcoin-dev] I do not support the BIP 148 UASF

On Tuesday 23 May 2017 6:30:01 AM Karl Johan Alm via bitcoin-dev wrote: > Essentially, if we make a potentially very harmful option easy to > enable for users, we are putting them at risk, so yes, this is about > protecting users of the base Bitcoin Core implementation. In this case, NOT enforcing

[bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

In light of some recent discussions, I wrote up this BIP for a real 2 MB block size hardfork following Segwit BIP148 activation. This is not part of any agreement I am party to, nor anything of that sort. Just something to throw out there as a possible (and realistic) option. Note that I cannot

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

On Wednesday 31 May 2017 1:22:44 AM Jorge Timón via bitcoin-dev wrote: > Why is it > https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1661 > not enough at this point? > Why the need for a transaction size limit? Because the bottleneck is hashing the transaction, which costs (in C

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

On Tuesday 06 June 2017 10:39:28 PM Tao Effect via bitcoin-dev wrote: > I believe the severity of replay attacks is going unvoiced and is not > understood within the bitcoin community because of their lack of > experience with them. Replay is a solved problem. It can be improved on and made simple

[bitcoin-dev] BIP148 temporary service bit (1 << 27)

To ease the transition to BIP148 and to minimise risks in the event miners choose to perform a chain split attack, at least Bitcoin Knots will be using the temporary service bit (1 << 27) to indicate BIP148 support. Once the transition is complete, this will no longer be necessary, and the bit

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

On Friday, July 17, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote: > BIP PR: https://github.com/bitcoin/bips/pull/173 I'm concerned that miners are prematurely bumping their soft limit to 1 MB lately. The only reason block size limit lifting is remotely reasonable is if we can trust miners t

Re: [bitcoin-dev] BIP Draft: Minimum Viable TXIn Hash

On Thursday, July 23, 2015 8:12:19 PM Jeremy Rubin via bitcoin-dev wrote: > Please see the following draft BIP which should decrease the amount of > bytes needed per transaction. This is very much a draft BIP, as the design > space for this type of improvement is large. > > This BIP can be rolled

Re: [bitcoin-dev] Alternative chain support for payment protocol

On Monday, August 10, 2015 6:32:10 PM Ross Nicoll wrote: > BTW, did you mean to take this off-list? No, accidental. I'll re-CC it on this email. > On 10/08/2015 00:46, Luke Dashjr wrote: > > On Sunday, August 09, 2015 2:12:24 PM Ross Nicoll via bitcoin-dev wrote: > >> BIP 70 currently lists two n

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

On Tuesday, September 01, 2015 1:30:17 PM Ahmed Zsales via bitcoin-dev wrote: > Rationale and details of our draft BIP for discussion and evaluation are > here: > > https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=shari > ng BIPs should be in MediaWiki-compatible markdown for

Re: [bitcoin-dev] BIP 100 repo

On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev wrote: > The repo: https://github.com/jgarzik/bip100 What is the purpose of the newly added 1 MB floor? It seems clear from the current information available that 1 MB is presently too high for the limit, and it is entirel

Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43

On Tuesday, June 30, 2015 5:53:05 PM Justus Ranvier wrote: > Monetas has developed a Bitmessage address derivation method from an > HD seed based on BIP-43. > > https://github.com/monetas/bips/blob/bitmessage/bip-bm01.mediawiki > > We're proposing this as a BIP per the BIP-43 recommendation in ord

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

On Friday, September 04, 2015 12:30:50 AM Andy Chase via bitcoin-dev wrote: > Here's a BIP. I wrote the BIP mostly to stir the pot on ideas of > governance, but I’m moderately serious about it. Sigh. There is *no governance at all*. Any such a BIP like this needs to document the natural forces in

Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43

On Friday, September 04, 2015 5:48:48 PM Justus Ranvier wrote: > On 09/03/2015 07:06 PM, Luke Dashjr via bitcoin-dev wrote: > > Since BIP 43 is still a draft, I propose modifying it to refer non- > > > > Bitcoin purpose codes to the SLIP repository: > > https:

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

On Friday, September 04, 2015 8:13:18 PM Andy Chase via bitcoin-dev wrote: > Who makes high-level Bitcoin decisions? Miners, client devs, merchants, or > users? Let's set up a system where everyone has a say and clear acceptance > can be reached. For hardforks (removing consensus rules), economic

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

On Friday, September 04, 2015 9:36:42 PM Andy Chase wrote: > I understand your concerns. What kinds of changes do you think should go > through a process like this? Just hard forks? The process loses meaning if it doesn't reflect reality. So only hardforks should go through the hardfork process;

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

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

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 protoc

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: > https://g

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 > https://github.com/bitcoin/bips/pull

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 defi

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

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

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 activ

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

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 to

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 o

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 c

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 j

[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 meeting on IRC - Tuesday 16th March 19:00 UTC

s far seem acceptable 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> wr

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

gt; > It sucks to lose another week 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

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

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 ad

[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] 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 qualifies

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 befor

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 d

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 via

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 t

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 h

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 signa

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

of what people want. > >>> >> Given 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. > >>> >&g

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

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 by

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 engag

[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 21.

[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. Pleas

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

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

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 ful

<    1   2   3   4   >