Re: [Bitcoin-development] SmartSPV – A better Simplified Payment Verification for Smartphones

On Thu, Apr 24, 2014 at 9:52 PM, Sergio Lerner wrote: > In a previous e-mail Mike Hearn asked me how I was going to handle 17K block > headers a day in my NimbleCoin currency in a the SPV mode. > I designed a variation of the standard headers-only SPV mode I called > SmartSPV. This mode could also

[Bitcoin-development] SmartSPV – A better Simplified Payment Verification for Smartphones

In a previous e-mail Mike Hearn asked me how I was going to handle 17K block headers a day in my NimbleCoin currency in a the SPV mode. I designed a variation of the standard headers-only SPV mode I called SmartSPV. This mode could also be implemented by BitcoinJ for Bitcoin. The method is explain

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

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 j

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

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 t

Re: [Bitcoin-development] Translators Needed for Bitcoin Core

Thanks for this reminder, I will bring this up with some others who I think may be able to help in this area and dedicate some time. I may be able to free up some time with a little language work as well. > You do not need to be a developer to help in the improvement of Bitcoin. > > http://source

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

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 circumstances

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

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

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

-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] Coinbase reallocation to discourage Finney attacks

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

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

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

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

> 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] 0 confirmation txs using replace-by-fee and game theory

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

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

On 4/24/14, Mike Hearn 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 proof of work,

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

Thanks Sergio! On Thu, Apr 24, 2014 at 5:13 PM, Sergio Lerner wrote: > 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 it's based on BitcoinJ

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

On 23/04/2014 05:51 p.m., Mike Hearn wrote: > On Wed, Apr 23, 2014 at 10:44 PM, Adam Ritter > 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 transactions, t

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

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 tim

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

I wouldn't mind having $5 of my money held at Apple/Google/VISA/Mastercard/BitPay (and I wouldn't be sad of losing $5 if any of these companies go bankrupt). Actually I had in mind creating a centralized version of Bitcoin for ultra-fast payments. With keeping all addresses on SSDs, asking for 1 ce

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

On 4/24/14, Mike Hearn wrote: >> >> 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 so

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

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 without losing their usefulness: Assume a world where 75% of the hashpow

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

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

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

On 4/24/14, Peter Todd 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 child-pays-for par

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

> > 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] Coinbase reallocation to discourage Finney attacks

On 4/24/14, Mike Hearn 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 given the po

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

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] 0 confirmation txs using replace-by-fee and game theory

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 th

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

On Thu, Apr 24, 2014 at 10:25 AM, Wladimir wrote: > On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr. 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 tails it doesn't seem like anyo

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

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

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

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 becau

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

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

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

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] Coinbase reallocation to discourage Finney attacks

On Thu, Apr 24, 2014 at 1:22 PM, Jorge Timón 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 > work. > The

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

On 4/23/14, Mike Hearn 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. Ho

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

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

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

On Thu, Apr 24, 2014 at 1:39 AM, Mike Hearn 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 wouldn't make it a

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

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

On Thu, Apr 24, 2014 at 10:19 AM, Gregory Maxwell wrote: > 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: https://bitcointalk.org/index.php?topi

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

On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr. 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 compiler/buil

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

On Thu, Apr 24, 2014 at 12:58 AM, Mike Hearn 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 several times a

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

On Wed, Apr 23, 2014 at 10:02 PM, Wladimir wrote: > On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell > wrote: > > On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. > wrote: > >> If you are > >> a rare user who needs Bitcoin-Qt on an incompatible system you can at > least > >> build it from so

Re: [Bitcoin-development] New BIP32 structure

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

Re: [Bitcoin-development] New BIP32 structure

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

On Thu, Apr 24, 2014 at 10:02 AM, Wladimir wrote: > On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell wrote: >> On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. wrote: >>> If you are > > Another option: Instead of statically building it'd be easy enough to > build against the 4.6 Qt headers in

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

On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell wrote: > On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. 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 really build it from source— tal

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

On Thu, Apr 24, 2014 at 12:06 AM, Alex Mizrahi wrote: > > 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 other hand, it has

Re: [Bitcoin-development] New BIP32 structure

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 p

Re: [Bitcoin-development] New BIP32 structure

On Thu, Apr 24, 2014 at 12:10 AM, Pieter Wuille wrote: > On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin 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 wil

Re: [Bitcoin-development] New BIP32 structure

On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin 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 definition