Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

2014-04-26 Thread Mike Hearn
I'm not sure I understand why you need any special structure for this at all. The way I'd do it is just use regular HD wallets for everyone, of the regular form, and then swap the watching keys. Why do people need to be given a cosigner index at all, given that they all have unique root keys

Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

2014-04-26 Thread Thomas Voegtlin
Le 26/04/2014 11:43, Mike Hearn a écrit : I'm not sure I understand why you need any special structure for this at all. The way I'd do it is just use regular HD wallets for everyone, of the regular form, and then swap the watching keys. Why do people need to be given a cosigner index at all,

Re: [Bitcoin-development] BIP32 wallet structure in use? Remove it?

2014-04-26 Thread Thomas Voegtlin
I totally agree with gmaxwell here. The cost of interoperability is too high. It would force us to freeze all features, and to require a broad consensus everytime we want to add something new. In addition, some partial level of compatibility would probably lead to users not able to recover all

Re: [Bitcoin-development] BIP32 wallet structure in use? Remove it?

2014-04-26 Thread Tier Nolan
Maybe the solution is to have a defined way to import an unknown wallet? This means that the gap space and a search ordering needs to be defined. Given a blockchain and a root seed, it should be possible to find all the addresses for that root seed. The hierarchy that the wallet actually uses

Re: [Bitcoin-development] BIP32 wallet structure in use? Remove it?

2014-04-26 Thread Tamas Blummer
Yes, it is expensive but possible to discover any funds associated with a seed, provided there are set limits to: 1. gap of address use (e.g. 20) 2. depth of hierarchy (e.g. 6) 3. gap in use of parallel branches (e.g. 0) I would pick the limits in brackets above. Regards, Tamas Blummer

Re: [Bitcoin-development] BIP32 wallet structure in use? Remove it?

2014-04-26 Thread Tamas Blummer
Actually gap in parallel branches already fails with BIP64 as it starts with m/64'/…. without having m/63' Regards, Tamas Blummer http://bitsofproof.com On 26.04.2014, at 12:59, Tamas Blummer ta...@bitsofproof.com wrote: Yes, it is expensive but possible to discover any funds associated with

Re: [Bitcoin-development] BIP - Hash Locked Transaction

2014-04-26 Thread Jorge Timón
Does it make sense to implement a generic Policy interface (abstract class) which StandardPolicy extends? Maybe you can then implement a WhitelistPolicy, ReplacebyFeeStandardPolicy, ReplacebyFeeWhitelistPolicy... This would make it simpler for miners to implement their own policies in general.

[Bitcoin-development] Eliminating double-spends with two-party self-escrow for high value transactions

2014-04-26 Thread Peter Todd
In the majority of high-value transactions the fact that funds will be sent is known prior to when they actually are. For instance, if Alice is to meet Bob in person to buy a car or sell some Bitcoins, both parties know the transaction will probably happen in the near future some time before it

Re: [Bitcoin-development] BIP - Hash Locked Transaction

2014-04-26 Thread Tier Nolan
On Sat, Apr 26, 2014 at 12:11 PM, Jorge Timón jti...@monetize.io wrote: script IsStandard main IsStandardTx main AcceptToMemoryPool Accept to memory pool could probably be replaced with an IsStandard(scriptPubKey, scriptSig) method. The only isStandard part of the process is the check

Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

2014-04-26 Thread Manuel Araoz
On Apr 26, 2014 6:43 AM, Mike Hearn m...@plan99.net wrote: I'm not sure I understand why you need any special structure for this at all. The way I'd do it is just use regular HD wallets for everyone, of the regular form, and then swap the watching keys. Why do people need to be given a cosigner

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-26 Thread Gareth Williams
On 26/04/14 01:28, Mike Hearn wrote: When you have a *bitcoin* TXn buried under 100 blocks you can be damn sure that money is yours - but only because the rules for interpreting data in the blockchain are publicly documented and (hopefully) immutable. If they're mutable then

Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)

2014-04-26 Thread Gavin Andresen
The main area of concern is handling unexpected problems while sending the Payment message, or receiving the corresponding PaymentACK message. For example, in case of a transport layer failure or non-200 HTTP status code while sending the Payment message, what should the wallet software do

Re: [Bitcoin-development] BIP32 wallet structure in use? Remove it?

2014-04-26 Thread Pavol Rusnak
On 04/26/2014 12:48 PM, Tier Nolan wrote: Maybe the solution is to have a defined way to import an unknown wallet? That is nonsense. There is no way how to import the wallet if you don't know its structure. Given a blockchain and a root seed, it should be possible to find all the addresses

Re: [Bitcoin-development] BIP32 wallet structure in use? Remove it?

2014-04-26 Thread Pieter Wuille
On Sat, Apr 26, 2014 at 2:24 PM, Pavol Rusnak st...@gk2.sk wrote: On 04/26/2014 12:48 PM, Tier Nolan wrote: Maybe the solution is to have a defined way to import an unknown wallet? That is nonsense. There is no way how to import the wallet if you don't know its structure. I agree. Especially

Re: [Bitcoin-development] BIP32 wallet structure in use? Remove it?

2014-04-26 Thread Jeff Garzik
It is very young in bitcoin's life. We don't know what features will work out best, or need to be radically changed after initial deployment in the field. Loose coordination is good. Good ideas will spread on their own. Users will demand compatibility with certain features, and fail to care

Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)

2014-04-26 Thread Ross Nicoll
Dear Gavin, Andreas, I'd see standardisation (or at least suggested standards) for error handling as positive for consistency of user experience. I do see what you mean about over-specification, however. Thanks for the feedback, I've taken the main points and created two pull requests:

Re: [Bitcoin-development] BIP - Selector Script

2014-04-26 Thread Mark Friedenbach
I think you're misunderstanding the point. The way you get IsStandard changed is that you make an application-oriented BIP detailing the use of some new standard transaction type (say, generalized hash-locked transactions for atomic swaps). We then discuss that proposal for its technical merits

Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)

2014-04-26 Thread Mike Hearn
PaymentRequests are limited to 50,000 bytes. I can't think of a reason why Payment messages would need to be any bigger than that. Submit a pull request to the existing BIP. In future it might be nice to have images and things in the payment requests, to make UIs look prettier. But with the

Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)

2014-04-26 Thread Ross Nicoll
I'd be very cautious of security implications of embedding files into the payment request. Even file formats one would presume safe, such as images, have had security issues (i.e. https://technet.microsoft.com/library/security/ms11-006 ) Longer term I was wondering about embedding the

Re: [Bitcoin-development] Compatibility Bitcoin-Qt with Tails

2014-04-26 Thread Kristov Atlas
On 04/25/2014 04:27 PM, Wladimir wrote: Kristov, I've modified the gitian build so that it builds against Qt 4.6 instead of Qt 4.8 in this pull request: https://github.com/bitcoin/bitcoin/pull/4094 A test build of master with that pulls gitian descriptor is available:

Re: [Bitcoin-development] Eliminating double-spends with two-party self-escrow for high value transactions

2014-04-26 Thread Mike Hearn
What stops the buyer just always waiting to get their money back? -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet -

Re: [Bitcoin-development] Proof-of-Stake branch?

2014-04-26 Thread Mike Hearn
Please be aware that your emails are being spamfoldered by Gmail. This is because Yahoo has enabled DMARC enforcement for mail sent from Yahoo and that renders it incompatible with Sourceforge mailing lists. There are two fixes: 1) Don't use Yahoo. 2) The real fix which is, we should stop using

Re: [Bitcoin-development] Eliminating double-spends with two-party self-escrow for high value transactions

2014-04-26 Thread Peter Todd
On Sat, Apr 26, 2014 at 08:07:58PM +0200, Mike Hearn wrote: What stops the buyer just always waiting to get their money back? The seller won't hand over the goods of course until they have a valid transaction signed by the buyer sending them the escrowed funds. (and the nLockTime deadline is

Re: [Bitcoin-development] Eliminating double-spends with two-party self-escrow for high value transactions

2014-04-26 Thread Mike Hearn
Note how the mechanism I'm proposing is basically just a Jeremy Spilman-style micropayment channel(1) used for a single payment; I should have made that clear in my original post. Right, that does make more sense. Yes, it's a good idea. The question is whether wallet UI's can support it

Re: [Bitcoin-development] Eliminating double-spends with two-party self-escrow for high value transactions

2014-04-26 Thread Peter Todd
On Sat, Apr 26, 2014 at 02:31:19PM -0400, Peter Todd wrote: On Sat, Apr 26, 2014 at 08:07:58PM +0200, Mike Hearn wrote: What stops the buyer just always waiting to get their money back? The seller won't hand over the goods of course until they have a valid transaction signed by the buyer

[Bitcoin-development] BIP0071 media type registration with IANA

2014-04-26 Thread Ross Nicoll
Dear all, Still going through the payment protocol specifications... the MIME types in BIP0071 aren't IANA registered, and honestly look unlikely to be accepted if they were submitted as-is. Latest RFC on media type registration is RFC 6838, which very strictly restricts what can go in the

Re: [Bitcoin-development] BIP0071 media type registration with IANA

2014-04-26 Thread Mike Hearn
Bitcoin is not a vendor, so I doubt that would work. I doubt we should spend any time on this. The chance of a string collision is extremely low. The current mime types are fine. On Sat, Apr 26, 2014 at 10:15 PM, Ross Nicoll j...@jrn.me.uk wrote: Dear all, Still going through the payment

Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

2014-04-26 Thread Mike Hearn
Let's assume we use one shared branch for everyone. Then two cosigners could need a new receiving address at the same time, and get the next unused address on that branch. This is the part I struggle to understand. There is no shared branch because each user/cosigner has their own unique seed

Re: [Bitcoin-development] Proof-of-Stake branch?

2014-04-26 Thread Mark Friedenbach
There's no need to be confrontational. I don't think anyone here objects to the basic concept of proof-of-stake. Some people, myself included, have proposed protocols which involve some sort of proof of stake mechanism, and the idea itself originated as a mechanism for eliminating checkpoints,

Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

2014-04-26 Thread Alan Reiner
On 04/26/2014 04:33 PM, Mike Hearn wrote: Let's assume we use one shared branch for everyone. Then two cosigners could need a new receiving address at the same time, and get the next unused address on that branch. This is the part I struggle to understand. There is no shared

Re: [Bitcoin-development] BIP0071 media type registration with IANA

2014-04-26 Thread Jannis Froese
Am 2014-04-26 22:17, schrieb Mike Hearn: Bitcoin is not a vendor, so I doubt that would work. By my interpretation of RFC 6838, the Bitcoin Foundation or even Gavin himself could register a vendor tree for Bitcoin. In the case of the foundation registering, getting the subtree named vdn.bitcoin

Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

2014-04-26 Thread Mike Hearn
Ah, I see now. Thanks. And actually now I re-read it, Manuel's explanation was clear, it just didn't sink in for some reason. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with

Re: [Bitcoin-development] Proof-of-Stake branch?

2014-04-26 Thread Gareth Williams
What about using fraud proofs? Your coinbase only matures if nobody publishes proof that you signed a competing block. Then something is at least at stake. When it's your chance to sign a block, attempting to sign and publish more than one at the same height reliably punishes you (you

[Bitcoin-development] About Compact SPV proofs via block header commitments

2014-04-26 Thread Sergio Lerner
I read the post in this threads about Compact SPV proofs via block header commitments (archived e-mail in https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04318.html). I was working on the same problem almost at the same time, which is something that's becoming very common

Re: [Bitcoin-development] Proof-of-Stake branch?

2014-04-26 Thread Mark Friedenbach
That makes double-spends trivially easy: sign two blocks, withholding one. Then at a later point in time reveal the second signed block (demonstrating your own fraud) and force a reorg. On 04/26/2014 04:44 PM, Gareth Williams wrote: What about using fraud proofs? Your coinbase only matures if

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

2014-04-26 Thread Mark Friedenbach
Sergio, First of all, let's define what an SPV proof is: it is a succinct sequence of bits which can be transmitted as part of a non-interactive protocol that convincingly establishes for a client without access to the block chain that for some block B, B has an ancestor A at some specified

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-26 Thread Christophe Biocca
This seems like splitting hairs, no? A block isn't a guarantee (it can get orphaned). And as a user of bitcoin (as opposed to a miner), this change cannot affect any payment you ever receive. Some of the interpretation is already different for coinbase UTXO's (need a valid height, locked for 100

Re: [Bitcoin-development] Proof-of-Stake branch?

2014-04-26 Thread Gareth Williams
Who said anything about a re-org? The original block remains valid, your block reward is just zero, upon maturity, in light of a valid fraud proof. ie. the coinbase confiscation that I was just arguing against in another thread :P but of course here based on cryptographic proof, not human

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

2014-04-26 Thread Sergio Lerner
El 26/04/2014 10:43 p.m., Mark Friedenbach escribió: Sergio, First of all, let's define what an SPV proof is: it is a succinct sequence of bits which can be transmitted as part of a non-interactive protocol that convincingly establishes for a client without access to the block chain that for