wumpus changed the topic of #bitcoin-wizards to: This channel is is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
orik has joined #bitcoin-wizards
the`doctor has quit [Ping timeout: 250 seconds]
bedeho has joined #bitcoin-wizards
davec has quit [Read error: Connection reset by peer]
snthsnth has quit [Ping timeout: 265 seconds]
davec has joined #bitcoin-wizards
Yoghur114 has joined #bitcoin-wizards
Yoghur114 has quit [Remote host closed the connection]
airbreather has quit [Remote host closed the connection]
snthsnth has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
snthsnth has quit [Ping timeout: 264 seconds]
nwilcox has joined #bitcoin-wizards
airbreather has joined #bitcoin-wizards
dEBRUYNE has quit [Ping timeout: 265 seconds]
nwilcox has quit [Ping timeout: 268 seconds]
p15x has joined #bitcoin-wizards
joesmoe has joined #bitcoin-wizards
p15x has quit [Ping timeout: 240 seconds]
the`doctor has joined #bitcoin-wizards
agorecki has quit [Quit: Leaving]
zooko has joined #bitcoin-wizards
GGuyZ_ has joined #bitcoin-wizards
GGuyZ has quit [Ping timeout: 244 seconds]
GGuyZ_ is now known as GGuyZ
a5m0 has quit [Ping timeout: 250 seconds]
a5m0 has joined #bitcoin-wizards
GGuyZ has quit [Read error: Connection reset by peer]
GGuyZ has joined #bitcoin-wizards
the`doctor has quit [Ping timeout: 260 seconds]
Burrito has quit [Quit: Leaving]
zooko` has joined #bitcoin-wizards
zooko has quit [Ping timeout: 240 seconds]
ONI_Ghost has joined #bitcoin-wizards
the`doctor has joined #bitcoin-wizards
Dr-G2 has joined #bitcoin-wizards
Dr-G has quit [Disconnected by services]
the`doctor has quit [Ping timeout: 268 seconds]
Giszmo has joined #bitcoin-wizards
sparetire_ has quit [Quit: sparetire_]
GGuyZ has quit [Ping timeout: 264 seconds]
rusty has joined #bitcoin-wizards
belcher_ has quit [Quit: Leaving]
TheSeven has quit [Disconnected by services]
[7] has joined #bitcoin-wizards
mkarrer_ has quit []
the`doctor has joined #bitcoin-wizards
the`doctor has quit [Ping timeout: 264 seconds]
snthsnth has joined #bitcoin-wizards
zooko` has quit [Ping timeout: 256 seconds]
PaulCape_ has joined #bitcoin-wizards
snthsnth has quit [Ping timeout: 268 seconds]
PaulCapestany has quit [Ping timeout: 240 seconds]
snthsnth has joined #bitcoin-wizards
Giszmo has quit [Quit: Leaving.]
matsjj has joined #bitcoin-wizards
matsjj_ has joined #bitcoin-wizards
matsjj has quit [Ping timeout: 244 seconds]
snthsnth has quit [Ping timeout: 240 seconds]
mjerr has joined #bitcoin-wizards
notj has joined #bitcoin-wizards
alferz has quit [Ping timeout: 244 seconds]
alferz has joined #bitcoin-wizards
alferz has quit [Ping timeout: 244 seconds]
notj has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
damethos has joined #bitcoin-wizards
rusty has quit [Ping timeout: 255 seconds]
matsjj_ has quit [Remote host closed the connection]
bramc has quit [Quit: This computer has gone to sleep]
moa has joined #bitcoin-wizards
mjerr has quit [Ping timeout: 272 seconds]
Krellan has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
bitdevsnyc has quit [Remote host closed the connection]
damethos has quit [Quit: Bye]
GAit has joined #bitcoin-wizards
GAit has quit [Quit: Leaving.]
GAit has joined #bitcoin-wizards
nsh has quit [Excess Flood]
nsh has joined #bitcoin-wizards
GAit has quit [Client Quit]
matsjj has joined #bitcoin-wizards
matsjj has quit [Ping timeout: 252 seconds]
b_lumenkraft has joined #bitcoin-wizards
nuke1989 has joined #bitcoin-wizards
wumpus has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 272 seconds]
nuke1989 has quit [Quit: my connection probably sucks]
Ylbam has joined #bitcoin-wizards
wiz_ is now known as wiz
gielbier has quit [Ping timeout: 265 seconds]
orik has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
gielbier has joined #bitcoin-wizards
jgarzik has quit [Quit: Leaving]
mkarrer has joined #bitcoin-wizards
c0rw|zZz is now known as c0rw1n
merlincorey has quit [Read error: Connection reset by peer]
merlincorey has joined #bitcoin-wizards
Keefe has quit [Ping timeout: 256 seconds]
Keefe has joined #bitcoin-wizards
arubi has quit [Quit: Leaving]
arubi has joined #bitcoin-wizards
Yoghur114 has joined #bitcoin-wizards
dEBRUYNE has joined #bitcoin-wizards
matsjj has joined #bitcoin-wizards
arubi has quit [Quit: Leaving]
Quanttek has joined #bitcoin-wizards
arubi has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
matsjj has quit [Ping timeout: 264 seconds]
arubi has quit [Ping timeout: 240 seconds]
arubi has joined #bitcoin-wizards
damethos has joined #bitcoin-wizards
harrigan has quit [Quit: leaving]
harrigan has joined #bitcoin-wizards
MoALTz has quit [Quit: Leaving]
harrigan has quit [Client Quit]
bedeho has quit [Ping timeout: 268 seconds]
harrigan has joined #bitcoin-wizards
Yoghur114 has quit [Quit: Konversation terminated!]
Guyver2 has joined #bitcoin-wizards
ne1l has joined #bitcoin-wizards
GAit has joined #bitcoin-wizards
bramc has joined #bitcoin-wizards
belcher_ has joined #bitcoin-wizards
dEBRUYNE_ has joined #bitcoin-wizards
dEBRUYNE has quit [Ping timeout: 244 seconds]
CodeShark has quit []
CodeShark_ has joined #bitcoin-wizards
CodeShark_ is now known as CodeShark
sundance has quit [Remote host closed the connection]
wiz has quit [Remote host closed the connection]
leakypat has quit [Remote host closed the connection]
laoban has quit [Remote host closed the connection]
kinoshitajona has quit [Remote host closed the connection]
TBI has quit [Read error: Connection reset by peer]
TBI has joined #bitcoin-wizards
TBI has quit [Read error: Connection reset by peer]
TBI has joined #bitcoin-wizards
TBI has quit [Read error: Connection reset by peer]
se3000 has quit [Ping timeout: 260 seconds]
Guyver2 has quit [Quit: :)]
ttttemp has quit [Remote host closed the connection]
bramc has quit [Quit: This computer has gone to sleep]
notj has joined #bitcoin-wizards
notj has quit [Client Quit]
TBI has joined #bitcoin-wizards
TBI_ has joined #bitcoin-wizards
TBI has quit [Ping timeout: 268 seconds]
ttttemp has joined #bitcoin-wizards
damethos has quit [Quit: Bye]
<maaku>
Is it possible to have a merged mined system whereby the block relay of all chains are not synchronized?
<maaku>
The solution may be a variant of Bitcoin NG with some sort of per-chain weak block that follows the merged mined block...
<maaku>
Doing this would actually make sidechains a scaling solution.
<arubi>
maaku, can't answer your question fully, do you mean relayed to all nodes or only to miners that are part of a certain pool (like p2pool does)? I assume the former
melvster1 has quit [Ping timeout: 265 seconds]
<maaku>
So the reason sidechains are not a sclaing solution is that the miner has to mine all chains to stay profitable.
<maaku>
And specifically although sidechains are inherently shareded (different daemons can run on different severs), the block relay is all done at once for the merged mined chains
<maaku>
So as much as bandwidth and latency are the limiters, sidechains make it the same or worse as a single big block.
<gmaxwell>
huh, no
<psztorc>
Question: Has anyone suggested that difficulty be cut in half at exactly the time that the coinbase-reward halves?
<gmaxwell>
satisfaction criteria can be totally orthorgonal (though it needs to share a common share criteria for communications efficiency.
<psztorc>
I did a search but the keywords are overloaded.
<maaku>
gmaxwell: right, I'm imagining searching for offset ranges
<gmaxwell>
maaku: its the same implenentation as anti-withholding; but I think you are expecting it to have more interesting effects than it does.
<gmaxwell>
lack of any true scaling improvement comes mostly not due to synchronization but because the systems remain global broadcast systems that depend on very widespread (if not quite ubiquitious) participation. :)
<maaku>
gmaxwell: oh wait I see. no complicated Bitcoin NG like system required, you just accept different ranges for merged mining satisfaction
<gmaxwell>
maaku: yes IsBitcoinShare() && arbritary_function(header)<target2 in fact.
<gmaxwell>
adjusting target2 to to account for the work represented by the share difficulty.
<maaku>
right as a practical engineering matter you'd want to make sure it's at least diff-1
<gmaxwell>
(that complexity so that you're not asking the hardware to test arbritary_function().
<gmaxwell>
)
<maaku>
gmaxwell: that argument doesn't make sense to me, although I am likely misunderstanding..
<maaku>
if there were 20 1MB sidechains, each with their own aux_fn(header) that makes them independent of each other, then you'd effectively spread block relay out over roughtly 30s intervals, no?
<gmaxwell>
the hardware isn't going to send back every sha2 invocation it performs, right? it's going to send back a subset and (unless you redesign it and tolerate overheads), it'll be the same subset for all your potential real solutions.
<gmaxwell>
oh sorry didn't get what you were commenting on.
<gmaxwell>
maaku: block relay _already_ doesn't primarily happen at block finding now, due to relay network protocol.
<gmaxwell>
and certantly can do much better with other enhancements.
<maaku>
gmaxwell: right, but managing the worst/adversarial case.
<maaku>
which sets limits on scaling
<bsm117532>
psztorc: difficulty is calculated dynamically. No one decides difficulty so no one can "decide" to halve the difficulty. (though it could happen if half the miners turn their machines off). Also -> #bitcoin
<gmaxwell>
So sure I agree that breaking things up is an improvement, but it doesn't change the asymtopics or the scale/decenteralization tradeoffs (except by constant factors)
<gmaxwell>
bsm117532: I thought it was a fine question.
<psztorc>
bsm117532: I am talking about adding a rule which deliberately halves it once every four years.
<maaku>
gmaxwell: well a constant factor of 20 is not something to sneeze at
<psztorc>
gmaxwell: Thank you.
<maaku>
but yes it doesn't definitively solve the problem
<bsm117532>
psztorc: how would you do that? It's calculated from the average of recent blocks.
<maaku>
but I believe I have been incorrect in pedanticly correcting other people that sidechains are not a scaling solution
<bsm117532>
So one can't add a rule to set it.
<gmaxwell>
maaku: I don't think it's at all a factor of 20 0_o
TBI has joined #bitcoin-wizards
melvster1 has joined #bitcoin-wizards
<smooth>
bsm117532: he's saying that on the inverval you just divide it by two
<smooth>
*interval right after the having
<bsm117532>
The effect of that would be to halve the block time.
<psztorc>
Haha
<psztorc>
You should give me a little more credit, I think.
<gmaxwell>
psztorc: prior times its come up people have pointed out that half the hashrate turning off at once wouldn't be a big deal. and that proposed automatic correction could be entirely out of wack with transaction fees. Ignoring that later point, I doubt it would break anything but does not appear to be needed.
<smooth>
anyway, im not sure half is right. why would you necessarily expect exactly half the miners to turn of
<bsm117532>
Maybe, I don't understand what you're proposing.
<gmaxwell>
(and activity around the last having didn't suggest a need)
<smooth>
i would expect some to turn off, though not exactly half (without much thought to a real model though)
<gmaxwell>
(though I don't mean to suggest that half hashrate has any correspondance there)
<maaku>
psztorc: it would merely delay by 2016 blocks the adjustment
<psztorc>
Let me clarify my concern, based on my own intuition and conversations with actual mining pool operators.
<gmaxwell>
(rather just that huge hashrate changes don't greatly impair things)
<psztorc>
The concern is that two things have happened over the last 3 or so years.
<bsm117532>
The difficulty adjustment in bitcoin is extremely naive. There are many better ways to do it. But just throwing a factor of two at it isn't a real improvement.
TBI_ has quit [Ping timeout: 268 seconds]
<smooth>
the concern is simple: some miners will almost certainly turn off as soon as the halving happens, so block times will be extended
<gmaxwell>
bsm117532: I disagree strongly with that statement FWIW.
<smooth>
oh wait, maybe they all turn off, hmm
<gmaxwell>
bsm117532: there are many desirable properties of the box filter, including no overshoot. And quite a few altcoins have actually destroyed themselves tinkering with what they believed to be "extremely naive".
<psztorc>
The first is that mining is now very homogeneous in specialization...margins are EQUALLY-thin everywhere...sell for $1000, cost $998.
<smooth>
i think that's what psztorc is getting at
<smooth>
if they're all equal, they all just turn off and bitcoin ends
TBI has quit [Ping timeout: 246 seconds]
<gmaxwell>
lol
<gmaxwell>
no.
<psztorc>
The second is that we have reached a point where non-specialized people cannot "cover" for the network if we lose the miners.
<bsm117532>
gmaxwell: The "naive" part? it's an overly simple calculation and very easy to game. Bitcoin has been lucky to not have huge hashrate swings.
<smooth>
gmaxwell: why not?
<maaku>
psztorc: it would have be more complex than halving the difficulty, because if you do that you'll just have 2016 5-min blocks and a 2x adjustment 7 days later
<gmaxwell>
smooth: put down the crack pipe, should something like that happen (not saying it can't but more in a moment) then you hardfork perfork that change with minor disruption.
<gmaxwell>
there is no "over".
<psztorc>
maaku: That is exactly what I think will not happen.
<smooth>
of course it was a stupid/simple model, but im explaining the reason for the question
<gmaxwell>
smooth: regardless in large scale industrial mining right now there are power cost disparities far beyond a factor of two.
TBI has joined #bitcoin-wizards
<psztorc>
I think instead you might actually have 10 minute blocks and no adjustment.
<psztorc>
gmaxwell: I agree but my concern is that the profit margin does not differ by a factor of two.
<smooth>
gmaxwell: sure, but it isn't clear that dividing by two is more wrong than not dividing by two
Giszmo has joined #bitcoin-wizards
<maaku>
psztorc: except if you half the difficulty for half the reward, all the miners that were on before will be on after (assuming trivial fees)
<gmaxwell>
smooth: I agree so long as you totally disregard fees which is pretty dull more than two halvings out.
<bsm117532>
psztorc: the difficulty adjustment targets 10 minute blocks. If half the miners disappeared, blocks would be 20 minutes for a while, and then back to 10 minutes 2 weeks later. (effectively achieving what you propose, 2 weeks later)
<maaku>
bsm117532: 4 weeks, but yes
<psztorc>
cut it by (3/4), then.
<psztorc>
"the difficulty adjustment targets 10 minute blocks. If half the miners disappeared, blocks would be 20 minutes for a while" This is not clear to me.
<bsm117532>
Yes 4 weeks.
<bsm117532>
psztorc: Why are you trying to guess what miners will do? Just measure it instead.
<smooth>
gmaxwell: when the subsidy becomes "negligible" i agree, not sure when that is exactly. "fees" aren't really the point it is profit margin on fees
<psztorc>
Normally, yes, but during the halving, it could take really any length of time.
<maaku>
bsm117532: because we don't know their costs
<bsm117532>
maaku: I think we're agreeing with each other.
<gmaxwell>
psztorc: what is not clear to you?
<maaku>
psztorc: I'm surprised you haven't suggested a prediction market because that's what really is needed here ;)
<maaku>
we don't know how miners will respond because we don't know their cost sensitivities
<psztorc>
: ]
<gmaxwell>
(I'm just trying to get a clarify because it just sounded like you were saying that it wasn't clear that half the hashrate loss would result in 20 minute blocks; which I think you're not actually unclear on :))
<psztorc>
The thing is, my concern is indeed some more-realistic version of "all the miners shut of their incredibly specialized hardware at once".
c-cex-yuriy has joined #bitcoin-wizards
<psztorc>
If the capital costs are sunk, it is all electricity.
<psztorc>
So they might all decide to take a 2 week break.
<maaku>
psztorc: the dystopian vision is unlikely to happen due to a significant fraction of miners e.g. having free electricity
<bsm117532>
psztorc: So measure it. Which bitcoin does by looking at the block time and readjusting 2016 blocks later
<psztorc>
That single 2016 block period might last like 2 months or something.
<bsm117532>
It might.
<gmaxwell>
bsm117532: his complaint is that it takes blocks to adjust.
<maaku>
but I do worry about major consolidation as these players are basically the only ones left after the halving..
<psztorc>
I'm not saying it is inevitable or anything.
<smooth>
in the less realistic version it might last forever
<bsm117532>
This goes back to my "naive" comment. If bitcoin's goal were to maintain a stable block time, it's using a terrible algorithm. The argument is that this is not a goal.
<psztorc>
Actual mining pool operators are worried about this (for what that's worth).
<gmaxwell>
Yes, as I said, it's possible.. but expect in the really extreme cases its no big deal. It might have been more sensible to adjust it (though constant half doesn't makes sense due to fees, esp in the long run).
<smooth>
im not sure the constant half makes sense even without fees
<maaku>
alt coins have seen that when hashing drops by 50x or 100x blocks are so infrequent that there's a vicious cycle of losing interest
<smooth>
all 1/2 does is make no one turn off, which is probabyl not what is desired
<gmaxwell>
smooth: "less stupid than not"
<maaku>
but i'm not sure a 2x or 4x drop would be significant in that wya
<gmaxwell>
psztorc: there are other effects though, of course because there an increased demand pressure because inflation just halved.
<bsm117532>
FWIW if achieving stable block times is desirable, I can offer up a much better algorithm than has been used by any alt coin so far. But no one seems to care about this, so I haven't pursued it.
<psztorc>
I agree that 1/2 pushes the problem back...try 3/4.
<psztorc>
bsm117532: "FWIW if achieving stable block times is desirable," no one is saying that.
<gmaxwell>
bsm117532: stable blocktimes are generally incompatible with both fairness (not allowing large miners an advantage) and actually achieving consensus!
<smooth>
psztorc: 3/4 could theoretically result in a stall too...
<psztorc>
smooth: I agree.
<gmaxwell>
bsm117532: as the variance in block finding times is the fundimental process that makes the system gain consensus with exponential probablity.
<maaku>
bsm117532: there is interest in better adjustment algorithms (for sidechains, for example)
<psztorc>
The phrase "less wrong" comes to mind.
JackH has joined #bitcoin-wizards
TBI_ has joined #bitcoin-wizards
<maaku>
bsm117532: but, with respect, this may be a harder problem than you're giving credit
<gmaxwell>
bsm117532: its seriously easy to do worse, as I mentioned before.
<bsm117532>
gmaxwell: One can keep constant variance while keeping the median block time at 10 minutes. I'm not arguing for decreased variance, just keeping the central value closer to 10m.
<gmaxwell>
bsm117532: okay, retract my varriance related complaint then. :P
<bsm117532>
Ok...then to fairness. Can you elaborate?
<gmaxwell>
bsm117532: that was also variance related.
<bsm117532>
Ah ok.
<bsm117532>
So the better algorithm is just to use a damped harmonic oscillator.
<psztorc>
I actually think this is pretty serious.
<gmaxwell>
bsm117532: the other stuff is that e.g. any generic least squares optimizing scheme will have overshoot which risks you the psztorc non-linear shutoff effects at every difficulty adjustment.
<smooth>
psztorc: you think there could be in practice a catestrophic lengthening of the block time?
<bsm117532>
gmaxwell: hence the "damped" part of the oscillator.
<psztorc>
I mean, if this spooks people, the exchange rate will probably go down, and people might not bother sending transactions.
<bsm117532>
Avoids overshoot.
<gmaxwell>
bsm117532: _any_ overshoot is potentially doom under psztorc's complaint.
<psztorc>
So the revenues would just spiral into the ground while the difficulty chokes everyone out.
TBI has quit [Ping timeout: 264 seconds]
<bsm117532>
I see. From a miner profit perspective, constant block times are actually very important...
<psztorc>
Yes, unfortunately this "homogeneous specialization" is sort of fragile.
<gmaxwell>
psztorc: people gloomed about this at 50->25. and it didn't happen, and I think you are not crediting the levels of similarity we still have.
<gmaxwell>
bsm117532: a linear phase lowpass filter.
<smooth>
the commit message explains it
<bsm117532>
Commit message is truncated. github fail.
<gmaxwell>
(with a bunch of group delay)
<nsh>
really want a 6th order bandpass
<bsm117532>
aha, then that's a good idea ;-)
<psztorc>
I suppose I will look into the 50 -> 25 conditions more, specifically profit margin homogeneity, before commenting further.
<nsh>
that's where all the cool optima hang out
<maaku>
gmaxwell: to be fair, the price spiked just before the 50 -> 25 halving, so we didn't actually learn much :(
<gmaxwell>
bsm117532: so much for the idea that you actually understood that overshoot is basically optimally bad from psztorc's perspective.
<gmaxwell>
maaku: this was " of course because there an increased demand pressure because inflation just halved"
<bsm117532>
gmaxwell: :-P
<bsm117532>
So I like this Freicoin approach, I hadn't seen it before.
<gmaxwell>
seriously control theory is a whole domain of science onto itself, and especially non-linear control is especially nasty. And one of the most potent lessons for non-linear control is that if your model is wrong doom can befall you badly, and so often simpler models are better.
MoALTz has joined #bitcoin-wizards
<gmaxwell>
bsm117532: Doesn't speak highly of your understanding.
<bsm117532>
However: is it any better than a simple damped harmonic oscillator? This can be cast as a measurement problem: how well do I know the hashrate and its first and second derivatives? Doing a derivative expansion, you end up with a damped harmonic oscillator by default.
<bsm117532>
gmaxwell: be nice
<gmaxwell>
Because seriously, how the @#$@ can you decide you like that approach in a discussion where psztorc is complaining that difficulty overshoot can kill the system!
<nsh>
ye shall not suffer a complexity to live
<gmaxwell>
sorry, just a little irritated. Haven't slept.
<nsh>
all good :)
<bsm117532>
I don't know anything about the Parks-McClellan filter, but it's a much better attempt than "gravity well" which is basically bullshit.
<nsh>
.wik Parks McClellan
<yoleaux>
"The Parks–McClellan algorithm, published by James McClellan and Thomas Parks in 1972, is an iterative algorithm for finding the optimal Chebyshev finite impulse response (FIR) filter. The Parks–McClellan algorithm is utilized to design and implement efficient and optimal FIR filters." — https://en.wikipedia.org/wiki/Parks-McClellan
<gmaxwell>
go find a nice bessel filter and at least avoid getting my vomit all over you.
<nsh>
'The goal of the algorithm is to minimize the error in the pass and stop bands by utilizing the Chebyshev approximation. The Parks–McClellan algorithm is a variation of the Remez exchange algorithm, with the change that it is specifically designed for FIR filters. It has become a standard method for FIR filter design.'
<gmaxwell>
bsm117532: yes that stuff is BS and usually opens up big attacks and other nonsense.
<nsh>
.wik Chebyshev approximation
<yoleaux>
"In mathematics, approximation theory is concerned with how functions can best be approximated with simpler functions, and with quantitatively characterizing the errors introduced thereby. Note that what is meant by best and simpler will depend on the application." — https://en.wikipedia.org/wiki/Chebyshev_approximation
<nsh>
this is especially pernicious because the subsumed complexity is opaque
<nsh>
so it's hard even to reason about possible attack classes except that they exist with high likelihood
<bsm117532>
That seems to be failing to achieve stability...looks like it's generating oscillations...
<nsh>
but you can't know the extent to which the data it operated on was controlled by an (adaptively) adversarial party or cohort
<maaku>
you see the oscillations of pool hoppers going somewhere else when difficulty rises
<nsh>
you can consider bounded oscillations to be stable
<nsh>
it's about what you define as 'reasonable' periodic variance
<maaku>
bsm117532: it's constrained to a livable amount, and you would not expect exactly this behavior with bitcoin (becuase the alternative is shutting off, not going somewhere else)
<bsm117532>
It appears to be a linear decay to the lower hashrate.
<nsh>
periodic and aperiodic variance can be separated spectral analysis
<nsh>
[FFT]
<gmaxwell>
in any case, one should not knock the humble box filter. It has many desirable properties. Including no overshoot at all. :P though there filters with almost no overshoot that have other desirable properties (minimal group delay at DC is very useful for control.)
<bsm117532>
Harmonic analysis is probably not appropriate here. I see no reason to believe miners turn things on and off in an oscilltory fashion.
snthsnth has joined #bitcoin-wizards
<nsh>
no but harmonics may be intrinsic to the targeting system
<psztorc>
If fees and the blockreward were both 25 BTC (totaling 50), then one could expect the halving to result in slower block times to increase fee-pressure. It might be 12.5 blockreward + 37.5 fees.
<smooth>
they turn off in response to difficulty, that's enough potentially
<nsh>
and those below a certain magnitude accepted
<bsm117532>
Likewise with financial markets (which are essentially a set of random impulses) generally don't have oscillatory behavior.
<nsh>
glad we solved recessions
<maaku>
bsm117532: freicoin had design requirements of being finite response, not infinite, and minimizing overshoot to the greatest extent possible (using back-tested real world data)
<nsh>
i'll inform the our mortgage lender
<nsh>
:)
<nsh>
-the
<maaku>
within that specification of the problem I think it's a pretty close to optimal solution.
<maaku>
there's just only so much you can do in an adversarial environment
<smooth>
you cant backtest thats for sure
<psztorc>
So it would only be a problem when the block-reward is large enough to be motivating, but miners are homogeneous enough to all be affected by the reward halfing at once.
<nsh>
and the more you do, the more you complexity you offer to the adversary
<nsh>
this is inevitable unless you constrain your functions extremely
<gmaxwell>
maaku: you could have relaxed the finite response requirement by commiting to the filter state at each block.
<psztorc>
So perhaps it would only ever be a problem in 2016 and 2020.
<gmaxwell>
then there is no reason for finiteness.
<maaku>
gmaxwell: yet another commitment? ugh
<bsm117532>
FWIW I've been working on converting the block "chain" to a DAG (multiple parents per block). With this you can substantially increase the block rate without orphans, and get a much finer time resolution measurement of the hash rate.
<gmaxwell>
I mean I would have just added it to the header.
<bsm117532>
I think I can remove block time, block size, and target difficulty altogether.
<nsh>
bsm117532, you should peruse the logs from here for DAG talk
<gmaxwell>
it would just be two additional fixed point numbers (assuming a second order filter) and you could compute the next block with only one block input, instead of the last bunch.
<bsm117532>
Reducing the set of arbitrary parameters in the code and commitments makes the system more resilient.
<nsh>
(i am in favour of DAG vs. single-history periodic ordering if it can be empirically demonstrated as viable)
<nsh>
(because this allows for some other interesting stuff)
<bsm117532>
Yay! Working on it.
* nsh
smiles
Burrito has joined #bitcoin-wizards
<maaku>
gmaxwell: would it give significantly better results?
<bsm117532>
I've got some new formulas for "highest work DAG-tip" calculation, which is needed.
<nsh>
(especially operating on the relative state of piecewise-inconsistent superposed time-shapes of capital flow)
<nsh>
or partially-inconsistent
<nsh>
but where you can model functionally the degree of boundaries of inconsistency
Quanttek has quit [Ping timeout: 250 seconds]
<bsm117532>
nsh: what other "interesting stuff" does it allow? Can you elaborate? (Don't understand your last comment)
<nsh>
*and
<nsh>
i mean that already we can analyse the time-shapes of capital flow. we can watch bitcoins moving through the system over time and reduce these to compositions of particular classes of shapes
<gmaxwell>
maaku: I believe a second order bessel filter or likewise would give signficantly better results. This is because the delay is basically as low as possible for DC, and there is virtually no overshoot. But ... hard to say without trying, I know for other control systems an approach like freicoin's will often immediately give self-oscillation where a bessel filter will not. I have fixed point cod
<gmaxwell>
e for one of these someplace.
<nsh>
and that's great, and largely unelaborated still, but if you have a DAG then you can afford some degree of inconsistency in the transaction chain
<bsm117532>
gmaxwell: Let me do a derivative expansion on your bessel function, I'll end up with a damped harmonic oscillator and a 3rd derivative term that is very poorly measured.
<nsh>
and then you can analyse what properties that results in and think about the relative-state, which is a bit more abstract still but related to Everett's interpretation of QM
damethos has joined #bitcoin-wizards
<nsh>
poorly measured as in hard to know its average contribution?
<bsm117532>
In my DAG approach, I'm removing the target difficulty and block time. Each miner chooses his own (which complicates the highest-work-chain calculation -- but it can be done).
<nsh>
sounds very difficult to make an argument for convergence of consensus
<nsh>
without semi-objective block-time and difficulty
<nsh>
but i'm open-minded
<maaku>
removing block time? that's removing a primary feature of bitcoin
<bsm117532>
nsh: poorly measured (3rd derivative). 1st derivative is finite difference between two blocks, averaged. 2nd derivative is differences of those, and so on. Errors compound with higher derivatives.
<nsh>
ah, okay
<bsm117532>
Which is why most control systems don't go beyond 2 derivatives.
<nsh>
i'm assuming there would still be an varying average blocktime under bsm117532's proposal
<nsh>
you could say over some period what the average blocktime over all the individual miners was
<bsm117532>
nsh: there would be no block time. Shove out blocks as fast as you want. Peer nodes set the minimum difficulty that they will relay.
<bsm117532>
The hashrate can be measured by looking at the distribution of seen blocks. But, I want to remove it from consideration, so that these parameters can be used for bandwidth control by nodes/miners instead.
<nsh>
oh okay, that's a kind of relay-level voting 'market' for that gives a function for blocktime in terms of hashrate [and difficulty 'to date']
<nsh>
well, everyone is choosing to increase their individually in theory so it's an average over a bunch of functions
<bsm117532>
Basically. There would be in effect an average block rate, but it comes from the chaos of how nodes are setting their parameters, and does not harm consensus.
<bsm117532>
If you want to shoot out blocks 10/second with small hashes go ahead, I might ignore you, and take a block from someone else who has bundled your blocks/tx's into a higher-work block.
<gmaxwell>
awful useful for having any confidence you've been paid or not... :P
<Taek>
psztorc: We discussed the coinbase halving in a roundtable in Montral. The conclusion was that it won't be an issue
<bsm117532>
Aaaaand organizing the block reward is the hard part.
<Taek>
one of the big reasons is that many miners are locked into power contracts
<Taek>
if they shut off their miners, they actually pay higher bills because they promised to use X power at a constant rate
<psztorc>
Well I would like to learn more. If unprofitable, they'll eventually be shutting them off, so why not break the contract sooner rather than later.
<nsh>
depends on the terms of the contract
<Taek>
If you are under legal contract to pay for a year of electricity, and have no clean way to break the contract, you might as well mine at half revenue
<gmaxwell>
There are a number of factors that mitigate my concerns; that one isn't one of the highest just because ... many mining companies have historically violated power contracts (there is some nice multimillion dollar litigation going on about that. :) )... but it's not, I think, too crazy to expect a zillion unrelated reasons to contribute to smoothing things out. :)
<nsh>
but even with a variance in the costs of early-termination you get a smoothing until deflationary effects counterbalance the loss of reward
* nsh
nods
<bsm117532>
Taek: I'm sure miners are taking that and the halving into account...
<smooth>
when you get down into the nuts and bolts of power the marginal cost can be negative
<psztorc>
Yes, the "waterfall argument".
<smooth>
psztorc: what is the waterfall argument
<psztorc>
Well the waterfall gives you power for like no operating cost. If it is on a mountain or something, transmitting the power is a waste so might as well just hash with it.
orik has joined #bitcoin-wizards
<psztorc>
I think I heard it from Peter Todd somewhere.
<psztorc>
Like a power turbine making a constant amount of power you aren't using.
<smooth>
the point is someone has to use it
<smooth>
electricity is incompressible
<maaku>
smooth: in a nutshell, there are hydrodams in china which aren't connected to anything using the power. there are bitcoin miners getting -paid- to use power from these
<nsh>
plenty of places where there is a locality waste/expenditure
<smooth>
yeah pretty much that
<psztorc>
Yeah I think that's great.
<smooth>
it happens in the US grids too
<bsm117532>
As I understand it it's partially a money-export scam, since Chinese can't easily get their assets out of Yuan.
<nsh>
but there's significant overhead, capital expenditure and risk analysis on installing mining equipment
<nsh>
so there's a need for 'market-makers' in this respect to lend, install, support and remove mining h/w from places with excess power
<nsh>
and that's still mostly not done
<bsm117532>
Corollary: PoS doesn't work because sometimes, marginal costs can be negative. ;-)
<maaku>
nsh: but once it is installed, there is absolutely no marginal cost to having them on
<nsh>
there is risk of fire
<nsh>
etc.
<maaku>
price could drop to $0.01/btc and these miners would stay on
<nsh>
but that can be covered by general insurance
<maaku>
nsh: I think perhaps you misunderstand the locality ;)
<nsh>
maybe :)
<smooth>
the miners probably wouldn't stay on at 0.01/btc because people would find more useful ways to be an electricity sink
<smooth>
mail order battery charging
<bsm117532>
Hahaaaaa that's a smooth idea.
<psztorc>
Well I am not as worried...even if the 2016 blocks take a long time, there will probably be increased tx-fee pressure offsetting that.
<smooth>
kind of like the old netflix envelopes
<smooth>
psztorc: you made a good point earlier that people (and their tranasctions) may just leave
<smooth>
will people really compete for fees in one-day latancy blocks? maybe, but probably a lot less
<psztorc>
The "confidence" thing.
<psztorc>
Obviously always a problem.
<psztorc>
My guess is that, if Bitcoin were being redesigned from scratch, it would probably benefit to measure the ratio of block-reward/tx-fees, and impose "difficulty forgiveness" during each reward-halving.
<Taek>
complexity often means vulnerability. Every time you add a new rule you have to be certain there aren't unintended consequences
<maaku>
psztorc: if it were redesigned from scratch it'd have a constantly adjusting block subsidy imho
<psztorc>
The strange thing is that the difficulty adjustment itself causes miner-homogeneity, which causes this problem.
<maaku>
then we wouldn't have this debate at all
<psztorc>
Yes that would solve it wouldn't it.
<maaku>
(further proof that satoshi was not a time traveller)
<psztorc>
My guess is that Satoshi didn't want anyone to think he was getting an "unfair" advantage.
<psztorc>
Too nice of a guy.
<psztorc>
Gotta get those people in the door.
<nsh>
if he was that nice of a guy he'd have given me loads of money by now
<psztorc>
This is where Satoshi re-time-travels (and destroys this universe).
<psztorc>
Satoshi: make it 50 BTC to 25 BTC and *then* make it continuously declining.
<psztorc>
8 year fairness clause.
notj has joined #bitcoin-wizards
<psztorc>
Are we all still here? Was this universe destroyed?
<smooth>
the other one was
<psztorc>
^
Madars has quit [Remote host closed the connection]
jeremyrubin has quit [Ping timeout: 255 seconds]
jlrubin_ has quit [Ping timeout: 255 seconds]
jeremyrubin has joined #bitcoin-wizards
airbreather has quit [Remote host closed the connection]
airbreather has joined #bitcoin-wizards
Madars has joined #bitcoin-wizards
jlrubin has joined #bitcoin-wizards
mkarrer_ has joined #bitcoin-wizards
mkarrer_ has quit [Client Quit]
c0rw1n is now known as c0rw|away
JackH has quit [Ping timeout: 272 seconds]
JackH has joined #bitcoin-wizards
b_lumenkraft has quit [Quit: b_lumenkraft]
Quanttek has joined #bitcoin-wizards
Transisto2 has joined #bitcoin-wizards
gsdgdfs has quit [Ping timeout: 252 seconds]
gsdgdfs has joined #bitcoin-wizards
Transisto2 has quit [Ping timeout: 252 seconds]
orik has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
dEBRUYNE__ has joined #bitcoin-wizards
dEBRUYNE_ has quit [Read error: Connection reset by peer]
mkarrer_ has joined #bitcoin-wizards
moa has joined #bitcoin-wizards
copumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bitdevsnyc has joined #bitcoin-wizards
notj has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
bitdevsnyc has quit [Ping timeout: 240 seconds]
damethos has quit [Quit: Bye]
bedeho has joined #bitcoin-wizards
gsdgdfs has quit [Read error: Connection reset by peer]
Transisto2 has joined #bitcoin-wizards
nwilcox has joined #bitcoin-wizards
Madars has quit [Ping timeout: 246 seconds]
the`doctor has joined #bitcoin-wizards
copumpkin has joined #bitcoin-wizards
damethos has joined #bitcoin-wizards
Madars has joined #bitcoin-wizards
moa has quit [Ping timeout: 264 seconds]
bliljerk_ has quit [Ping timeout: 244 seconds]
bliljerk101 has joined #bitcoin-wizards
hazirafel has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
damethos has quit [Quit: Bye]
gielbier has quit [Ping timeout: 240 seconds]
damethos has joined #bitcoin-wizards
bedeho has quit [Ping timeout: 246 seconds]
dEBRUYNE__ has quit [Ping timeout: 246 seconds]
AaronvanW has quit [Ping timeout: 246 seconds]
bedeho has joined #bitcoin-wizards
nwilcox has quit [Ping timeout: 246 seconds]
mkarrer_ has quit [Remote host closed the connection]
damethos has quit [Quit: Bye]
nwilcox has joined #bitcoin-wizards
Guyver2 has quit [Quit: :)]
orik has joined #bitcoin-wizards
nwilcox has quit [Ping timeout: 265 seconds]
tcrypt has joined #bitcoin-wizards
bedeho has quit [Ping timeout: 260 seconds]
bramc has joined #bitcoin-wizards
snthsnth has quit [Ping timeout: 244 seconds]
the`doctor has quit [Ping timeout: 255 seconds]
orik has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
c-cex-yuriy has quit [Quit: Connection closed for inactivity]
bramc has quit [Quit: This computer has gone to sleep]
gielbier has joined #bitcoin-wizards
orik has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 240 seconds]
notj has joined #bitcoin-wizards
justanotheruser has joined #bitcoin-wizards
notj has quit [Client Quit]
notj has joined #bitcoin-wizards
Luke-Jr has quit [Ping timeout: 246 seconds]
Luke-Jr has joined #bitcoin-wizards
notj has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
notj has joined #bitcoin-wizards
paveljanik has quit [Quit: Leaving]
notj has quit [Client Quit]
notj has joined #bitcoin-wizards
notj has quit [Client Quit]
the`doctor has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
notj has joined #bitcoin-wizards
orik has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
notj has quit [Client Quit]
orik has joined #bitcoin-wizards
orik has quit [Client Quit]
melvster1 has quit [Ping timeout: 255 seconds]
nwilcox has joined #bitcoin-wizards
notj has joined #bitcoin-wizards
runeks has quit [Ping timeout: 240 seconds]
runeks has joined #bitcoin-wizards
Yoghur114 has joined #bitcoin-wizards
notj has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ThomasV has quit [Ping timeout: 260 seconds]
moa has joined #bitcoin-wizards
melvster1 has joined #bitcoin-wizards
orik has joined #bitcoin-wizards
notj has joined #bitcoin-wizards
moa has quit [Quit: Leaving.]
ketadmin has joined #bitcoin-wizards
devrandom has quit [Ping timeout: 240 seconds]
devrandom has joined #bitcoin-wizards
dario_ has joined #bitcoin-wizards
antiatom has joined #bitcoin-wizards
dario_ is now known as esneider
esneider has quit [Remote host closed the connection]
esneider has joined #bitcoin-wizards
orik has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Yoghur114 has quit [Remote host closed the connection]
belcher_ has quit [Read error: Connection reset by peer]
bedeho has joined #bitcoin-wizards
belcher_ has joined #bitcoin-wizards
CodeShark is now known as CodeShark_
CodeShark has joined #bitcoin-wizards
notj has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ONI_Ghost has left #bitcoin-wizards ["Leaving"]
PRab has quit [Read error: Connection reset by peer]
dEBRUYNE__ has joined #bitcoin-wizards
PRab has joined #bitcoin-wizards
notj has joined #bitcoin-wizards
notj has quit [Quit: My Mac has gone to sleep. ZZZzzz…]