path: root/62/690c581a4a2f05e7a1b27539036c48fcb829f2

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 <etotheipi@gmail.com>) id 1ROUBT-0005LM-9m
	for bitcoin-development@lists.sourceforge.net;
	Thu, 10 Nov 2011 12:56:47 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.47 as permitted sender)
	client-ip=209.85.212.47; envelope-from=etotheipi@gmail.com;
	helo=mail-vw0-f47.google.com; 
Received: from mail-vw0-f47.google.com ([209.85.212.47])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.76) id 1ROUBS-0002rk-0I
	for bitcoin-development@lists.sourceforge.net;
	Thu, 10 Nov 2011 12:56:47 +0000
Received: by vwe42 with SMTP id 42so3073224vwe.34
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 10 Nov 2011 04:56:40 -0800 (PST)
Received: by 10.52.25.107 with SMTP id b11mr12544664vdg.75.1320929800544;
	Thu, 10 Nov 2011 04:56:40 -0800 (PST)
Received: from [192.168.1.85] (c-76-111-108-35.hsd1.md.comcast.net.
	[76.111.108.35])
	by mx.google.com with ESMTPS id ka10sm3104395vdb.4.2011.11.10.04.56.39
	(version=SSLv3 cipher=OTHER); Thu, 10 Nov 2011 04:56:39 -0800 (PST)
Message-ID: <4EBBCA0D.9060906@gmail.com>
Date: Thu, 10 Nov 2011 07:56:45 -0500
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
References: <BD206D96-C458-4DD7-92F6-32AE476C259A@ceptacle.com>
	<CABsx9T3T7UZ-G9wsb_NDMBYpnnp9XBnjULmVVDgVXzEaUKn=5w@mail.gmail.com>
	<200034A7-15F9-438F-A6B1-923A69348F55@ceptacle.com>
	<4EBB3E68.6060402@gmail.com>
	<CBFE8E7C-7A30-4450-A111-4EB413E068DF@ceptacle.com>
In-Reply-To: <CBFE8E7C-7A30-4450-A111-4EB413E068DF@ceptacle.com>
Content-Type: multipart/alternative;
	boundary="------------050706010402060708020404"
X-Spam-Score: -0.8 (/)
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
	(etotheipi[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	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
	-0.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1ROUBS-0002rk-0I
Subject: Re: [Bitcoin-development] multisig,
	op_eval and lock_time/sequence...
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 10 Nov 2011 12:56:47 -0000

This is a multi-part message in MIME format.
--------------050706010402060708020404
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Michael, thanks for taking time to read the proposal.  Responses are 
inline, below.
> I am not sure where you prefer the discussion on the content of the BIP - but now you get it here, but feel free to redirect...
>
> Likes:
> * inclusion of prevout txout scripts - could prove handy
> * that it is a proposal to do this similarly on all clients
The txout scripts are not just handy, they /need/ to be included in the 
txin scripts for signing.  By putting them there already, the parser 
only has to blank out the others txins, add the hashcode, and pass it to 
the ECDSA code for signing (if you're not familar with OP_CHECKSIG, see 
my diagram here <https://bitcointalk.org/index.php?topic=29416.0>).  I 
think this feature is *critical* to adoption, as it works for the most 
lightweight clients that might not even contain blockheaders -- 
everything you need to understand and sign the the transaction is 
included (except for the txin values).

For that reason, this doubles as a convenient way to do offline 
wallets/signing:  you don't have to keep transporting 700 MB of 
blockchain to the offline computer just so it can sign your transactions.
> Dislikes:
> * the format - I guess I would prefer a normal JSON format - where the scripts gets populated step by step. As for the scriptPubKey (now an awful name...) it would be easy to just add it to the JSON, or have the prevouts simply be the actual txouts instead of {hash,n}.
I see the benefit of JSON for dynamic information with lots of optional 
fields.  But this information is fairly static -- if there's extra 
information developers need for this process, it can be added.  I don't 
see a lot of variation in the amount/types of data to be included here.

The core benefit follows PGP messages:  compact, easy-to-identify, 
blocks of text, that can be included inline in an email as easily as it 
can be supplied as a file/attachment, and only requires code that's 
already available in a BTC developer toolbox.  I can even remove the 
numsigs counter, as it's easy enough to search for the END-TXDP line.  
Think about a non-developer opening a file and trying to identify it:  
JSON looks like code, this looks like... "----BEGIN-TXDP---"  (now that 
I think about it, "BEGIN-TRANSACTION-9fj3fsQ" might be better...)
> Comments:
> * it is good to have this proposal, but I think that once we see ways to communicate it they could very well radically steer how a format should look. Take e.g. the discussion we had with Gavin yesterday, if we had chosen to move in that direction BIP0010 would had been useless. So perhaps a bit premature?
>
If we start talking about in-blockchain techniques, I agree with you.  
But If that idea is discarded, *all* out-of-band solutions are going to 
require encoding this exact information somehow.  I think offering this 
solution before developers start asking the question of how to do it is 
exactly what's needed.

-Alan
> Cheers,
>
> Michael
>
>
> On 10/11/2011, at 04:00, Alan Reiner wrote:
>
>> The purpose of creating BIP 0010 now, is to encourage a standard that developers want to adopt, from the outset.  Every developer who is planning to touch multi-signature transactions, is going to have to solve the problem of multi-sig tx exchanges, eventually.  By offering an excellent solution before they've started asking the question, there's a good chance people will use it.   Hear me out...
>>
>> Protocols get fragmented when there's multiple competing ways to do something, each having some advantages the others don't have.  This leads to developers with differing priorities picking different ones, or creating their own.   However, I believe that the problem BIP 0010 seeks to solve is a fairly straightforward problem.  There's not a lot of variety in the solutions that could compete against it.  People just need a way to pass this data around, and they want it to be as convenient to use, and as easy to implement as possible.  In that sense, I think BIP 0010 (or some future variant) is fairly optimal as a building block for higher-level protocols.
>>
>> If anyone has ideas for why someone would want to create a competing idea to BIP 0010 (besides not being aware of it when they start), I'd like to discuss it.  I'm fairly confident that any such ideas could just be added to BIP 0010 and thus reset the question of why anyone would need a competing idea.
>>
>>
>>
>> On 11/09/2011 03:03 PM, Michael Grønager wrote:
>>> My main concern when it comes to introducing other protocols is that they might never be standard (I think a great number of clients will emerge - and this would be a thing to compete on). If it is part of the p2p network it will be a seamless standard and easy for everyone to use, even across different clients. But I share your concern on the
>>>
>>> /M
>>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Save $700 by Nov 18
>> Register now
>> http://p.sf.net/sfu/rsa-sfdev2dev1
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> Michael Gronager, PhD
> Owner Ceptacle / NDGF Director, NORDUnet A/S
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 62 14 01
> E-mail: gronager@ceptacle.com
>
>
> Michael Gronager, PhD
> Owner Ceptacle / NDGF Director, NORDUnet A/S
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 62 14 01
> E-mail: gronager@ceptacle.com
>
>


--------------050706010402060708020404
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Michael, thanks for taking time to read the proposal.&nbsp; Responses are
    inline, below.<br>
    <blockquote
      cite="mid:CBFE8E7C-7A30-4450-A111-4EB413E068DF@ceptacle.com"
      type="cite">
      <pre wrap="">I am not sure where you prefer the discussion on the content of the BIP - but now you get it here, but feel free to redirect...

Likes:
* inclusion of prevout txout scripts - could prove handy
* that it is a proposal to do this similarly on all clients
</pre>
    </blockquote>
    The txout scripts are not just handy, they <i>need</i> to be
    included in the txin scripts for signing.&nbsp; By putting them there
    already, the parser only has to blank out the others txins, add the
    hashcode, and pass it to the ECDSA code for signing (if you're not
    familar with OP_CHECKSIG, see my diagram <a
      href="https://bitcointalk.org/index.php?topic=29416.0">here</a>).&nbsp;
    I think this feature is <b>critical</b> to adoption, as it works
    for the most lightweight clients that might not even contain
    blockheaders -- everything you need to understand and sign the the
    transaction is included (except for the txin values).<br>
    <br>
    For that reason, this doubles as a convenient way to do offline
    wallets/signing:&nbsp; you don't have to keep transporting 700 MB of
    blockchain to the offline computer just so it can sign your
    transactions. <br>
    <blockquote
      cite="mid:CBFE8E7C-7A30-4450-A111-4EB413E068DF@ceptacle.com"
      type="cite">
      <pre wrap="">Dislikes:
* the format - I guess I would prefer a normal JSON format - where the scripts gets populated step by step. As for the scriptPubKey (now an awful name...) it would be easy to just add it to the JSON, or have the prevouts simply be the actual txouts instead of {hash,n}.
</pre>
    </blockquote>
    I see the benefit of JSON for dynamic information with lots of
    optional fields.&nbsp; But this information is fairly static -- if
    there's extra information developers need for this process, it can
    be added.&nbsp; I don't see a lot of variation in the amount/types of
    data to be included here.<br>
    <br>
    The core benefit follows PGP messages:&nbsp; compact, easy-to-identify,
    blocks of text, that can be included inline in an email as easily as
    it can be supplied as a file/attachment, and only requires code
    that's already available in a BTC developer toolbox.&nbsp; I can even
    remove the numsigs counter, as it's easy enough to search for the
    END-TXDP line.&nbsp; Think about a non-developer opening a file and
    trying to identify it:&nbsp; JSON looks like code, this looks like...
    "----BEGIN-TXDP---"&nbsp; (now that I think about it,
    "BEGIN-TRANSACTION-9fj3fsQ" might be better...)<br>
    <blockquote
      cite="mid:CBFE8E7C-7A30-4450-A111-4EB413E068DF@ceptacle.com"
      type="cite">
      <pre wrap="">Comments:
* it is good to have this proposal, but I think that once we see ways to communicate it they could very well radically steer how a format should look. Take e.g. the discussion we had with Gavin yesterday, if we had chosen to move in that direction BIP0010 would had been useless. So perhaps a bit premature?

</pre>
    </blockquote>
    If we start talking about in-blockchain techniques, I agree with
    you.&nbsp; But If that idea is discarded, <b>all</b> out-of-band
    solutions are going to require encoding this exact information
    somehow.&nbsp; I think offering this solution before developers start
    asking the question of how to do it is exactly what's needed.<br>
    <br>
    -Alan<br>
    <blockquote
      cite="mid:CBFE8E7C-7A30-4450-A111-4EB413E068DF@ceptacle.com"
      type="cite">
      <pre wrap="">Cheers,

Michael

</pre>
    </blockquote>
    <blockquote
      cite="mid:CBFE8E7C-7A30-4450-A111-4EB413E068DF@ceptacle.com"
      type="cite">
      <pre wrap="">

On 10/11/2011, at 04:00, Alan Reiner wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">The purpose of creating BIP 0010 now, is to encourage a standard that developers want to adopt, from the outset.  Every developer who is planning to touch multi-signature transactions, is going to have to solve the problem of multi-sig tx exchanges, eventually.  By offering an excellent solution before they've started asking the question, there's a good chance people will use it.   Hear me out...

Protocols get fragmented when there's multiple competing ways to do something, each having some advantages the others don't have.  This leads to developers with differing priorities picking different ones, or creating their own.   However, I believe that the problem BIP 0010 seeks to solve is a fairly straightforward problem.  There's not a lot of variety in the solutions that could compete against it.  People just need a way to pass this data around, and they want it to be as convenient to use, and as easy to implement as possible.  In that sense, I think BIP 0010 (or some future variant) is fairly optimal as a building block for higher-level protocols.  

If anyone has ideas for why someone would want to create a competing idea to BIP 0010 (besides not being aware of it when they start), I'd like to discuss it.  I'm fairly confident that any such ideas could just be added to BIP 0010 and thus reset the question of why anyone would need a competing idea.



On 11/09/2011 03:03 PM, Michael Gr&oslash;nager wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">My main concern when it comes to introducing other protocols is that they might never be standard (I think a great number of clients will emerge - and this would be a thing to compete on). If it is part of the p2p network it will be a seamless standard and easy for everyone to use, even across different clients. But I share your concern on the 

/M

</pre>
        </blockquote>
        <pre wrap="">
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/rsa-sfdev2dev1">http://p.sf.net/sfu/rsa-sfdev2dev1</a>
_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
      </blockquote>
      <pre wrap="">
Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: <a class="moz-txt-link-abbreviated" href="mailto:gronager@ceptacle.com">gronager@ceptacle.com</a>


Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: <a class="moz-txt-link-abbreviated" href="mailto:gronager@ceptacle.com">gronager@ceptacle.com</a>


</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------050706010402060708020404--