From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YimPR-0006eL-6z for bitcoin-development@lists.sourceforge.net; Thu, 16 Apr 2015 16:12:57 +0000 Received-SPF: neutral (sog-mx-4.v43.ch3.sourceforge.com: 162.222.225.13 is neither permitted nor denied by domain of sky-ip.org) client-ip=162.222.225.13; envelope-from=s7r@sky-ip.org; helo=outbound.mailhostbox.com; Received: from outbound.mailhostbox.com ([162.222.225.13]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YimPK-0006RX-Vg for bitcoin-development@lists.sourceforge.net; Thu, 16 Apr 2015 16:12:57 +0000 Received: from [0.0.0.0] (tor32.anonymizer.ccc.de [217.115.10.132]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: s7r@sky-ip.org) by outbound.mailhostbox.com (Postfix) with ESMTPSA id B7FF81A1287; Thu, 16 Apr 2015 16:12:40 +0000 (GMT) Message-ID: <552FDF73.6010104@sky-ip.org> Date: Thu, 16 Apr 2015 19:12:35 +0300 From: s7r User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Pieter Wuille References: <552EF785.7000207@sky-ip.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 X-CTCH-RefID: str=0001.0A020203.552FDF7D.0185, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: s7r@sky-ip.org X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.8 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [162.222.225.13 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.7 SPF_NEUTRAL SPF: sender does not match SPF record (neutral) 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Headers-End: 1YimPK-0006RX-Vg Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: s7r@sky-ip.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 16:12:57 -0000 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: >=20 > On Apr 16, 2015 1:46 AM, "s7r" > > 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 th= e >> transactions in the latest 1000 blocks are version 'n' mark all previo= us >> transaction versions as invalid. >=20 > What problem are you trying to solve? >=20 > The reason why BIP62 (as specified, it is just a draft) does not make v= 1 > 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. >=20 > Forcing v3 transactions would require every piece of wallet software to > be changed. >=20 > --=20 > Pieter >=20