public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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, 9 Nov 2011 10:22:57 -0500	[thread overview]
Message-ID: <CALf2ePw2zcxrPFfQtJrDYSNWQ-rfNPv1R7LnH=8MHApe3_D1+Q@mail.gmail.com> (raw)
In-Reply-To: <4EBA9199.7050201@gmail.com>

[-- 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 --]

  reply	other threads:[~2011-11-09 15:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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='CALf2ePw2zcxrPFfQtJrDYSNWQ-rfNPv1R7LnH=8MHApe3_D1+Q@mail.gmail.com' \
    --to=etotheipi@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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