From: s7r <s7r@sky-ip•org>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Date: Thu, 16 Apr 2015 19:12:35 +0300 [thread overview]
Message-ID: <552FDF73.6010104@sky-ip.org> (raw)
In-Reply-To: <CAPg+sBgAhdgPPjmT5i0PMYhQo=Hk6Weo8tpX_Wyn-NJ5Ye9D_A@mail.gmail.com>
Hi Pieter,
Thanks for your reply. I agree. Allen has a good point in the previous
email too, so the suggestion might not fix anything and complicate things.
The problem I am trying to solve is making all transactions
non-malleable by default. I guess there is a very good reason why BIP62
will not touch v1 anyway.
I am trying to build a bitcoin contract which will relay on 3 things:
- coinjoin / txes with inputs from multiple users which are signed by
all users after they are merged together (every user is sure his coins
will not be spent without the other users to spend anything, as per
agreed contract);
- pre-signed txes with nLockTime 'n' weeks. These txes will be signed
before the inputs being spent are broadcasted/confirmed, using the txid
provided by the user before broadcasting it. Malleability hurts here.
- P2SH
In simple terms, how malleable transactions really are in the network at
this moment? Who can alter a txid without invalidating the tx? Just the
parties who sign it? The miners? Anyone in the network? This is a little
bit unclear to me.
Another thing I would like to confirm, the 3 pieces of the bitcoin
protocol mentioned above will be supported in _any_ future transaction
version or block version, regardless what changes are made or features
added to bitcoin core? The contract needs to be built and left unchanged
for a very very long period of time...
On 4/16/2015 8:22 AM, Pieter Wuille wrote:
>
> On Apr 16, 2015 1:46 AM, "s7r" <s7r@sky-ip•org <mailto:s7r@sky-ip•org>>
> wrote:
>> but for transaction versions? In simple terms, if > 75% from all the
>> transactions in the latest 1000 blocks are version 'n', mark all
>> previous transaction versions as non-standard and if > 95% from all the
>> transactions in the latest 1000 blocks are version 'n' mark all previous
>> transaction versions as invalid.
>
> What problem are you trying to solve?
>
> The reason why BIP62 (as specified, it is just a draft) does not make v1
> transactions invalid is because it is opt-in. The creator of a
> transaction needs to agree to protect it from malleability, and this
> subjects him to extra rules in the creation.
>
> Forcing v3 transactions would require every piece of wallet software to
> be changed.
>
> --
> Pieter
>
next prev parent reply other threads:[~2015-04-16 16:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-15 23:43 s7r
2015-04-16 2:04 ` Allen Piscitello
2015-04-16 5:22 ` Pieter Wuille
2015-04-16 16:12 ` s7r [this message]
2015-04-16 17:34 ` Mark Friedenbach
2015-04-16 23:17 ` s7r
2015-04-17 9:02 ` Pieter Wuille
2015-04-18 14:49 ` s7r
2015-04-24 8:55 ` Jorge Timón
2015-04-24 8:58 ` Jorge Timón
2015-04-24 19:58 ` William Swanson
2015-04-24 20:16 ` Gregory Maxwell
2015-04-25 15:40 ` Stephen Morse
2015-04-26 0:01 ` s7r
2015-04-26 6:51 ` Joseph Poon
2015-04-26 16:48 ` Joseph Poon
2015-04-25 14:32 ` Stephen Morse
2015-04-27 19:21 ` Peter Todd
2015-04-28 10:17 ` Oleg Andreev
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=552FDF73.6010104@sky-ip.org \
--to=s7r@sky-ip$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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