Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.169 as permitted sender)
	client-ip=209.85.212.169; envelope-from=etotheipi@gmail.com;
	helo=mail-wi0-f169.google.com; 
MIME-Version: 1.0
Date: Thu, 14 Jun 2012 10:25:07 -0400
Message-ID: <CALf2ePzWye8fFn8oV=q-izudbPFQ5wDyn+n=j+=9LiwhZxBozQ@mail.gmail.com>
From: Alan Reiner <etotheipi@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0442835c6b152e04c26f77ab
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] A tangent about BIP 10
Precedence: list

--f46d0442835c6b152e04c26f77ab
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 14, 2012 at 9:22 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:

>
> I've been asked a couple of times: why doesn't signrawtx handle the
> BIP 0010 (https://en.bitcoin.it/wiki/BIP_0010) transaction format?
>
> I considered parsing/writing BIP 10 format for raw transactions, but
> decided that reading/writing BIP 10 format should happen at a higher
> level and not in the low-level RPC calls. So 'raw transactions' are
> simply hex-encoded into JSON strings, and encoding/decoding them is
> just a couple of lines of already-written-and-debugged code.
>
>
BIP 10 <https://en.bitcoin.it/wiki/BIP_0010> could use some improvement.  I
created it for offline and multi-sig tx but there was no reception to it
because no one was using offline or multi-sig tx at the time except for
Armory (which only currently implements offline tx).  So I made something
that fit my needs, and it has served its purpose well for me. But I also
think it could be expanded and improved before there is wider adoption of
it.  It's a little clunky and not very rigorous.

Elements of it that I'd really like to keep:

(1) Some aspects of human-readability -- even if regular users will never
look at it, it should be possible for advanced users to manually copy&paste
the data around and see what's going on in the transaction and what
signatures are present.  I'm thinking of super-high-security situations
where manual handling of such data may even be the norm.
(2) Should be compact -- I took the concept of ASCII-armoring from PGP/GPG,
because, for the reason above, it's much easier and cleaner to view/select
when copied inline.  If a random user accidentally runs across it, it will
partially self-identify itself
(3) Includes all previous transactions so the device can verify transaction
inputs without the blockchain.


Things that could be added:

-- It needs a BIP16 script entry (this was created for vanilla multi-sig
before BIP 16 was created)
-- Comment lines
-- Version number
-- Use base58/64 encoding
-- Rigorous formatting spec
-- Binary representation
-- A better name than "Tx Distribution Proposal"

I'll be releasing the Beta version of Armory soon, and after that, I'll
probably be thinking about a multi-signature support interface.  That would
be a good time for me to tie in a better version of BIP 10 -- one that is
compatible with other clients implementing the same thing.

--f46d0442835c6b152e04c26f77ab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Jun 14, 2012 at 9:22 AM, Gavin Andresen =
<span dir=3D"ltr">&lt;<a href=3D"mailto:gavinandresen@gmail.com" target=3D"=
_blank">gavinandresen@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<br>
I&#39;ve been asked a couple of times: why doesn&#39;t signrawtx handle the=
<br>
BIP 0010 (<a href=3D"https://en.bitcoin.it/wiki/BIP_0010" target=3D"_blank"=
>https://en.bitcoin.it/wiki/BIP_0010</a>) transaction format?<br>
<br>
I considered parsing/writing BIP 10 format for raw transactions, but<br>
decided that reading/writing BIP 10 format should happen at a higher<br>
level and not in the low-level RPC calls. So &#39;raw transactions&#39; are=
<br>
simply hex-encoded into JSON strings, and encoding/decoding them is<br>
just a couple of lines of already-written-and-debugged code.<br>
<br></blockquote><div><br></div><div><a href=3D"https://en.bitcoin.it/wiki/=
BIP_0010">BIP 10</a> could use some improvement. =A0I created it for offlin=
e and multi-sig tx but there was no reception to it because no one was usin=
g offline or multi-sig tx at the time except for Armory (which only current=
ly implements offline tx). =A0So I made something that fit my needs, and it=
 has served its purpose well for me. But I also think it could be expanded =
and improved before there is wider adoption of it. =A0It&#39;s a little clu=
nky and not very rigorous.</div>
<div><br></div><div>Elements of it that I&#39;d really like to keep:</div><=
div><br></div><div>(1) Some aspects of human-readability -- even if regular=
 users will never look at it, it should be possible for advanced users to m=
anually copy&amp;paste the data around and see what&#39;s going on in the t=
ransaction and what signatures are present. =A0I&#39;m thinking of super-hi=
gh-security situations where manual handling of such data may even be the n=
orm.</div>
<div>(2) Should be compact -- I took the concept of ASCII-armoring from PGP=
/GPG, because, for the reason above, it&#39;s much easier and cleaner to vi=
ew/select when copied inline. =A0If a random user accidentally runs across =
it, it will partially self-identify itself</div>
<div>(3) Includes all previous transactions so the device can verify transa=
ction inputs without the blockchain.</div><div><br></div><div><br></div><di=
v>Things that could be added:</div><div><br></div><div>-- It needs a BIP16 =
script entry (this was created for vanilla multi-sig before BIP 16 was crea=
ted)</div>
<div>-- Comment lines</div><div>-- Version number</div><div>-- Use base58/6=
4 encoding</div><div>-- Rigorous formatting spec</div><div>-- Binary repres=
entation</div><div>-- A better name than &quot;Tx Distribution Proposal&quo=
t;</div>
<div><br></div><div>I&#39;ll be releasing the Beta version of Armory soon, =
and after that, I&#39;ll probably be thinking about a multi-signature suppo=
rt interface. =A0That would be a good time for me to tie in a better versio=
n of BIP 10 -- one that is compatible with other clients implementing the s=
ame thing.</div>
</div>

--f46d0442835c6b152e04c26f77ab--