[Bitcoin-development] multisig, op_eval and lock_time/sequence...
etotheipi at gmail.com
Wed Nov 9 15:22:57 UTC 2011
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 at gmail.com> wrote:
> That's what my proposal was for, in BIP 0010:
> 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
> 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
>> 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...
>> 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 at lists.**sourceforge.net<Bitcoin-development at lists.sourceforge.net>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev