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
<zookolaptop>
vladzamfir: this is still bothering my brain. If your adversay controls, let's say, 50% of all the Vladcoin on Planet Vlad, and your system either transfers the value of the forfeited bond to all stakeholders,
<zookolaptop>
so 50% to your adversary, and the rest to a bunch of other folks, or
<zookolaptop>
else your system transfers the value of the forfeited bond to some special designated
<zookolaptop>
beneficiary,
<zookolaptop>
then my question is: how much does it cost to subvert that designated beneficiary?
jcorgan|away is now known as jcorgan
AaronvanW has joined #bitcoin-wizards
cheetah2 has quit [Remote host closed the connection]
Guyver2 has quit [Quit: :)]
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
<petertodd>
bramc: cool, email me your draft when it'sready
<AdrianG>
bramc: where are you going to publish the write up?
CubicEarth has quit [Remote host closed the connection]
AaronvanW has quit [Ping timeout: 260 seconds]
psztorc has quit [Ping timeout: 252 seconds]
pozitrono has quit [Ping timeout: 260 seconds]
PaulCapestany has quit [Remote host closed the connection]
<JackH>
<JackH> anyone know of some crazy implementation of bitcoin in an altcoin? for example, with new op_codes that does something, or with some new features? the closest I come to anything is the sidechains protocol.
PaulCapestany has joined #bitcoin-wizards
CubicEarth has joined #bitcoin-wizards
<bramc>
AdrianG, Probably my blog or medium
<JackH>
hi bramc, what was the eventual conclusion on that whitepaper? is there anything substantial to it?
<bramc>
JackH, If you mean the one on hash tubes, I think it has an interesting idea but nothing important to add yet.
<JackH>
alright, thanks bramc
GGuyZ has quit [Quit: GGuyZ]
<dcousens>
Anyone available to review a coinswap alternative I'm looking at implementing?
OneFixt has joined #bitcoin-wizards
<kanzure>
better to just post a link instead of asking
<bramc>
petertodd, Sure, still working on it. I'm specifically not going to work out some of the math, so finding closed form rather than monte carlo solutions would be much appreciated.
<kanzure>
unclear to me if you have seen some of the selfish mining papers
Alopex has quit [Remote host closed the connection]
<bramc>
I don't understand the bizarre pseudocode which academics use in papers. What's wrong with Python?
AaronvanW has joined #bitcoin-wizards
<dcousens>
bramc: whats more annoying is when they include pseudo-code for very common algorithms not relevant to their work
<dcousens>
what ever happened to just using the built-ins or an #include of the std-lib
<bramc>
There appears to be some 'real' standard the pseudocode is supposed to conform to, even though nothing actually runs it and it doesn't have any particular expressive power.
justanotheruser has joined #bitcoin-wizards
go1111111 has quit [Ping timeout: 256 seconds]
go1111111 has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
adam3us1 has joined #bitcoin-wizards
adam3us has quit [Ping timeout: 256 seconds]
adam3us1 has quit [Client Quit]
adam3us has joined #bitcoin-wizards
cheetah2 has quit [Remote host closed the connection]
<bramc>
Okay, so what I've come up with is a reinvention of the algorithm by Eyal and Sirer
cheetah2 has joined #bitcoin-wizards
cheetah2 has quit [Remote host closed the connection]
<bramc>
I don't understand the claim in that paper that 'under current conditions any size mining pool can effectively collude'
tripleslash_i has joined #bitcoin-wizards
tripleslash has quit [Ping timeout: 265 seconds]
JackH has quit [Ping timeout: 264 seconds]
Dizzle_ has joined #bitcoin-wizards
cheetah2 has quit [Remote host closed the connection]
cheetah2 has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
Dizzle_ has quit [Remote host closed the connection]
<AdrianG>
i think it just means there is nothing in the protocol that prevents collusion.
<alpalp>
Nor is there any way to identify it
<bramc>
A high orphan rate would be a red flag
AaronvanW has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
<coinoperated>
could be masked if colluders slowly ramped up orphan rate artificially ahead of collusion
<coinoperated>
but good catch
NewLiberty has quit [Ping timeout: 256 seconds]
Burrito has quit [Quit: Leaving]
cheetah2 has quit [Remote host closed the connection]
cheetah2 has joined #bitcoin-wizards
GGuyZ has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 250 seconds]
cheetah2 has quit [Remote host closed the connection]
cheetah2 has joined #bitcoin-wizards
p15 has joined #bitcoin-wizards
brg444 has quit [Quit: Page closed]
cheetah2 has quit [Remote host closed the connection]
cheetah2 has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
Yoghur114_2 has quit [Remote host closed the connection]
<bramc>
It would be highly ballsy to pull off a withholding attack in practice. If you had, say, 40% of mining power, you'd have to go a full cycle (actually a bit longer, because you slowed it down) earning 20% less than usual, to make 10% more on subsequent cycles, so you'd be talking six weeks from the start to make break-even, assuming that no big increases in hashpower happened in the interim
<bramc>
But if you think hash power will stay stable for the next 3 months or so and have 40% of hash power you can pull it off, assuming your margins are big enough to be able to handle a massive hit for a cycle.
Jeremy_Rand_2 has quit [Remote host closed the connection]
AaronvanW has quit [Ping timeout: 250 seconds]
cheetah2 has quit [Remote host closed the connection]
Jeremy_Rand_2 has joined #bitcoin-wizards
cheetah2 has joined #bitcoin-wizards
<CubicEarth>
phantomcircuit: "Weak blocks are useless under adversarial conditions." So are strong blocks
Newyorkadam has joined #bitcoin-wizards
brg444 has joined #bitcoin-wizards
cheetah2 has quit [Remote host closed the connection]
justanotheruser has quit [Ping timeout: 256 seconds]
<bramc>
Another pet peeve: Latin letters. What's wrong with english ones?
cheetah2 has joined #bitcoin-wizards
Cory has joined #bitcoin-wizards
<bramc>
Quick summary of the more sophisticated selfish mining papers: Very modest improvements are possible
<bramc>
The discussion of γ is not helpful. If you assume an attacker can notice when someone else is publishing a block and front-run they of course you're fucked
<bramc>
In practice there's the high speed relay network and the mining pools are probably directly connected to each other, so the value of it is close to 0
<kanzure>
why bother complaining about latin vs english letters when you could just insist on actual variable names? even relevant variable names.
bildramer has quit [Ping timeout: 245 seconds]
bildramer has joined #bitcoin-wizards
<bramc>
Hey man, the time it takes to type in variable names in papers is a big part of the time it takes to write them. Shaving off letters matters!
tripleslash has joined #bitcoin-wizards
tripleslash_i has quit [Ping timeout: 265 seconds]
cheetah2 has quit [Remote host closed the connection]
cheetah2 has joined #bitcoin-wizards
GGuyZ has quit [Quit: GGuyZ]
AaronvanW has joined #bitcoin-wizards
cheetah2 has quit [Remote host closed the connection]
fwefwefew has joined #bitcoin-wizards
fwefwefew has quit [Client Quit]
AaronvanW has quit [Ping timeout: 250 seconds]
wallet42 has joined #bitcoin-wizards
NLNico has joined #bitcoin-wizards
<bramc>
And of course the Majority is not Enough paper was already next up on my list of papers to read
TheSeven has quit [Ping timeout: 260 seconds]
TheSeven has joined #bitcoin-wizards
tulip has joined #bitcoin-wizards
<tulip>
bramc: I don't blame you for not noticing, but nobody actually keeps track of stale blocks.
<coinoperated>
if you are composing in LaTeX you aren't concerned about speed anyway
<bramc>
Since that's already been analyzed to death, next step for me is to analyze whether it really is beneficial to have one's blocks propagate more slowly. I suspect not, but the papers don't address that one directly and since the claim has been made that it is, so I should do a thorough analysis because I think that's wrong
<tulip>
in all probability nobody would catch the vast majority of attacks against the network.
<bramc>
tulip, That's unfortunate
<aj>
bramc: you mean greek letters, surely
<tulip>
bramc: I doubt anybody would care anyway.
<bramc>
aj, Is that what those are? Not cyrilic?
<bramc>
tulip, People wouldn't get concerned if there was a 20% orphan rate?
<tulip>
cyrillic shares some of the same characters as greek, but usually in papers it's going to be greek.
<tulip>
bramc: in 2013 a pool had an abysmal stale rate, nobody cared. people still happily mined with them.
<bramc>
*sigh*
<tulip>
miners still used the pool which admitted to Finney attacking!
<aj>
bramc: selfish mining with 40% hashpower (and without effective countermeasures) gives you ~100% of blocks though doesn't it?
<aj>
bramc: that's just \gamma isn't it?
<tulip>
ф Φ
<tulip>
^ spot the greek
<coinoperated>
you pointed to it
heyrhett has quit [Quit: Leaving]
<tulip>
the right is Greek phi, left is Cyrillic ef
<bramc>
aj: \gamma is a representation of how effective your front-running is, that is assuming that you have a setup where whenever a block is published you notice fast and spam yours out quick to beat it
<coinoperated>
and everyone else 100% orphans, i think they would get concerned pretty fast. wonder how long it would be written off as bad luck
<tulip>
coinoperated: a private pool mined *invalid* blocks for a week at several petahash.
<tulip>
nobody noticed.
<bramc>
Hey, here's an idea: Use weak block height as a tiebreak on near-equal time arrived sibling blocks
<petertodd>
bramc: not enforceable
<bramc>
petertodd, Neither is anything about picking between sibling blocks
<aj>
bramc: most work is enforcable
<petertodd>
bramc: indeed, now there may be a incentive there if you think it has propagated more widely, but that'sa very complex question
<coinoperated>
tulip, don't they have bills to pay? Or is the mine-to-market meme debunked now
<aj>
bramc: but weak blocks have the same height as the strong block that replaces them, so i don't see how that works?
royce has joined #bitcoin-wizards
<tulip>
right now I'm looking at the control interface of a private pool with a 5% stale rate.
<tulip>
nobody cares.
<aj>
bramc: maybe prefer the strong block whose weak block you saw first?
<bramc>
So the thing with \gamma is that if it's 100% then trivially selfish mining works, and making any assumptions about its value at all is presuming a fairly effective attack
<petertodd>
tulip: indeed, which means we need a system where lazy people like that pool don't end uppunishing others' for their lazyness
royce has quit [Quit: Leaving]
<petertodd>
bramc: fwiw, my conjunctor is that if selfish mining is possible through sybil, you're in a situation where you're fucked anyway
<bramc>
aj, The idea here is that you want to stop somebody from front-running, so what you do is say that if two blocks arrive within, say, 5 seconds of each other, and the second one is based off 2 weak blocks more than the first, then the second one wins. That would make there only be a narrow window in which you could even dream of having gamma
<tulip>
bramc: the latency of block transversal is far higher than that.
<bramc>
petertodd, That's my assumption as well, hence only being interested in \gamma = 0
<bramc>
tulip, One would hope that with weak blocks it wouldn't be
justanotheruser has joined #bitcoin-wizards
<aj>
bramc: weak blocks don't build on each other though... ?
<bramc>
aj, Of course they do
<bramc>
aj, Or rather, you could design it so they do or don't, but the approaches currently favored by most people in the know do
<aj>
bramc: hmm, maybe i'm behind then. i didn't think there was a directed cryptographic relationship between weak blocks?
<bramc>
aj, Each weak block uses a previous weak block as a form of compression, resulting in it itself being useful for later weak blocks
<bramc>
And also, as I just pointed out, a reasonable method of timestamping when some numnutz is trying to front-run previously withheld blocks
<aj>
what's the distribution for weak blocks with time? if it takes 2*n minutes to find a strong block, do you expect 2*k weak blocks, or k weak blocks?
<petertodd>
note that weak blocks is tech that disadvantages small miners... if you're sufficiently small, you don't have any opportunity to find weak blocsk, equally, if you're large, you don'tneed them
wallet42 has quit [Quit: Leaving.]
<tulip>
bramc: I think if you are hedging on weak blocks (or anything else) being the saviour of the network latency you'll probably end up disappointed.
<bramc>
petertodd, I'm assuming weak blocks are simply a form of compression, and are all about making latencies very low everywhere
<petertodd>
yeah, ifyou want to fix lnetwork latency, fix the underlying O(n^2) problem
zookolaptop has quit [Ping timeout: 265 seconds]
<petertodd>
bramc: yes, but this is one of those "if you need it, you're fucked"situations
justanotheruser has quit [Quit: Reconnecting]
justanot1eruser has joined #bitcoin-wizards
<tulip>
petertodd: arguably we're already in trouble if this behaviour is showing its head.
<petertodd>
tulip: yes, I think we are
pozitron has joined #bitcoin-wizards
<tulip>
well, I think we're in trouble from the perspective of everything quickly becoming unmanageable.
<bramc>
tulip, I disagree. With weak blocks it should be possible for the blocks themselves to be way under 1k of 'new' stuff to transport and the weak blocks themselves and be distributed in a slightly more leisurely way.
<tulip>
something interesting is that the rapid UTXO growth as stopped. I noticed that a while ago and still don't know what to make of it.
<coinoperated>
easy, just make Bitcoin only work in a geographic area the size of rhode island. I bet you could have as many TPS as you want, with no latency-based advantage attacks. dontations welcome
cheetah2 has joined #bitcoin-wizards
<bramc>
aj, Weak blocks should probably be some constant factor more common than strong blocks based on social convention. Probably 10x or 100x. I've tried to start discussion on here about what that factor should be but haven't been successful so far.
<petertodd>
bramc: _if_ everyone cooperates and everything works perfectly
<tulip>
bramc: there's probably room for taking p2pools share chain and using that as "weak blocks" today and seeing how it goes.
<bramc>
petertodd, Maybe I'm an optimist. I don't think it requires universal cooperation and the parts which have to work 'perfectly' are completely manageable.
<tulip>
the p2pool share chain is just a diff/20 Bitcoin blockchain pretty much.
<petertodd>
bramc: notice how if there's a bug in weak blocks that disables them temporarily, low bandwidth miners are fucked, yet high bandwidth ones don't care much
<bramc>
petertodd, Yes bugs suck and if there's a problem then small miners are stuck where they are today
<petertodd>
bramc: but today we have a blocksize limit low enough that everyone has access to reasonably low orphan rates
<petertodd>
bramc: (remember that the networking code we have right now on the p2p network is *really* inefficient)
<bramc>
I do think a conservative approach to using weak blocks for sibling selection makes sense, or at least enough sense to consider seriously
<coinoperated>
dumb non-wizard question: where to catch up on strong/weak block discussion? i.e. are strong blocks some sort of checkpointing mechanism etc. paper i should read?
<petertodd>
coinoperated: none that I know of
<tulip>
coinoperated: please never, ever use the term "checkpointing" in the context of consensus.
<bramc>
petertodd, And the blocksize limit is staying down there, by design
<petertodd>
bramc: what do you mean?
<bramc>
petertodd, The current 'plan of record' is for the block size to de facto go up by less than 2x with segwit and otherwise stay put, at least for now
<bramc>
For exactly that reason
<petertodd>
bramc: sure
Newyorkadam has quit [Quit: Newyorkadam]
<petertodd>
bramc: OTOH, I think that plan is kinda misleading, as it doesn't make clear thatwe have no reason to think further increases are possible (modulo fundemental tech improvements)
<bramc>
coinoperated, You aren't the first person to ask that. We've been assuming that the implications of weak blocks are 'obvious', which is, uh, probably a wrong assumption
<tulip>
petertodd: the problem is ultimately that there's the perception that the current network status is healthy.
<bramc>
petertodd, I'm with you there, but there are some... political problems
<petertodd>
tulip: well, from the point of view of circle and coinbase, it probably is reasonably healthy - they want different things from bitcoin than we do
<tulip>
petertodd: I don't see why they want a terrible paypal clone.
<petertodd>
tulip: remember that they're in a position where hearn's centralized checkpoint proposal wouldn't be a bad thing
<bramc>
petertodd, On the network protocol: People with blue hair keep bugging me to make a new peer protocol, which I could certainly do, but right now I'm working on things I find a lot more interesting
<tulip>
petertodd: it's paypal! but slower, has no consumer protection built in, it's difficult to work with, has no fungibility and no privacy. but hey, the name is cool!
<petertodd>
bramc: I'm very dubious about hiding problems, because it invites responses like jgarzik/gavin's recent medium post
<tulip>
bramc: to be fair the current P2P network does suck terribly. not as bad as the original creators design of it mind you.
<bramc>
petertodd, I wish I could successfully argue that a balloon payment on a mortgage was a 'new economic policy' and hence I shouldn't have to pay it.
<petertodd>
bramc: sure, yet, that argument does ring true in a certain way
<bramc>
tulip, It's a totally fair argument that it can be improved, and that I'm the most qualified to do it. It just hasn't bubbled up to the top of my list of things to do, in no small part because it doesn't sound like much fun.
<coinoperated>
bramc, not obvious to the semi informed at least. didn't know if the discussion was based on a paper where terms are defined. I can lurk and log up, extra clueless thx to spotty IRC attendance thanks to Santa Week
<tulip>
bramc: in the wxBitcoin implementation things got weird. it was designed to host other services like a marketplace, so most of the commands were to do with subscribing to receiving review and product information. some connections were direct TCP for making payments, playing games and things like that. there was no inventory messages so every message was flooded to every peer perhaps hundreds of times. the implementation of it had 100ms sleeps in
<tulip>
the networking loop as well.
<bramc>
Maybe I should do a post on weak blocks. I should learn exactly what p2pool's side chains do first though.
<bramc>
tulip, No blame being cast about the current state of the peer protocol. It's entirely to be expected.
<tulip>
p2pool isn't quite that. it's a blockchain that has a significantly lower difficulty, targeting 30 seconds. every now and then people will find a p2pool sharechain block which also happens to be difficult enough to be a Bitcoin network block, and that gets pushed onto the Bitcoin network. every block solved includes all the payments to other miners as an internal consensus rule.
<bramc>
That's very much like weak blocks, extra stuff added though and not quite as optimized for latency as it could be.
<tulip>
it has its strong and weak points, one problem is that the number of possible payments to make is limited. you really can't be a tiny miner on p2pool or you will get dust payments every block which you can never spend economically. here's a recent p2pool block paying out 300 people with a 10kb transaction. https://webbtc.com/tx/1564fb99bed0db4069a955092c4dd2f52209cf73304f0e1f0cde374c1778f6c4
<tulip>
for quite a while p2pool was the most efficient pool due to the way it pushes around blocks to other p2pool nodes using the sharechain. that might still be true to some degree now, I don't know. it's probably suffering a bit now due to being written in Python.
<CubicEarth>
tulip: Can it smoothly sample a single 5 TH/s miner?
<CubicEarth>
tulip: or would the variance still be very high?
<tulip>
CubicEarth: 5TH would be fine. variance really doesn't matter, you've just got to learn to ignore it.
<bramc>
For anyone curious about the selfish mining papers: The 'Optimal Selfish Mining Strategies in Bitcoin' paper takes the 'Mining is not Enough' paper and squeezes a little more blood from the stone. It also debunks the proposed improvement in the first paper.
<bramc>
The other related papers aren't very good
<CubicEarth>
tulip: Personally I agree about the variance, being good to ignore, but someone also mentioned recently (maybe it was ptodd) that variance is a real cosst of doing business, which I thought was interesting and I can see how that could be true
<bramc>
I'm a bit annoyed at jgarzik making an appeal to what Satoshi said about raising the block size limit, because (a) it doesn't matter what Satoshi thought, and (b) if Satoshi wanted that he wouldn't have made mining rewards fall exponentially over time
CubicEarth has quit [Remote host closed the connection]
<kanzure>
security is more important than market misexpectation
<coinoperated>
kanzure, thanks. IRC logs help but still jump in around mid november with some sort of definition already established. Weakly validated, weakly propagated, weakly confirmed, weakly understood :D
<bramc>
jgarzik, There are very real market expectations of the block size staying put
<petertodd>
bramc: +1
<petertodd>
equally, demanding devs say things about what tx fees willbe is unrealistic:we don't know, and can't know
<petertodd>
in a system that doesn't scale, there's absolutely nothing we can do to keep a lid on tx fees if demand goes up
<petertodd>
(well, we aqn centralize bitcoin, but thats not going to happen by this dev team)
funkenstein_ has quit [Quit: Leaving]
<jcorgan>
seems we're at a point where all that can be said, has been. we'll only learn more about "market expectations" and the motivations of everyone in this grand experiment by allowing things to play out
<petertodd>
jcorgan: yeah, I'm inclined to recommend that those who don't agree with the bitcoin core team's general direction leave and work on a competing project
<petertodd>
jcorgan: trying to change dev's minds with the types of arguments being used is silly
<petertodd>
jcorgan: people are talking past each other because what they want out of bitcoin is radically different (and/or their understanding of the technology is radically different)
<dgenr8>
petertodd: bitcoin doesn't have a dev team
<petertodd>
dgenr8: that'swhy I said "bitcoin core"
<bramc>
On my list of stuff to do now: essay on weak blocks, essay on the long term of bitcoin mining and transaction fees, make a concrete proposal for not valid after (ideally a BIP), make a new peer protocol, finish the merkle set data structure
<jcorgan>
is that all?
<bramc>
That's my *bitcoin* list of stuff to do
<dgenr8>
petertodd: miners have access to a 1MB orphan rate any time they like
<petertodd>
dgenr8: huh?
<dgenr8>
<petertodd> bramc: but today we have a blocksize limit low enough that everyone has access to reasonably low orphan rates
<petertodd>
dgenr8: your orphan rate is influenced by the blocksize *other* miners use
<kanzure>
and also asymmetries in the network bandwidth graph
<kanzure>
... for various definitions of network. and "your".
<bramc>
I got excited the other day about not-valid-after when I realized it's possible to hack it into the output, getting around the limitations in extending transactions. It will undoubtedly be ugly though, and I'll have to do some digging in low level details to figure it out
<kanzure>
propagation delay too
<petertodd>
dgenr8: or even more simple: if 90% of the hashing power has chosen a blocksize such that your bandwidht can'treceive those blocks in <10mins, you're gonna have a damn high orphan rate...
<jcorgan>
bramc: looking forward to reading your essays and proposal.
<brg444>
+1
<bramc>
jcorgan, Thanks for the encouragement. At the moment I'm stuck on the merkle set data structure, which I am going to get finished, dammit
<brg444>
jcorgan can you take care of the troll in #bitcoin ?
<dgenr8>
petertodd: it'd be good to try not to conflate bandwidth-challenged miners with low-hashpower miners. the first problem is orders of magnitude cheaper to fix
<petertodd>
bramc: sheesh, that code looks like crap, were you drunk while writing it?
<petertodd>
dgenr8: if you thnk that's easy to fix, you have fundementally different ideas about what bitcoin should be than I do, and further discussion is pointless
dcousens has left #bitcoin-wizards [#bitcoin-wizards]
<kanzure>
oops got the url wrong
<bramc>
petertodd, In all seriousness, it isn't even done as a first draft yet, although at least the documentation is getting a bit coherent. Maybe a few more days and I'll deem it not horribly embarrassing for other people to look at. It's going to be probably two weeks before it even has all the methods filled in as a first draft
<petertodd>
kanzure: oh weird, *that* one loads for me... and that letter to your wife is really sweet
<kanzure>
petertodd: i am disappointed in you- surely you have better info on me than that?
<jcorgan>
wtf
<petertodd>
bramc: what properties do you think you can get?
<bramc>
petertodd, Low L1 and L2 cache misses, fairly good memory compactness, lazy root evaluation, 'reasonable' defense against malicious data
<petertodd>
kanzure: well, I'm not going to reveal everything....
<petertodd>
bramc: so the crypto itself isn'tspecial? justthe efficiency?
<kanzure>
in an effort to not assume what bramc has seen or not seen, i should probably mention proofchains to him
<petertodd>
kanzure: oh yeah, I need to do a writeup for that...
<petertodd>
kanzure: although I may need to change the name for bullshit legal reasons :/
<kanzure>
that bad, huh?
<bramc>
petertodd, Also compact and simple proofs of inclusion and exclusion which can be generated fast. It's a sha256 patricia tree, similar to what maaku's done but with different proofs of inclusion and exclusion (I don't know how different because I don't know what he did for that)
<bramc>
kanzure, I don't know proofchains
<petertodd>
kanzure: yup - granted, my lawyer is cautious, but most are, so...
<bramc>
Or at least, I don't know them under that name
<kanzure>
petertodd: broadcast your hashed commitments now while you still have a tongue
<petertodd>
bramc: I've got a rustversion of that too IIRC, butthe legal status of that code is murky...
<kanzure>
damn i keep forgetting to link to the marshalling stuff. i always end up at the other unit tests and then confused why there seems to be nothing there (like in python-proofchains.git).
<bramc>
petertodd, I'm also doing all the memory management manually. Mine is meant to be highly performant but fairly pedestrian in terms of crypto and API. I'll look through yours as a reference. My main interest from other implementations is in how they do proofs of inclusion/exclusion. The patricia tree idea I got from maaku.
<petertodd>
kanzure: yeah, when I did the rust version I put both in the same repo :)
<petertodd>
bramc: I optimised for low probability of fuckups rather than performance :)
<petertodd>
bramc: there's a bunch of neat compressions that you can use on mine too that make the serialized size not as bad as ait looks at first glance
<bramc>
petertodd, Also my proofs of inclusion/exclusion are strongly canonical. Don't know if that matters for anything but it's possible and sounds good so I'm doing it.
<petertodd>
bramc: yes, my stuff is all canonical as well - 100% deterministic
<bramc>
petertodd, Mine is meant to be implementable very simply with low probability of fuckup as well if that's what you want to optimize for in implementation
<petertodd>
bramc: though my proofs of inclusion/exclusion are somewhat weird, as they're based on code that just determines theminimal set of data needed to prove a statement
<kanzure>
ha see not even you can figure out what to link to
<petertodd>
kanzure: they both started with m :)
<bramc>
Ah, this is the MerkleMountainRange stuff. What I'm doing is quite a bit dumber at the expense of not supporting as efficient merging of data sets
coinoperated has quit [Ping timeout: 256 seconds]
<kanzure>
but didn't you have something about efficient diff updating or something?
<bramc>
Oh I see, the apples-to-apples is with that last link
<petertodd>
bramc: see, one of my working assumptions, is that ifI can't implement it fast enough in python, my system doesn't scale well enough :)
<bramc>
kanzure, Yeah it does efficient updating but it always does it by shoving the data into the tree. You can in principle do better with batching things but... uh... we'd like to avoid that if it's possible.
<bramc>
petertodd, It may be that the Python implementation I'm doing will in the end be fairly performant, but it looks ridiculous with it being in Python and the intention is for it to be ported to C/C++
<petertodd>
bramc: fwiw, I'd suggest writing it in rust first actually! the struct types I found made it easier to be clar about what exactly is what
<bramc>
For what I'm doing now the language doesn't matter much, it's going to look like C regardless.
<petertodd>
bramc: well, what can I say, if you haven't already, try rust out
<bramc>
Like, my central data structure is a byte array called self.memory
brg444 has quit [Ping timeout: 252 seconds]
<petertodd>
ha
<bramc>
Not even slightly joking
<tulip>
petertodd: what would you like to see in a Bitcoin P2P network?
<petertodd>
tulip: O(1) scalability :P
<tulip>
petertodd: what would you like to see in a realistic Bitcoin P2P network?
<petertodd>
tulip: actually, make that O(0) scaling :P
<tulip>
I'm talking wire protocol.
<petertodd>
tulip: I genuinely think that if you need to optimize that stuff, something is wrong
<tulip>
do we need to optimise that stuff today?
<petertodd>
tulip: yes :)
<tulip>
thought so.
adam3us1 has joined #bitcoin-wizards
adam3us has quit [Read error: Connection reset by peer]
cheetah2 has quit [Remote host closed the connection]
cheetah2 has joined #bitcoin-wizards
justanot1eruser has quit [Ping timeout: 245 seconds]
cheetah2 has quit [Client Quit]
<bramc>
petertodd, A difference between your tree and mine: In yours if there's only stuff on one side the stuff below is collapsed in. In mine it's treated as a special case with there simply being stuff on only one side. I also don't hash in prefixes, because they're implicit
<bramc>
My reasons for doing this are (1) simplicity, and (2) it makes proofs of non-inclusion cleaner
vladzamfir has quit [Ping timeout: 252 seconds]
<petertodd>
bramc: collapsed in? what do you mean by that?
tripleslash has quit [Ping timeout: 246 seconds]
<bramc>
petertodd, Like, if you have a tree with exactly two things in it, they'll branch at the top level. In mine they branch n levels down, where n is the size of their shared prefix
tripleslash has joined #bitcoin-wizards
<bramc>
I'm also specifying whether the children are terminals in the parent, which sounds more complicated but actually makes implementation simpler
<bramc>
petertodd, You misspelled 'invarients'
<petertodd>
bramc: pull-reqs accepted :P
<kanzure>
coinoperated: for weak block stuff, check out the following-
<petertodd>
bramc: ah right, because in my version the philosophy is "since we have the prefix, below is everything under this prefix"
<petertodd>
(I have no concept of depth, kinda)
<petertodd>
(sorry, my internet is lagged all to hell irgh tnow)
<kanzure>
oops that's the same date. whoops.
<bramc>
petertodd, I waffled on exactly how to format it and concluded that what I'm doing now is simpler for reasons having to do with practical implementation details. They aren't meaningfully different semantics.
<kanzure>
am i forgetting anything for syncing bramc up? i regret not pointing out the selfish mining stuff to him...
<petertodd>
bramc: yeah, if there were, something would be wrong :)
<petertodd>
bramc: my version probably lets you share muore stuff between different versions in some cases, but that disn't necessarily good for l1/l2 caches
<bramc>
kanzure, Somebody had pointed out the selfish mining stuff to me because it was in my list of stuff to read, I just didn't realize that until I'd reinvented it today.
<kanzure>
yeah but i mean it would be more efficient if you were to focus on reinventing the stuff that isn't widely known, though
<kanzure>
okay i can't think of anything else for the moment, bbl
<bramc>
kanzure, No major harm done, I only spent part of today on it and now I understand it deeply and am more prepared to work through the details of the related question of whether you can benefit from your own blocks getting propagated slowly, which I don't think is handled directly anywhere in the literature
<petertodd>
bramc: note that my writeup only made the claim that getting your own blocks propagated slowly would hurt others more than it hurt you, in many cases
<kanzure>
"propagated slowly" is too ambiguous- there is a network bandwidth graph with lots of asymmetries in uplinks and downlinks. different bandwidth available in different locations. slowness is approximately the same thing as withholding in some cases. selectively choosing which parts of the network to send the data more quickly to... and er, something about cartel consensus building.
<kanzure>
also, big blocks can propagate more slowly on the wider network due to those bandwidth bottlenecks. but really it's the race to propagate to hashrate, not to the nodeso, so the nodes will (absent a limit) get squeezed out much more quickly.
<bramc>
petertodd, There's a subtle difference between hurting others more by proportionately or absolutely which may be the crux of the problem, but yes I know what you meant (well, one of those two anyway)
<bramc>
kanzure, Yes the meaning of 'propagate slowly' is something which needs to be nailed down in any discussion whether you can benefit from it.
<kanzure>
and more specifically, it's whether an adversary can benefit
<kanzure>
but you already know this so i'm not sure why i'm saying that
<petertodd>
bbl, sleep!
<kanzure>
same.
<bramc>
All you people without kids
<bramc>
Oh, and also not in the time zone desert of the west coast
<kanzure>
i am a child at heart, does that count
<bramc>
It's interesting what causes there to be large active developer communities. BitTorrent doesn't have one, because it does one thing and does it well, so there isn't a neverending supply of problems to work on. Web frameworks have lots of stuff to work on, because they do many things. Bitcoin has lots of stuff to work on, because although it only does one thing it does it so badly that you never have to worry about runnin
<bramc>
g out of things to fix.
<bramc>
The IBLT metrics in that IBLT/weakblocks presentation looks quite encouraging
<p15>
bittorrent has toolchain devs
<fluffypony>
I'd argue that BitTorrent is a protocol that can remain relatively stable and fixed, with only implementation weaknesses having to be fixed, whereas Bitcoin presents previously unknown challenges because of all the attack vectors against the consensus state
<bramc>
p15 True, but they're outside of core. People at my company do work on core stuff, but it's mostly humdrum maintenance which outside people would be unlikely to work on for fun.
<tulip>
BitTorrent also has the luxury of just making versions of the software which can speak multiple protocols for compatibility.
<bramc>
fluffypony, That's another way of putting it.
<bramc>
tulip, Well, we don't have to be quite as maniacal about avoiding hard forks, although for the most part we are anyway.
<tulip>
Bitcoin has remained remarkably backwards compatible, though I would hardly suggest anybody run anything older than 0.11 under any circumstances.
<tulip>
the P2P wire protocol is the main incompatibility.
<bramc>
The wire protocol incompatibility isn't so bad. The thing you can never, ever do is cause a utxo to no longer be valid, no matter how old and busted it is.
<tulip>
we do that with soft forks, it's the other way around that's a problem
copumpkin has quit [Ping timeout: 240 seconds]
<bramc>
The hong kong weak blocks presentation actually suggests a ration: 20x. So nice to see a number suggested by someone other than me. (I've been suggesting 10-100, which 20 is close to the middle of)
<tulip>
P2Pool has a 20x lower difficulty target too for what that's worth.
<tulip>
it used to be 10s, then was altered to 30s.
<bramc>
Sounds like another good data point
<tulip>
perhaps.
<tulip>
lots of things like this are dictated by other factors. for example, at one point in time a lot of the Bitcoin hardware couldn't flush the current work from their buffers quickly which made them produce ridiculous amounts of stale work.
<bramc>
That sounds like Their Problem
<bramc>
Interesting point in the weak blocks presentation: maybe you should accept weaker weak blocks when only a fraction of all mining power is using them. Maybe a good convention would be for peers to accept all weak blocks within some fraction of the strongest weak block they've seen in recent history
<bramc>
Maybe it would be good to be a bit more sophisticated than that in case some joker decides to make lots of weak blocks but throw out his 'good' weak blocks
sparetire_ has quit [Quit: sparetire_]
<bramc>
Also to make it less noisy
<tulip>
bramc: not really, that hardware and configuration performed a block withholding attack against p2pool.
<bramc>
Here's a formula: For each block, take the weakest weak block accepted, multiply by the number of weak blocks accepted for that block, and divide by 20. That's a reasonable threshold.
<bramc>
To prevent DoS set a maximum number of weak blocks you'll accept per block, say 100
NLNico has quit [Quit: Leaving]
<bramc>
although the number of weak blocks per strong block is extremely noisy due to strong block arrival being so noisy. Harumph.
<bramc>
Another post on weak blocks suggests their strength as 5%. Apparently the going rate is that there should be 20 weak blocks for every strong block.
c-cex-yuriy has quit [Quit: Connection closed for inactivity]
<bramc>
Another post on weak blocks suggests they should have a size limit. I don't like that idea at all.
dgenr8 has joined #bitcoin-wizards
<bramc>
Also I need to think through the important distinction between implicit links between weak blocks and weak references to sets of transactions, sets of transactions meant as deltas, and previous weak blocks
Ylbam has joined #bitcoin-wizards
silvaedium has quit [Ping timeout: 265 seconds]
<bramc>
Peter Todd suggests that weak references to upcoming transactions could be used to determine fees for getting things in quickly, which isn't an awful idea.
<bramc>
although I think it's only applicable in the narrow case where you really really want your transaction to go into the next block
<bramc>
A thought on selfish mining: it's particularly applicable when a miner happens to know that they've got more hash power coming online soon, so they can prime the pump for themselves
<bramc>
Okay, I'm done plowing through all the references about weak blocks. Good night everybody.
pozitron has quit [Ping timeout: 240 seconds]
c0rw|zZz has joined #bitcoin-wizards
c0rw|zZz_ has quit [Ping timeout: 240 seconds]
arowser has quit [Quit: No Ping reply in 180 seconds.]
arowser has joined #bitcoin-wizards
yosso has joined #bitcoin-wizards
ozanyurt has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
Logicwax has joined #bitcoin-wizards
nuke1989 has quit [Remote host closed the connection]
CubicEarth has joined #bitcoin-wizards
CubicEar_ has joined #bitcoin-wizards
CubicEarth has quit [Ping timeout: 245 seconds]
CubicEar_ has quit [Remote host closed the connection]
CubicEarth has joined #bitcoin-wizards
CubicEarth has quit [Remote host closed the connection]
LeMiner2 has joined #bitcoin-wizards
CubicEarth has joined #bitcoin-wizards
LeMiner has quit [Ping timeout: 246 seconds]
LeMiner2 is now known as LeMiner
CubicEarth has quit [Remote host closed the connection]
JackH has joined #bitcoin-wizards
CubicEarth has joined #bitcoin-wizards
CubicEarth has quit [Remote host closed the connection]
kmels has quit [Ping timeout: 245 seconds]
tripleslash has quit [Ping timeout: 260 seconds]
tripleslash has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
bramc has quit [Quit: This computer has gone to sleep]
adam3us1 has quit [Quit: Leaving.]
adam3us has joined #bitcoin-wizards
CubicEarth has joined #bitcoin-wizards
p15_ has joined #bitcoin-wizards
Guyver2 has quit [Ping timeout: 245 seconds]
p15 has quit [Ping timeout: 272 seconds]
arowser has quit [Ping timeout: 260 seconds]
arowser has joined #bitcoin-wizards
eudoxia has joined #bitcoin-wizards
Piper-Off is now known as Monthrect
stevenroose_ has joined #bitcoin-wizards
yosso has quit [Ping timeout: 250 seconds]
pozitrono has joined #bitcoin-wizards
AaronvanW_ has joined #bitcoin-wizards
AaronvanW_ has quit [Remote host closed the connection]
AaronvanW has quit [Ping timeout: 260 seconds]
<CubicEarth>
That's why I think we need some general
<CubicEarth>
consensus rules which is not written in code, but as a social contract.
<CubicEarth>
jl2012: You are absolutly correct on this point
<CubicEarth>
That's was jl2012's quote
dEBRUYNE has joined #bitcoin-wizards
arowser has quit [Ping timeout: 256 seconds]
arowser has joined #bitcoin-wizards
<jl2012>
CubicEarth, for example, a black list system is a softfork technically, but is a hardfork as social contract
adam3us has quit [Quit: Leaving.]
adam3us has joined #bitcoin-wizards
adam3us has quit [Client Quit]
<CubicEarth>
jl2012: Yes. And presumably there are ideals & goals that the contract could lay out, even if they would be imperfect in any real-world implementation
<CubicEarth>
I raised this idea myself a few weeks ago on this channel, and there was serious opposition to the idea. I still think it is needed though.
eudoxia has quit [Quit: Leaving]
TBI_ has quit [Read error: Connection reset by peer]
dEBRUYNE has quit [Ping timeout: 256 seconds]
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Changing host]
AaronvanW has joined #bitcoin-wizards
CubicEarth has quit [Remote host closed the connection]
copumpkin has joined #bitcoin-wizards
JackH has quit [Ping timeout: 265 seconds]
JackH has joined #bitcoin-wizards
tulip has joined #bitcoin-wizards
tulip has quit [Client Quit]
p15_ has quit [Ping timeout: 276 seconds]
davec has quit [Read error: Connection reset by peer]
davec has joined #bitcoin-wizards
<kanzure>
00:39 < bramc> Another post on weak blocks suggests they should have a size limit. I don't like that idea at all.
<kanzure>
size limit is necessary because weak blocks can only provide a constant factor improvement compared to strong blocks ....
dEBRUYNE has joined #bitcoin-wizards
zookolaptop has joined #bitcoin-wizards
alpalp has quit [Ping timeout: 240 seconds]
dEBRUYNE has quit [Ping timeout: 265 seconds]
qadaemon has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<amiller>
is it possible to soft fork to increase the 21m coin cap? what would that even mean?
<amiller>
the obvious answer is "of course not"... but generalized soft-forks seem pretty broad so i'm not actually sure where the boundary is
dEBRUYNE has joined #bitcoin-wizards
<kanzure>
do you consider double-spends to increase the cap? :-)
<amiller>
maybe!
<maaku>
amiller: absolutely yes
<maaku>
the 'generalized soft-fork' (aka evil fork) lets you arbitrarily change the consensus rules
Yoghur114_2 has joined #bitcoin-wizards
<kanzure>
we should publicly document the soft-hard fork idea
<kanzure>
which was iirc the super-evil variant of the evil soft-fork idea
<amiller>
i'm not clear at all on the boundaries of the ideas referred to by these names
<amiller>
is an "evil fork" specifically when miners convince everyone to start using anyonecanspend because they commit to a nice new policy, but then they actually just take all the coins?
<kanzure>
22:30 < gmaxwell> which is this idea we were calling evil forks at the time, and were intentionally not proposing (though they've since been independantly invented twice so I don't see any point in being quiet about them now)
<kanzure>
22:30 < gmaxwell> which is that you can basically build a soft fork which makes a hardfork extension via an extension block but denies all other transactions.
<kanzure>
22:31 < gmaxwell> which sort of highlights why at least at the limits softforks are bad too.
<amiller>
ok so i guess the "evil" part is that it supresses all other transactions
<amiller>
i dunno, it seems like double-counting in a way
<kanzure>
i think it's ;;seen
<amiller>
if soft-fork is defined by what old, un-upgraded nodes expect,
<amiller>
then suppressing transactions from old nodes should count as 'hard'
<amiller>
;;seen
<gribble>
(seen [<channel>] <nick>) -- Returns the last time <nick> was seen and what <nick> was last seen saying. <channel> is only necessary if the message isn't sent on the channel itself. <nick> may contain * as a wildcard.
<amiller>
;;seen gmaxwell
<gribble>
gmaxwell was last seen in #bitcoin-wizards 2 weeks, 2 days, 7 hours, 58 minutes, and 33 seconds ago: <gmaxwell> yea, and 10 layers is a lot, if you're assuming 16 layers of "common data"
<amiller>
likewise you can argue it's impossible to soft-fork to more than 21M because there's no way to convince old un-upgraded nodes to see more than 21M coins
<kanzure>
evil fork requires an extension block commitment, the evil part is that the soft-fork provides a consensus rule that the only transactions in the new block version blocks are extension block commitments and transfers into the extension block
<amiller>
maybe a better definition of soft-fork is about what kinds of service are guaranteed to legacy nodes
<amiller>
for example, receiving finalized payments is a service (and that seems to be what most people have in mind when saying soft-fork)
<amiller>
increasing max block size would cause old nodes to be on a diverged chain where they're easily double-spent so that's why it's a soft-fork
<amiller>
but as another example, some kinds of apparently-softfork policies break some kinds of legacy service, such as having pre-signed transactions
<kanzure>
hmm actually i am not sure about the details of soft-hard forks
<amiller>
like where you make a "cold-wallet recovery" transaction with a reasonable fee and throw away the key
<amiller>
a change that requires higher fees, or stops eventually prioritizing old txouts, sort of spoils that reasonably expected service
tripleslash has quit [Remote host closed the connection]
ElmerFunk has quit [Remote host closed the connection]
<kanzure>
instagibbs: i agree that we have been slacking on assembling a hard-fork wishlist
<instagibbs>
Open question to all: What are the things we should get around to including to Bitcoin if/when we hardfork? This can include cleanups of Segwit, for example, no-brainers, as well as possibly controversial or unfinished ideas.
<instagibbs>
Bonus points for what the challenges to doing it are, if any.
* Taek
suffocates under the high-signal scrollback
<Taek>
<vladzamfir> paul, do you agree that we have a bigger design space, in security-deposit-based PoS than you do in PoW?
eightbitcoder has joined #bitcoin-wizards
<Taek>
I would argue that a bigger design space is not a good thing, at least, not when it's a less-well-understood design space
<Taek>
means there's more surface area for you to miss something that attackers can take advantage of later
<Taek>
as we're seeing with Bitcoin, even the simple idea behind Bitcoin has a lot of hidden nooks and cranines
MrHodl has joined #bitcoin-wizards
<Taek>
.tell bramc I was (independently, believe it or not) working on a closed form solution to selfish mining all day yesterday. I am quite close, have code and everything to produce results
<yoleaux>
Taek: I'll pass your message to bramc.
<Taek>
petertodd: my calculations are actually even more pessimistic than 29% - you missed some optimizations where miners who find 2 blocks before the network finds any can pusure longer private-chains that result in even more orphans for the network, at no risk
<Taek>
.tell bramc I've also got a proposal to make selfish mining significantly harder. Hoping to have something done in a few days. Would be interested in collaborating on a paper if you've got time
<yoleaux>
Taek: I'll pass your message to bramc.
<tromp>
instagibbs: undo relegation of what should be header fields (like extranonce) into coinbase
bsm117532 has joined #bitcoin-wizards
coinoperated has joined #bitcoin-wizards
dEBRUYNE has quit [Read error: Connection reset by peer]
<kanzure>
petertodd: sounds like you are going to be sending an email about a variant of forced soft-forks. is that going to happen soon? i'm trying to decide when to send an email with a handful of links collecting related topics.
dEBRUYNE has joined #bitcoin-wizards
dEBRUYNE_ has joined #bitcoin-wizards
dEBRUYNE__ has joined #bitcoin-wizards
dEBRUYNE has quit [Ping timeout: 265 seconds]
ElmerFunk has joined #bitcoin-wizards
dEBRUYNE_ has quit [Ping timeout: 250 seconds]
<coinoperated>
kanzure, you should start a list of all these links somewhere. perhaps categorized by topic hierarchy. you could give it a catchy name to make it hip with all the kids, something like "woo hoo"
dEBRUYNE__ has quit [Read error: Connection reset by peer]
dEBRUYNE__ has joined #bitcoin-wizards
supasonic has joined #bitcoin-wizards
<bsm117532>
BTW if anyone is interested, we're looking for people to host future Whitepaper Wednesday journal-club events. I'd really like to have one about ECC encryption, curves, and signatures. I was just reading about Ed225519. Message me privately if you'd like to lead a discussion in NYC, we will host.
paveljanik has joined #bitcoin-wizards
ElmerFunk has joined #bitcoin-wizards
ElmerFunk has quit [Remote host closed the connection]
frankenmint has joined #bitcoin-wizards
kmels has joined #bitcoin-wizards
brianhoffman has joined #bitcoin-wizards
<amiller>
Taek, yoleaux, bramc, selfish mining is not even the optimal attack
<amiller>
you should make sure that whatever defense you make for selfish mining doesn't open up other attacks
<kanzure>
bram has seen your first link, dunno about the second
dEBRUYNE__ has quit [Ping timeout: 256 seconds]
<coinoperated>
bsm117532, thx. 8333.info useful on phone
Guyver2 has joined #bitcoin-wizards
frankenm_ has joined #bitcoin-wizards
<JackH>
is enigma on github yet
AaronvanW has quit [Ping timeout: 250 seconds]
frankenmint has quit [Ping timeout: 260 seconds]
jcorgan is now known as jcorgan|away
AaronvanW has joined #bitcoin-wizards
frankenmint has joined #bitcoin-wizards
frankenm_ has quit [Ping timeout: 255 seconds]
CubicEarth has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 250 seconds]
AaronvanW has joined #bitcoin-wizards
RedEmerald has quit [Changing host]
RedEmerald has joined #bitcoin-wizards
<bsm117532>
JackH: Not as far as I know, they haven't released code.
AaronvanW has quit [Ping timeout: 250 seconds]
<instagibbs>
amiller, your title is catchier, so i remembered it :)
bramc has joined #bitcoin-wizards
bramc has quit [Client Quit]
dEBRUYNE__ has joined #bitcoin-wizards
jannes has quit [Ping timeout: 276 seconds]
pavel_ has joined #bitcoin-wizards
pavel_ has quit [Remote host closed the connection]
<Taek>
amiller: I chose to ignore combinations of attacks. There are a significant handful of things you could combine to produce some pretty nasty results.
<Taek>
amiller: the solution is to tag 'late' blocks and require that they get more confirmations before switching to mining on them. I don't think there's any clear way to abuse it, because it requires having a block that is late in the first place
<Taek>
Under my proposal, a block would be considered 'late' if it appears >120 seconds after another block with the same parent
<Taek>
I'm not done with the solution, but it appears to bump the required hashrate for selfish mining from ~28% to ~42%, which imho is very significant
<bsm117532>
Sounds like it opens an attack which is Sybil + delayed relaying.
paveljanik has quit [Ping timeout: 255 seconds]
wallet42 has joined #bitcoin-wizards
Guyver2 has quit [Ping timeout: 245 seconds]
<Taek>
bsm117532: it's expensive to reveal a late block. If you are announcing a block late, it means that it's already got a substantially reduced chance of winning a race, because by necessity there's already another block that's had at least 120 seconds to propagate
<Taek>
*by definition
<bsm117532>
I'm saying the attacker's nodes delay the relay. The miner announces promptly.
Guyver2 has joined #bitcoin-wizards
<Taek>
I believe that's similar to the eclispse attack, and is not exacerbated by miners tagging 'late' blocks. An attacker who is performing succesful delayed relaying is going to have more powerful attacks available than those enabled by late blocks
<Taek>
I will try to have a more formal explanation ready today or tomorrow, but I do believe that all types of attacks which might leverage late blocks already have more powerful options available to them
<bsm117532>
Yes you'd have to achieve an eclipse attack essentially, so that your delayed relay is presented first to a victim's node.
sparetire_ has joined #bitcoin-wizards
<Taek>
right, and by the time you've achieved an eclipse attack the range of options available to you are much more diabolical than anything you can leverage out of the late block specifically - I do need to read the rest of the stubborn mining paper though
Guyver2 has quit [Read error: Connection reset by peer]
Guyver2 has joined #bitcoin-wizards
psztorc has joined #bitcoin-wizards
<psztorc>
Hello everyone, what remains to be done for the 'canonical assembly of blocks', so as to make best use of the IBLT propagation idea?
<psztorc>
I know that Kristov Atlas did part of this -the inputs and output ordering- for a privacy reason.
laurentmt has joined #bitcoin-wizards
brg444 has quit [Ping timeout: 252 seconds]
laurentmt has quit [Client Quit]
<psztorc>
I thought that that was within each transaction, though. Not across all transactions in a block.
paveljanik has joined #bitcoin-wizards
<kanzure>
psztorc: i'm confused what you are asking about. which IBLT things have you seen lately? then maybe i can fill in some gaps if any.
bitdevsnyc has joined #bitcoin-wizards
<gavinandresen>
psztorc: you mean canonical ordering of transactions? As far as I know, nobody is working on that. Easiest (but not fastest) implementation would be a sorting pass at the end of CreateNewBlock()
<psztorc>
gavinandresen: yes that's what I meant
<psztorc>
That is the last piece, after which IBLT will work better, it seems?
<bsm117532>
Maybe better to keep the mempool sorted?
<kanzure>
bramc was doing some canonical ordering regarding utxo merkle set stuff
<kanzure>
mempool sorting was recently recommended to be in a fee per byte ordering, i think this was mentioned on the mailing list(?)
<kanzure>
search for fee-for-byte in that log file
<psztorc>
It would allow SPV clients to learn about the fees accepted by miners, specifically the marginally-acceptable fee (min fee/kb).
<psztorc>
Well, that's why I asked, because it seems that the sort would be arbitrary. But this would actually allow it to be useful.
<instagibbs>
im not seeing how an SPV client would know feerate unless it had access to previous transactions. possibly overthinking
<psztorc>
Because you can just see how many times you've gone 'left' (or whatever) in the merkle tree. If you go all the way left you get the coinbase, which reveals total fees. You have total tx quantity from the header.
<psztorc>
While you're already all left, you might as well pick up the 'most barely acceptable transaction'.
<psztorc>
You now know the average fee, and the least-acceptable fee, for a given block.
<gavinandresen>
I asked Mike if sorting by fee would be useful to SPV clients, he was skeptical. Too complicated ... your high-fee transaction might happen to get sorted to the right of the merkle tree because it depends on transactions earlier in the block
<psztorc>
Then you can query other things.
<dgenr8>
mempool is now sorted multiple ways, and more indexes could easily be added
<instagibbs>
psztorc, true the spv client could just ask for that min transaction
jcorgan|away is now known as jcorgan
<psztorc>
gavinandresen: It seems strange that the order would matter for something that happens at the same time, does that really matter?
<instagibbs>
psztorc, that's how it's coded now
<psztorc>
Yes, the difference is that the SPV client can *know* that it got the min transaction.
<instagibbs>
you linearly scan transactions for validity
<psztorc>
I see, thanks.
Yoghur114_2 has quit [Remote host closed the connection]
Newyorkadam has joined #bitcoin-wizards
<psztorc>
Still, I think it is worth it, because it would be hard to game this system when SPV clients can just start sampling randomly in the left half of the tree to learn about the distribution of fees there.
<instagibbs>
random sampling certainly makes more sense
<psztorc>
Pretty safe way to automate fee-minimization, I think.
<instagibbs>
you can take that number as a seed then do whatever else you want. Lowball to see if miners would include anyways and to discourage lying, etc.
<psztorc>
I mean, just by going left to the coinbase, you have the average, and the min, which are the two most ideal fee-parameters.
<psztorc>
I saw bram's thing, I thought it was good. But did he discuss 'how users become aware of fees'? I thought not.
<instagibbs>
psztorc, like gavinandresen said, miners may game this or include really low stuff to pay for higher stuff
<instagibbs>
hence random sampling
<gavinandresen>
... better/simpler to commit to fees as part of the segwitness data.
<psztorc>
Well I would want them to random sample something that was sorted, so they'd always be 'lower than average' but 'was accepted by a block'.
<psztorc>
Both of those true.
<psztorc>
This would safely glide fees down.
<psztorc>
Otherwise it is just 'average fee' (which you can already get with division).
<psztorc>
- some random number.
<psztorc>
Fee(block) = average_fee - alpha
<psztorc>
which I don't like.
<psztorc>
(By 'random number' I meant a disparaging 'arbitrary static parameter').
CubicEarth has quit [Remote host closed the connection]
<psztorc>
I suppose, with pure random sampling, you can do something similar, by simply sampling and then taking the 25% percentile. This takes much more samples but I guess it doesn't really matter.
brg444 has joined #bitcoin-wizards
<instagibbs>
I'd want to plot a feerate curve anyways, heh
<psztorc>
I won't deny that this is partially out of a arbitrary and emotional desire to see The Supply Curve in the blocks themselves.
Yoghur114_2 has joined #bitcoin-wizards
<psztorc>
[14:59] <instagibbs> psztorc, like gavinandresen said, miners may game this or include really low stuff to pay for higher stuff
wallet42 has quit [Ping timeout: 256 seconds]
<psztorc>
Are you talking about the way it is done now?
<psztorc>
Because the way it is done now, the miner can stuff the block with a high n of high fee transactions to make it look like fees are high.
pozitron has joined #bitcoin-wizards
<psztorc>
This would trick people who don't sample enough, whereas sampling from the lower half of fee-per-kb sort would always work, even with only 3 or 4 samples.
<psztorc>
In fact, if miners include >50% of transactions as high fee to themselves, this produces different effects in each sort: the traditional way, each sample is likely to be high fee, but in the supply curve lower half way, each sample is likely to be not-from-a-miner.
c-cex-yuriy has joined #bitcoin-wizards
<instagibbs>
We are on the same page.
bitdevsn_ has joined #bitcoin-wizards
bitdevsnyc has quit [Ping timeout: 255 seconds]
dEBRUYNE__ has quit [Ping timeout: 250 seconds]
<psztorc>
Ok, how's this idea: they are all sorted by fee-per-kb, but if anyone double-transacts within a block, these go directly to the right of their parent.
<psztorc>
Optionally, force any such children to have the exact same fee/kb as their parents, but I don't think that's required.
RoboTeddy has quit []
<psztorc>
The result is all of the benefits of both, the supply curve is just distorted by these, but if you sample from the lower half, it can only be gamed to make it look as though transactions are much lower.
<psztorc>
Which is not what miners would want.
<psztorc>
Oh wait, I don't think that's right...
<psztorc>
Just put in on high-fee transaction and then a long sequence of low-fees, to crowd the right side.
<psztorc>
Oops.
<psztorc>
I'll think about it some more I guess.
<dgenr8>
psztorc: an index that includes only child fee, but all parent sizes, in the calc is suitably punishing to dependencies
<psztorc>
Ah yes, it interacts with child-pays-for-parent, very logical.
<psztorc>
But the spv client probably can't tell which transactions are part of (?) single-block families (or whatever).
<psztorc>
So I would get my supply curve but not really be able to use it for anything.
<psztorc>
Unless there were extra stuff to flag tx-families.
<dgenr8>
i'm actually working on that. not sure when it might get into a release of some codebsae or other
<psztorc>
Cool.
<psztorc>
Well that should be good enough, right, each user can get a "lower-than-average, but acceptable" value, then you just slowly increase this "bid" until a miner includes it.
<dgenr8>
let's go to #bitcoin-dev
<dgenr8>
psztorc: i'm not totally sure what you're doing. looking for historical fee data (per block?) or currently-being assembled estimates
se3000 has joined #bitcoin-wizards
dEBRUYNE has joined #bitcoin-wizards
Myagui has quit [Ping timeout: 260 seconds]
Myagui has joined #bitcoin-wizards
Yoghur114_2 has quit [Ping timeout: 240 seconds]
MrHodl has quit [Ping timeout: 240 seconds]
bitdevsnyc has joined #bitcoin-wizards
Yoghur114_2 has joined #bitcoin-wizards
bitdevsn_ has quit [Ping timeout: 255 seconds]
JayDugger has quit [Ping timeout: 276 seconds]
frankenmint has quit [Remote host closed the connection]
rustyn has quit [Read error: Connection reset by peer]
rustyn has joined #bitcoin-wizards
psztorc has quit [Ping timeout: 252 seconds]
CubicEarth has joined #bitcoin-wizards
eudoxia has joined #bitcoin-wizards
frankenmint has joined #bitcoin-wizards
phy1729 has quit [Changing host]
phy1729 has joined #bitcoin-wizards
bitdevsnyc has quit []
pozitron has quit [Ping timeout: 260 seconds]
<Taek>
I think gmaxwell has discussed similar things in the past, but it would be cool to have an OP_REQUIRE which mandated that a certain transaction or set of transactions appeared in the blockchain in order for your txn to be valid. If preconsensus becomes strong enough, you could commit to clusters of transactions with a single hash, and then if each of those txns contained their own OP_REQUIRE codes, you'd end up with an entire chain of valid
<Taek>
transacions which work together to fight censorship
<Taek>
I was thinking about this because I've become more aware of the fact that miners are untrusted entities
<Taek>
nobody chooses them, and nobody controls their behavior, except by incentives which they may have regulatory reason to ignore
<Taek>
I though an OP_REQUIRE might make a dent in their power by having everything depend on everything else in a way that makes it very difficult for miners to ignore indivual transactions - in doing so you end up needing to ignore entire clusters
qadaemon has quit [Ping timeout: 240 seconds]
<instagibbs>
so basically the relationship is quite like using utxos, but not consuming them? Trying to reason about pitfalls.
<Taek>
yeah. You end up with parent transactions that are really only spiritual
GGuyZ has quit [Quit: GGuyZ]
<instagibbs>
like a spirit animal, nice
amiller has quit [Ping timeout: 260 seconds]
psztorc has joined #bitcoin-wizards
bramc has joined #bitcoin-wizards
<bramc>
I saw Taek sent messages for me via gribble in the log but gribble didn't send them
<yoleaux>
16:40Z <Taek> bramc: I was (independently, believe it or not) working on a closed form solution to selfish mining all day yesterday. I am quite close, have code and everything to produce results
<yoleaux>
16:42Z <Taek> bramc: I've also got a proposal to make selfish mining significantly harder. Hoping to have something done in a few days. Would be interested in collaborating on a paper if you've got time
<Taek>
yoleaux doesn't print the messages until you speak, I'm not sure if there's a more preferable way to do it
Guest7736 has joined #bitcoin-wizards
<bsm117532>
What's this solution to selfish mining?
GGuyZ has joined #bitcoin-wizards
<bramc>
Taek, What I did yesterday was mostly reinvent what's in the Mining is not Enough paper, but I'm curious what your idea is for a countermeasure
<bramc>
(the countermeasure suggested in that paper is busted, which you probably already knew)
<Taek>
bramc: my proposal is to mark blocks as 'late' if they appear more than 120 seconds after a block with the same parent. Chains built on top of late blocks need to be 2 blocks ahead instead of the usual 1 block ahead to be accepted as the longest chain
<Taek>
the reasoning is that there's no honest situation in which a block is going to appear 120 seconds behind a sibling block. Any honest miner would have stopped mining on the parent long before that
<bramc>
Taek, Peers are free to do that based on their own local info although gossip info about lateness is of course not to be trusted
adam3us has joined #bitcoin-wizards
_whitelogger has quit [Ping timeout: 240 seconds]
_whitelogger has joined #bitcoin-wizards
<phantomcircuit>
Taek, it's difficult to delay propagation of blocks to specific recipients, but easy to delay to most of the network
<Taek>
though I'm not convinced that you don't open up other, bigger problems
CubicEarth has joined #bitcoin-wizards
<bsm117532>
Taek: yes. I'm trying to make the cost of producing a sibling zero.
<phantomcircuit>
obviously im not going to describe how to do this, which is going to make it harder for you to think up countermeasures :P
<Taek>
bsm117532: that's also bad though, you need incentives to keep the network moving forward. Someone who is mining on a late block should have some sort of penalty.
<bsm117532>
Taek: That is present in my incentive formula.
<Taek>
phantomcircuit: does it involve network code, or does it involve speficially constructed blocks? I don't need to know more than that for what I'm working on right now
<bsm117532>
I'm very wary of "solving" this problem with arbitrary timing heuristics and band-aids, rather than pursuing a more fundamental solution, as this is a fundamental problem due to physics and a linked list being an over-simplified data structure.
<bramc>
bsm117532 Trying to give people credit for orphan blocks and trying to penalize people for mining old blocks seem to be directly contradictory goals
<phantomcircuit>
Taek, the former
<Taek>
bsm117532: changing the fundamentals is opening a whole new can of worms. The fundamentals as they exist are pretty well understood, if not pretty. I, and likely most of the bitcoin-core developers, would be slow to switch to any paradigm that changes the 6-year-proven blockchain. Kind of how cryptographers don't accept a new signature algorithm until the paradigms are very well explored
<bsm117532>
bramc: With a graph structure you have more power. The former is a "sibling", the latter is measured using the "cohort". For very small graphs they're the same, but for larger graphs they're not.
<bsm117532>
Taek: I'm well aware of opening a can of worms and it will take time to prove. But let's just keep in mind that the true solution is allowing parallel blocks, and not invent heuristics in the meantime which make a better solution difficult or impossible.
<bsm117532>
(I'm not saying don't invent heuristics, just don't invent heuristics which make a better solution impossible) ;-)
<bramc>
bsm117532 There's also the question of which side wins in terms of its transactions going through, especially when fees are all transaction fees and not mining rewards, so a shorter blockchain may have better rewards
<psztorc>
What exactly are you trying to accomplish with this crusade against selfish mining?
<bramc>
psztorc, Selfish mining is a very real threat to the network as a whole, it could cause massive pooling and reorgs if it started happening at scale
<psztorc>
A linear relationship between hashrate and revenue?
<Taek>
psztorc: a variety of adversarial mining behaviors make it possible to impact competitor profitability with less than 30% of the hashrate. If you are doing multiple attacks at the same time, you don't need much hashrate at all
<psztorc>
Imagine that all of mining ends up in two pools, each with 50% of the hashrate.
<psztorc>
Should they selfish mine, yes or no?
<psztorc>
Assume they are risk averse.
<bsm117532>
The larger goal is the decentralization of mining.
<Taek>
as long as only one participates in selfish mining, that one will be able to increase their revenue substantially
<psztorc>
So, you would say "yes"?
<psztorc>
Both should selfish mine?
<Taek>
I'm not sure what would happen if both started selfish mining
<Taek>
but if a new miner appeared with 5% hashrate, it wouldn't be able to engage in selfish mining, and would be driven off
<psztorc>
Imagine you are in one pool, and you are selfish mining.
<bsm117532>
psztorc: The incentives of the bitcoin system are not currently compatible with correct operation of the system. It's a rather fundamental problem to solve.
<psztorc>
We'll see.
<psztorc>
You are in a 50% pool which is selfish mining.
<psztorc>
You have found two blocks against the latest public chain so far.
<psztorc>
What should you do?
<Taek>
It's extremely important to me that a 1% miner can have, in adversarial conditions, as much profitability as a rational, selfish, stubborn, etc. miner with 33% hashrate and a whole boatload of resources to dedicate towards network based optimizations and attacks
<psztorc>
I intend to demonstrate that he can, Taek, if you would answer my questions.
<Taek>
ok
<bsm117532>
psztorc: Are you going to argue that everyone should selfish mine, and that solves the problem?
<Taek>
what do you mean by 'against the latest public chain'?
<psztorc>
I am going to argue that anyone *has the option* to selfish mine, which, eventually, solves the problem.
<bsm117532>
psztorc: Only at the expense of network speed.
<Taek>
psztorc: the problem there is that you can't profitably engage in selfish mining until you hit 29% hashrate. Smaller miners don't have selfish mining as an option available to them, and the more hashrate you have the more effective your selfish mining is
<psztorc>
Forgive me, but does the phrase "off path reasoning" mean anything to you?
<bsm117532>
psztorc: If everyone selfish mines, the orphan rate goes way up, and the network is way slower.
<psztorc>
Ah, I thought not.
<psztorc>
Anyway, back to Taek.
<bramc>
psztorc, If a selfish miner gets ahead by two block they generally continue to hold onto and build their local chain and if the public network gets within one they publish the entirety of their private chain thus eclipsing the public network
<psztorc>
By 'latest public chain' I mean that there is a publicly known block to everyone, call it the genesis block for all I care. Everyone has it at t=0.
<bramc>
bsm117532 The interactions between two selfish miners and the rest of the network are... interesting. I don't think that's been evaluated properly.
<psztorc>
Does that make sense? It is just the starting block.
<bsm117532>
bramc: I'd rather fix the problem than analyze this broken incentive system...
<Taek>
psztorc: If I am a miner with 50% hashrate, and the latest public chain is 2 blocks behind my private chain, I don't publish until the latest public chain is within 1 block of my private chain
<psztorc>
Ok, now imagine you've found a third block. Still no word from the other mining pool.
<psztorc>
And remember I said to assume the miners are risk averse because they are.
<Taek>
If I know that I've got even slightly more hashrate, it won't bother me
<Taek>
the longer I don't hear from them, the further my own lead
<psztorc>
You have exactly the same hashrate.
<psztorc>
As far as you know, anyway.
<psztorc>
Maybe you think you secretly have more, but, then, maybe the other pool is tricking you.
<Taek>
in that case I'm not sure what the optimal strategy would be, but selfish mining by both parties would cause a divergent network
Alanius has quit [Ping timeout: 255 seconds]
<Taek>
at some point I'd publish, just to get the rest of the nodes to where I am
<Taek>
maybe every 6 blocks or so
<bramc>
bsm117532 It seems your system, assuming it works, is very all or nothing: A simplified scheme which only allows siblings to be joined makes the problem worse
<psztorc>
There we go....
<Taek>
psztorc: ok, but what is the point?
<Taek>
it's a highly contrived example which doesn't generalize to how mining works in the full ecosystem
<psztorc>
Last point: assume that you have the ability, somehow, to learn how many blocks the other pool has.
binary01 has joined #bitcoin-wizards
<bsm117532>
bramc: I'd agree with that, a new incentive formula is required as well. But that basically goes without saying if you're going to allow two causally-disconnected miners to both be compensated.
_whitelogger has joined #bitcoin-wizards
<psztorc>
Smaller miners are just as valueable as big miners, because anyone with a coalition of >50% is in charge.
<bramc>
Taek, There's never any downside to publishing the blocks more than two back from your own tip
<psztorc>
The concept of selfish mining makes no difference whatsoever, because the hashing power is homogenous.
<Taek>
psztorc: yeah but also completely hostile to anybody not participating in either of the two pools. The two pools might be hostile towards eachother, but at least they don't need to fear any small competition. Being competitive with them would require getting to the same hashrate as them.
<psztorc>
If anything, a market for hashrate would help.
<kanzure>
bsm117532: wouldn't it make more sense to have your paper reviewed prior to their deadline?
<psztorc>
Yes, they would all have to participate, but not at any disadvantage.
<bsm117532>
kanzure: A call for papers is a submission deadline. Then they send it to reviewers...
<psztorc>
No no no these pools will be very fearful of competition...the rival pool can crush them with 55%.
<Taek>
bramc: I disagree. If I'm 100 blocks ahead, but have 10% hashrate, it's in my best interest not to publish *any* of them. I can get 10 more blocks in the time that it's going to take the network to catch up - if I published my previous 98 the network would catch up in only 2 blocks
<Taek>
highly contrived, but proves a point
<Taek>
psztorc: yes but not with 5%
<phantomcircuit>
Taek, but you dont know if other miners with >10% are also 100 blocks ahead
<bramc>
Taek, Oh right, that's true. You should publish at least up to the point where you're one behind the public chain, or maybe tied with it. Ironically in that case you specifically want your own chain to fail in a test between siblings
<psztorc>
The 49% pool will pay almost anything to get a new 6%.
<Taek>
phantomcircuit: yeah, I have been assuming that the rest of the network is *not* engaging in selfish mining, something I could probably measure
<psztorc>
They get zero otherwise, they can off the 6% the entire revenue stream - epsilon.
<psztorc>
offer*
<phantomcircuit>
Taek, it becomes extremely difficult to model if you stop assuming that
<psztorc>
Selfish mining is very interesting, but the fundamentals are very clear: the hashing power is homogenous, so the game is symmetric. 51% always wins.
<kanzure>
bsm117532: yes, good point, you said call for papers. ok.
<phantomcircuit>
Taek, realistically if a major pool is selfish mining you should expect everybody to respond to that
<psztorc>
The fact that "Strategy X is better" only matters if "some people can't do Strategy X".
<Taek>
phantomcircuit: would you at least agree that if some subset of miners are engaging in selfish mining, it becomes very difficult for low-hashrate miners to compete? I do believe that much is true
<psztorc>
That is not the case, so the fact that selfish mining is better does not matter.
<Taek>
hmm
<psztorc>
Asymmetric dual selfish mining is not in strategic equilibrium, so it is eliminated.
<phantomcircuit>
Taek, im not sure that's actually true if there are two roughly equal sized pools selfish mining
<phantomcircuit>
indeed they might just increase their orphan rate giving smaller pools an advantage
<phantomcircuit>
but i honestly do not know (and dont think anybody has modeled this)
<psztorc>
Dual selfish mining is riskier than plural selfish mining, so it is eliminated.
<bsm117532>
FWIW I'd avocate: calculate coinbases 100 blocks later, and assign a 25 BTC coin creation to the miners of ALL valid blocks (including orphans) It doesn't solve the problem with tx fees and orphans (that requires a DAG), but solves the dominant economic problem for miners/selfish mining right now.
<bramc>
psztorc, That... makes no sense
<Taek>
ok. I can't say I understand very well what happens when everyone starts engaging in selfish mining, except that I know that when nobody is engaging in selfish mining, it's not profitable below 25% hashrate (unless you start using other attacks)
<bsm117532>
It removes the incentive to withhold blocks.
<psztorc>
bramc: What specifically do you not agree with?
<bramc>
bsm117532 It also causes there to be very little incentive to move the blockchain forwards
<bsm117532>
Eh, I withdraw that statement. It make mining double spends way more profitable.
<bramc>
psztorc, Selfish miners won't magically avoid having two of them just because it's a mess.
jlrubin has quit [Quit: Lost terminal]
<psztorc>
How do you explain the current mining environment?
<psztorc>
If selfish mining gives a superlinear advantage, there should be two (or one) pools.
<Taek>
psztorc: none of the existing pools have enough hashrate to be engaging in selfish mining
<bsm117532>
bramc: People keep repeating this weird idea that miners would only mine on their own blocks (in a DAG or blockchain) but that makes no sense because ALL miners will mine on top of the largest cumulative work. So you have a natural incentive to publish your block quickly in most circumstances because it gets *other* miners to mine on your block.
<Taek>
also, most of the large pools are very benevolent. It seems today that our miners are largely altruistic, and would not engage in network-toxic behaviors. No guarantees that it will last, but it's nice to have for the time being
<bramc>
bsm117532 Thats the case now but if you make it so you can get credit anyway that incentive is dramatically lessened
<psztorc>
Taek: Firstly I don't think that's accurate. But it doesn't matter -- why don't they just form bigger pools (if it is more profitable)?
<psztorc>
The one paper said 25% was enough.
<psztorc>
What is the difference between 'benevolent' and 'selfish', if you assume that is is possible that my theory is correct?
<Taek>
psztorc: https://blockchain.info/pools - biggest pool is at 24%. People get very unhappy when pools get close to 50%, and those pools tend to start losing hashrate quickly
<bsm117532>
bramc: that's because you're calculating the cumulative work wrong: it's not the "height" anymore, it's the total number of ancestor blocks.
<bsm117532>
(assuming constant difficulty target
<psztorc>
Taek: ok but that doesn't answer my question -- if they are profitable, why isn't this being done?
<bramc>
Taek, They seem to have a gentleman's agreement not to mess things up. You can get away with that when there are small numbers of them, and when there are large numbers they can't collude. Having 100 miners each at 1% might be a lot more painful.
<Taek>
bramc: you think having 100 miners at 1% would be painful? To me it's closer to the ideal situation.
<psztorc>
What is the difference between "gentleman's agreement" and "profit maximizing", if we assume a negative exchange rate reaction to 'reports of an ability to slow network speed'?
<psztorc>
(aka 'selfish mining').
<Taek>
well, the current gentlemans agreement does seem to be profit-maximizing behavior. At the very least it's causing any alarm bells that would be ringing to be quieter. But every individual has different utility functions, I don't think it's reasonable to assume that we won't see any selfish mining in the next 2-3 years, especially since there's no code to combat it yet
Guyver2 has quit [Ping timeout: 245 seconds]
<bramc>
psztorc, The benefits of selfish mining only start at 1/3, and even there they're dubious: You need to go at least two weeks before the work difficulty goes down, and you lose 20% of your own value during that time, and get back 10% later, so you need to be fairly confident that your own fraction of hash power will stay a healthy percent above 1/3 for more than the next six weeks and be able to stomach substantial short term loss to justify it
<psztorc>
This is still ignoring the fundamental symmetry.
<psztorc>
What if I paid someone to pretend to help my rival selfish mine...but then back out at the last second.
<psztorc>
How much could I afford to pay him, if the rival could indeed be tricked.
<psztorc>
?
<bramc>
There are interesting questions of how a selfish mining pool could enforce cooperation within themselves. I think it's entirely doable, but I'm not going to analyze how, much less publish notes on how to do it.
<bramc>
psztorc, What you're saying seems to amount to selfish mining can't work because mumble mumble efficient markets mumble mumble profit maximization
<psztorc>
If you didn't catch any words I'd be happy to repeat them.
<bramc>
You've repeated them enough already
<psztorc>
Any miner can execute any known strategy, any miner can team up with another miner. So 50% will always be the threshold.
<AdrianG>
thats not a convincing argument
<bramc>
You don't appear to understand what selfish mining is. We're discussing a very specific technical topic with actual properties. You can read the 'mining is not enough' paper if you are actually interested in details.
<psztorc>
I've read it.
<psztorc>
If someone with 31% selfish mines, and someone else with 50% selfish mines, and 19% are honest, is that in strategic equilibrium?
<psztorc>
The 31% will keep doing what they are doing?
<psztorc>
31% is enough?
<psztorc>
I'm sure it is...have fun with your tinkering, see ya later.
psztorc has quit [Quit: Page closed]
<bramc>
That was easier than I expected
<Taek>
Though it took a while to digest, I think his fundamental argument is that people will continue to adapt their behavior any time they find themselves on the losing side of an equation, teaming up or engaging in whatever tactics they need to in order to survive
<Taek>
which to me is a bit of a cop-out
<Taek>
I'd rather not have that overhead, and rather just exist in a system where everyone following a very simple, very defined set of rules yeilds them the optimal amount of utility
<bsm117532>
That's certainly a true argument, but useless.
<bsm117532>
We analyze the economic incentives under the best assumptions we can, and bitcoin requires that the net incentive moves the network forward...throwing up your hands is incompatible with using "profit maximization" as the mechanism of consensus.
<bramc>
About 'evil' soft forks: In general the definition of soft fork is that full nodes will continue to accept the new stuff. It also seems to be the case that a miner making no-transaction blocks should be able to mint new ones. But some soft forks result in there being transactions which appear valid to unupdated miners but cause their blocks to get orphaned, and other soft forks cause the number of transactions which old miners are able to accept to dro
<bramc>
p dramatically over time, possibly down to nothing, which also is potentially problematic. I don't know what the terms for those properties are, or if there are even standard ones.
<AdrianG>
optimal for whom?
<bramc>
There have been soft forks with both of those properties which were uncontroversial: getting rid of concat for the first one, adding p2sh for the second
<bramc>
So my questions are: What are the names for those properties, and what's the dividing line between having those properties and being 'evil'?
<Taek>
the general idea is that you can divide your participants into a few categories. Some will be byzantine, meaning they'll fail in ways that hurt the system maximally. Some will be altruistic, meaning they will follow the protocol exactly no matter what, and the rest will be rational, meaning that they'll only follow the protocol if there's incentive, and they'll deviate from the protocol where there is incentive to do so
<bramc>
Taek, Thanks I'll read that paper later
<bramc>
Taek, While somewhat related that doesn't answer my questions
<bsm117532>
frankenmint: That's cool, I didn't know about it.
<Taek>
bramc: iirc p2sh wasn't actually uncontrovertial. There was a lot of discussion about how it should be done, then gavin merged a proposal because he did not want to keep waiting for nothing to happen
<Taek>
and as /r/bitcoin has demonstrated, there's no such thing as 'uncontrovertial' in Bitcoin :P
<jcorgan>
some people are only happy with controversy and if there is not enough, by golly, they will make some
<bramc>
Well, potentially acceptable if not uncontroversial
binary01 has quit [Quit: Leaving]
<phantomcircuit>
Taek, which was a mistake since his version of p2sh is actually demonstrably worse than the other proposal