Re: [Bitcoin-development] DS Deprecation Window

2014-10-28 Thread Thomas Zander
On Monday 27. October 2014 19.26.48 Tom Harding wrote: Miner has to be very careful including a double-spend in his block -- he hopes: How does it help the zero-confirmation to not include a payment? Doesn't that just mean that if I send a double spend that neither of the payments will be

Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

2014-10-28 Thread Mike Hearn
Could you explain a little further why you think the current approach is statistically incorrect? There's no doubt that the existing estimates the system produces are garbage, but that's because it assumes players in the fee market are rational and they are not. Fwiw bitcoinj 0.12.1 applies the

Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

2014-10-28 Thread Gavin Andresen
I think Alex's approach is better; I don't think we can know how much better until we have a functioning fee market. We don't have a functioning fee market now, because fees are hard-coded. So we get pay the hard-coded fee and you'll get confirmed in one or two or three blocks, depending on which

Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

2014-10-28 Thread Alex Morcos
Oh in just a couple of blocks, it'll give you a somewhat reasonable estimate for asking about every confirmation count other than 1, but it could take several hours for it to have enough data points to give you a good estimate for getting confirmed in one block (because the prevalent feerate is

Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

2014-10-28 Thread Alex Morcos
Sorry, perhaps I misinterpreted that question. The estimates will be dominated by the prevailing transaction rates initially, so the estimates you get for something like what is the least I can pay and still be 90% sure I get confirmed in 20 blocks won't be insane, but they will still be way too

Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

2014-10-28 Thread Gavin Andresen
On Tue, Oct 28, 2014 at 10:30 AM, Alex Morcos mor...@gmail.com wrote: Do you think it would make sense to make that 90% number an argument to rpc call? For instance there could be a default (I would use 80%) but then you could specify if you required a different certainty. It wouldn't

Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

2014-10-28 Thread Alex Morcos
RE: 90% : I think it's fine to use 90% for anything other than 1 confirmation, but if you look at the real world data test I did, or the raw data from this new code, you'll see that even the highest fee rate transactions only get confirmed at about a 90% rate in 1 block, so that if you use that as

Re: [Bitcoin-development] DS Deprecation Window

2014-10-28 Thread Tom Harding
On 10/27/2014 7:36 PM, Gregory Maxwell wrote: Consider a malicious miner can concurrently flood all other miners with orthogonal double spends (which he doesn't mine himself). These other miners will all be spending some amount of their time mining on these transactions before realizing others

Re: [Bitcoin-development] death by halving

2014-10-28 Thread Ferdinando M. Ametrano
On Oct 25, 2014 9:19 PM, Gavin Andresen gavinandre...@gmail.com wrote: We had a halving, and it was a non-event. Is there some reason to believe next time will be different? In november 2008 bitcoin was a much younger ecosystem, with less liquidity and trading, smaller market cap, and the

[Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Gregory Maxwell
On Tue, Oct 28, 2014 at 8:17 PM, Ferdinando M. Ametrano ferdinando.ametr...@gmail.com wrote: On Oct 25, 2014 9:19 PM, Gavin Andresen gavinandre...@gmail.com wrote: We had a halving, and it was a non-event. Is there some reason to believe next time will be different? In november 2008

Re: [Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Alex Mizrahi
This thread is, in my opinion, a waste of time. It's yet again another perennial bikeshedding proposal brought up many times since at least 2011, suggesting random changes for non-existing(/not-yet-existing) issues. There is a lot more complexity to the system than the subsidy schedule.

Re: [Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Jérémie Dubois-Lacoste
Answering today's concerns with yesterday's facts is dangerous, especially with bitcoin on a 4 years period. I personally consider all arguments like we went through once, and nothing special. So no disturbance worthy of discussion to expect baseless. Also, starting a topic with mentions of death

Re: [Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Ferdinando M. Ametrano
In november 2008 bitcoin was a much younger ecosystem, Or very old, indeed, if you are using unsigned arithmetic. [...] :-) I meant 2012, of course, but loved your wit and the halving happened during a quite stable positive price trend Hardly,

Re: [Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Neil
Economically a halving is almost the same as a halving in price (as fees take up more of the pie, less so). Coincidentally the price has halved since early July to mid-October, and we've not even seen difficulty fall yet. I don't think there's much to see here. Neil

Re: [Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Gregory Maxwell
On Tue, Oct 28, 2014 at 9:19 PM, Jérémie Dubois-Lacoste jeremie...@gmail.com wrote: The fact that a topic was brought up many times since a long time, does not mean it is not relevant. I am not saying that it is not relevant, I'm saying the discussion is pointless: No new information has

Re: [Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Ferdinando M. Ametrano
On Tue, Oct 28, 2014 at 10:34 PM, Neil kyuupic...@gmail.com wrote: Economically a halving is almost the same as a halving in price (as fees take up more of the pie, less so). Coincidentally the price has halved since early July to mid-October, and we've not even seen difficulty fall yet.

Re: [Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Christophe Biocca
The fact that it is known in advance is no counter argument to me. But it does change miner behaviour in pretty significant ways. Unlike difficulty forecasting, which seems near impossible to do accurately, miners can plan to purchase less hardware as they approach the revenue drop. You can do

Re: [Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Thomas Zander
On Tuesday 28. October 2014 22.44.50 Ferdinando M. Ametrano wrote: It amazes me that basic economic considerations seems completely lost here, especially when it comes to mining. Please don't confuse people dismissing your thoughts with dismissing the basic economic considerations. The fact of

Re: [Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Ferdinando M. Ametrano
On Tue, Oct 28, 2014 at 11:00 PM, Thomas Zander tho...@thomaszander.se wrote: you didn't read the archives where these ideas have been brought forward and discussed, a consensus was reached. (it wasn't so basic afterall) The fact that people don't want to repeat the discussion just for your

Re: [Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Ferdinando M. Ametrano
On Tue, Oct 28, 2014 at 10:43 PM, Gregory Maxwell gmaxw...@gmail.com wrote: As of now the cost per block is probably already about 100USD, probably in the 50-150USD. This is wildly at odds with reality. I don't mean to insult, but please understand that every post you make here consumes