On Tue, Oct 12, 2021 at 5:34 PM Prayank via bitcoin-dev
> Hi Michael,
> Agree with almost everything.
> > Miner signaling is a tool for signaling readiness. It is not voting for the
> > soft fork or expressing support for the soft fork. There should not be any
> > attempt to
"Softforks arentcompatible without miner enforcement"
Compatible with what?
"Softforks without miner support cause splits".
No, what causes splits are 3 things:
2) coordination mistakes
3) people wanting different rules.
Let me give an example. Let's say all users want change A.
"Confirmation" isn't needed for softforks. Miners controlling confirmation
doesn't mean miners control the rules, they never did. Read section 11 of
the bitcoin paper "even with a majority of hashrate one cannot arbitrarily
change rules or forge signatures.
You may say users chosing the rules is
I think the option of "permanent failure because miners veto" should
actually be abandoned.
No, I don't think we should avoid splits when possible, I don't think we
should avoid splits at all costs.
On Sun, Jun 27, 2021, 19:12 Billy Tetrud wrote:
> > They can still slow it down.
If different users want different incompatible things (enough on each
side), there's no way to avoid the split. We shouldn't try to avoid
such a split.
Users decide the rules, not miners nor developers.
On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
> Ultimately there is
Sounds really interesting, thanks. Making CPFP reliable would be very nice
in my opinion.
On Sat, May 29, 2021, 14:24 Antoine Riard via bitcoin-dev <
> Hi Mark and Clara,
> Great research, thanks for it!
> Few questions out of mind after a first
Sure, many things that were though only possible with hardforks initially
were later shown to be possible with softforks.
That doesn't mean hardforks should be taboo in my opinion though.
On Mon, May 24, 2021, 01:09 vjudeu via bitcoin-dev <
Your analysis is correct.
In perfect competition, profits tend to zero, which means the costs of
mining tend to equal the reward.
Since the reward is fees plus subsidy, reducing the subsidy should reduce
I think convincing other users we need such a softfork to reeuce the
Hardforks can be useful too.
But, yes, I agree softforks are preferable whenever possible.
On Sat, May 22, 2021, 20:55 Raystonn . wrote:
> None of these required a hard fork. I should rephrase my previous email
> to clarify the intended topic as hard consensus changes, requiring a hard
That is clearly not true. People entretain making changes to the protocol
all the time. Bitcoin is far from perfect and not improving it would be
stupid in my opinion.
Some improvements require changes to the consensus rules.
Recent changes include relative lock time verify or segwit. These are
> Despite the continual harassment, I have even made two efforts to try to
> (fairly) make things faster, and have been obstructed both times by ST
> advocates. It appears they intend to paint me as "deliberately refusing"
> use your words) in order to try to put Bitcoin and the BIP process
So the only thing that seemed clear, using height as per bip8, it's not
And, as usual, we're not talking about activation in general but about
taproot activation, segwit activation...
I won't make it to the meeting because I don't think I have much more to
contribute that I haven't
This has no advantage over bip8(true).
Bip9(false) is just bip9.
Thr only reasonable argument against bip8(true) is "some people may do
bip8(false) instead", which is a stypid argument applyable to any
People against taproot should want code to forbid its
Just to clarify, I'm not saying bitcoin core should maintain the
"oppose proposal" part of the software. presumably people opposing the
change don't want much of the recent software changes anyway.
But perhaps it wouldn't be so bad, to oppose other proposals, perhaps.
I don't expect anyone to want
Sorry, I haven't read everything. I just want to say what I think is
the best option and why.
Let's say something like 2 years in which miners can signal activation
after which, the MUST signal it for their blocks to be valid (I think
this is LOT=true, but I don't remember what LOT stands for).
I see how your approach doesn't lose goal 3 while "mine" does.
Regarding goal 4, I don't think any of the approaches loses it. "Use
hashpower enforcement to de-risk the upgrade process, wherever
Well, in the case of activation while there's "many" non upgrade
miners, they simply can't
Well, bip9 doesn't only fall apart in case of unreasonable objection,
it also fails simply with miners' apathy.
Anyway, your proposed plan should take care of that case too, I think.
Overall sounds good to me.
Regarding bip8-like activation, luke-jr suggested that instead of
simply activating on
The complains I could imagine about this, (apart from being a very
specific use case) are the same complains I heard about op_expiry.
Namely, that in a reorg, the same tx, having been valid in a given
block could potentially become invalid in some other block mining it.
I guess in this case the
It seems we forgot
since getblockstats is only mentioned in the commits.
On Wed, Oct 3, 2018 at 12:32 PM Wladimir J. van der Laan via
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> Bitcoin Core
I only knew about ArtForz's fix, which isn't backwards compatible.
On Mon, Aug 20, 2018 at 10:14 PM, Gregory Maxwell via bitcoin-dev
op_return outputs can be pruned because they are not spendable.
putting a hash on in the witness script data won't make things better
(it would actually make them worse) and it definitely doesn't help
"block size bloat".
I think I'm missing some context, but if you're using op_return purely
But in prnciple I don't oppose to making it stardard, just want to
understand what's the point.
On Thu, 10 May 2018, 02:16 Jorge Timón, wrote:
> I fail to see what's the practical difference between sending to op_true
> and giving the coins are fees directly. Perhaps it is ao
I fail to see what's the practical difference between sending to op_true
and giving the coins are fees directly. Perhaps it is ao obvious to you
that you forget to mention it?
If you did I honestlt missed it.
On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, <
Yes, in fact, you don't need to lose those bits like bitcoin by
imposing that the version is greater than that. But I guess just doing
the same is simpler.
On Thu, Mar 29, 2018 at 7:14 AM, Samad Sajanlal
> Excellent - Thanks for your response Jorge. This helps us
Yes, you can activate softforks at a given height.
I don't see any reason why you couldn't rebase to 0.16 directly.
The block version bumping was a mistake in bip34, you don't really
need to bump the version number. In any case, I would recommend
reading bip34 and what it activates in the code.
Gmaxwell I think what's new is that in this case, with a single tx you
would take out all txs with fee below 1 btc. With current rules, you would
only remove enoguh txs for that one to fit, not empty the whole block and
mine only a block with that single tx.
On 30 Sep 2017 5:53 am, "Jorge Timón"
er Todd <p...@petertodd.org> wrote:
> On Tue, Sep 05, 2017 at 11:51:45PM +0200, Jorge Timón via bitcoin-dev wrote:
>> This is not a priority, not very important either.
>> Right now it is possible to create 0-value outputs that are spendable
>> and thus stay in the utxo (poten
This is not a priority, not very important either.
Right now it is possible to create 0-value outputs that are spendable
and thus stay in the utxo (potentially forever). Requiring at least 1
satoshi per output doesn't really do much against a spam attack to the
utxo, but I think it would be
Regarding storage space, have you heard about pruning? Probably you should.
On 27 Aug 2017 12:27 am, "Adam Tamir Shem-Tov via bitcoin-dev" <
> Thank You Christian for your response.
> https://bitcointalk.org/index.php?topic=473.0 : I dont see the
On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <
On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
> I think anything less than 1 year after release of tested code by some
> implementation would be
On Mon, Jul 10, 2017 at 1:50 PM, Sergio Demian Lerner via bitcoin-dev
> Regarding the timeline, its certainly rather short, but also is the UASF BIP
> 148 ultimatum.
This is correct. If you are trying to imply that makes the short
What if you want height based but lockinontimeout = false ?
On 7 Jul 2017 8:09 am, "shaolinfry via bitcoin-dev" <
> I have written a height based reference implementation as well as updated
> the BIP text in the following proposals
I'm all for using height instead of time. That was my preference for
bip9 all along, but my arguments at the time apparently weren't
Regarding luke's proposal, the only advantage I see is that it would
allow nodes that don't know a deployment that gets activated to issue
First the implementation, then the technical design (BIP)... will the
analysis come after that?
Will there be any kind of simulations of tje proposed size or will thag
come only after activation on mainnet?
I assume the very last step will be activation on testnet 3 ?
On 27 Jun 2017 8:44 am,
On Sun, Jun 11, 2017 at 7:11 PM, Jorge Timón wrote:
> On Sat, Jun 10, 2017 at 8:04 PM, Jacob Eliosoff via bitcoin-dev
>> Just a quick follow-up on BIP91's prospects of avoiding a BIP148 chain
>> split, because I
On Sat, Jun 10, 2017 at 8:04 PM, Jacob Eliosoff via bitcoin-dev
> Just a quick follow-up on BIP91's prospects of avoiding a BIP148 chain
> split, because I may have left an overly pessimistic impression -
> In short: the timing isn't as dire as I
> I believe that means 80% of hashrate would need to be running BIP91
> (signaling bit 4) by ~June 30 (so BIP91 locks in ~July 13, activates ~July
> 27), not "a few days ago" as I claimed. So, tight timing, but not impossible.
This is not needed, if segwit is locked in by aug 1 (with or
On Sun, Jun 11, 2017 at 3:44 PM, Martijn Meijering via bitcoin-dev
> Jorge Timón wrote:
> Why not just make sure BIP 149 will never activate unless BIP 141 has
> expired unsuccessfully?
Right, that would be part of it, as well as not removing the
The current proposal assumes that bip149 would only be merged and
released after nov15, so there's not time in one day.
My preference would be a bip149 proposal that could be merged and
released now, but some people complain that would require more
testing, because if you deploy bip149 and then
On Wed, May 31, 2017 at 1:50 AM, James MacWhyte wrote:
>> The 1MB classic block size prevents quadratic hashing
>> problems from being any worse than they are today.
> Add a transaction-size limit of, say, 10kb and the quadratic hashing problem
> is a non-issue.
> problems from being any worse than they are today.
> On Tue, May 30, 2017 at 6:27 AM, Jorge Timón via bitcoin-dev
> <email@example.com> wrote:
>> Why not simply remove the (redundant after sw activation) 1 mb size
Hi, I didn't want to comment on
because it seemed to me that thread was more broad.
I like bip8 very much as an extension to bip9, but I think it could be better.
With bip9, a bip9-ready node that sees a softfork
On Tue, May 23, 2017 at 2:55 PM, Luke Dashjr via bitcoin-dev
> 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
If there's a better factor than 0.25 I would change it now before deploying
segwit instead of leaving it to be changed later with a hf.
On 9 May 2017 10:59 pm, "Sergio Demian Lerner via bitcoin-dev" <
> I agree with you Matt.
> I'm artificially
On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
> I've changed the proposal so only 8 bits are given to grinding so something
> like 20 bits are available for signaling.
> I have to say I'm at a loss here as to what's next? Should I make
The discussion is going offtopic. Can we please take vague discussions
about changing pow, so called "asic resistance", the environment etc
to bitcoin-disscuss or some other forum?
bitcoin-dev mailing list
On 9 Apr 2017 4:01 pm, "Jimmy Song" wrote:
Why won't the attacker use asicboost too? (Please don't say because of
We're assuming the ASIC optimization in my example is incompatible with
ASICBoost. But if the new optimization were compatible with
Why won't the attacker use asicboost too? (Please don't say because of
On 9 Apr 2017 12:26 am, "Jimmy Song" wrote:
> Suppose someone figures out an ASIC optimization that's completely
> unrelated that gives X% speed boost over your non-ASICBoosted
On 8 Apr 2017 8:31 pm, "praxeology_guy via bitcoin-dev" <
There is the equation:
Power Cost + Captial Rent + Labor ~= block reward + fees
I don't know why many people insist on calling the subsidy the blick
reward. Thw block reward is both the block
To be more specific, why "being higher will secure the Bitcoin network
better against newer optimizations"?
Or, to be more clear, let's forget about future "optimizations", let's
just think of an attacker. Does asicboost being used by all miners
make the system more secure against an attacker? No,
On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev" <
Why would the actual end users of Bitcoin (the long term and short term
> owners of bitcoins) who run fully verifying nodes want to change Bitcoin
> policy in order to make their
On Thu, Apr 6, 2017 at 4:39 AM, Bram Cohen via bitcoin-dev
> Asicboost also has the problem that it isn't treating the hashing as a black
> box, and thus has impacts on what gets mined. In particular it creates an
> incentive to make blocks smaller.
On Thu, Apr 6, 2017 at 2:30 PM, Luv Khemani via bitcoin-dev
> Just to add on to the ethical issue of blocking this.
> If blocking the covert form of ASICBOOST is seen as unethical, then the same
> can be said about libsecp256k1, various client
Just saying that we can talk in terms of weight alone after segwit. 8 mb
weight is much more clear than 2 mb size to me. 2 mb size seems to
obfuscate the actual new limit with the proposed hf, which simply 8 mb
On 2 Apr 2017 12:03 pm, "Natanael" wrote:
> My point,
On Sat, Apr 1, 2017 at 5:34 PM, Natanael <natanae...@gmail.com> wrote:
> Den 1 apr. 2017 16:07 skrev "Jorge Timón" <jti...@jtimon.cc>:
> On Sat, Apr 1, 2017 at 3:15 PM, Natanael <natanae...@gmail.com> wrote:
>> Den 1 apr. 2017 14:33 skrev "
On Sat, Apr 1, 2017 at 3:15 PM, Natanael <natanae...@gmail.com> wrote:
> Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev"
> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
Segwit replaces the 1 mb size limit with a weight limit of 4 mb. After
segwit there's no need for MAX_BLOCK_BASE_SIZE anymore, let alone
Thus, by "hf to 2 mb" it seems you just really mean hardforking from 4
mb weight to 8 mb weight.
I would also use the hardfork bit (sign
While Segwit's change from 1 mb size limit to 4 mb weight limit seems to be
controversial among some users (I find that very often it is because they
have been confused about what segwit does or even outright lied about it) I
don't think it's very interesting to discuss further size increases.
Great stuff, although the ordering of the sections seems a little bit confusing.
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.
Also, in "For
Segwit allows old -> old, old -> new, new -> old and of course new -> new
On 17 Mar 2017 1:47 a.m., "Erik Aronesty via bitcoin-dev" <
Yeah, it does make things harder, and it's easy enough to soft fork to
handle arbitrary opt-in protocol
I would assume that the controversial part of op_cat comes from the fact
that it enables covenants. Are there more concerns than that?
On 4 Jan 2017 04:14, "Russell O'Connor via bitcoin-dev" <
> For the record, the OP_CAT limit of 520 bytes was added
There were talks about implementing spv mode for bitcoin core without using
bloom filters. Less efficient because it downloads full blocks, but better
for privacy. Perhaps other spv implementations should consider doing the
same instead of committing the filters in the block?
Now I feel I was
On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
> Older node versions may generate issues because some upgrades will make
> several of the nodes running older protocol versions obsolete and or
> incompatible. There may be other hard
On Fri, Dec 2, 2016 at 5:18 AM, Luke Dashjr <l...@dashjr.org> wrote:
> 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
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). It seems the softfork serves
only to warn about soft-hardforks, assuming it chooses to use this
mechanism (which a
On Wed, Nov 16, 2016 at 2:58 PM, Eric Voskuil via bitcoin-dev
> This sort of statement represents one consequence of the aforementioned bad
> Are checkpoints good now?
Checkpoints are not necessary for consensus and work is being done
On Mon, Oct 17, 2016 at 1:17 PM, Tom Zander via bitcoin-dev
> You are asking people to create everyone-can-spend transactions that would
> mean a loss of funds to everyone that used it if we do find a major flaw and
> need to rollback.
As has been mentioned there have been a lot of time to upgrade
software to support segwit. Furthermore, since it is a softfork, there
will be plenty of time after activation too for those taking a "wait
and see" approach.
You keep insisting on "2 months after activation", but that's not how
Hello, since trying to encapsulate consensus code without exposing
anything else (see my post from january
) wasn't succesful in getting review, I decided to turn "phase 2" into
"expose verifyHeader" again. I was
No, anyone with the bip32 public seed can do the same as the receiver as
"watch only". The only difference is rhat the receiver can actually spend
the coins. As gmaxwell explained, if it's expensive for everyone, it will
be also expensive for the receiver (assuming no interaction after the bip32
On May 19, 2016 01:53, "Peter Todd" wrote:
tip of the tree.
> > How expensive it is to update a leaf from this tree from unspent to
> log2(n) operations.
Updating a leaf is just as expensive as adding a new one?
That's not what I expected.
Or is adding a new one
On May 17, 2016 15:23, "Peter Todd via bitcoin-dev" <
> # TXO Commitments
> Specifically TXO commitments proposes a Merkle Mountain Range¹ (MMR), a
> type of deterministic, indexable, insertion ordered merkle tree, which
> new items to be
On May 12, 2016 00:43, "Timo Hanke via bitcoin-dev" <
> This is what I meant. If existing hardware gets forked-out it will
inevitably lead to the creation of an altcoin. Simply because the hardware
exists and can't be used for anything else both chains
On May 11, 2016 05:15, "Timo Hanke via bitcoin-dev" <
> Again: this is unlike the hypothetical persistence of two chains after a
hardfork that is only contentious but doesn’t change the mining algorithm,
the kind of hardfork you are proposing would
On Mar 10, 2016 17:28, "Mustafa Al-Bassam" wrote:
> The fact that it takes very little time and effort to prevent a BIP from
reaching final status, means that in an base of millions of users it's
guaranteed that some disgruntled or bored person out there will attack it,
On Mar 10, 2016 16:51, "Mustafa Al-Bassam via bitcoin-dev" <
> I think in general this sounds like a good definition for a hard-fork
> becoming active. But I can envision a situation where someone will try
> to be annoying about it and point to one
On Mar 10, 2016 02:04, "Mustafa Al-Bassam via bitcoin-dev" <
> >A hard-fork BIP requires adoption from the entire Bitcoin economy,
> particularly including those selling desirable goods and services in
> exchange for bitcoin payments, as well as
There's an absurd fee (non-consensus) check already. Maybe that check can
be improved, but probably the wallet layer is more appropriate for this.
On Mar 3, 2016 16:23, "Henning Kopp via bitcoin-dev" <
> I think there is no need to do a
On Feb 6, 2016 16:37, "Gavin Andresen" wrote:
> Responding to "28 days is not long enough" :
Any thoughts on the "95% better than 75%" and "grace period before miner
coordination instead of after" comments ?
> I suspect there ARE a significant percentage of
In the section
Can we please find another term for the "consensus" here (which is
often confused with "consensus rules", "consensus code" etc)?
In BIP99 I used the term "uncontroversial", but
On Fri, Jan 29, 2016 at 5:39 PM, Gavin Andresen via bitcoin-dev
> On Thu, Jan 28, 2016 at 9:31 PM, Jannes Faber via bitcoin-dev
> It doesn't matter much where in the difficulty period the fork happens;
On Tue, Jan 12, 2016 at 8:17 PM, Eric Voskuil wrote:
> Jorge, first, thanks again for your work on this.
> Without creating and using a public blockchain interface in phase 2, how
> will you isolate the database dependency from consensus critical code?
> Is it that the
After talking to some people about libconsensus in the last Hong Kong
conference I realized that my initial plan of exposing one more thing
at a time would actually probably slow things down.
There's still a promised pdf with pictures that will be released, and
actually drafting the UML pictures
On Fri, Jan 8, 2016 at 4:50 PM, Gavin Andresen via bitcoin-dev
> And to fend off the messag that I bet somebody is composing right now:
> Yes, I know about a "security first" mindset. But as I said earlier in the
> thread, there is a tradeoff here
On Dec 26, 2015 5:45 PM, "Pieter Wuille via bitcoin-dev" <
> My opinion is that the role of Bitcoin Core maintainers is judging
whether consensus for a hard fork exists, and is technically necessary and
safe. We don't need a hashpower vote to decide
On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <
> Unfortunately, this also means longer confirmation times, lower
throughput, and lower miner revenue. Note, however, that confirmations
would (on average) represent more PoW, so fewer
To clarify, although I have defended the deployment of segwit as a
hardfork, I have no strong opinion on whether to do that or do it as a
softfork first and then do a hardfork to move things out of the
coinbase to a better place.
I have a strong opinion against never doing the later hardfork
Well, if it's not going to be height, I think median time of the previous
block is better than the time of the current one, and would also solve Chun
But as said I prefer to use heights that correspond to diff recalculation
(because that's the window that bip9 will use for the
I believe the attacks are the same for height or median time of the prev
block are equal, only the time of the current block has more edge cases.
On Dec 18, 2015 9:15 PM, "Jeff Garzik" wrote:
> My preference is height activation + one step per block (i.e. also
On Dec 18, 2015 9:43 PM, "Peter Todd" wrote:
> FWIW all these median time based schemes should be using median time
past: the point is to use a time that the block creator has no direct
control of, while still tying the rule to wall clock time for planning
Although I agree that how safe a pre-hardfork upgrade period is depends on
the complexity of the changes (we should assume everyone may need time to
reimplementat it themselves in their own implementations, not just upgrade
bitcoin core) and bip102 is indeed a very simple hardfork, I think less
To me it's getting clearer and clearer that th frintier between
softforks and hardforks it's softer than we thought.
Aoftforks should start having a minimum median time deplayment day (be
it height or median time, I don't care, just not header.nTime).
On Fri, Dec 18, 2015 at
On Thu, Dec 17, 2015 at 8:44 PM, Peter Todd via bitcoin-dev
> If Bitcoin remains decentralized, miners have veto power over any
> blocksize increases. You can always soft-fork in a blocksize reduction
> in a decentralized blockchain that actually
On Fri, Dec 11, 2015 at 10:45 PM, Luke Durback wrote:
>>If it's voting for something consensus, you will need something special. If
>> it's not consensus (ie external) thw voting doesn't have to hit the chain at
> I had in mind voting for something that can't be
On Dec 9, 2015 5:40 PM, "Gavin Andresen" wrote:
> On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev <
>> I think it would be logical to do as part of a hardfork that moved
>> commitments generally; e.g. a
On Dec 9, 2015 4:03 PM, "Gregory Maxwell" wrote:
> On Wed, Dec 9, 2015 at 7:54 AM, Jorge Timón wrote:
> > From this question one could think that when you said "we can do the
> > cleanup hardfork later" earlier you didn't really meant it. And that
On Dec 10, 2015 10:10 AM, "Luke Durback via bitcoin-dev" <
> This, combined with the ability to make new transactions arbitrarily
would allow a function to pay its creator.
I don't understand what you mean by "a function" in this context, I assume
On Dec 8, 2015 7:08 PM, "Wladimir J. van der Laan via bitcoin-dev" <
> - Gregory linked to an implementation but as he mentions it is not
> finished yet. ETA for a Segwit testnet is later this month, then you
can test as well.
On Wed, Dec 9, 2015 at 7:29 AM, Gregory Maxwell via bitcoin-dev
> What was being discussed was the location of the witness commitment;
> which is consensus critical regardless of where it is placed. Should
> it be placed in an available location which
On Wed, Dec 9, 2015 at 12:59 AM, Gregory Maxwell via bitcoin-dev
> On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev
> We already have consensus critical enforcement there, the height,
1 - 100 of 244 matches
Mail list logo