From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WNmDr-0001ht-Mc for bitcoin-development@lists.sourceforge.net; Wed, 12 Mar 2014 16:41:39 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.173 as permitted sender) client-ip=209.85.214.173; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f173.google.com; Received: from mail-ob0-f173.google.com ([209.85.214.173]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WNmDq-0004ZA-Sc for bitcoin-development@lists.sourceforge.net; Wed, 12 Mar 2014 16:41:39 +0000 Received: by mail-ob0-f173.google.com with SMTP id gq1so10257344obb.32 for ; Wed, 12 Mar 2014 09:41:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.98.73 with SMTP id eg9mr1016629oeb.81.1394642493536; Wed, 12 Mar 2014 09:41:33 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.71.231 with HTTP; Wed, 12 Mar 2014 09:41:33 -0700 (PDT) In-Reply-To: References: <531DFDF8.80008@gmail.com> <531E52FE.5090107@jerviss.org> <531E5454.1030601@gmail.com> <4fca6b510dd57d2f92affeb988d2ee5d.squirrel@fulvetta.riseup.net> <531FAA55.2020108@xeno-genesis.com> <531FC808.7060709@gmail.com> <9A6499BC-E546-45CC-A7EF-5182FC86052D@gmail.com> <53202D51.8010008@plan99.net> Date: Wed, 12 Mar 2014 17:41:33 +0100 X-Google-Sender-Auth: YKFkP4KvzJXdS5hhf1vjTu84zdM Message-ID: From: Mike Hearn To: Jeff Garzik Content-Type: multipart/alternative; boundary=089e0139fc606b6bac04f46b82f0 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WNmDq-0004ZA-Sc Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Multisign payment protocol? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 16:41:39 -0000 --089e0139fc606b6bac04f46b82f0 Content-Type: text/plain; charset=UTF-8 > > Partially signed and multisig transactions within bitcoind go through > the raw transaction API, which does absolutely nothing if the sig > pushes the TX to a higher fee level. Well, we'll have to make sure this is carefully and loudly documented in the new developer part of the website that's being worked on. Because this seems like a recipe for people writing flaky apps. In practice it would seem like you need to implement the fee loop in your own app: 1) Create tx with an estimated fee level 2) Add signatures 3) Submit. If REJECT for too low fees, increment, go to 1 and try again. --089e0139fc606b6bac04f46b82f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Partially signed and multisig transactions withi= n bitcoind go through
the raw transaction API, which does absolutely nothing if the sig
pushes the TX to a higher fee level.

Well, = we'll have to make sure this is carefully and loudly documented in the = new developer part of the website that's being worked on. Because this = seems like a recipe for people writing flaky apps. In practice it would see= m like you need to implement the fee loop in your own app:

1) Create tx with an estimated fee level
2) A= dd signatures
3) Submit. If REJECT for too low fees, increment, g= o to 1 and try again.


--089e0139fc606b6bac04f46b82f0--