Re: [Bitcoin-development] New BIP32 structure

2014-04-24 Thread Pieter Wuille
On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin thoma...@gmx.de wrote: Why do clients need to use the features in BIP 64? If Electrum doesn't want to use accounts, [...] To clarify: Electrum plans to have bip32 accounts; Multibit will not, afaik. To clarify: BIP64 has a much stricter

Re: [Bitcoin-development] New BIP32 structure

2014-04-24 Thread Gregory Maxwell
On Thu, Apr 24, 2014 at 12:10 AM, Pieter Wuille pieter.wui...@gmail.com wrote: On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin thoma...@gmx.de wrote: Why do clients need to use the features in BIP 64? If Electrum doesn't want to use accounts, [...] To clarify: Electrum plans to have bip32

Re: [Bitcoin-development] New BIP32 structure

2014-04-24 Thread Thomas Voegtlin
Le 24/04/2014 09:10, Pieter Wuille a écrit : To clarify: BIP64 has a much stricter definition for accounts than BIP32. In BIP32, it is not well specified what accounts are used for. They can be used for subwallets, receive accounts (as in bitcoind's account feature), recurring payments,

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

2014-04-24 Thread Mike Hearn
On Thu, Apr 24, 2014 at 12:06 AM, Alex Mizrahi alex.mizr...@gmail.comwrote: Different approaches have different trade-offs, and thus different areas of applicability. Proof-of-work's inherent disadvantage is that it takes some time until transaction becomes practically irreversible. On the

Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2

2014-04-24 Thread Wladimir
On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. wtog...@gmail.com wrote: If you are a rare user who needs Bitcoin-Qt on an incompatible system you can at least build it from source. Tails users usually can't

Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2

2014-04-24 Thread Wladimir
On Thu, Apr 24, 2014 at 10:02 AM, Wladimir laa...@gmail.com wrote: On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. wtog...@gmail.com wrote: If you are Another option: Instead of statically building it'd be easy

Re: [Bitcoin-development] New BIP32 structure

2014-04-24 Thread Mike Hearn
Right. So part of this is my fault, I'm afraid, because I do not intend to implement any kind of subwallet/account support in bitcoinj. My reasons are: 1. The bitcoinj API already lets you create and use multiple wallets. What's more, because of the desire to do key rotation (think rotating

Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2

2014-04-24 Thread Warren Togami Jr.
On Wed, Apr 23, 2014 at 10:02 PM, Wladimir laa...@gmail.com wrote: On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. wtog...@gmail.com wrote: If you are a rare user who needs Bitcoin-Qt on an incompatible system

Re: [Bitcoin-development] New BIP32 structure

2014-04-24 Thread Thomas Voegtlin
Le 24/04/2014 09:21, Gregory Maxwell a écrit : It doesn't appear to me that reoccurring payments, receive accounts, multisig addresses, etc can be used with this proposal, but instead you must use a different purpose code and another BIP and are not compatible with the draft here. Am I

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

2014-04-24 Thread Gregory Maxwell
On Thu, Apr 24, 2014 at 12:58 AM, Mike Hearn m...@plan99.net wrote: The complexity overhead is trivial - we already used coinbase scriptSigs for voting on P2SH, I'm sure it'll be used for voting on other things in future too. We use coinbase sigs to gauge the safety of enforcing a soft fork

Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2

2014-04-24 Thread Wladimir
On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr. wtog...@gmail.com wrote: I now see how it worked with Bitcoin 0.8.6. Lucid has qt-4.6.2. It is more than one symbol. It does not seem to be a wise thing to replace functions beyond the trivial in glibc and libstdc++. Qt is not part of the

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

2014-04-24 Thread Mike Hearn
On Thu, Apr 24, 2014 at 10:19 AM, Gregory Maxwell gmaxw...@gmail.comwrote: This is not voting. It absolutely is! It was widely discussed as such at the time, here is a thread where people ask how to vote and the operator of Eclipse said he was removing his vote for P2SH:

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

2014-04-24 Thread Andy Parkins
On Wednesday 23 April 2014 15:31:38 Mike Hearn wrote: There _are_ consequences though: 95% of the time, you end up buying something and paying for it. Yeah, I was imagining a situation in which people who use Bitcoin regularly do buy things they actually want, but wouldn't say no to

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

2014-04-24 Thread Gregory Maxwell
On Thu, Apr 24, 2014 at 1:39 AM, Mike Hearn m...@plan99.net wrote: It absolutely is! https://bitcointalk.org/index.php?topic=60937.0 May I direct your attention to the third post in that thread? Luke attempting to ret-con the enforcement flag into a vote didn't make it one, and certantly

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

2014-04-24 Thread Mike Hearn
Yes, you can reorg out the blocks and actually remove them, but I understood that you were _not_ proposing that quite specifically. But instead proposed without reorging taking txouts that were previously assigned to one party and simply assigning them to others. Well, my original thought

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

2014-04-24 Thread Jorge Timón
On 4/23/14, Mike Hearn m...@plan99.net wrote: I guess word honest might have different meanings, that can be a source of confusing. 1. Honest -- not trying to destroy bitcoin 2. Honest -- following rules which are not required by the protocol I'm using it in the same sense Satoshi used it.

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

2014-04-24 Thread Mike Hearn
On Thu, Apr 24, 2014 at 1:22 PM, Jorge Timón jti...@monetize.io wrote: I'm using it in the same sense Satoshi used it. Honest miners work to prevent double spends. That's the entire justification for their existence. I thought the mechanism they used to prevent double-spends was proof of

[Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Jorge Timón
Here is a solution to the problem of having 0 confirmation transactions that relies on game theory and most miners implementing replace-by-fee and child-pays-for-parent. This has been proposed before http://sourceforge.net/p/bitcoin/mailman/message/30876033/ I'm just going to describe the general

Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Mike Hearn
Am I missing something? The scheme you described does nothing about Finney attacks, which is the issue presently faced. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo

Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Chris Pacia
This scheme would discourage people from attempting a Finney attack because they would end up worse off if they did. It would work but it's an ugly hack IMO. What do people do if they don't have extra to pay when making a purchase? I have 200 mbtc and want to buy a 200 mbtc phone but I can't

Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Mike Hearn
This scheme would discourage people from attempting a Finney attack because they would end up worse off if they did. Phrased another way, it simply makes every block a Finney attack that charges the maximum double spending fee possible. This doesn't solve the problem. Beyond needing to double

Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2

2014-04-24 Thread Wladimir
On Thu, Apr 24, 2014 at 10:25 AM, Wladimir laa...@gmail.com wrote: On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr. wtog...@gmail.com wrote: But indeed we need to decide on a cut-off point. I'd have preferred 4.7 or 4.8. Qt 4.6 is *ancient* - it was released in februari 2010. Apart from

Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Peter Todd
On Thu, Apr 24, 2014 at 12:48:54PM +0200, Jorge Timón wrote: Here is a solution to the problem of having 0 confirmation transactions FWIW I'm running an experiment right now to detect how easy it is to doublespend 0-conf transactions I need to collect more data, but initial results indicate

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

2014-04-24 Thread Peter Todd
On Thu, Apr 24, 2014 at 11:56:23AM +0200, Mike Hearn wrote: ... proposing the mechanism be used to claw back mining income from a hardware vendor accused of violating its agreements on the amount of self mining / mining on customers hardware. I think this would not be doable in

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

2014-04-24 Thread Jorge Timón
On 4/24/14, Mike Hearn m...@plan99.net wrote: No! This is a misunderstanding. The mechanism they use to prevent double spends is to *ignore double spends*. The blocks they created indicate the ordering of transactions they saw and proof of work is used to arrive at a shared consensus ordering

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

2014-04-24 Thread Mike Hearn
Like I said before, that leads to the obvious next step of deleting/stealing their coinbases if they don't identify themselves. And as I said before, that's a huge leap. A majority of miners deciding double spending needs tougher enforcement doesn't imply they also think all miners should

Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Jorge Timón
On 4/24/14, Peter Todd p...@petertodd.org wrote: ... With replace-by-fee scorched-earth the success rate of such double-spends would be significantly reduced as the attacker would need to get lucky with bad propagation not just once, but twice in a row. Interesting. Replace-by-fee and

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

2014-04-24 Thread Mike Hearn
And that's achieved through proof of work, not through miner's honesty. You can't disentangle the two. Proof of work just makes a block chain hard to tamper with. What it contains is arbitrary. Honest miners build a block chain that's intended to stop double spending. Dishonest miners don't.

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

2014-04-24 Thread Peter Todd
On Thu, Apr 24, 2014 at 10:47:35AM -0400, Christophe Biocca wrote: Actually Peter, coinbase confiscations are a much worse mechanism for enforcement of widespread censorship rules than simple orphaning. They lose their power when the transaction miners are punished for can build up over time

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

2014-04-24 Thread Sergio Lerner
On 23/04/2014 05:51 p.m., Mike Hearn wrote: On Wed, Apr 23, 2014 at 10:44 PM, Adam Ritter arit...@gmail.com mailto:arit...@gmail.com wrote: Isn't a faster blockchain for transactions (maybe as a sidechain) solving the problem? If there would be a safe way for 0-confirmation

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

2014-04-24 Thread Mike Hearn
Thanks Sergio! On Thu, Apr 24, 2014 at 5:13 PM, Sergio Lerner sergioler...@certimix.comwrote: For more information you can check my post: http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/ Also NimbleCoin is a new alt-coin that uses 5-sec block intervals, allows 100 tps and

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

2014-04-24 Thread Jorge Timón
On 4/24/14, Mike Hearn m...@plan99.net wrote: You can't disentangle the two. Proof of work just makes a block chain hard to tamper with. What it contains is arbitrary. Honest miners build a block chain that's intended to stop double spending. Dishonest miners don't. They're both engaging in

Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Mike Hearn
Of course if we're not comparing this with Bitcoin today and we're comparing it to some theoretical mechanism for instant p2p serialization without requiring proof of work then, yes, this concept is not very interesting. Bitcoin's competition is not some theoretical perfect p2p system but

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

2014-04-24 Thread Christophe Biocca
Casting that vote does them no harm. Every time another pool joins the blacklist, there's no harm to them to doing so. I actually agree that this is a problem, but that's actually not inherent in the proposed enforcement mechanism (just the current voting rules). Here's an alternate: - To

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

2014-04-24 Thread Mike Hearn
Casting that vote does them no harm. Every time another pool joins the blacklist, there's no harm to them to doing so. At some point they will reach a majority These statements do not follow from each other. --

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

2014-04-24 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/24/2014 03:37 PM, Jorge Timón wrote: The 21 million bitcoin limit is not important because of its exact value, nor is it important because Satoshi picked it. The 21 million limit is important because users hold bitcoin based on the promise

Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Jannis Froese
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24.04.2014 14:15, Mike Hearn wrote: Beyond needing to double balances, what if the shop is selling me a phone on contract? So the actual cost of the phone is lower than the real price on the assumption of future revenue. Alice double spends

Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption

2014-04-24 Thread William Yager
Gmaxwell pointed out that we could safely front-load all the key pre-stretching. The spec has been updated to take advantage of this. The user's password is now protected by 10,000 rounds of salted PBKDF2-HMAC-SHA512, as well as the main KDF (which ranges from scrypt 2^14/8/8 to scrypt 2^18/16/16

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

2014-04-24 Thread Stephen Reed
Hello all. I understand that Proof-of-Stake as a replacement for Proof-of-Work is a prohibited yet disputed change to Bitcoin Core. I would like to create a Bitcoin branch that provides a sandboxed testbed for researching the best PoS implementations. In the years to come, perhaps

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

2014-04-24 Thread Gareth Williams
On 25/04/14 00:28, Mike Hearn wrote: Why are we here? We are here because we were brought together by shared goals. What are those goals? They were defined at the start of the project by the creator of the project. Why do we issue 21 million coins and not 42? Because 21 million is the

Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Gareth Williams
On 24/04/14 22:07, Chris Pacia wrote: It would work but it's an ugly hack IMO. What do people do if they don't have extra to pay when making a purchase? I have 200 mbtc and want to buy a 200 mbtc phone but I can't because I need 400 mbtc. Sucks for me. I don't see why it couldn't work with