Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
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. If that design was later adopted by others it can be documented and agreed upon in a BIP, just like a regular RFC. For what it's worth I would not attempt to send half-valid escrow transactions through the p2p network, not even using the overlay networks the protocol already supports. A correct escrow protocol requires the seller to challenge the dispute mediator with the public key to be sure they actually own it, and the simplest way to do that is to leverage the existing DNS/EV-SSL infrastructure with a "sign this nonce" HTTP request. BIPs should not be a place for people to come up with armchair designs, because a design with no corresponding implementation is likely to be full of problems. Let's revisit this once I can install some software on my laptop, my server, and a friends server, and do a 3-way mediated transaction between them. -- 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...
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 a BIP is for... just no one needs/should use it until it removes the "draft" marking. As for the protocol on top of it, my BIP was not intended to address that. It's only proposing how unsigned transactions can be serialized and users can collect addresses. Whatever system you want to implement on top of it to exchange the data is up to the developer. My only motivation is that if the user clicks "Save this proposal to file", that any client can use the resulting file, just the same way we serialize any other blockdata that has a consistent representation. -Alan On 11/12/2011 11:58 AM, Mike Hearn wrote: 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. If that design was later adopted by others it can be documented and agreed upon in a BIP, just like a regular RFC. For what it's worth I would not attempt to send half-valid escrow transactions through the p2p network, not even using the overlay networks the protocol already supports. A correct escrow protocol requires the seller to challenge the dispute mediator with the public key to be sure they actually own it, and the simplest way to do that is to leverage the existing DNS/EV-SSL infrastructure with a "sign this nonce" HTTP request. BIPs should not be a place for people to come up with armchair designs, because a design with no corresponding implementation is likely to be full of problems. Let's revisit this once I can install some software on my laptop, my server, and a friends server, and do a 3-way mediated transaction between them. -- 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...
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 good plan to design these things in isolation. You'll end up with bizarre user experiences because of technical decisions taken months earlier that are now hard to reverse. A working end to end implementation gives you the confidence to say, yes, this is how it should work, because here's the demo and you can see it works very well and the code is clean. If your BIP is informational then no problems, but I don't think there's much point in informational BIPs to be honest - it's easier to just write an email or forum post summarizing your views on things. If you find it a useful framework to write your thoughts in that's OK, but don't expect implementors to follow what's written there just because it's a BIP. It carries no more weight than any other document would. -- 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...
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 features/fixes to add to it. Right now, I have actually implemented BIP 0010 in my own client software (which is still a few weeks from even having an alpha version, but nontheless I'm actually implementing it). I'm going to use TxDPs in offline-wallet transactions, which is a nearly identical process (it's just a 1-of-1 transaction). As such, I will be interested to test with some other client developers, whether they can easily use the TxDPs I produce. I assume it doesn't bother you if I leave it the way it is, with the acknowledgment that I know no one is adopting it yet (except for myself). It's informational, until we get a couple different clients, or at least test setup to play with it. -Alan On 11/12/2011 12:16 PM, Mike Hearn wrote: > 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 good > plan to design these things in isolation. You'll end up with bizarre > user experiences because of technical decisions taken months earlier > that are now hard to reverse. A working end to end implementation > gives you the confidence to say, yes, this is how it should work, > because here's the demo and you can see it works very well and the > code is clean. > > If your BIP is informational then no problems, but I don't think > there's much point in informational BIPs to be honest - it's easier to > just write an email or forum post summarizing your views on things. If > you find it a useful framework to write your thoughts in that's OK, > but don't expect implementors to follow what's written there just > because it's a BIP. It carries no more weight than any other document > would. > > -- 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...
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 should become clearer what steps the protocol needs and what order they need to come in. Specific feedback on this format - as far as I can tell the format represents a subset of the regular bitcoin transaction format? Couldn't you just serialize a Bitcoin CTransaction structure with the txins containing the output scripts? -- 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] [RFC] BIP 14 - Protocol Version and User Agent
Looks pretty reasonable to me. If Gavin changes the mainline client to use this format I'll change BitcoinJ as well. It'll need a bit of API work so clients are sure to set it up properly. On Thu, Nov 10, 2011 at 10:16 PM, Amir Taaki wrote: > Hi, > > https://en.bitcoin.it/wiki/BIP_0014 > > Thanks to Gavin Andresen for proof reading and suggesting clarifications. > Thanks to Patrick Strateman for suggesting the hierarchical format and > pointing out some flaws of browser user-agents to me. > > The timeline is written in the past tense since BIPs are meant to be > readable in the future for explaining why we took certain decisions with > bitcoin. A nice cache for future historians when bitcoin is ubiquitous ;) > > The next version 0.6 should be the protocol version which becomes peeled > off from the current client. There are still some changes migrating into > the protocol that need to be finished. > > > > -- > 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
