On Tue, Oct 28, 2014 at 10:43 PM, Gregory Maxwell
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 the time of
On Tue, Oct 28, 2014 at 11:00 PM, Thomas Zander
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
> sake is
> not the
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 o
> 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
On Tue, Oct 28, 2014 at 10:34 PM, Neil 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.
>
because mining pr
On Tue, Oct 28, 2014 at 9:19 PM, Jérémie Dubois-Lacoste
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 arrived since the very
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
-
> > 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,
>
>
> http://bitcoincharts.com/char
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 "deat
> 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
On Tue, Oct 28, 2014 at 8:17 PM, Ferdinando M. Ametrano
wrote:
>
> On Oct 25, 2014 9:19 PM, "Gavin Andresen" 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,
Or very ol
On Oct 25, 2014 9:19 PM, "Gavin Andresen" 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 halving happened during a
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 oth
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
On Tue, Oct 28, 2014 at 10:30 AM, Alex Morcos 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
> require any code
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 to
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 not
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
Yeah, so to explain points 1 and 2 a bit more
1) It's about what question you are trying to answer. The existing code
tries to answer the question of what is the median fee of a transaction
that gets confirmed in Y blocks. It turns out that is not a very good
proxy for the question we really wa
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 Ja
20 matches
Mail list logo
