* [Bitcoin-development] multisig, op_eval and lock_time/sequence... @ 2011-11-09 10:22 Michael Grønager 2011-11-09 14:43 ` Alan Reiner 2011-11-09 19:13 ` Gavin Andresen 0 siblings, 2 replies; 18+ messages in thread From: Michael Grønager @ 2011-11-09 10:22 UTC (permalink / raw) To: Bitcoin Dev Hi All, Along with the multisig/op_eval BIPs (11/12) I am considering how the actual client functionality could be. Some of you might already have the solution for this - if not I would like to propose the following... Lets consider the 2 of 3 multisig - and lets say I now have some coins hence only redeemable using 2 key signatures. So when I want to spend them I would do: 1. from client1 I issue a transaction containing one of the signatures, with a locktime e.g. 10 minutes from now and a sequence of 0. This transaction is now posted to the p2p network. 2. client2 discovers the transaction and that it will affect its wallet. It hence modifies the transaction to includes also the second signature, changes the sequence to 0xFFFFFFFF=final and the lock_time to 0 and retransmits the transaction. 3. The transaction is now valid and final and will be approved by the miners. However, for this setup to be possible, we need to reenable the replacement of transaction in the client.... Anyone working on this now ? Alternatively, the transactions would need to be sent between clients using another protocol... Cheers, Michael ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-09 10:22 [Bitcoin-development] multisig, op_eval and lock_time/sequence Michael Grønager @ 2011-11-09 14:43 ` Alan Reiner 2011-11-09 15:22 ` Alan Reiner 2011-11-09 19:13 ` Gavin Andresen 1 sibling, 1 reply; 18+ messages in thread From: Alan Reiner @ 2011-11-09 14:43 UTC (permalink / raw) To: bitcoin-development That's what my proposal was for, in BIP 0010: https://github.com/genjix/bips/blob/master/bip-0010.md However, I just found a minor problem with it that should be addressed if we want to enable super-lightweight clients that only sign tx's without needing the blockchain. Simply that the TxIns don't contain the value of the TxOuts they are spending, which means the dumb tx-signers with no blockchain can't tell how much input there is. They can only see the output values and recipients, which means they can't figure out the tx fee, or how much money is in each of the TxIns they are signing. And most users/clients will have access to the blockchain, so it's not a dealbreaker. But it's something to consider. Otherwise, I think this is a big step towards bringing this complicatedprotocol a little closer to Earth... On 11/09/2011 05:22 AM, Michael Grønager wrote: > Hi All, > > Along with the multisig/op_eval BIPs (11/12) I am considering how the actual client functionality could be. > > Some of you might already have the solution for this - if not I would like to propose the following... > > Lets consider the 2 of 3 multisig - and lets say I now have some coins hence only redeemable using 2 key signatures. So when I want to spend them I would do: > > 1. from client1 I issue a transaction containing one of the signatures, with a locktime e.g. 10 minutes from now and a sequence of 0. This transaction is now posted to the p2p network. > > 2. client2 discovers the transaction and that it will affect its wallet. It hence modifies the transaction to includes also the second signature, changes the sequence to 0xFFFFFFFF=final and the lock_time to 0 and retransmits the transaction. > > 3. The transaction is now valid and final and will be approved by the miners. > > However, for this setup to be possible, we need to reenable the replacement of transaction in the client.... > > Anyone working on this now ? > > Alternatively, the transactions would need to be sent between clients using another protocol... > > Cheers, > > Michael > > > > ------------------------------------------------------------------------------ > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-09 14:43 ` Alan Reiner @ 2011-11-09 15:22 ` Alan Reiner 0 siblings, 0 replies; 18+ messages in thread From: Alan Reiner @ 2011-11-09 15:22 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 3314 bytes --] Actually, I'm not sure if your solution works, because it relies on broadcasting a tx to the network that isn't valid. I believe that the first tx in your proposal will be rejected and thus you'll need to exchange the tx's offline. However, third-parties could pretty easily and conveniently host a service for this kind of exchange. --Sent from my overpriced smartphone On Nov 9, 2011 9:43 AM, "Alan Reiner" <etotheipi@gmail•com> wrote: > That's what my proposal was for, in BIP 0010: > > https://github.com/genjix/**bips/blob/master/bip-0010.md<https://github.com/genjix/bips/blob/master/bip-0010.md> > > However, I just found a minor problem with it that should be addressed if > we want to enable super-lightweight clients that only sign tx's without > needing the blockchain. Simply that the TxIns don't contain the value of > the TxOuts they are spending, which means the dumb tx-signers with no > blockchain can't tell how much input there is. They can only see the > output values and recipients, which means they can't figure out the tx fee, > or how much money is in each of the TxIns they are signing. > > And most users/clients will have access to the blockchain, so it's not a > dealbreaker. But it's something to consider. Otherwise, I think this is a > big step towards bringing this complicatedprotocol a little closer to > Earth... > > > > > > > On 11/09/2011 05:22 AM, Michael Grønager wrote: > >> Hi All, >> >> Along with the multisig/op_eval BIPs (11/12) I am considering how the >> actual client functionality could be. >> >> Some of you might already have the solution for this - if not I would >> like to propose the following... >> >> Lets consider the 2 of 3 multisig - and lets say I now have some coins >> hence only redeemable using 2 key signatures. So when I want to spend them >> I would do: >> >> 1. from client1 I issue a transaction containing one of the signatures, >> with a locktime e.g. 10 minutes from now and a sequence of 0. This >> transaction is now posted to the p2p network. >> >> 2. client2 discovers the transaction and that it will affect its wallet. >> It hence modifies the transaction to includes also the second signature, >> changes the sequence to 0xFFFFFFFF=final and the lock_time to 0 and >> retransmits the transaction. >> >> 3. The transaction is now valid and final and will be approved by the >> miners. >> >> However, for this setup to be possible, we need to reenable the >> replacement of transaction in the client.... >> >> Anyone working on this now ? >> >> Alternatively, the transactions would need to be sent between clients >> using another protocol... >> >> Cheers, >> >> Michael >> >> >> >> ------------------------------**------------------------------** >> ------------------ >> RSA(R) Conference 2012 >> Save $700 by Nov 18 >> Register now >> http://p.sf.net/sfu/rsa-**sfdev2dev1 <http://p.sf.net/sfu/rsa-sfdev2dev1> >> ______________________________**_________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.**sourceforge.net<Bitcoin-development@lists•sourceforge.net> >> https://lists.sourceforge.net/**lists/listinfo/bitcoin-**development<https://lists.sourceforge.net/lists/listinfo/bitcoin-development> >> > > [-- Attachment #2: Type: text/html, Size: 3888 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-09 10:22 [Bitcoin-development] multisig, op_eval and lock_time/sequence Michael Grønager 2011-11-09 14:43 ` Alan Reiner @ 2011-11-09 19:13 ` Gavin Andresen 2011-11-09 20:02 ` Gavin Andresen 2011-11-09 20:03 ` Michael Grønager 1 sibling, 2 replies; 18+ messages in thread From: Gavin Andresen @ 2011-11-09 19:13 UTC (permalink / raw) To: Michael Grønager; +Cc: Bitcoin Dev > 1. from client1 I issue a transaction containing one of the signatures, with a locktime e.g. 10 minutes from now and a sequence of 0. This transaction is now posted to the p2p network. As Alan said, that won't work-- it will not be relayed across the network because it isn't a valid transaction until it has enough signatures. > Alternatively, the transactions would need to be sent between clients using another protocol... Formats and protocols for gathering signatures are in the TODO category-- Alan's BIP 10 is the next piece of the puzzle, maybe a standardized http/https RESTful API, or HTTP/JSON, or protocol buffers and raw sockets, or... something... solution (or solutions) built on top of that makes sense. I don't think partially-signed transactions belong on the main Bitcoin P2P network, mostly because I don't see any way of preventing somebody from endlessly spamming bogus, will-never-be-completed partial transactions just to be annoying. -- -- Gavin Andresen ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-09 19:13 ` Gavin Andresen @ 2011-11-09 20:02 ` Gavin Andresen 2011-11-09 20:31 ` Michael Grønager 2011-11-09 22:13 ` theymos 2011-11-09 20:03 ` Michael Grønager 1 sibling, 2 replies; 18+ messages in thread From: Gavin Andresen @ 2011-11-09 20:02 UTC (permalink / raw) To: Michael Grønager; +Cc: Bitcoin Dev > I don't think partially-signed transactions belong on the main Bitcoin > P2P network, mostly because I don't see any way of preventing somebody > from endlessly spamming bogus, will-never-be-completed partial > transactions just to be annoying. ... of course I write that and then start thinking about ways you COULD use the P2P network to distribute signatures, maybe by broadcasting (and paying fees for) complete transactions that contain extra signatures for the transaction that you want to sign. Here's a half-baked idea that might be brilliant or stupid: + Start with an escrow transaction, with 3 public keys. I own one of the keys. + I broadcast a 'fee-only' transaction that pays 0 bitcoins to the key I own. But I add extra data to the scriptSig; something like: scriptSig: <escrow_signature> <serialized_escrow_transaction> <sig> <pubkey> scriptPubKey: ...standard DUP HASH160 <pubkeyhash> ...etc nValue: 0 The other parties to the escrow transaction could monitor the block-chain for transactions to my <pubkeyhash>, and get the signature and proposed "spend the funds in escrow" transaction from the scriptSig. ....... "But won't that gunk up the block chain with more data?" Yup. But the parties to the transaction will have to pay for the extra data they're including. And everything in the scriptSigs can, theoretically, be forgotten (or never sent) to most nodes on the network once the transaction is spent and is buried deep enough in the block chain. (a nValue=0 transaction can be considered 'immediately spent'). "Can you really put arbitrary stuff in the scriptSig?" Yup. The IsStandard() check today allows up to 200 bytes, which wouldn't be enough for an extra signature and <serialized transaction>. The standard <sig> <pubkey> is about 150 bytes; part of the multi-signature proposal will be increasing that to 500 bytes to accomodate 3-signatures transactions. A simple 1-input-1-output <serialized transaction> would be around 50 bytes or so. "Wouldn't it be cheaper/better to NOT use the block chain to distribute signatures?" Yup. The only advantage I see is it might be more anonymous to use the blockchain instead of directly connecting to, and finding out the IP address of, the parties involved in the transaction. -- -- Gavin Andresen ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-09 20:02 ` Gavin Andresen @ 2011-11-09 20:31 ` Michael Grønager 2011-11-09 21:18 ` Gavin Andresen 2011-11-09 22:13 ` theymos 1 sibling, 1 reply; 18+ messages in thread From: Michael Grønager @ 2011-11-09 20:31 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev Crossing posts ;) I like your idea! - It adds a pricetag to distributing a signature - and - as you mention it will be part of the standard. It is only up to the clients if they want to support it or not, but it does give you 0-conf world wide instantaneous anonymously distribution of half-baked transactions... However, the parties will anyway need to know at least about each others public keys up front and hence the 0-conf might not be that important... Left is, as you said, some anonymity (not much extra though)... /M On 09/11/2011, at 21:02, Gavin Andresen wrote: >> I don't think partially-signed transactions belong on the main Bitcoin >> P2P network, mostly because I don't see any way of preventing somebody >> from endlessly spamming bogus, will-never-be-completed partial >> transactions just to be annoying. > > ... of course I write that and then start thinking about ways you > COULD use the P2P network to distribute signatures, maybe by > broadcasting (and paying fees for) complete transactions that contain > extra signatures for the transaction that you want to sign. > > Here's a half-baked idea that might be brilliant or stupid: > > + Start with an escrow transaction, with 3 public keys. I own one of the keys. > + I broadcast a 'fee-only' transaction that pays 0 bitcoins to the key > I own. But I add extra data to the scriptSig; something like: > > scriptSig: <escrow_signature> <serialized_escrow_transaction> <sig> <pubkey> > scriptPubKey: ...standard DUP HASH160 <pubkeyhash> ...etc > nValue: 0 > > The other parties to the escrow transaction could monitor the > block-chain for transactions to my <pubkeyhash>, and get the signature > and proposed "spend the funds in escrow" transaction from the > scriptSig. > > ....... > > "But won't that gunk up the block chain with more data?" > > Yup. But the parties to the transaction will have to pay for the > extra data they're including. > > And everything in the scriptSigs can, theoretically, be forgotten (or > never sent) to most nodes on the network once the transaction is spent > and is buried deep enough in the block chain. (a nValue=0 transaction > can be considered 'immediately spent'). > > "Can you really put arbitrary stuff in the scriptSig?" > > Yup. The IsStandard() check today allows up to 200 bytes, which > wouldn't be enough for an extra signature and <serialized > transaction>. > > The standard <sig> <pubkey> is about 150 bytes; part of the > multi-signature proposal will be increasing that to 500 bytes to > accomodate 3-signatures transactions. A simple 1-input-1-output > <serialized transaction> would be around 50 bytes or so. > > "Wouldn't it be cheaper/better to NOT use the block chain to > distribute signatures?" > > Yup. The only advantage I see is it might be more anonymous to use the > blockchain instead of directly connecting to, and finding out the IP > address of, the parties involved in the transaction. > > > -- > -- > Gavin Andresen 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-09 20:31 ` Michael Grønager @ 2011-11-09 21:18 ` Gavin Andresen 2011-11-09 21:32 ` Joel Joonatan Kaartinen 0 siblings, 1 reply; 18+ messages in thread From: Gavin Andresen @ 2011-11-09 21:18 UTC (permalink / raw) To: Michael Grønager; +Cc: Bitcoin Dev One more thought on putting arbitrary stuff in the scriptSig: Miners could decide to revolt and remove the extra scriptSig information before including the transaction in their blocks. They'd still get the full transaction fee, and the transaction would still validate so the block would be accepted by everybody else. Come to think of it, if a node relaying transactions wanted to save bandwidth costs or be annoying, it could also strip off the extra information before forwarding it, so this isn't a reliable communication mechanism. It is probably a much better idea to use another protocol to gather signatures. -- -- Gavin Andresen ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-09 21:18 ` Gavin Andresen @ 2011-11-09 21:32 ` Joel Joonatan Kaartinen 0 siblings, 0 replies; 18+ messages in thread From: Joel Joonatan Kaartinen @ 2011-11-09 21:32 UTC (permalink / raw) To: Gavin Andresen; +Cc: Dev, Bitcoin It's propably best to create a separate p2p network for off-band information like this. No need to involve the blockchain with it. - Joel On Wed, 2011-11-09 at 16:18 -0500, Gavin Andresen wrote: > One more thought on putting arbitrary stuff in the scriptSig: > > Miners could decide to revolt and remove the extra scriptSig > information before including the transaction in their blocks. They'd > still get the full transaction fee, and the transaction would still > validate so the block would be accepted by everybody else. > > Come to think of it, if a node relaying transactions wanted to save > bandwidth costs or be annoying, it could also strip off the extra > information before forwarding it, so this isn't a reliable > communication mechanism. It is probably a much better idea to use > another protocol to gather signatures. > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-09 20:02 ` Gavin Andresen 2011-11-09 20:31 ` Michael Grønager @ 2011-11-09 22:13 ` theymos 1 sibling, 0 replies; 18+ messages in thread From: theymos @ 2011-11-09 22:13 UTC (permalink / raw) To: bitcoin-development For now I think requiring direct-connection negotiation is best for these kinds of things. A direct connection is OK in most cases, and more complicated schemes will be more likely to fail. Maybe the IP transactions protocol can be used. In the future, I imagine that users of ultra-lightweight clients will connect to a new P2P network built on top of the core Bitcoin network in order to receive block headers and info about sent/received transactions without leeching off of the few full nodes. This network could also be used for indirect transaction negotiation, which is similar to the goal of finding your own received transactions. On Wednesday, November 09, 2011 3:02 PM, "Gavin Andresen" <gavinandresen@gmail•com> wrote: > a nValue=0 transaction can be considered 'immediately spent' I believe it's possible to spend a 0-value output, so they can't be considered automatically spent. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-09 19:13 ` Gavin Andresen 2011-11-09 20:02 ` Gavin Andresen @ 2011-11-09 20:03 ` Michael Grønager 2011-11-10 3:00 ` Alan Reiner 1 sibling, 1 reply; 18+ messages in thread From: Michael Grønager @ 2011-11-09 20:03 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev Hi Gavin / Alan, Agree that we would also need to consider these "half" transaction valid. At least for the time being up to the lock_time, and one could have an extra constrain - that the lock_time should be within e.g. 30minutes that would avoid the will-never-be-completed cases. 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 I can, however, also understand your worries, and some other constraints should be introduced to ensure that not even short time spamming is possible... /M On 09/11/2011, at 20:13, Gavin Andresen wrote: >> 1. from client1 I issue a transaction containing one of the signatures, with a locktime e.g. 10 minutes from now and a sequence of 0. This transaction is now posted to the p2p network. > > As Alan said, that won't work-- it will not be relayed across the > network because it isn't a valid transaction until it has enough > signatures. > >> Alternatively, the transactions would need to be sent between clients using another protocol... > > Formats and protocols for gathering signatures are in the TODO > category-- Alan's BIP 10 is the next piece of the puzzle, maybe a > standardized http/https RESTful API, or HTTP/JSON, or protocol buffers > and raw sockets, or... something... solution (or solutions) built on > top of that makes sense. > > I don't think partially-signed transactions belong on the main Bitcoin > P2P network, mostly because I don't see any way of preventing somebody > from endlessly spamming bogus, will-never-be-completed partial > transactions just to be annoying. > > -- > -- > Gavin Andresen ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-09 20:03 ` Michael Grønager @ 2011-11-10 3:00 ` Alan Reiner 2011-11-10 9:55 ` Michael Grønager 0 siblings, 1 reply; 18+ messages in thread From: Alan Reiner @ 2011-11-10 3:00 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1796 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 2375 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-10 3:00 ` Alan Reiner @ 2011-11-10 9:55 ` Michael Grønager 2011-11-10 12:56 ` Alan Reiner 0 siblings, 1 reply; 18+ messages in thread From: Michael Grønager @ 2011-11-10 9:55 UTC (permalink / raw) To: Alan Reiner; +Cc: bitcoin-development Hi Alan, I have now read BIP0010 - one first idea is: add a link to it on the wiki (or remove all bip links from the wiki... - we don't want two places for BIPs...) 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}. 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-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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-10 9:55 ` Michael Grønager @ 2011-11-10 12:56 ` Alan Reiner 2011-11-12 16:58 ` Mike Hearn 0 siblings, 1 reply; 18+ messages in thread From: Alan Reiner @ 2011-11-10 12:56 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5551 bytes --] 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 > > [-- Attachment #2: Type: text/html, Size: 7336 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-10 12:56 ` Alan Reiner @ 2011-11-12 16:58 ` Mike Hearn 2011-11-12 17:10 ` Alan Reiner 0 siblings, 1 reply; 18+ messages in thread From: Mike Hearn @ 2011-11-12 16:58 UTC (permalink / raw) To: Alan Reiner; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1155 bytes --] Please don't create BIPs that don't have any actual implementation behind them. Design discussion is fine but the mailing list works for that. If I were going to implement escrow transactions in BitCoinJ it would not matter what was written here. I'd just implement the design I thought made sense. If that design was later adopted by others it can be documented and agreed upon in a BIP, just like a regular RFC. For what it's worth I would not attempt to send half-valid escrow transactions through the p2p network, not even using the overlay networks the protocol already supports. A correct escrow protocol requires the seller to challenge the dispute mediator with the public key to be sure they actually own it, and the simplest way to do that is to leverage the existing DNS/EV-SSL infrastructure with a "sign this nonce" HTTP request. BIPs should not be a place for people to come up with armchair designs, because a design with no corresponding implementation is likely to be full of problems. Let's revisit this once I can install some software on my laptop, my server, and a friends server, and do a 3-way mediated transaction between them. [-- Attachment #2: Type: text/html, Size: 1264 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-12 16:58 ` Mike Hearn @ 2011-11-12 17:10 ` Alan Reiner 2011-11-12 17:16 ` Mike Hearn 0 siblings, 1 reply; 18+ messages in thread From: Alan Reiner @ 2011-11-12 17:10 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2138 bytes --] Maybe I'm new to this, but this doesn't make any sense. I thought the point of the BIP was to collaborate to come up with a good solution. That's exactly what I want to do before I implement it in my software. After all, they are "Bitcoin Improvement *Proposals*." It seems like EXACTLY what a BIP is for... just no one needs/should use it until it removes the "draft" marking. As for the protocol on top of it, my BIP was not intended to address that. It's only proposing how unsigned transactions can be serialized and users can collect addresses. Whatever system you want to implement on top of it to exchange the data is up to the developer. My only motivation is that if the user clicks "Save this proposal to file", that any client can use the resulting file, just the same way we serialize any other blockdata that has a consistent representation. -Alan On 11/12/2011 11:58 AM, Mike Hearn wrote: > Please don't create BIPs that don't have any actual implementation > behind them. Design discussion is fine but the mailing list works for > that. > > If I were going to implement escrow transactions in BitCoinJ it would > not matter what was written here. I'd just implement the design I > thought made sense. If that design was later adopted by others it can > be documented and agreed upon in a BIP, just like a regular RFC. > > For what it's worth I would not attempt to send half-valid escrow > transactions through the p2p network, not even using the overlay > networks the protocol already supports. A correct escrow protocol > requires the seller to challenge the dispute mediator with the public > key to be sure they actually own it, and the simplest way to do that > is to leverage the existing DNS/EV-SSL infrastructure with a "sign > this nonce" HTTP request. > > BIPs should not be a place for people to come up with armchair > designs, because a design with no corresponding implementation is > likely to be full of problems. Let's revisit this once I can install > some software on my laptop, my server, and a friends server, and do a > 3-way mediated transaction between them. [-- Attachment #2: Type: text/html, Size: 2828 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-12 17:10 ` Alan Reiner @ 2011-11-12 17:16 ` Mike Hearn 2011-11-12 17:25 ` Alan Reiner 0 siblings, 1 reply; 18+ messages in thread From: Mike Hearn @ 2011-11-12 17:16 UTC (permalink / raw) To: Alan Reiner; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1076 bytes --] BIPs are either "standards track" (affects everyone, represents consensus), "informational" (ie basically just summarizing the authors viewpoints on things) or "process". My point is you can't have a credible standards track BIP until something has been implemented end to end. I don't think it's a good plan to design these things in isolation. You'll end up with bizarre user experiences because of technical decisions taken months earlier that are now hard to reverse. A working end to end implementation gives you the confidence to say, yes, this is how it should work, because here's the demo and you can see it works very well and the code is clean. If your BIP is informational then no problems, but I don't think there's much point in informational BIPs to be honest - it's easier to just write an email or forum post summarizing your views on things. If you find it a useful framework to write your thoughts in that's OK, but don't expect implementors to follow what's written there just because it's a BIP. It carries no more weight than any other document would. [-- Attachment #2: Type: text/html, Size: 1239 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-12 17:16 ` Mike Hearn @ 2011-11-12 17:25 ` Alan Reiner 2011-11-12 17:38 ` Mike Hearn 0 siblings, 1 reply; 18+ messages in thread From: Alan Reiner @ 2011-11-12 17:25 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev Fair enough. I'm not expecting anyone to just suddenly adopt BIP 0010 just because I published it to the wiki. I put it there to get feedback on what it might be missing, and maybe we can converge on a good preliminary solution. Then update it as we start playing with it and find more features/fixes to add to it. Right now, I have actually implemented BIP 0010 in my own client software (which is still a few weeks from even having an alpha version, but nontheless I'm actually implementing it). I'm going to use TxDPs in offline-wallet transactions, which is a nearly identical process (it's just a 1-of-1 transaction). As such, I will be interested to test with some other client developers, whether they can easily use the TxDPs I produce. I assume it doesn't bother you if I leave it the way it is, with the acknowledgment that I know no one is adopting it yet (except for myself). It's informational, until we get a couple different clients, or at least test setup to play with it. -Alan On 11/12/2011 12:16 PM, Mike Hearn wrote: > BIPs are either "standards track" (affects everyone, represents > consensus), "informational" (ie basically just summarizing the authors > viewpoints on things) or "process". > > My point is you can't have a credible standards track BIP until > something has been implemented end to end. I don't think it's a good > plan to design these things in isolation. You'll end up with bizarre > user experiences because of technical decisions taken months earlier > that are now hard to reverse. A working end to end implementation > gives you the confidence to say, yes, this is how it should work, > because here's the demo and you can see it works very well and the > code is clean. > > If your BIP is informational then no problems, but I don't think > there's much point in informational BIPs to be honest - it's easier to > just write an email or forum post summarizing your views on things. If > you find it a useful framework to write your thoughts in that's OK, > but don't expect implementors to follow what's written there just > because it's a BIP. It carries no more weight than any other document > would. > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... 2011-11-12 17:25 ` Alan Reiner @ 2011-11-12 17:38 ` Mike Hearn 0 siblings, 0 replies; 18+ messages in thread From: Mike Hearn @ 2011-11-12 17:38 UTC (permalink / raw) To: Alan Reiner; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 624 bytes --] Sure, of course, as long as it's clearly labelled as just your thoughts, no issues. For dispute mediation the way I'd start is playing around with some UI design stuff and a toy protocol underneath. Once the process is smooth from the users POV (no seeing binary blobs disguised as text) then it should become clearer what steps the protocol needs and what order they need to come in. Specific feedback on this format - as far as I can tell the format represents a subset of the regular bitcoin transaction format? Couldn't you just serialize a Bitcoin CTransaction structure with the txins containing the output scripts? [-- Attachment #2: Type: text/html, Size: 687 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-11-12 17:38 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-11-09 10:22 [Bitcoin-development] multisig, op_eval and lock_time/sequence Michael Grønager 2011-11-09 14:43 ` Alan Reiner 2011-11-09 15:22 ` Alan Reiner 2011-11-09 19:13 ` Gavin Andresen 2011-11-09 20:02 ` Gavin Andresen 2011-11-09 20:31 ` Michael Grønager 2011-11-09 21:18 ` Gavin Andresen 2011-11-09 21:32 ` Joel Joonatan Kaartinen 2011-11-09 22:13 ` theymos 2011-11-09 20:03 ` Michael Grønager 2011-11-10 3:00 ` Alan Reiner 2011-11-10 9:55 ` Michael Grønager 2011-11-10 12:56 ` Alan Reiner 2011-11-12 16:58 ` Mike Hearn 2011-11-12 17:10 ` Alan Reiner 2011-11-12 17:16 ` Mike Hearn 2011-11-12 17:25 ` Alan Reiner 2011-11-12 17:38 ` Mike Hearn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox