Summary
---
It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.
I've backported the CLTV op-code and a IsSuperMajority() soft-fork to
the v0.10 and v0.11 branches, pull-reqs #6706 and #6707 respectively. A
pull-req for git HEAD for the soft-fork deployment has been open since
June 28th, #6351 - th
+1 for deploying BIP65 immediately without further waiting. Agree with
all Peter's points.
If BIP65 has to follow the 0.12 schedule, it will take almost 9 months
from now to complete the softfork. I don't see any good reason to wait
for that long. We have too much talk, too little action.
So
On Sun, Sep 27, 2015 at 04:26:12PM -0400, jl2...@xbt.hk wrote:
> +1 for deploying BIP65 immediately without further waiting. Agree
> with all Peter's points.
Thanks!
> By the way, is there any chance to backport it to 0.9? In the
> deployment of BIP66 some miners requested a backport to 0.9 and
>
Agree with all CLTV and nVersionBits points. We should deploy a lock-time
soft-fork ASAP, using the tried and true IsSuperMajoirty test.
However your information regarding BIPs 68 (sequence numbers), 112
(checksequenceverify) and 113 (median time past) is outdated. Debate
regarding semantics has b
On Sun, Sep 27, 2015 at 7:50 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 10) Waiting for nVersion bits and CHECKSEQUENCEVERIFY will significantly
> delay deployment of CLTV
>
> It's been proposed multiple times that we wait until we can do a single
> soft-f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
+1
I was actually waiting for this. It makes 'smart contracts' simpler
and better from many points of view.
Pete I don't see anything about RCLTV in BIP65, was that a separate
BIP? Which one is it and are we also deploying it via
IsSuperMajority()?
There is *no* consensus on using a soft fork to deploy this feature. It
will result in the same problems as all the other soft forks - SPV wallets
will become less reliable during the rollout period. I am against that, as
it's entirely avoidable.
Make it a hard fork and my objection will be droppe
I wonder what Gavin's views are, he's usually constructive, and see if
he'll include it in XT - I think he may have said he was supportive.
The rationale for soft vs hard-forks is well known, so I wont go over them.
Adam
On 28 September 2015 at 06:48, Mike Hearn via bitcoin-dev
wrote:
> There
My initial reaction is just HUH?!?!? Is this some sophisticated form of humor
I'm just not getting?
On September 28, 2015 3:48:57 AM PDT, Mike Hearn via bitcoin-dev
wrote:
>There is *no* consensus on using a soft fork to deploy this feature. It
>will result in the same problems as all the other
>
> The rationale for soft vs hard-forks is well known, so I wont go over them.
>
The rationale of "backwards compatibility" is well known, yet wrong. I've
gone over the arguments here and explained why the concept makes no sense:
https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7
Perhaps Adam won't go into the rationale...but I think it is important we
clarify this.
For better or worse, the only "voting" system available to Bitcoin that cannot
be trivially attacked is hashing power. Soft forks are essentially
miner-enforced rule changes...rules they could have decided t
>
> Go ahead and object to soft forks...but at least try not to make arguments
> based on changing the definitions of terms we all generally agree upon.
>
I don't intend to do that, and I don't think I am - I know what the
difference between a soft and hard fork is and am not trying to confuse or
SPV wallets in their current form are inherently insecure. Moreover, while we
at least have a soft fork mechanism that is not trivially exploitable (yes,
it's got issues...but unlike SPV wallets, it isn't so easily exploitable), we
have NO hard fork mechanism in place that isn't highly prone to
On Mon, Sep 28, 2015 at 11:48 AM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 1) Drop the "everyone must agree to make changes" idea that people here
> like to peddle, and do it loudly, so everyone in the community is correctly
> informed
>
There never was a rule
>
> we have NO hard fork mechanism in place that isn't highly prone to
> systemic consensus failure.
>
Just use an opcode that isn't currently defined. Done. What about that
mechanism is prone to failure?
Re: coma. No need for insults. Please read my article and address the
points raised there, w
I think three things need to happen:
1) Stop pretending that "everyone must agree to make consensus rule
changes." "Rough consensus" is what we've always gone with, and is good
enough.
2) Mr. Todd (or somebody) needs to write up a risk/benefit security
tradeoff analysis doo-hickey document and pu
On Mon, Sep 28, 2015 at 12:48:57PM +0200, Mike Hearn wrote:
> There is *no* consensus on using a soft fork to deploy this feature. It
> will result in the same problems as all the other soft forks - SPV wallets
> will become less reliable during the rollout period. I am against that, as
> it's enti
On Mon, Sep 28, 2015 at 09:01:02AM -0400, Gavin Andresen wrote:
> I think three things need to happen:
>
> 1) Stop pretending that "everyone must agree to make consensus rule
> changes." "Rough consensus" is what we've always gone with, and is good
> enough.
>
> 2) Mr. Todd (or somebody) needs to
>
> 1) Do you agree that CLTV should be added to the Bitcoin protocol?
>
> Ignoring the question how exactly it is added, hard-fork or soft-fork.
>
The opcode definition seems OK.
> 2) Will you add a IsSuperMajority() CLTV soft-fork to Bitcoin XT if it
>is added to Bitcoin Core?
>
Yes. It m
On Mon, Sep 28, 2015 at 9:28 AM, Peter Todd wrote:
> > 2) Mr. Todd (or somebody) needs to write up a risk/benefit security
> > tradeoff analysis doo-hickey document and publish it. I'm reasonably
> > confident that the risks to SPV nodes can be mitigated (e.g. by deploying
> > mempool-only first,
On Mon, Sep 28, 2015 at 12:40 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> There is no consensus. Now pick. Lose the requirement that everyone agree
> for consensus changes, and tell people you've done it. Change the spec. Or
> do nothing.
>
Of course there is
On Mon, Sep 28, 2015 at 09:43:42AM -0400, Gavin Andresen wrote:
> On Mon, Sep 28, 2015 at 9:28 AM, Peter Todd wrote:
>
> > > 2) Mr. Todd (or somebody) needs to write up a risk/benefit security
> > > tradeoff analysis doo-hickey document and publish it. I'm reasonably
> > > confident that the risk
>
> 2. As for SPV wallets need to handle awareness of the new blocks.
>
There is simply no need for any wallets to change. Making the spec a hard
fork instead of a soft fork means all existing software does the right
thing automatically.
To repeat, please bear in mind that bitcoinj is no longer t
On Mon, Sep 28, 2015 at 03:41:56PM +0200, Mike Hearn wrote:
> >
> > 1) Do you agree that CLTV should be added to the Bitcoin protocol?
> >
> > Ignoring the question how exactly it is added, hard-fork or soft-fork.
> >
>
> The opcode definition seems OK.
Good!
> > 2) Will you add a IsSuperMajorit
>
> SPV wallets can't detect hard-forks
They don't have to - they pick the highest work chain. Any miner who hasn't
upgraded makes blocks on the shorter chain that are then ignored (or
rather, stored for future reorgs). After the fork point, there won't be any
blocks in the main chain that violat
On Mon, Sep 28, 2015 at 04:33:23PM +0200, Mike Hearn wrote:
> >
> > SPV wallets can't detect hard-forks
>
>
> They don't have to - they pick the highest work chain. Any miner who hasn't
> upgraded makes blocks on the shorter chain that are then ignored (or
> rather, stored for future reorgs). Aft
>
> Ok, so again, if that's your security criteria, what's the issue
> with soft-forks?
Please read my article as it's all explained there.
But to reiterate: the risk is that miners will build invalid blocks on top
of the best work chain, instead of an ignored lower work side chain. This
opens u
On Mon, Sep 28, 2015 at 04:51:22PM +0200, Mike Hearn wrote:
> >
> > Ok, so again, if that's your security criteria, what's the issue
> > with soft-forks?
>
>
> Please read my article as it's all explained there.
I have read your article. In fact we reviewed it at a NY BitDevs meetup
that I atten
>
> Can you explain exactly how you think wallets will "know" how to ignore
> the invalid chain?
>
I'm confused - I already said this. For a fork to work, hard or soft, there
must be support from a majority of the hash power.
Therefore, the usual SPV technique of following the highest work chain
Mike Hearn via bitcoin-dev 於 2015-09-28 11:38 寫到:
My point about IsStandard is that miners can and do bypass it,
without expecting that to carry financial consequences or lower the
security of other users. By making it so a block which includes
non-standard transactions can end up being seen as
>
> Let me try to answer this question. Softfork is beneficial to non-mining
> full nodes as they will follow the majority chain.
That is not a benefit. That is a description of what the software will do,
but not why you would want it.
In case this seems like a pedantic point, consider the conse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
And still no movement on BIP 63...
https://bitcointalk.org/index.php?topic=1083961.20
Apart from that,
All my prior objections to XT still hold as expressed on this list.
XT is not acceptable.
On the topic of consensus:
Reaching consensus, I hop
Why are they called soft forks when they are really hidden forks? Isn't
the point of a soft fork to prevent old clients from rejecting what they
don't have the code to validate? That seems dangerous.
notplato
On Mon, Sep 28, 2015 at 2:12 PM, odinn via bitcoin-dev <
bitcoin-dev@lists.linuxfounda
On Sep 28, 2015 7:14 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>> In a hardfork, however, there is no mechanism to stop the old fork and
we may have 2 chains co-exist for a long time.
>
>
> There isn't any difference in how long the divergent state exists for.
Mike,
Insults were not really my intention. Let's set aside our differences regarding
SPV security and assume you understand the different implications for soft
forks and hard forks.
Other than the fact that doing this as a soft fork requires an extra OP_DROP,
how would doing this as a hard fo
>
> Other than the fact that doing this as a soft fork requires an extra
> OP_DROP, how would doing this as a hard fork make any difference to SPV
> clients? If, as others have suggested, all clients warn the user on
> unrecognized nVersion
>
All clients do *not* do this. Why would they? What acti
Hi Jorge,
Yes, there is a difference. Assuming the hashrate majority upgrades, in the
> case of a softfork [snip] .. In the case of a hardfork [snip]
>
Yes, I know what the difference between them is at a technical level. You
didn't explain why this would make any difference to how fast miners
On Sep 28, 2015, at 7:43 AM, Peter Todd via bitcoin-dev
wrote:
>
> Ok, so again, if that's your security criteria, what's the issue with
> soft-forks? With soft-forks, the result of a SPV wallet following the
> highest work chain is the same: eventually invalid blocks are reorged
> out.
>
> H
Jonathan Toomim (Toomim Bros) via bitcoin-dev 於 2015-09-29 09:30 寫到:
SPV clients will appear to behave normally, and
will continue to show new transactions and get confirmations in a
timely fashion. However, they will be systematically susceptible to
attack from double-spends that attempt to spen
On Mon, Sep 28, 2015 at 10:48 AM, Mike Hearn via bitcoin-dev
wrote:
> There is no consensus on using a soft fork to deploy this feature. It will
> result in the same problems as all the other soft forks - SPV wallets will
> become less reliable during the rollout period. I am against that, as it's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello, (see my remarks below)
jl2012 via bitcoin-dev:
> Jonathan Toomim (Toomim Bros) via bitcoin-dev 於 2015-09-29 09:30 寫
> 到:
>> SPV clients will appear to behave normally, and will continue to
>> show new transactions and get confirmations in a t
On Sun, Sep 27, 2015 at 02:50:31PM -0400, Peter Todd via bitcoin-dev wrote:
> It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.
There appears to be common agreement on that.
The only source of some controversy is how to deploy: versionbits versus
IsSuperMajority. I think the versionbits proposal sh
"Wladimir J. van der Laan via bitcoin-dev"
writes:
> On Sun, Sep 27, 2015 at 02:50:31PM -0400, Peter Todd via bitcoin-dev wrote:
>
>> It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.
>
> There appears to be common agreement on that.
>
> The only source of some controversy is how to deploy: versionbi
I think from discussion with Gavin sometime during the montreal
scaling bitcoin workshop, XT maybe willing to make things easy and
adapt what it's doing. For example in relation to versionBits Gavin
said he'd be willing to update XT with an updated/improved
versionBits, for example.
It seems more
>
> I think from discussion with Gavin sometime during the montreal
> scaling bitcoin workshop, XT maybe willing to make things easy and
> adapt what it's doing.
If Core ships CLTV as is, then XT will have to adopt it - such is the
nature of a consensus system.
This will not change the fact that
On Tue, Sep 29, 2015 at 2:07 PM, Mike Hearn wrote:
> Hi Jorge,
>
>> Yes, there is a difference. Assuming the hashrate majority upgrades, in
>> the case of a softfork [snip] .. In the case of a hardfork [snip]
>
> Yes, I know what the difference between them is at a technical level. You
> didn'
Hi Gregory,
> I'm surprised to see this response
Why? I have objected to the idea of soft forks many times. I wrote an
entire article about it in August. I also objected in April 2014, for
instance, where Pieter agreed with me that soft forks can result in ugly
hacks, and that they are "not nic
I was talking about the versionBits from Rusty's email (pasted below) and
simplifying that by XT adopting the patch as Gavin had seemed agreeable to.
Adam
Rusty wrote:
> Agreed. Unfortunately, a simple "block version >= 4" check is
> insufficient, due to XT which sets version bits 001111.
>
On Wed, Sep 30, 2015 at 7:11 PM, Mike Hearn via bitcoin-dev
wrote:
> Several people have asked several times now: given the very real and widely
> acknowledged downsides that come with a soft fork, what is the specific
> benefit to end users of doing them?
As previously explained, the biggest adv
On 30 September 2015 at 13:11, Mike Hearn via bitcoin-dev
wrote:
>> Have I missed a proposal to change BIP101 to be a real hardfork
>
> There's no such thing as a "real" hard fork - don't try and move the goal
> posts. SPV clients do not need any changes to do the right thing with BIP
> 101, they
Two observations from a Bitcoin investor and non-programmer:
1) I think it's possible that those who are adamantly opposed to a soft
fork may be largely (if not completely) correct on purely technical
terms, but that they also may be underestimating the risk of a
contentious hardfork.
2) The
On Wed, Sep 30, 2015 at 1:11 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Several people have asked several times now: given the very real and
> widely acknowledged downsides that come with a soft fork, *what* is the
> specific benefit to end users of doing them
>
> Field experience shows it successfully delivers new features to end users
> without a global software upgrade.
>
The global upgrade is required for all full nodes in both types. If a full
node doesn't upgrade then it no longer does what it was designed to do; if
the user is OK with that, they
On Wed, Sep 30, 2015 at 5:11 PM, Mike Hearn wrote:
> Hi Gregory,
>
>>
>> I'm surprised to see this response
>
>
> Why? I have objected to the idea of soft forks many times. I wrote an entire
> article about it in August.
Yes, your article contained numerous factual and logical inaccuracies
which
On Sep 30, 2015 9:56 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Jorge has said soft forks always lead to network convergence. No, they
don't. You get constant mini divergences until everyone has upgraded, as
opposed to a single divergence with a hard fork (
tl;dr Nothing I have read here has changed my mind. There is still no
consensus to deploy CLTV in this way.
> Yes, your article contained numerous factual and logical inaccuracies
> which I corrected
>
I responded to your response several times. It was not convincing, and I do
not think you corr
>
> Exactly, all those "mini divergences" eventually disappear
>
A miner that has accepted a newly invalid transaction into its memory pool
and is trying to mine it, will keep producing invalid blocks forever until
the owner shuts it down and upgrades. This was happening for weeks after
P2SH trigge
On Wed, Sep 30, 2015 at 11:06 PM, Mike Hearn wrote:
>> Exactly, all those "mini divergences" eventually disappear
>
> A miner that has accepted a newly invalid transaction into its memory pool
> and is trying to mine it, will keep producing invalid blocks forever until
> the owner shuts it down an
On Wed, Sep 30, 2015 at 3:56 PM, Mike Hearn wrote:
> Field experience shows it successfully delivers new features to end users
>> without a global software upgrade.
>>
>
> The global upgrade is required for all full nodes in both types. If a full
> node doesn't upgrade then it no longer does what
On Wed, Sep 30, 2015 at 9:01 PM, Mike Hearn wrote:
> I coined the term SPV so I know exactly what it means, and bitcoinj
The term comes from the Bitcoin whitepaper.
> On the other hand, full nodes all claim they run scripts. Users expect that
> and may be relying on it. The unstated assumption h
On Wed, Sep 30, 2015 at 10:17 PM, Jeff Garzik wrote:
> It is correct that security is slightly reduced for full nodes that have not
> upgraded. It is not correct that the choice is binary, full node or SPV.
>
> Any user running a not-upgraded full node still retains protection against
> many atta
John Winslow via bitcoin-dev
writes:
> Two observations from a Bitcoin investor and non-programmer:
Please take this off the -dev list.
Thanks,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/
Adam Back writes:
> I think from discussion with Gavin sometime during the montreal
> scaling bitcoin workshop, XT maybe willing to make things easy and
> adapt what it's doing. For example in relation to versionBits Gavin
> said he'd be willing to update XT with an updated/improved
> versionBits
On Oct 1, 2015 12:14 AM, "Jorge Timón" wrote:
>
> On Wed, Sep 30, 2015 at 11:06 PM, Mike Hearn wrote:
> >> Exactly, all those "mini divergences" eventually disappear
> >
> > A miner that has accepted a newly invalid transaction into its memory
pool
> > and is trying to mine it, will keep producin
On 9/30/2015 10:58 AM, Jorge Timón via bitcoin-dev wrote:
> I don't think we need to wait for you to understand the advantages of
> softforks to move forward with BIP65, just like we didn't need to wait
> for every developer and user to understand BIP66 to deploy it.
What a bad example. BIP66 de
On 28 September 2015 at 06:48, Mike Hearn via bitcoin-dev
wrote:
> There is no consensus on using a soft fork to deploy this feature. It will
> result in the same problems as all the other soft forks - SPV wallets will
> become less reliable during the rollout period. I am against that, as it's
>
2015 9:57 am
To:
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
On 28 September 2015 at 06:48, Mike Hearn via bitcoin-dev
wrote:
> There is no consensus on using a soft fork to deploy this feature. It will
> result in the same problems as all the other soft forks -
Putting aside stupid arguments about who is older or who starting using the
term SPV wallet first, let me try and make a better suggestion than what's
in the BIP. How about the following:
A new flag is introduced to Core, --scriptchecks=[all,standardonly,none].
The default is all. When set to "sta
- It is true that hard forks produce a much cleaner outcome, in terms of
well defined behavior across the entire network.
- Replacing an opcode should not result in undefined behavior. The
non-upgraded behavior is defined and deterministic.
- IsStandard remains an assistant. Miners may mine non
Well, let's agree to disagree on these two things:
- I define "working" for a full node as verifying everything; if a node
starts skipping bits then I'd say it's not really "working" according to
its original design goals
- Saying the pre-fork behaviour is defined and deterministic is true, but
o
On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Well, let's agree to disagree on these two things:
>
> - I define "working" for a full node as verifying everything; if a node
starts skipping bits then I'd say it's not really "working" accordi
It will get correct results about :
- the existence every block
- the existence of every transaction
It will get incorrect results :
- about the *nature* of some transactions
- and therefore, about the balances of some wallets.
I fully agree with Mike here.
Le lun. 5 oct. 2015 à 14:04, Jorge Tim
Hi Jorge,
I'm glad we seem to be reaching agreement that hard forks aren't so bad
really and can even have advantages. It seems the remaining area of
disagreement is this rollout specifically.
> a non-upgraded full node and an upgraded full will converge on what they
> see: "the most-work valid c
On Oct 5, 2015 2:08 PM, "Clément Elbaz" wrote:
>
> It will get correct results about :
> - the existence every block
> - the existence of every transaction
>
> It will get incorrect results :
> - about the nature of some transactions
Given the assumptions above, only of transactions without enoug
I fail to see how the number of confirmations has anything to do with it.
With a non-upgraded Bitcoin software during a soft fork, you get the same
blocks as everyone else, and you get the same confirmed transactions as
everyone else. So you do have the exact same "writings" as everyone else to
ca
"Consensus" it's a term we use for consensus critical code and we
refer to different machines (potentially with different software)
validating in exactly the same way.
I think also using the term for people agreeing on what those
consensus rules is confusing, so in BIP99 I used the term
"uncontrove
On Fri, Oct 2, 2015 at 4:12 AM, GC via bitcoin-dev
wrote:
> Or, you know, enter some discussions on what exactly are the issues that SPV
> clients face during soft forks and see if anything can be done (on all
> sides) to mitigate the risks.
This has already been discussed. The recommended risk m
On Mon, Oct 5, 2015 at 2:10 PM, Mike Hearn wrote:
> Hi Jorge,
>
> I'm glad we seem to be reaching agreement that hard forks aren't so bad
> really and can even have advantages. It seems the remaining area of
> disagreement is this rollout specifically.
>>
>> a non-upgraded full node and an upgrade
On Mon, Oct 5, 2015 at 2:29 PM, Clément Elbaz wrote:
> The problem is that some transactions that are meaningless to you are
> actually meaningful to people using an upgraded Bitcoin software.
>
> Therefore during a softfork, while you can not miss the existence of a
> transaction, you can miss it
>
> As Greg explained to you repeatedly, a softfork won't cause a
> non-upgraded full node to start accepting blocks that create more
> subsidy than is valid.
>
It was an example. Adam Back's extension blocks proposal would, in fact,
allow for a soft forking change that creates more subsidy than i
On Mon, Oct 05, 2015 at 06:46:28PM +0200, Mike Hearn via bitcoin-dev wrote:
> The example is this: find someone that accepts 1-block confirmed
> transactions in return for something valuable. There are plenty of them out
> there. Once the soft fork starts, send a P2SH transaction that defines a
> n
On Monday, October 5, 2015, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> As Greg explained to you repeatedly, a softfork won't cause a
>> non-upgraded full node to start accepting blocks that create more
>> subsidy than is valid.
>>
>
> It was an example. Adam Back'
On Tue, Sep 29, 2015 at 06:31:28PM +, Gregory Maxwell via bitcoin-dev wrote:
> On Mon, Sep 28, 2015 at 10:48 AM, Mike Hearn via bitcoin-dev
> wrote:
> > There is no consensus on using a soft fork to deploy this feature. It will
> > result in the same problems as all the other soft forks - SPV
On Oct 7, 2015, at 8:00 AM, Anthony Towns via bitcoin-dev
wrote:
> *But* a soft fork that only forbids transactions that would previously
> not have been mined anyway should be the best of both worlds, as it
> automatically reduces the liklihood of old miners building newly invalid
> blocks to
That's why it's important to measure miner adoptance. Note that this isn't a
vote - it's an adoption metric for what is presumably a fairly uncontroversial
upgrade. If there's contentious controversy amongst miner all bets are off.
Our current mechanisms are imperfect in this regard...as we've s
You're right about the potential for 1 bad confirmation even with very low
frequency...but with an overwhelming supermajority of hashpower, 2 bad
confirmations become quite unlikely, n bad confirmations becomes exponentially
unlikely in n.
As part of such soft fork deployments, it's true that o
On Oct 7, 2015, at 9:02 AM, Eric Lombrozo wrote:
> But a real hashpower supermajority would make such attacks hard to pull off
> in practice.
If you had a 99% hashpower supermajority on the new version, an attacker would
still be able to perform this attack once per day. Since the attacker i
On Wed, Oct 07, 2015 at 08:46:08AM -0700, Jonathan Toomim (Toomim Bros) via
bitcoin-dev wrote:
> On Oct 7, 2015, at 8:00 AM, Anthony Towns via bitcoin-dev
> wrote:
> > *But* a soft fork that only forbids transactions that would previously
> > not have been mined anyway should be the best of both
On Thu, Oct 08, 2015 at 01:00:14AM +1000, Anthony Towns via bitcoin-dev wrote:
> *But* a soft fork that only forbids transactions that would previously
> not have been mined anyway should be the best of both worlds, [...]
> * more restrictive than consensus, but less restrictive than policy
>
Thanks for that great breakdown Anthony. I think it helps a lot of us get a
better handle on the matter without getting too technical.
A couple of questions on some of the points you made I'd like to put out there:
First I think your unsaid assumption about the fragility of a soft fork show
On Mon, Oct 12, 2015 at 12:02:51AM -0700, digitsu412 via bitcoin-dev wrote:
> Thanks for that great breakdown Anthony. I think it helps a lot of us
> get a better handle on the matter without getting too technical.
Glad you found it useful; there's a lot of subtleties in how this
stuff works, and
On Mon, Oct 12, 2015 at 12:02:51AM -0700, digitsu412 via bitcoin-dev wrote:
> First I think your unsaid assumption about the fragility of a soft
> fork showing incorrect confirmations is dependent on the percentage
> of hash power that didn't upgrade. If using your same numbers this
> was only 5%
Thanks AJ,
That is a must more concise example, which I think makes it very clear all the
variables at play.
I agree with its conclusion.
Though I'm wondering about its actual significance in ability to do harm as
with 5% hash power we would have to wait quite a long time before suc
93 matches
Mail list logo
