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

2011-11-12 Thread Mike Hearn
Sure, of course, as long as it's clearly labelled as just your thoughts, no issues. For dispute mediation the way I'd start is playing around with some UI design stuff and a toy protocol underneath. Once the process is smooth from the users POV (no seeing binary blobs disguised as text) then it sh

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

2011-11-12 Thread Alan Reiner
Fair enough. I'm not expecting anyone to just suddenly adopt BIP 0010 just because I published it to the wiki. I put it there to get feedback on what it might be missing, and maybe we can converge on a good preliminary solution. Then update it as we start playing with it and find more featur

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

2011-11-12 Thread Mike Hearn
BIPs are either "standards track" (affects everyone, represents consensus), "informational" (ie basically just summarizing the authors viewpoints on things) or "process". My point is you can't have a credible standards track BIP until something has been implemented end to end. I don't think it's a

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

2011-11-12 Thread Alan Reiner
Maybe I'm new to this, but this doesn't make any sense. I thought the point of the BIP was to collaborate to come up with a good solution. That's exactly what I want to do before I implement it in my software. After all, they are "Bitcoin Improvement *Proposals*." It seems like EXACTLY what

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

2011-11-12 Thread Mike Hearn
Please don't create BIPs that don't have any actual implementation behind them. Design discussion is fine but the mailing list works for that. If I were going to implement escrow transactions in BitCoinJ it would not matter what was written here. I'd just implement the design I thought made sense.

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

2011-11-10 Thread Alan Reiner
Michael, thanks for taking time to read the proposal. Responses are inline, below. I am not sure where you prefer the discussion on the content of the BIP - but now you get it here, but feel free to redirect... Likes: * inclusion of prevout txout scripts - could prove handy * that it is a prop

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

2011-11-10 Thread Michael Grønager
Hi Alan, I have now read BIP0010 - one first idea is: add a link to it on the wiki (or remove all bip links from the wiki... - we don't want two places for BIPs...) I am not sure where you prefer the discussion on the content of the BIP - but now you get it here, but feel free to redirect... L

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

2011-11-09 Thread 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 solut

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

2011-11-09 Thread 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

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

2011-11-09 Thread 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

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

2011-11-09 Thread 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 accepte

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

2011-11-09 Thread 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-bake

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

2011-11-09 Thread 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 con

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

2011-11-09 Thread 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

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

2011-11-09 Thread 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 transa

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

2011-11-09 Thread 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 h

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

2011-11-09 Thread 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 d

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

2011-11-09 Thread 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 henc