Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...

[Alan Reiner]

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

Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...

[theymos]

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" 
 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...

[Joel Joonatan Kaartinen]

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...

[Gavin Andresen]

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...

[Michael Grønager]

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: 
> scriptPubKey: ...standard DUP HASH160  ...etc
> nValue: 0
> 
> The other parties to the escrow transaction could monitor the
> block-chain for transactions to my , 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  transaction>.
> 
> The standard   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
>  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...

[Michael Grønager]

Hi Gavin / Alan,

Agree that we would also need to consider these "half" transaction valid. At 
least for the time being up to the lock_time, and one could have an extra 
constrain - that the lock_time should be within e.g. 30minutes that would avoid 
the will-never-be-completed cases.

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 

I can, however, also understand your worries, and some other constraints should 
be introduced to ensure that not even short time spamming is possible... 

/M

On 09/11/2011, at 20:13, Gavin Andresen wrote:

>> 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.
> 
> As Alan said, that won't work-- it will not be relayed across the
> network because it isn't a valid transaction until it has enough
> signatures.
> 
>> Alternatively, the transactions would need to be sent between clients using 
>> another protocol...
> 
> Formats and protocols for gathering signatures are in the TODO
> category-- Alan's BIP 10 is the next piece of the puzzle, maybe a
> standardized http/https RESTful API, or HTTP/JSON, or protocol buffers
> and raw sockets, or... something... solution (or solutions) built on
> top of that makes sense.
> 
> 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.
> 
> -- 
> --
> 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...

[Gavin Andresen]

> 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: 
scriptPubKey: ...standard DUP HASH160  ...etc
nValue: 0

The other parties to the escrow transaction could monitor the
block-chain for transactions to my , 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 .

The standard   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
 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...

[Gavin Andresen]

> 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.

As Alan said, that won't work-- it will not be relayed across the
network because it isn't a valid transaction until it has enough
signatures.

> Alternatively, the transactions would need to be sent between clients using 
> another protocol...

Formats and protocols for gathering signatures are in the TODO
category-- Alan's BIP 10 is the next piece of the puzzle, maybe a
standardized http/https RESTful API, or HTTP/JSON, or protocol buffers
and raw sockets, or... something... solution (or solutions) built on
top of that makes sense.

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.

-- 
--
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...

[Alan Reiner]

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 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...

[Alan Reiner]

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

[Bitcoin-development] multisig, op_eval and lock_time/sequence...

[Michael Grønager]

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