public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: jl2012@xbt.hk
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Compatibility requirements for hard or soft forks
Date: Tue, 03 Nov 2015 00:32:18 -0500	[thread overview]
Message-ID: <ceb486d3be77383158b15be98bfdc11f@xbt.hk> (raw)
In-Reply-To: <CABsx9T3w-=bqbfmG=gVxJ8SQZCoEXA7vQbFD+kC2CH36bd=xPw@mail.gmail.com>

The other strategy is to have an informational BIP to define "safe" use 
of Bitcoin.

1. scriptPubKey must be one of the following types: P2PK, P2PKH, P2SH, 
n-of-m multisig with m < 4 (with or without CLTV or CSV, we should 
define standard use of CLTV and CSV)

2. For P2SH, the serialized script must be one of the standard type

3. No use of unknown transaction version

4. Tx size < 100k

5. If conditions 1-4 are all satisfied, the locktime must not be longer 
than 4 years from the creation of the tx

6. If at least one of the conditions 1-4 is not satisfied, the lock time 
must not be longer than 6 months from the creation of the tx

7. A chain of unconfirmed transactions is unsafe due the malleability

8. Tx created by wallet software last updated 1 year ago is unsafe

9. Permanently deleting a private key is unsafe (that might be safe if 
stricter practice is followed)

We must not introduce a new rule that may permanently invalidate a safe 
tx, unless in emergency. Even in emergency, we should try to preserve 
backward compatibility as much as possible (see the example at the end 
of my message)

Being unsafe means there is a chance that the tx may become 
unconfirmable, outputs become unspendable, or funds may be stolen 
without a private key.

A grace period of 5 years must be given for "soft-fork" type change of 
any of the rules. For example it is ok to introduce new standard script 
anytime but not to remove.

----------------------

Back to Gavin's original question. If you want to somehow keep backward 
compatibility for expensive-to-validate transactions in the future, you 
may have rules like there could only be at most one 
expensive-to-validate transaction in every 10 blocks, until year 2025. I 
know this is over-complicated but it's a possible way to address your 
concern.



Gavin Andresen via bitcoin-dev 於 2015-11-02 15:33 寫到:
> On Sun, Nov 1, 2015 at 6:46 PM, Tier Nolan via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>> For guidelines
>> 
>> * Transaction version numbers will be increased, if possible
>> 
>> * Transactions with unknown/large version numbers are unsafe to use
>> with locktime
>> 
>> * Reasonable notice is given that the change is being contemplated
>> 
>> * Non-opt-in changes will only be to protect the integrity of the
>> network
>> 
>> Locked transaction that can be validated without excessive load on
>> the network should be safe to use, even if non-standard.
>> 
>> An OP_CAT script that requires TBs of RAM to validate crosses the
>> threshold of reasonableness.
> 
> I like those guidelines, although I'm sure there may be lots of
> arguing over what fits under "protects the integrity of the network"
> or what constitutes "reasonable notice" (publish a BIP at least 30
> days before rolling out a change? 60 days? a year?)
> 
> --
> 
> --
> Gavin Andresen
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



      parent reply	other threads:[~2015-11-03  5:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-28 14:06 [bitcoin-dev] Compatibility requirements for hard or soft forks Gavin Andresen
2015-10-31  3:43 ` Rusty Russell
2015-11-01 14:36   ` Justus Ranvier
2015-11-01 17:28 ` jl2012
2015-11-01 23:46   ` Tier Nolan
2015-11-02  0:23     ` Justus Ranvier
2015-11-02  0:33       ` Luke Dashjr
2015-11-02  1:30       ` Tier Nolan
2015-11-02  4:15         ` Justus Ranvier
2015-11-02  6:12         ` Justus Ranvier
2015-11-02 20:33     ` Gavin Andresen
2015-11-02 22:12       ` Justus Ranvier
2015-11-03  5:32       ` jl2012 [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ceb486d3be77383158b15be98bfdc11f@xbt.hk \
    --to=jl2012@xbt.hk \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gavinandresen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox