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" wrote: > 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 >> > >