sipa changed the topic of #bitcoin-wizards to: This channel 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
<sipa>
bramc: "in a future hardfork" :)
<bramc>
Hard forks are likely to wind up like Perl 6 or Python 3. They either ship never, or never minus a day :-)
bramc has quit [Quit: This computer has gone to sleep]
<tulip>
gmaxwell: in the last 500 blocks there's 2 useless nlockTime transactions with maxed sequence numbers.
<tulip>
quite a few with seemingly random sequence numbers too, I wonder what that's about.
<gmaxwell>
(I didn't mean to suggest that I think that particular scheme above is a equlibrium, but something along those lines-- and any would require being able to pay fees forward)
<gmaxwell>
tulip: see?
<midnightmagic>
:-o
<midnightmagic>
"provably destroyed! see?!"
ratbanebo has joined #bitcoin-wizards
notreallyhere has joined #bitcoin-wizards
dEBRUYNE_ has quit [Read error: Connection reset by peer]
DougieBot5000 has joined #bitcoin-wizards
DougieBot5000 has quit [Read error: Connection reset by peer]
roconnor has joined #bitcoin-wizards
Monthrect is now known as Piper-Off
bramc has joined #bitcoin-wizards
ratbanebo has quit [Remote host closed the connection]
ratbanebo has joined #bitcoin-wizards
DougieBot5000 has joined #bitcoin-wizards
skyraider has quit [Quit: Connection closed for inactivity]
Quanttek has quit [Ping timeout: 260 seconds]
ratbanebo has quit [Ping timeout: 252 seconds]
<bramc>
Why is being able to spend coinbase outputs immediately a good thing? Isn't the theory that being able to do so might somehow make it possible to create incentives to orphan?
<tulip>
it's mostly just to stop big chains of transactions being invalidated in a reorganisation.
<bramc>
tulip, Right, so why re-allow that behavior?
<tulip>
who is suggesting that?
<bramc>
tulip, gmaxwell is, a little bit up in the chat
snthsnth has quit [Ping timeout: 250 seconds]
<gmaxwell>
bramc: only be other coinbase transactions. You can already pay to incentivize orphaning, sadly, without using coinbase outputs; just using ordinary transactions.
<bramc>
gmaxwell, I don't follow what you're proposing allowing exactly
<gmaxwell>
Allow coinbase outputs to be spent by coinbase transactions. The coinbase->bitcoin path retains its 100 block delay.
<gmaxwell>
bramc: As an extreme example, right now if a bogon fee (e.g. 50 BTC) shows up ... you might be better off to just not mining the darn thing. (or would be, if miners currently had optimizing software)
<gmaxwell>
this is not good because it means that equlibrium seeking behavior from miners can only get expressed in reorg wars.
<bramc>
What is a 'coinbase transaction'?
<gmaxwell>
The special first transaction that gets paid the fees (and subsidy) in a block.
<gmaxwell>
If, instead, coinbases can spend coinbase outputs, you could take the bogon fee and pay some fraction (e.g. half) of it forward, and now there is a bounty for extending your block drawn from it-- without you having to put up your own coins seperately, in a similar manner.
<bramc>
gmaxwell, Is there some semantics to 'pay this to the next transaction output' that I'm not aware of? If so, what does it allow? For example, can it pay no N+2 and N+3?
<gmaxwell>
well one could presumably use CLTV to achieve that, if only the ability to spend in the first place existed.
<bramc>
And yes, a bogon fee is what I was calling a hot potato fee - Everybody will just orphan the same block over and over again trying to grab it for themselves
<tulip>
there's probably something fun there if you know other peoples behaviours, dropping a large fee in a block and having all the other miners squabble trying to make it stale, while you mine a higher chain away from the noise.
<bramc>
Gets even worse if it can have a max block height
<gmaxwell>
Right I think its likely that there are stable behavior of the class "consider the total known (or expected) fee income for the next _two_ blocks jointly, compute your block, and then pay half of any excess fee you got from that average forward." you could go next two to next N but the mempool becomes less accurate over time, since the transactions for 10 blocks from now haven't been announced y
<gmaxwell>
et.
<bramc>
gmaxwell, But if you don't need to use the cltv, then doesn't the transaction go immediately from coinbase -> bitcoin on that very first spend?
<gmaxwell>
bramc: no, any coins that come out of a coinbase transaction aren't bitcoins for 100 blocks; as there could be a reorg that forever destroys them even absent any dishonest (or strategic!) behavior.
<bramc>
gmaxwell, Hopefully transactions in general are smoothed out enough that this isn't such a problem, but yeah it's bad if somebody can send the blockchain into a tailspin for days just by spending a few thousand dollars
<gmaxwell>
so the system has a maturity rule that anything coming out of that transaction can't be spent, this includes subsidy and fees.
<bramc>
Ah, but right now there is no coinbase transaction, it just goes to a specific output?
<bramc>
Also, this vague 'pay it forward' functionality isn't in there, right? I mean, right now outputs go to specific keys, not the unknown key of some future block
<gmaxwell>
bramc: there is a coinbase transaction. The first transaction in a block. It's has a single magic input (the all zeros hash) that pays it the subsidy for the height (25 btc currently) and all the fees from the block. It pays out to 1 or more outputs, just like an ordinary transaction; except with a special behavior that these outputs cannot be used as inputs in any transaction for 100 blocks.
<gmaxwell>
So I would propose allowing coinbase transactions to have multiple inputs, and that its inputs ignore the 100 block coinbase restriction --- after all, if a prior block gets reorged out then _necessarily_ the current coinbase txn will get reorged out too.
<gmaxwell>
There is no pay it forward really possible now, due to the height restriction, well you could pay it forward, but you have to pay a miner 100 blocks from now. :)
<gmaxwell>
as far as how you pay them, you'd just write a output with the scrippubkey OP_TRUE, ... e.g. anyone can spend it.
<gmaxwell>
if you wanted to pay +1 +2 +3 blocks in the future seperately, then presumably you could do height+2 OP_CLTV, height+3 OP_CLTV etc. outputs.
<bramc>
gmaxwell, Oh I see. You can also combine CLTV and OP_TRUE to pay out for the next several blocks
<bramc>
jinx
<gmaxwell>
at least for some models all you need to do is go one forward, and then by induction that guy will keep paying forward.. but with unequal hashpower I think there is a defection problem, e.g. "I'll take the jackpot, and try to reorg war to keep it, because I have more hashpower".
<bramc>
Allowing multiple inputs to a coinbase transactions sounds like a safe and reasonable thing to do, except for that whole hard fork problem
<kang_>
Is it possible that such payforward deals be happening off-chain even now? That ways there's no restriction. I just tell 5 people, if you extend my work I'll send you some money..
<gmaxwell>
I think it's a really modest and uninteresting hardfork in and of itself, at least.
<gmaxwell>
kang_: it's possible, but it's hard to make secure. You can do them "on chain" to by just paying with your own coins, but you'll lose there if there is a reorg.
<gmaxwell>
Lots of things are possible with private deals, but access to private deals is a centeralizing effect I like to avoid the need for. :)
<tulip>
kang_: I don't think anybody has "smart" mining behaviour.
<kang_>
What is the use of allowing this? Doesn't this polarize the protocol?
<gmaxwell>
kang_: you can think of it like: doing it that way requires trust. Trust is a centeraizing force; it would make larger miners more profitable than smaller ones (better able to overcome the constant cost of establishing these relationships)
<bramc>
Although I haven't thought through all the details of how it should work out in practice. Really what you want is for all mining fees to me spread out over the next several blocks, dropping down over time, to avoid such issues. Having fees be set well, for example using the algorithms I've proposed, should fix the problem, but someone can still be a jerk and make a transaction which is too big causing chaos...
<gmaxwell>
kang_: it's already possible, but only in crappy centeralizing ways.
<gmaxwell>
and without it the system is not obviously stable as fees become larger than subsidy.
<kang_>
Yes, I first heard of this durinf scalingBitcoin Montreal on this channel itself
<gmaxwell>
(I mean it might not even be obviously stable _with_ this either, but its very obviously not incentive compatibly stable absent fee sharing.)
<bramc>
gmaxwell, I think with proper fee setting the system is stable-ish, but there's a trivial and inexpensive attack which really fucks shit up
<gmaxwell>
bramc: or errors, we'e had people pay fees much larger than the subsidy apparently on accident.
<gmaxwell>
There has been at least one 300 BTC fee, and I think two 150 BTC fees, and many more at other larger than subsidy sizes.
<bramc>
'Sorry I dropped $100,000 on the sidewalk'
<gmaxwell>
yea.. mostly due to screwing around with raw transactions without understanding the bitcoin protocol. :(
Mat555 has joined #bitcoin-wizards
<gmaxwell>
every once in a while someone showed up in #bitcoin confused/upset that sendrawtransaction in bitcoin core is rejecting their txn (because it's paying a supermassive fee)
<tulip>
there's also various applications for making transactions which do sanity checking at all.
<go1111111>
bramc: which trivial + inexpensive attack are you referring to?
rustyn has quit [Ping timeout: 265 seconds]
<gmaxwell>
(we added a guard rail after seeing several people do this stupidity-- though most people doing it weren't using bitcoin core :()
<belcher>
did you get any "BUT FREEDOM?!" comments against it ?
<kang_>
exactly!
<gmaxwell>
go1111111: paying a fee far in excess of typical income makes the income maximizing behavior to be to reorg the chain constantly until you win it, especially if you have more hashpower than other indivigual miners.
<bramc>
I think your idea of spreading fees over two transactions should work. Ideally the formula for all transactions would be that three units of fee go to this miner, two to the next miner, and one to the miner after that
ratbanebo has joined #bitcoin-wizards
<gmaxwell>
go1111111: at least if you work under an assumption that behavior is income maximizing the reorgs would continue until by lock someone gets decisively ahead.
rustyn has joined #bitcoin-wizards
<gmaxwell>
now obviously there are other forces at play (esp now) but it's preferable if the system works in theory. :)
cocoBTC has quit [Quit: Leaving]
<gmaxwell>
esp if there is a simple fix, as we have for BIP113 for a similar problem related to locktime.
<bramc>
If there are only a small number of miners they'll likely agree to simply not do such reorgs because each of them individually will lose more than they might gain as individuals if rewards shut down for a while due to bullshit
<gmaxwell>
belcher: I did have someone angry about it once until I got through their head that it was saving them from a $100 mistake.
<gmaxwell>
That was a good day. :)
<bramc>
gmaxwell, Hard forks are never a simple fix. There's an interesting question of how many small, safe things one might one to squeeze into a hard fork
Ylbam has quit [Quit: Connection closed for inactivity]
<go1111111>
gmaxwell: yeah, that seems correct for situations in which one block contains unusually high fees / rewards. is that what Bram meant with his reference to an attack though? that seems less like an attack and more like broken incentives leading to a bad situation
<gmaxwell>
bramc: there are other reasons to want to allow coinbase spending,.. but yea, in any case, this is one of those really trivial adjustments, in bitcoin core it is likely a couple single character changes.
<gmaxwell>
go1111111: well it's an attack when you trigger it intentionally and then laugh as the incentives make the network attack itself.
ratbanebo has quit [Ping timeout: 252 seconds]
<gmaxwell>
(and then exploit the instability for varrious purposes, like double spending)
<kang_>
But coinbase spending would further worsen it IMO, since a shorter branch would immediately want to share reward just to keep the rst of it
<bramc>
gmaxwell, I'd advocate for forcing all coinbase outputs to include a pay to next transaction of at least x% of the amount they're taking, where x is in the 25-50% range. That isn't quite such a trivial change and more likely to be controversial though.
<gmaxwell>
kang_: people can already share rewards; but only with trusty deals or by having a surplus coins of their own. So to the extent that it could be abused, it already can.
<gmaxwell>
bramc: I don't think forced forwarding makes sense, sadly-- though adding that is just a softfork on top of the spending behavior. The issue is that people can bypass the fee system entirely.
notreallyhere has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<bramc>
gmaxwell, Not sure what you mean about bypassing the fee system
<gmaxwell>
And so unless the forced fordwarding was always at equlibrium it'll start driving people to pay out of band fees. (e.g. by including outputs paying directly to big miners in their transaction; something that has, in fact, been done in the past)
<kang_>
Yes, but lots can happen over trusty deals. When we talk blockchain we cant account them. Atleast not above what the protocol allows..
<tulip>
why pay 50% of the fees to the next block when you can receive them out of band and get 100%?
<gmaxwell>
kang_: what we normally should strive to do is to diminish the advantage of schemes that provide income advantages for larger miners however.
snthsnth has joined #bitcoin-wizards
<bramc>
gmaxwell, I'm just trying to avoid the bogon fee attack in a way which is reliable rather than halfassed and based on social convention
<gmaxwell>
bramc: if you look back in the history here you'll see I described a particular fee forward scheme which I think is actually an equlibrium under some (unrealistic) assumptions; and its one which cannot be implemented as a consensus rule itself-- because it requires knoweldge of the mempool backlog.
<bramc>
You're right that once the multiple inputs are allowed the forced forwarding is a soft fork, although that's an extremely viscous soft fork.
<bramc>
I don't follow why mempool knowledge is necessary or matters.
<gmaxwell>
because I don't want to reorg you anymore when we share the potentially fees for our two blocks equally. And that depends on the fees in your block plus the fees that will be available in my block.
<kang_>
gmaxwell: pooled mining is beneficial only because of variance. Meni Rosenfield showed long ago that "If you distribute your hashrate among multiple pools in proportion to their respective total hashrate, your variance will be as if you mine in one pool with the total hashrate of all pools." Why then do we still see large operations?
c-cex-finch has quit [Quit: Connection closed for inactivity]
<gmaxwell>
kang_: many effects, it's hard to gauge their effect size. Probably some we don't know about. Shall I list?
<bramc>
gmaxwell, What's it matter to me if the fees in the next block might go up?
<kang_>
gmaxwell: If you could just give me keywords, I'd find and read
<gmaxwell>
kang_: For one, a large number of miners believe that mining is a race and the largest miner will get much higher rewards. I don't know if this generally incorrect belief is a majority view, but it's common and I've even heard it exposed by major hardware makers and pool operators. People do _not_ get poisson even when money is on the line.
<kang_>
So education can solve it?
<bramc>
It's funny how VCs pontificate arrogantly about how bitcoin is the future of finance and that's why they're dumping tens of millions of dollars into it, while we have highly technical discussions here in -wizards about how us people who they aren't even paying can keep the whole system from spontaneously imploding.
<belcher>
that insane, how hard can it be that if you're 10% of hash rate you'll get ~10% of blocks
<gmaxwell>
kang_: another is that the above is not actually entirely untrue, because of block propagation delays there actually is an excess return for larger pools; which has become pretty non-neglible over time. Right now time from first pool to half the pools on stratum servers has a median of about 5.7 seconds. Go compute the orphaning rate for that. :(
<gmaxwell>
this makes education harder.
<gmaxwell>
The worse confusion is one that has an element of truth.
smak has joined #bitcoin-wizards
<gmaxwell>
kang_: another factor is that all existing pools (cept p2pool) are in a trusted position where they can rob their users significantly. The variance of mining is so great an operator can skim several percent for basically forever and be undetectable. Some popular pools have hit 'luck' that had one in a billion chances of happening at random.
<bramc>
That's about a 1% bonus. Not a trivial amount.
<kang_>
Yeah I heard that in your devcore talk
<gmaxwell>
Meni's scheme maximizes the risk there.
<gmaxwell>
bramc: yea 1% return, and if your profits over returns were small, it can be a big impact on profits.
JackH has quit [Ping timeout: 250 seconds]
<bramc>
Right, 1% of gross, likely 10-50% of net
<gmaxwell>
bigger pools can cheat less without it being detectable, and maybe more eyes would detect cheating (dubious in our case, but not a bad hurestic in general).
<kang_>
belcher: due to variance, if you are 10% of hashrate you'll get >10% of blocks
jaekwon has quit [Remote host closed the connection]
<bramc>
Unlike the exchanges. Those are totally trustworthy.
<gmaxwell>
Bigger pools also can provide better user expirences, their frequent blocks are also effectively advertising for them.
<kang_>
So, as a thought experiment, if there was a central bot in the network that was distributing work to everyone and after 10 mins distributes the reward to everyone who contributed, there would be no variance (Basically everyone on one pool) and would solve this (except propagation delay)
<gmaxwell>
Then --- continuing, many of the current big pools are not really the same kind of thing that were pools N years ago; quite a few large miners themselves (either directly or via commonly owned sister orgs); that just let other people use their infrastrcture (to lower the variance).
<kang_>
So if we could design a distributed algo to divide work,(and rather than block reward as lottery, give every hash contributed its share) there would be no variance right?
<gmaxwell>
kang_: in the bitcoin consensus system the variance is an integral component, since its what causes consensus (eventually one fork gets lucky compared to anotherone by enough margin to overcome all communication delays decisively)
<tulip>
dividing work isn't really a thing, either.
<gmaxwell>
but yea sure if something were entirely different than bitcoin and magically solved consensus then one could avoid the specific challenges that arise from bitcoin's scheme. :)
<midnightmagic>
individual hash results being rewarded individually: share rewards would increase coinbase so greatly, in its current form, that it could be an effective ddos that dwarfs all other transaction activity.
<bramc>
Noone who knows it intimately ever accused bitcoin of being elegant and beautiful
<kang_>
Consider the bitcoin network as an entity. It collects raffle tickets over a period of 10 mins and then awards one of them. But if one owns m of total n tickets contributed during that time, their wining probability is not m/n due to variance.
<tulip>
bramc: I disagree, the original 0.1 client is pretty in its own right.
<kang_>
So if block reward was divided equally among n collected, then anyone owning m will win m/n reward only. hence no variance..
<midnightmagic>
the original codebase I found much more modifiable, and easier to track, than its current form. it made a lot more sense.
<gmaxwell>
kang_: it's probably better to stop thinking in terms of reward and remember that the mining process does not exist for reward, it exists to make the system work. The reward is a secondary effect.
<gmaxwell>
midnightmagic: I agree too, FWIW.
<kang_>
Yes I understand. but this scheme removes the centralization problem
<gmaxwell>
kang_: if you can make that work you can despense with mining entirely and just use it to select transactions.
<kang_>
Nope, because proof of work secures it
<gmaxwell>
I think the properties you're describing are not known to be acheivable in the setting bitcoin operates in. :)
<kang_>
If a competing network was able to perform more than n hashes then the entity rewards it instead (basically the definition of 51% attack)
<gmaxwell>
kang_: you made a comment above which was-- as far as I can tell-- untrue, and I've been trying to figure out what you were thinking. and I'm at a loss
<kang_>
Wizards chan is for thought experiments, anyways :)
<gmaxwell>
"their wining probability is not m/n due to variance"
<gmaxwell>
ignoring _progress_ effects (e.g. due to latency and block processing) the winning probablity actually is your hashrate.
<kang_>
A miner controlling a fraction p of the mining power has a probability p to mine each block. This follows a Bernoulli distribution and the variance is given by p(1-p). Since all blocks are independent, and since in a year there are 365 days of 24 hours of 6 blocks each, the annual variance is 365.24.6.p(1-p) while the expected return is 365.24.6.p The relative standard deviation is the square root of the variance divided by
<kang_>
sqrt[ 365.24.6.p(1-p)] / (365.24.6.p)
AaronvanW has quit [Ping timeout: 246 seconds]
<tulip>
lots of things in the code are more complex now in quite understandable ways. having inventory messages obviously reduces the bandwidth significantly down from a full flood system, moving away from BDB makes it a lot faster, removing vulnerable features like product review flooding and IRC based discovery are clearly positive choices. there's probably a lesson about "simple" being too simple, or something, I'm struggling to draw a conclusion
<tulip>
from that.
<kang_>
A miner projecting to obtain an expected return on investment of 10% and controlling 0.19% of the hashing power would have about a 16% chance of losing money by the end of the year.
<gmaxwell>
kang_: yes, the distribution is not symmetrical; but the expect income is the expected income; the variance doesn't change that.
<kang_>
gmaxwell: So even ignoring progress effects, winning probability is not the hashrate
<bramc>
It's true that the stochastic nature of rewards is part of scaling. The coinbase transaction counts towards the size of the block as a whole for good reason.
<gmaxwell>
gah. thats not correct. Even read the first sentence you quoted.
<tulip>
bramc: if it wasn't counted you could make the block infinitely large, there's no limit on the size of individual transactions other than the p2p message size
<kang_>
ok sorry. I understand my mistake. The probability is yes m/n, but over a period of time the deviation is very high for small values of m
<tulip>
gmaxwell: would a pull request putting Satoshis poker client back into Bitcoin Core be accepted? :P
<kang_>
So larger values of m win over a longer period of time
<kang_>
But you get what I wanna say
snthsnth has quit [Ping timeout: 260 seconds]
<kang_>
"their wining probability over a longer period of time, say one year, is not m/n due to variance"
<bramc>
kang_ My point is that spreading that out enough starts hitting real transaction fees just for the spreading
<kang_>
gmaxwell: Beg for your patience. Call me wrong but please don't ignore me. I respect your time very much and would never troll you.
snthsnth has joined #bitcoin-wizards
ratbanebo has joined #bitcoin-wizards
<kang_>
I corrected the statement. So if there was a distributed algorithm that , say, had a score of contributed hashes, and distributed the reward rather than lucky draw, mining variance would vanish
<tulip>
are you aware of p2pool?
<kang_>
Sure. exactly that but for everybody. p2pool as a layer
<tulip>
p2pool has problems though. its block chain is similar to Bitcoins, just with a 30 second block time.
<tulip>
it's latency sensitive, and you have the problem of trying to make hundreds of payments of dust to participants. it's useless for the people mining and produces massive blocks.
<kang_>
Yes, true
<midnightmagic>
that's not quite a correct statement. p2pool provides signifiant advantages and IMO is not useless for the people mining.
ratbanebo has quit [Ping timeout: 252 seconds]
<midnightmagic>
it is less useful for hashrate which is relatively smaller than the overall p2pool hashrate.
<kang_>
Its not useless, but the crux was that it increases block size
<tulip>
sorry, it would be useless if you had all the participants in the network receiving small payouts with it. hypothetical rather than what happens today.
<kang_>
Yes, so the solution for that would be synced mempools.
<tulip>
if you had synced mempools you wouldn't need mining to begin with.
<midnightmagic>
p2pool is not granular on a single sharechain; the threshold of utility is, indeed, unfortunately increasing proportional to overall bitcoin hashrate but smaller chains and collections of cooperative/alternate sharechains are still possible.
adam3us has joined #bitcoin-wizards
<midnightmagic>
The main issue, it seems to me, is that the larger miners don't use it, and mining is centralized. But there are some really nice possibilities that forrest etc have dreamed up including spontaneous sub-sharechains and ghost-like subshares which *could* eliminate perceived sharechain "efficiency" loss.
<kang_>
Wow! Bitcoin is really in a failing state as of now
<kang_>
tulip: thanks, i get the fault in my line of thinking
adam3us1 has joined #bitcoin-wizards
adam3us has quit [Ping timeout: 250 seconds]
notreallyhere has joined #bitcoin-wizards
notreallyhere has quit [Client Quit]
<kang_>
What are the other ways to look at the blockchain than the distributed ledger. For example one is a DMMS algo to secure any token as stated in sidechains whitepaper
Yoghur114 has quit [Remote host closed the connection]
<gmaxwell>
kang_: hey, forgive me for leaving for dinner. :)
<kang_>
:) i got my mistake
<gmaxwell>
I see!
go1111111 has quit [Ping timeout: 246 seconds]
go1111111 has joined #bitcoin-wizards
epopt has joined #bitcoin-wizards
<gmaxwell>
To the extent that commercially significant variance is a cause of centeralization, p2pool had basically solved it prior to the introduction of generation after generation of asic with latency problems; it's novel propagation mechenisms gave it a significant return advantage... but it still was not widely used. I believe that this is due to first (misunderstanding mining as a race) reason I gave,
<gmaxwell>
as well as the UI ones; but it's hard to say.
snthsnth has quit [Ping timeout: 265 seconds]
<bramc>
The lack of decent canonical proofs of sequential work algorithms is driving me nuts. There *must* be something better than sequential hashing.
<bramc>
And it just occurred to me that you can make a history much more secure by including a direct link to the previous proof of space in each new proof of space in addition to the proof of time based on that proof of space. That results in a lot less trust when you only spot check the proofs of time.
ratbanebo has joined #bitcoin-wizards
simba has joined #bitcoin-wizards
ratbanebo has quit [Ping timeout: 252 seconds]
<bramc>
I just sent mail to a 'real' cryptographer begging him to come up with better canonical proofs of time
<bramc>
Despite the rube goldbergian nature of the space-based construction I have, the one part I'm really hating on is the proofs of time. Making it so most nodes an only afford to spot check is just gnarly.
<aj>
gmaxwell: so the idea with HTLCs is you pay to a hash and collect the payment by revealing the preimage. using sha256 or hash160 or whatever means that to forward a htlc you have to reuse the same hash/preimage at each step. i assume you're totally familiar with that?
<gmaxwell>
Yes. to make the payment atomic.
<aj>
gmaxwell: yeah
<aj>
gmaxwell: so it would be nice if you could use different hash/preimages at each step, so that different nodes in the route can't conspire and work out who was paying who. the "previous message" was me trying to do that with a SNARK
<gmaxwell>
So in here you pay to randomly relayed pubkeys along the way. But then how is the unlock atomic? e.g. if you just sign with Q at the end, the private key is not revealed... and so the other transfers are stuck, no?
<aj>
gmaxwell: so the use of ecc_multiply as the hash function instead solves it much more cleverly
<aj>
gmaxwell: ie PUBLIC = g*PREIMAGE
<aj>
gmaxwell: so that's still the last step in the chain, but the step prior to that becomes PUBLIC*n = g*PREIMAGE*n, and the step before that becomes PUBLIC*n*m = g*PREIMAGE*n*m*
AaronvanW has joined #bitcoin-wizards
<aj>
gmaxwell: the n and m are kept secret to the person doing the paying, and the particular node; so they're not random pubkeys, they're random multiples of the next pubkey
<gmaxwell>
that was supposted to be 'related'.
<aj>
gmaxwell: english should've been designed with a higher hamming distance
<aj>
gmaxwell: okay so if you're asked to forward PUBLIC*n*m to PUBLIC*n; then you need to be told PUBLIC*n*m, PUBLIC*n, and m; you can then verify the multiplication, and once the payment completes you'll find out PREIMAGE*n (because PUBLIC*n will have just cleared). But you know m, so you multiply and have PREIMAGE*n*m and can clear the next step
<gmaxwell>
Why not this alternative scheme; Q = xG; Q1 = Q+P1, Q2 = Q+P2, Q3 = Q+P3 where the P_n are the single keys of the participants.
flipswitchbitch has quit [Ping timeout: 272 seconds]
<gmaxwell>
And instead of revealing Q you sign with it, using a forced static R value, so all the participants learn the discrete log from the signature?
<aj>
gmaxwell: because then you could just subtract your key P1 to work out Q and correlate transactions?
<gmaxwell>
aj: the 'your key'-- the key is single use, and uniformly distributed.
<aj>
gmaxwell: hmm, i'm not sure how that would work
<gmaxwell>
(I was going to seperately say you should be doing Q+nG generally, as it is enormously faster and as far as I can tell you need no property of multiplication here)
<gmaxwell>
aj: What part isn't clear?
<aj>
gmaxwell: so "x" is the secret known by the merchant, and Q is revealed to the consumer, yes?
<gmaxwell>
Yes.
<aj>
gmaxwell: oh, or is it the signature that's revealed to the consumer, not Q?
<gmaxwell>
x is the hash preimage, if you will, Q is the hash. the Q+... the the derrived hashes. whos preimages will be known to the keyholders of P1, P2, P3 ... respectively (and only them), once they know x.
<gmaxwell>
x can be disclosed if the payment to Q at the end requires signing with a particular nonce (e.g. substr constraining the signature), and the particupants know the discrete log of that nonce already.
<gmaxwell>
beyond not requiring additional constructs and getting rid of the expensive multiply, I think the inner public keys can replace the need for a seperate signature, and potentially make it so that all transactions except the last look like more ordinary multisig transactions.
<aj>
gmaxwell: hmm
<aj>
gmaxwell: that /sounds/ plausible, but i'll need to work it out with pen and paper...
<aj>
gmaxwell: (substr is a disabled opcode though)
<gmaxwell>
(there is an extra constraint that you need to show that P_n wasn't generated as a function of Q but there are several ways to do that.)
<gmaxwell>
aj: sure, though all the other things you're talking about don't exist. And I would be much more keen to enable substr (it's there in alpha, ...) than a generic point scalar multiply, which is fairly expensive (basically the same cost as a signature verify)
<gmaxwell>
single show signatures tend to be useful for other things in any case.
DougieBot5000 has quit [Quit: Leaving]
moa has quit [Ping timeout: 276 seconds]
<aj>
gmaxwell: so i think "OP_DUP 16 OP_LEFT <r> OP_EQUALVERFIY <Q> OP_CHECKSIGVERIFY" would let you reveal "x" with just OP_SUBSTR/OP_LEFT; but i don't see how earlier steps could get away with just a regular multisig txn?
<gmaxwell>
instead of having to be a preimage + key, they're just payments to a key.
epopt has quit [Ping timeout: 272 seconds]
damethos has quit [Ping timeout: 240 seconds]
matsjj_ has joined #bitcoin-wizards
<aj>
gmaxwell: but that doesn't work transitively? ie, once I know <x> I can sign with <Q+P3>, but how does that help the next guy sign with <Q+P2>?
moa has joined #bitcoin-wizards
<gmaxwell>
when he knows x he can with with Q+P2. (presuming he could sign with P2 to begin with, he just adds x to his private key)
<aj>
gmaxwell: right, but he doesn't know <x> unless he forces me to sign with a known r too, rather than just asking me to pay to an address?
<gmaxwell>
I'm assuming he'll observe the Q single show payment.
matsjj has quit [Ping timeout: 272 seconds]
<gmaxwell>
same deal as with the plain hashlock, everyone tests the same preimage.
<aj>
gmaxwell: that only works if he knew the log of the <r> value that i chose?
<gmaxwell>
you can all share that in advance. (e.g. Q picks it and tells the whole channel Q,r at the start)
<aj>
gmaxwell: seems like that'd require trust... i don't think you'd get to see the reveal of Q normally either -- it'd be in a channel, rather than on the blockchain
<gmaxwell>
I don't see how this is different than the case where you are using a common Hx = H(x) everywhere.
<aj>
gmaxwell: not using a common Hx is the goal :)
<gmaxwell>
Yes for privacy!
<gmaxwell>
But you're not making a privacy related objection.
<aj>
gmaxwell: but with a common Hx each node along the chain says "Here's x!" to the previous node, who then verifies H(x)=Hx, and repeats. you forward along the same Hx each time because that's the only way you'll convince anyone to give you x
<gmaxwell>
okay you're counting on each step forcing there not the final being made public.
<gmaxwell>
Then I withdraw that optimization. Still, use of addition and single sure I hope turn out to be useful improvements. :) I'll think more about this.
<aj>
gmaxwell: okay :)
<aj>
gmaxwell: though... i think maybe you just end up with two OP_CHECKSIGVERIFIES anyway, rather than an OP_ECC_MUL + OP_CHECKSIGVERIFY (or OP_SHA256 + OP_CHECKSIGVERIFY) :(
<aj>
gmaxwell: revealing Q with just one OP_CSIGV would let the other guy publish the old commitment tx, then spend your output (ie, getting a refund), but then claim the original payment too (assuming they didn't rip them off in the same way)
<gmaxwell>
yes, if each step has to reveal then you need two keys. (a CMS with one being single show)
<aj>
CMS?
<gmaxwell>
checkmultisig.
moa has quit [Quit: Leaving.]
<gmaxwell>
I'm going to go try to find a single show signature in the existing system. There may well be one.
flipswitchbitch has joined #bitcoin-wizards
damethos has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 240 seconds]
TBI_ has joined #bitcoin-wizards
TBI has quit [Ping timeout: 240 seconds]
<gmaxwell>
y'all are gonna hate me, but I did it: we've already got a single show signature in Bitcoin!
<aj>
gmaxwell: ... so what is it?
<gmaxwell>
So I have a scheme, where you can give me a pubkey, and I can write a unusual scriptpubkey that pays to it, which you can sign for but not without leaking your private key to the world ... with computational soundness (e.g. you could do an intractable amount of computation and break it.)
<sipa>
hashlock where the preimage is the pubkey?
<amiller_>
guy fawkes signatures satisfy that description too
<sipa>
oh. leaks private key
<gmaxwell>
amiller_: from context, it need to be a ECDSA single show for other reasons.
<gmaxwell>
I'll let other people stew on it for a day. Someone might invent a better one along the way. :)
<gmaxwell>
amiller_: simplifying the earlier discussion and removing all the LN specific stuff, here is why I want it:
<gmaxwell>
Here is a private atomic swap that doesn't need the multiphase "CoinSwap" transform:
<gmaxwell>
B computes nonce x and P = xG
<gmaxwell>
B sends P, single-show-signature-with P to A
<gmaxwell>
B pays to if() {Apub2+P} else {CLTV Bpub}
<gmaxwell>
A pays to if() {Bpub, force R key P} else {CLTV Apub}
<gmaxwell>
the two payements are unlinkable (assumping apub2 is kept private to alice and bob; uh and assuming my two bpubs above are distinct keys)
<gmaxwell>
And they're atomic.
<amiller_>
what do you mean by B sends P, single-show-signature-with P to A.... does that reveal x to A?
<gmaxwell>
no, it's just a signature. then in the last payment the scriptpubkey requires a signature with P in such a way x will be made public. (e.g. if we had substr, you'd just use it to constrain R to be the R from the earlier signature)
<kanzure>
atomic swap should be applied to lightning transaction types at some point
<gmaxwell>
so the missing primitive for this private atomic swap was a way to do a signature which will leak the private key in bitcoin today. (since it's nicer if things work now...)
melvster has quit [Ping timeout: 260 seconds]
<amiller_>
after step 2 "B sends P, single-show-signature-with P to A", is the message that will be eventually single-show-signed predetermined?
<gmaxwell>
can't be, alas, it's a spend of the last transaction (pays) there, so it will commit to that txid.
<amiller_>
can you replace "A pays to if() {Bpub, force R key P} else {CLTV Apub}" with simply "A pays to if() {force R key P} else {CLTV Apub}"
flipswitchbitch has quit [Ping timeout: 246 seconds]
<gmaxwell>
amiller_: doing to means someone could see that spend and race it (now knowing x) to steal the funds.
<amiller_>
i cant see why this is a signature and not just revealing the preimage..... oh i see the point is for them to be unlinkable
<gmaxwell>
so the requirement for a Bpubkey there is important.
<gmaxwell>
Yes, to be unlinkable.
Guest1328 is now known as pigeons
<gmaxwell>
amiller_: I made a generic scheme for that in the past https://bitcointalk.org/index.php?topic=321228.0 which lets you hide any smart contract from the blockchain and make it private.. including an atomic swap (of the normal hashlock type)... but it has lots of steps, which is a pain to implement, and make it malleability vulnable.
melvster has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
<amiller_>
ok i guess that kind of unlinkability is cool enough, that's cool it improves coinswap, i guess it's obvious it's possible in general but probably requires cleverness to do with existing script
p15 has quit [Ping timeout: 260 seconds]
smk has quit [Ping timeout: 246 seconds]
<amiller_>
since the only tool at your disposal in bitcoin script is checking a signature over the current transaction, i imagine all you can hope to do is check multiple signatures over the same message under different but related public keys
<sipa>
and require related k
SgtStroopwafel has quit [Read error: Connection reset by peer]
<amiller_>
how do you require related k?
<sipa>
i've been asking myself that question for the past half hour
* gmaxwell
cheshire cat
<kanzure>
what was the signature scheme where you can insert arbitrary text into the middle of a signature?
SgtStroopwafel has joined #bitcoin-wizards
<kanzure>
perhaps adding that sort of requirement would reveal some key info
<kanzure>
er, it was not arbitrary text, i am misremembering, but that's already evident by me not remembering the name :-)
p15x has joined #bitcoin-wizards
<aj>
hmm, i can related keys, but can't get the sigs from the related keys to be related enough but not too much
Quanttek has joined #bitcoin-wizards
<gmaxwell>
unrelated; Anyone else here read Mother Earth Mother Board? I think it's online, fun read though probably a bit dated now. In it; it talks about undersea cables, once installed being something of a 'found artifact' ... like stargates left from a prior civilization, where generations of engineers pour over them to characterize them and extract every bit of capacity available... far beyond what t
<gmaxwell>
hey originally did. I've thought about the bitcoin network like this at times, just because the cost ratio of upgrading it vs coming up with a crazy way to use what it has already supports doing the latter.
<amiller_>
i don't think you can require related k but i also don't see why you need that
<kanzure>
there was some idea about using undersea sponges to make fiber optics at some point
<sipa>
amiller_: signing with related public keys does not automatically reveal the private key
<sipa>
amiller_: or BIP32 would be very broken
<kanzure>
like all weird scifi ideas, i am sure that orionsarm.com has shamelessly copied the idea
<aj>
gmaxwell: that's the neal stephenson travelogue? was hoping for a scifi story where they were literally found artifacts...
gielbier has joined #bitcoin-wizards
gielbier has joined #bitcoin-wizards
giel__ has joined #bitcoin-wizards
gielbier is now known as Guest14962
giel__ is now known as gielbier
gielbier has quit [Changing host]
gielbier has joined #bitcoin-wizards
Guest14962 has quit [Ping timeout: 240 seconds]
dEBRUYNE has joined #bitcoin-wizards
flipswitchbitch has joined #bitcoin-wizards
atgreen has joined #bitcoin-wizards
Giszmo has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 250 seconds]
Quanttek has quit [Remote host closed the connection]
p15x has quit [Ping timeout: 240 seconds]
Quanttek has joined #bitcoin-wizards
<bsm117532>
I just noticed that the Iota folks have put out a whitepaper. (It's a DAG-based crypto-currency) At first glance it looks pretty good. http://188.138.57.93/tangle.pdf
atgreen has quit [Ping timeout: 272 seconds]
flipswitchbitch has quit [Ping timeout: 264 seconds]
<bsm117532>
Is Serguei Popov or any of the Iota people going to be at Scaling Bitcoins? If not I'll try to cover this material...
<sipa>
that doesn't sound like applicable in the short term to bitcoin proper
davec has quit [Read error: Connection reset by peer]
davec has joined #bitcoin-wizards
adam3us has joined #bitcoin-wizards
sparetire_ has joined #bitcoin-wizards
<kanzure>
is there a way to do a 2-way spv peg where if the sidechain operators don't submit a conflicting proof within some number of confirmations, bitcoin users can recover their deposits to the spv address?
<kanzure>
spv address or er, spv mechanism
<kanzure>
unrelated; "segwit" == "segregated witness" (took me a few seconds..)
<bsm1175321>
sipa: better to take a long road to the right answer than a short-term band-aid that we'll regret the consequences of forever. To that end, DAGs can solve a lot of problems, and we should consider a route to it.
<bsm1175321>
If you want to hear how I think we can add a DAG layer to bitcoin without upsetting consensus and bitcoin blocks I can talk about it more here...
atgreen has joined #bitcoin-wizards
rdponticelli has quit [Ping timeout: 276 seconds]
dEBRUYNE has quit [Ping timeout: 255 seconds]
simba has joined #bitcoin-wizards
simba has quit [Remote host closed the connection]
<bsm1175321>
I have a hard time with word salad. Lots of salad in those last few links.
ThomasV has joined #bitcoin-wizards
Guest16720 is now known as grubles
grubles has quit [Changing host]
grubles has joined #bitcoin-wizards
TBI has joined #bitcoin-wizards
TBI_ has quit [Ping timeout: 260 seconds]
ebfull has joined #bitcoin-wizards
flipswitchbitch has quit [Ping timeout: 255 seconds]
<Taek>
.tell bramc you mentioned earlier working on Bitcion's peer protocol. gavinandresen was also talking about rewriting Bitcoin's peer protocol, perhaps there's value in collaboration
<yoleaux>
Taek: I'll pass your message to bramc.
bramc has joined #bitcoin-wizards
simba has quit [Remote host closed the connection]
simba has joined #bitcoin-wizards
simba has quit [Remote host closed the connection]
psztorc has joined #bitcoin-wizards
jaekwon has joined #bitcoin-wizards
paveljanik has joined #bitcoin-wizards
GGuyZ has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 240 seconds]
justanotheruser has quit [Ping timeout: 240 seconds]
jaekwon has quit [Read error: Connection reset by peer]
jaekwon has joined #bitcoin-wizards
<gwillen>
kanzure: hmmm interesting
<kanzure>
yeah seems likely to work if you can enforce some standard about sorting
<gwillen>
oh hm, like sorting the candidate utxos?
<kanzure>
right
<kanzure>
but lookup time is going to be painful for validators
<kanzure>
especially without references
<gwillen>
yeah it sounds like he wants it to take them all without actually having to know what they are
<kanzure>
validators will always have to know them all
justanotheruser has joined #bitcoin-wizards
<gwillen>
but if you instead do specify the amount
<gwillen>
and just have it take utxos from the beginning in sort order until you reach that amount
<gwillen>
and I mean, this is no more annoying for validators than SIGHASH_NO_TXID or whatever
<gwillen>
that would be "give me any coin with this scriptpubkey", versus this is "give me _all_ coins with this scriptpubkey"
cocoBTC has joined #bitcoin-wizards
<kanzure>
how would you do miner fees with the partial one?
justanotheruser has quit [Ping timeout: 250 seconds]
<kanzure>
you would have to specify the fee amount in script too :)
Cynexus has joined #bitcoin-wizards
<gwillen>
kanzure: I'm imagining that you do specify an input value, contra the original mailing list suggestion
<gwillen>
and that value has to be the some of the values of some prefix of the list of possible inputs in whatever the sort order is
<gwillen>
and it unambiguously uses all of those
<gwillen>
err, the sum*** of the values
<gwillen>
and then the fee works as normal
<kanzure>
i think that many implementations assume that all inputs are valid, and use that as a way to reject invalid transactions, though
priidu has quit [Ping timeout: 272 seconds]
<kanzure>
er. valid according to existing rules.
<kanzure>
so increases soft-fork difficulty
<gwillen>
hmm, can you explain a bit more?
<kanzure>
the input would be "invalid" according to existing rules
cocoBTC has quit [Quit: Leaving]
<kanzure>
implementation details- like how validators are implemented- can influence how you choose to implement a soft-forkable feature... if a change requires too much effort, widespread deployment is unlikely.
<kanzure>
gwillen: also; if you use the no-inputs-ever strategy, then you might accidentally spend some BTC to fees if you receive BTC to that scriptpubkey after you sign a transaction, but before the transaction is confirmed.
<gwillen>
kanzure: that's why you do specify a value
<bsm1175321>
Hahaa I decided on some terminology: In a DAG if one of your node's parent's parent is one of your own parents, that's {\it incest} and disallowed. (Popov's tangle has incest)
cocoBTC has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
CoinMuncher has quit [Quit: Leaving.]
jaekwon has quit []
AnoAnon has joined #bitcoin-wizards
jaekwon has joined #bitcoin-wizards
AnoAnon has quit [Max SendQ exceeded]
matsjj_ has quit []
simba has joined #bitcoin-wizards
matsjj has joined #bitcoin-wizards
matsjj has quit [Ping timeout: 246 seconds]
atgreen has joined #bitcoin-wizards
matsjj has joined #bitcoin-wizards
Jeremy_Rand has joined #bitcoin-wizards
matsjj_ has joined #bitcoin-wizards
kwonbie has joined #bitcoin-wizards
matsjj has quit [Ping timeout: 255 seconds]
GGuyZ has quit [Read error: Connection reset by peer]
GGuyZ_ has joined #bitcoin-wizards
snthsnth has joined #bitcoin-wizards
Lightsword has joined #bitcoin-wizards
MoALTz has quit [Quit: Leaving]
priidu has quit [Ping timeout: 250 seconds]
MoALTz has joined #bitcoin-wizards
GGuyZ_ has quit [Read error: Connection reset by peer]
GGuyZ has joined #bitcoin-wizards
simba has quit [Read error: Connection reset by peer]
simba has joined #bitcoin-wizards
GGuyZ has quit [Quit: GGuyZ]
justanotheruser has joined #bitcoin-wizards
justanot1eruser has joined #bitcoin-wizards
c-cex-yuriy has joined #bitcoin-wizards
moa has joined #bitcoin-wizards
adam3us has joined #bitcoin-wizards
GGuyZ has joined #bitcoin-wizards
justanot1eruser has quit [Ping timeout: 260 seconds]
justanotheruser has quit [Ping timeout: 264 seconds]
justanotheruser has joined #bitcoin-wizards
justanot1eruser has joined #bitcoin-wizards
GGuyZ has quit [Read error: Connection reset by peer]
snthsnth has quit [Ping timeout: 276 seconds]
justanotheruser has quit [Quit: leaving]
justanot1eruser has quit [Quit: leaving]
adam3us has quit [Quit: Leaving.]
pozitron has quit [Ping timeout: 260 seconds]
binaryFate has joined #bitcoin-wizards
damethos has quit [Quit: Bye]
damethos has joined #bitcoin-wizards
kwonbie has quit [Ping timeout: 272 seconds]
TBI_ has joined #bitcoin-wizards
GGuyZ has joined #bitcoin-wizards
TBI has quit [Ping timeout: 240 seconds]
ThomasV has quit [Ping timeout: 246 seconds]
mjerr has quit [Ping timeout: 240 seconds]
snthsnth has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
Emcy_ has quit [Ping timeout: 240 seconds]
simba has quit [Remote host closed the connection]
simba has joined #bitcoin-wizards
hsmiths_ has joined #bitcoin-wizards
simba has quit [Read error: Connection reset by peer]
simba has joined #bitcoin-wizards
priidu has joined #bitcoin-wizards
Guyver2_ has joined #bitcoin-wizards
priidu has quit [Read error: Connection reset by peer]
<bsm1175321>
Just in case anyone else wanted to read that Iota paper I posted...don't. It's a confused mess with some poorly understood textbook statistics thrown in.
priidu has joined #bitcoin-wizards
damethos has quit [Quit: Bye]
simba_ has joined #bitcoin-wizards
simba has quit [Read error: Connection reset by peer]
bramc has quit [Quit: This computer has gone to sleep]
<el33th4x0r>
This meme that is going around that Bitcoin is "eventually consistent" is just wrong.
<sipa>
bitcoin is not even eventually consistent. it's probabilistically consistent
GGuyZ has quit [Read error: Connection reset by peer]
<el33th4x0r>
Correct, it's not eventually consistent.
GGuyZ has joined #bitcoin-wizards
<el33th4x0r>
It provides a very strong probabilistic guarantee.
ThomasV has joined #bitcoin-wizards
<sipa>
with certain economic assumptions
kang_ has joined #bitcoin-wizards
<el33th4x0r>
And assumptions on the hash power of colluding attackers.
<el33th4x0r>
but the bottom line is that one cannot look at the tail of the blockchain, observe that it's changing, and conclude that the system is "eventually consistent" or "inconsistent"
<el33th4x0r>
Paxos proposals can change over time. Paxos guarantees serializability, one of the strongest consistency guarantees.
<el33th4x0r>
When we evaluate databases, we examine their behavior with respect to a Write protocol and Read protocol.
Alanius has quit [Ping timeout: 250 seconds]
Alanius has joined #bitcoin-wizards
<el33th4x0r>
We do not examine the intermediate states of their internal data structures. No one cares that those change, as long as the changes are not reflected to clients through the Read()/Write() API.
<el33th4x0r>
I've heard various people mention casually that Bitcoin offers weak consistency. This is incorrect -- the exponentially-decaying probabilistic guarantee offered by Bitcoin is stronger than most distributed databases.
<amiller_>
i think they should cite Exposing Computationally-Challenged Byzantine Impostors ftp://haskell.cs.yale.edu/pub/TR/tr1332.pdf and PoW-Based Distributed Cryptography with No Trusted Setup http://link.springer.com/chapter/10.1007/978-3-662-48000-7_19
lnovy has quit [Ping timeout: 240 seconds]
<bsm1175321>
el33th4x0r: Bitcoin's consistency is only asymptotic, not convergent (and certainly not exponential). Academic studies (PAXOS) generally go for convergence.
simba_ has quit [Read error: Connection reset by peer]
<el33th4x0r>
Paxos is not an academic study, it's a protocol.
simba has joined #bitcoin-wizards
<bsm1175321>
It originated in academia and is well studied there.
<el33th4x0r>
Right, I'm an academic, well aware of Paxos' origins.
<el33th4x0r>
If we wanted to be pedantic, Synod is the original consensus protocol, and Paxos has been applied to a family of consensus protocols.
<bsm1175321>
So why this dislike of "weak consistency"? Isn't it just saying "asymptotic"?
<el33th4x0r>
Because Bitcoin provides something stronger than weak consistency. Also, the framework people use to evaluate it is broken.
<el33th4x0r>
BTW "convergent" is not a well-defined term. And the probabilistic guarantee offered by Bitcoin is certainly exponential, discussed in the white paper.
<bsm1175321>
Convergent is a very well defined mathematical term.
<el33th4x0r>
Can you please define it for consensus protocols?
GGuyZ has quit [Quit: GGuyZ]
GGuyZ has joined #bitcoin-wizards
* bsm1175321
looks through notes. Would be happy to be wrong about this...
rusty2 has joined #bitcoin-wizards
<bsm1175321>
el33th4x0r: I think you're right. "Probabilistic Convergence" is better. If I figure out why I decided it was asymptotic I'll post about it. But the probability of an attacker with hashpower < 0.5 creating the highest-weight chain is absolutely convergent to zero.
ThomasV has quit [Ping timeout: 264 seconds]
atgreen has quit [Ping timeout: 255 seconds]
Guyver2 has quit [Quit: :)]
Guyver2_ is now known as Guyver2
Guyver2 has quit [Read error: Connection reset by peer]
<el33th4x0r>
bsm1175321: Great. And the probability of an attacker with hashpower < 0.33 creating the highest-weight chain indeed converges to 0 with increasing block height.
jaekwon has quit [Remote host closed the connection]
<bsm1175321>
Modulo the selfish mining attack...
<bsm1175321>
Which I think you wrote, no?
<el33th4x0r>
Right, that's me and Ittay Eyal.
jaekwon has joined #bitcoin-wizards
flipswitchbitch has joined #bitcoin-wizards
<el33th4x0r>
I'll head home for dinner and baby play, but let me leave on a positive note: we all have good reason to be proud of Bitcoin when it comes to claims about its consistency.
<el33th4x0r>
It provides stronger consistency guarantees than Mongo, for instance.
<el33th4x0r>
Not as strong as HyperDex, which provides a linearizability guarantee, but still stronger than many of the systems that people use to store their data.
<el33th4x0r>
Judging Bitcoin by the presence of change at the blockchain's tail reflects confusion, because no one would judge Paxos or Zab or RAFT by how the leader changes its proposal.
binaryFate has quit [Quit: Konversation terminated!]