From: Alan Reiner <etotheipi@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
Date: Wed, 09 Nov 2011 09:43:37 -0500 [thread overview]
Message-ID: <4EBA9199.7050201@gmail.com> (raw)
In-Reply-To: <BD206D96-C458-4DD7-92F6-32AE476C259A@ceptacle.com>
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
next prev parent reply other threads:[~2011-11-09 14:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-09 10:22 Michael Grønager
2011-11-09 14:43 ` Alan Reiner [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EBA9199.7050201@gmail.com \
--to=etotheipi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox