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). 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).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
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.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.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?
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-developmentMichael 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