[Bitcoin-development] multisig, op_eval and lock_time/sequence...
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 0x=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
Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
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 0x=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 -- 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
Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
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 etothe...@gmail.com wrote: That's what my proposal was for, in BIP 0010: https://github.com/genjix/**bips/blob/master/bip-0010.mdhttps://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 0x=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.netBitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/**lists/listinfo/bitcoin-**developmenthttps://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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
Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
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 -- 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
Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
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: grona...@ceptacle.com -- 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
Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
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 -- 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
Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
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. -- 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
Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
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 gavinandre...@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. -- 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
Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
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
