--- Log opened Fri Dec 06 00:00:35 2013
07:00 < typex> sorry about that. was drunk as fuck last night :-)
08:46 < Mike_B> cool paper! https://bitcointalk.org/index.php?topic=359582.20
08:46 < Mike_B> would love to hear gmaxwell's opinion when he gets up
08:46 < Mike_B> and has time to read
08:49 < _ingsoc> Mike_B: Would it have to operate as an alt?
08:49 < Mike_B> well, it seems like he's proposing a different way of considering transactions confirmed - orphaned blocks should also count as confirming tx's
08:49 < Mike_B> so you could adopt that rule in btc i guess
08:50 < Mike_B> but the idea is that once you adopt this rule it supposedly lets you shoot for a much shorter block generation time on average (1 sec he claims) without sacrificing security
08:50 < _ingsoc> Unlikely before getting some real-world data.
08:50 < Mike_B> right, i'm also skeptical
08:50 < Mike_B> i'm also curious if there are holes that can be poked in that... not entirely sure it's impossible to game it
10:20 < andytoshi> typex, probably the least regrettable drunk IRC posting I've seen..
10:23 < andytoshi> every bifurcation in a tree represents a halving of computing power, no?
10:23 < andytoshi> i'll have to read tho paper..
10:24 < andytoshi> and having one block per second is going to cause massive network split effects
11:35 < andytoshi> ok, the way this tree block thing works is, when determining which block continues the main chain, rather than looking at which extends to a chain with the largest total difficulty, you look at which one extends to a -tree- with largest total difficulty
11:35 < andytoshi> so you are still thinking in terms of chains, but your "which chain is best" algorithm considers all active forks along the way
11:37 < andytoshi> they prove that each block is eventually accepted or rejected (i.e. this does not cause permanent network splits)
11:38 < andytoshi> they point out that in the current system, if there are a lot of forks happening for some reason, this drops the effective hashrate because tons of work is being thrown away, thus making a 50% attack easier
11:38 < andytoshi> they claim that this does not affect their system as badly
11:39 < andytoshi> these are all proven, but the statements and proofs are technical and i don't have the time for a detailed analysis
11:41 < andytoshi> anyway my impression is that this is worth taking seriously
11:43 < t7> andytoshi what if two inputs are spent differently in two different chains ?
11:45 < andytoshi> eventually one side of the fork will "collapse" as there is a greater subtree weight on that
11:45 < andytoshi> and as blocks are piled on the usual more-time-means-more-confirmation heuristic applies
11:45 < t7> ah
11:46 < andytoshi> because everybody looks at the greatest subtree weight to decide what to mine on, there is an avalanche
11:56 < amiller> hm
11:56 < amiller> are there any risks of using this?
11:57 < amiller> i feel like we had a reason not to want to do it this way but maybe it's fine?
11:59 < amiller> i'm trying to read an undersatnd the security definitions...
11:59 < andytoshi> that was my thought too, but on a cursory review the math holds up
12:00 < andytoshi> so i'm trying to think about practical attacks, potential for DoS, storage/bandwidth usage..
12:00 < gmaxwell> amiller had suggested this before.
12:00 < gmaxwell> (or things substantially similar)
12:00 < amiller> so how did you talk me out of it, i don't remember :p
12:01 < gmaxwell> A couple reason, one is that its an enormous cost increase to lite codes (e.g. hundreds fold more bandwidth, potentially)
12:01 < gmaxwell> s/codes/nodes/
12:02 < gmaxwell> andytoshi: are they actually having new blocks commit to all branches of their past subtrees? amiller's idea was to do that. If they don't then I don't see how its convergent.
12:03 < andytoshi> no, blocks commit only to a single parent
12:03 < andytoshi> i'm not clear how the parent is chosen when there are multiple options with no existing subtree
12:04 < gmaxwell> andytoshi: uh, so why do you and someone who joined the system later than you pick the same solution at all?
12:04 < gmaxwell> e.g. you and I get the same longest tree, but different forrests, and so now later we choose different longest trees.
12:04 < andytoshi> after some time, new blocks will be mined on top of one or more of the options
12:04 < andytoshi> hmm, everyone starts from the same genesis..
12:04 < iddo> i think they say that each block does point to its
12:05 < iddo> ancestors
12:05 < iddo> maybe just for lite nodes optimization hmm
12:05 < gmaxwell> it has to be all of the ancestors needed to compute the highest difficulty, if they do that, then its what amiller proposed before.
12:05 < andytoshi> for a given leaf node, there is only one ancestor (and only one chain back to the genesis)
12:05 < gmaxwell> if they don't I don't see how it can be convergent, because nodes will pick chains based on data that has no strong synchronization method.
12:06 < andytoshi> so, algorithm 1 on page 18 says what i'm saying here, it's like 5 lines and a bit more precise
12:07 < andytoshi> there is an assumption that everybody eventually hears about every block, and synchronization happens because long-term forks are unstable
12:07 < andytoshi> one or the other will have a stronger POW on its subtree, and then everyone will mine on that
12:08 < gmaxwell> But what mechenism makes you know there are blocks in your subtree that you need to have? amiller's orphan-targeting stuff handled it by blocks commiting to the orphans their miners knew about.
12:08 < andytoshi> no such mechanism
12:08 < andytoshi> well, none that i saw
12:08 < andytoshi> the assumption is that every block propogates eventually
12:09 < andytoshi> so if you are missing blocks, that will give you a bad view of the network, but when the missing blocks come in your view will be corrected
12:10 < andytoshi> and since miners are incentivized to work on the strongest side of the fork, the likelihood that your view is so badly compromised that you think the wrong fork is correct, is very small
12:10 < gmaxwell> how do you prevent denial of service then? e.g. I constantly feed you difficulty 1 orphans for block 1?
12:10 < gmaxwell> you've got to take them, cause, you never know, all those diff 1 guys might eventually sum up to be greater than the current best.
12:10 < andytoshi> right, exactly
12:11 < andytoshi> i'm not sure
12:11 < andytoshi> hmmm
12:12 < gmaxwell> also, what about problems with goodput? lets imagine this with blocktimes of 1ms (e.g. way below the latency betwen nodes)
12:12 < andytoshi> not sure, i skipped over the propogation-time analysis
12:13 < gmaxwell> you would eventually converge on sufficiently old history, but you're spending all your bandwidth sending orphans.
12:13 < andytoshi> i think that's correct, my impression is that they did not look at bandwidth usage
12:14 < andytoshi> i wish they had published a shorter version that did not spend so much time discussing common knowledge about bitcoin..
12:14 < gmaxwell> liquidcoin (coin with fixed difficulty) basically melted down because it eventually was using all its bandwidth/cpu just switching between a zillion distinct forks and no longer making much progress.
12:14 < andytoshi> the opposite of solidcoin ;)
12:16 < pigeons> same as geistgeld but geistgeld was sha256 liquidcoin scrypt
12:16 < andytoshi> i expect if you were to ask the authors this, they would try to come up with some heuristic for ignoring spam blocks
12:17 < andytoshi> in the limit, you ignore all but the highest-difficulty chain, and you get bitcoin
12:17 < andytoshi> and it seems like anything weaker than that has the potential to cause forks when peoples' definition of "spam" diverges
12:17 < andytoshi> so you'd need to just accept everything, which is what this paper proposes
12:18 < iddo> gmaxwell: about DoS by feeding you diff 1 orphans for block 1, i think that they claim that your node can ignore the orphans until someone does enough PoW to send you many orphans together and prove to you that his subtree should win
12:18 < andytoshi> ...and then gmaxwell's "spam a trillion diff-1 blocks" attack would work
12:18 < gmaxwell> andytoshi: yea you could have any amount of difference between two subtrees.
12:19 < andytoshi> iddo: if a node doesn't know everything, he can't prove or disprove that a certain subtree will win
12:19 < andytoshi> and that'd certainly be the case for every node in a high-block-rate network
12:20 < andytoshi> so if you ignored blocks just because the sender couldn't prove they were worthwhile, you'd end up ignoring everything.
12:20 < andytoshi> and again your ignoring heuristic creates potential for a  long-term split
12:21 < amiller> maybe this is an important thing to simulate?
12:21 < amiller> they've gone through the trouble of formalizing what the algorithm should be
12:21 < amiller> the ddos behavior to implement seems straightforward to describe too
12:22 < andytoshi> do we have a simulator yet? there was some serious bounty..
12:22 < amiller> so what i'd expect is that the ordinary algorithm gets horribly overloaded by easy ddos
12:22 < amiller> we have a simulator that i think is lovely and i'm pissed because kjj doesn't want to pay it and no one else has chimed in
12:22 < amiller> https://bitcointalk.org/index.php?topic=326559.0
12:23 < iddo> pay it?
12:23 < amiller> call the bounty claimed
12:23 < amiller> kjj first posted the bounty i mean
12:23 < iddo> ahh
13:28 < _ingsoc> Chicago has given up. :(
13:29 < sipa> ?
13:47 < avivz78> hi :-)
13:51 < _ingsoc> sipa: -!- Chicago [~Chicago@2001:558:6033:ff:4450:74c5:b55:35d3] has quit [Quit: Leaving]
13:51 < _ingsoc> It was a lame joke.
13:59 < andytoshi> sigh, i bought in at 1050, was gonna just hold indefinitely
14:00  * andytoshi takes a 20% bath
14:03 < andytoshi> sorry, wrong channel
14:36 < Emcy> enjoy your haircut andytoshi
14:52 < warren> perhaps this channel should require login too
14:52 < warren> -dev has improved
14:53 < Emcy> just keep it on the dl
14:54 < warren> Emcy: too late for that
14:55 < Emcy> well ive never told anyone.......
14:55 < Emcy> never knew if this room was supposed to be quiet
14:55 < warren> quiet isn't the goal.  relevant is.
14:57 < Emcy> i thought this was the place where we do some blu sky thinking, generate some thought showers and synergise dem paradigms
14:57 < maaku> Emcy: you tell people privately, when you think it'd benefit the channel for them to be here
14:59 < maaku> am I blind or does this new paper not actually address any of the scalability concerns which necessitate a long interblock time?
15:02 < andytoshi> maaku: its premise appears to be that long interblock times are needed to prevent permanent forks due to the block rate being faster than the network speed
15:02 < andytoshi> and they fix that specific problem by using the forks to determine which block to mine on
15:03 < maaku> so ignorance, it seems
15:03 < maaku> someone should invite them here
15:04 < andytoshi> might be worthwhile, there was a conversation a bit earlier where gmaxwell pointed out a simple dos attack
15:04 < andytoshi> and it seemed to me that any attempt to fix it short of just throwing out the whole idea, would cause forks to happen
15:06 < maaku> there's all sorts of DoS vulnerabilities and bad incentive structures that emerge when you lower the interblock time to 1 second
15:07 < maaku> doesn't stop "most-work chain of the most-work tree" being a possibly good heuristic though
15:07 < maaku> but as usual with academic papers, there are claims blown way out of proportion :(
15:08 < andytoshi> well, it does because if you don't factor in depth then you can DOS people by sending them millions of low-difficulty blocks at some early point in the tree
15:08 < andytoshi> and they have to keep them around, just in case they wind up totalling more than the "real" chain
15:08 < andytoshi> maaku: yeah, and the forum posts are absurd
15:11 < maaku> andytoshi: no, they don't have to keep them around because there doesn't have to be global consensus on the forks
15:11 < maaku> they just decide locally how many they want to keep around
15:12 < maaku> and garbage remove the rest
15:12 < andytoshi> but then you've got different nodes making different decisions about what's garbage, and they'll wind up with permanently divergent views of the blockchain
15:13 < maaku> permanently? no
15:13 < maaku> temporarily, yes, but it's no different than when a fork occurs now, and nodes stay on the most recently heard block
15:14 < andytoshi> here all forks are involved in the decision as to what is the definitive chain
15:14 < maaku> yes, and eventually the chain with the most hash power behind it will overcome all those itsy bitsy forks
15:15 < maaku> this new GHOST agorithm just makes nodes a little bit more sticky to the forks which have been surpassed but nevertheless appear to have more work going into them
15:15 < andytoshi> ok, but until then, the DOS'd node needs to keep all the forks around
15:15 < maaku> why?
15:16 < andytoshi> because the node doesn't know that the chain with the most hashpower will overcome the forks
15:16 < andytoshi> or if it does, that it'll continue to overcome
15:16 < maaku> so what?
15:16 < andytoshi> so how does it decide what's garbage and what's not?
15:16 < maaku> all forks are garbage
15:17 < maaku> this is just a mechanism for using the information represented by those forks to more smartly choose the fork that is more likely to win
15:17 < andytoshi> then what happens when the node gets confused about what's the longest chain? then the main chain is decided to be garbage and the node never gets back on trakc
15:17 < maaku> but if you end up being wrong, it'll end up being because there was more power behind a different fork, and you will self-correct
15:18 < andytoshi> if you're using information from the forks, you need to hold the forks
15:18 < andytoshi> if you're using information from the forks, and you are picking-and-choosing which ones to keep, you will make decisions differently from other nodes
15:18 < maaku> *and that is not a problem*
15:18 < andytoshi> and if you keep them all, you get DOS'd, if you keep none of them, you have bitcoin
15:18 < maaku> you already make decisions differently from other nodes
15:19 < maaku> when you receive an orphan block, you choose the block you already have
15:19 < maaku> that's based on local knowledge, namely the arrival times of the two blocks
15:19 < maaku> which are different from node to node
15:19 < andytoshi> yes
15:19 < maaku> this is no different than when a GHOST protocol node chooses which orphan forks to keep around for
15:20 < maaku> you can't get permanently stuck on a fork because you have a few orphans lying around
15:20 < maaku> not unless someone is using more nethash than the entire network to create those orphans
15:20 < maaku> in which case this is another instance of the 51% attack
15:20 < andytoshi> the problem is that you don't know if somebody has more nethash than the entire network
15:21 < maaku> andytoshi: again, so what. that describes bitcoin currently
15:22 < andytoshi> in bitcoin currently if i start spamming you with orphans, you can ignore them until i send you one containing a higher POW than your current best chain
15:22 < maaku> <andytoshi> the problem is that you don't know if somebody has more nethash than the entire network
15:22 < maaku> ^^ that's nothing more than the majority-nethash attacker scenario
15:22 < andytoshi> whereas here you might be receiving orphans from many parties, none of whom individually have enough POW to overcome the main chain
15:23 < maaku> which already trivially defeats bitcoin
15:23 < avivz78> mmmm Hi guys
15:23 < avivz78> seems like you're talking about our paper?
15:23 < maaku> yes
15:23 < andytoshi> hi avivz78, yes
15:23 < avivz78> (was away at another window)
15:23 < avivz78> I'd be happy to respond / discuss
15:24 < avivz78> can someone explain to me how bitcoin proposes to handle low difficulty ddos attacks?
15:24 < andytoshi> my concern is that because you're using entire subtrees to determine the best chain, and spam subtrees can be created to be very large (e.g. by spamming many low-difficulty blocks at the same height), this exposes the network to dos attacks
15:25 < maaku> avivz78: I think it's a great idea, albeit derivative of unpublished work that's been thrown around here. You've gone further than anyone in formalizing it though.
15:25 < andytoshi> partially, the checkpointing mechanism
15:25 < avivz78> As I see it, bitcoin has to handle this too
15:25 < maaku> avivz78: can you explain "low difficulty ddos attacks" (there's more than one thing you could be referring to)
15:26 < andytoshi> well, it is hard to create enormous fraudulent individual chains
15:26 < avivz78> \msg avivz78 mmm
15:26 < avivz78> nope
15:27 < avivz78> I'm on a web client not sure I can privatemessage
15:27 < avivz78> andy - isn't it just as hard to create large fraudulent trees?
15:27 < _ingsoc> azariah4: Can we contact you via e-mail?
15:28 < andytoshi> avivz78: not quite, because you can avoid difficulty increases by staying at low depth
15:29 < maaku> avivz78: yes it is just as hard, that's what I was trying to tell andytoshi
15:29 < maaku> andytoshi: most-work, not longest
15:29 < andytoshi> yes, i understand that
15:33 < andytoshi> what i'm saying is that as long as there are low-diff blocks coming in, you don't know how big the tree is going to grow to, so you have to keep them all around
15:33 < andytoshi> but i'm not clear on how bitcoin solves this problem
15:33 < andytoshi> aside from checkpointing, which is a kluge
15:34 < andytoshi> so i guess, i tentatively cede my point
15:34 < andytoshi> sorry guys :}
15:34 < avivz78> I think these are all the same issue basically. I'd certainly like to learn a bit more about this as well.
15:36 < maaku> avivz78: my larger concern is the public perception. this new algorithm helps alleviate some of the pressure of shorter interblock times, but that has approximately nothing to do with transaction volume
15:37 < maaku> which has more to do with validation and propogration times
15:38 < avivz78> both have the same effect
15:39 < avivz78> larger blocks imply more propagation time, imply more orphans
15:39 < avivz78> higher block rates imply more orphans too
15:39 < avivz78> We make the connection in the paper
15:39 < avivz78> most of the first half of the paper is about scalability alone. GHOST comes in at section 8
15:39 < Emcy> 1 second blocks?
15:40 < maaku> no, larger blocks come with efficiencies that aren't seen with smaller, more frequent blocks
15:42 < avivz78> like what?
15:42 < avivz78> (besides the headers)
15:42 < maaku> batch validation
15:42 < maaku> mempool gossiping and partial proof-of-work to "pre-validate" transactions of a large block
15:43 < maaku> these can lead to very low propogation times for large, intermittant blocks
15:44 < avivz78> you'll need to explain those :-)
15:45 < avivz78> batch validation for example,how do you get a speedup?
15:47 < maaku> well this is more software engineering, but there's ECDSA batch verification engines that are able to process signatures faster in a large group
15:48 < maaku> i assume batch-validation of entire blocks would be easier to do than multiple blocks at once  (given that these are presumably handled by separate threads, etc.)
15:49 < maaku> mempool gossiping and partial proof-of-work is allowing miners to send blocks which almost meet the threshold
15:50 < maaku> other nodes then fetch and pre-validate the transactions in these partial proof of works so as to reduce the amount of work that needs be done when a block is actually found (presumably by one of the miners that found a partial pow)
15:50 < maaku> validating the actual proof of work then just becomes a matter of fetching the transaction list, filtering out those already validated, and handling the remaining few
15:54 < avivz78> can't you pre validate transactions upon reception even if they're not in blocks?
15:55 < maaku> if you have them
15:56 < maaku> the partial proof of work provides a DoS-free way of guessing which ones will make it into the next block (including which ones you need to query the network for because you don't have)
15:57 < avivz78> I thought the fees took care of DOSing in this case. Am I missing something?
16:04 < maaku> fees are collected by miners not nodes
16:05 < avivz78> true, but they are anti-spam because the spammer would lose the fee if a miner includes the transaction
16:11 < maaku> avivz78: i think the work you all have done is very valuable
16:11 < zooko> Okay folks, I was stupefied by gmaxwell's and amiller's assertion that a "dual-use" proof-of-expense, with some beneficial side-effect, might cause instability, or facilitate attacks, etc.
16:11 < zooko> So I've been pondering it. I'm not sure I buy the argument yet.
16:11 < maaku> but what it will do is allow bitcoin to scale to larger block sizes, not smaller interblock times
16:11 < zooko> But I mentioned it to my friend Kiln Ham, and he said "What if the beneficial side-effect were a public good that couldn't be used to remunerate the miner individually."
16:12 < maaku> zooko: do you understand the argument that a merged-mined altcoin can be attacked by bitcoin pools?
16:12 < zooko> I thought that was pretty brilliant, so I decided to throw it out there even though I haven't really grokked the original argument.
16:13  * zooko thinks about maaku's question.
16:14 < avivz78> maaku:  thanks!
16:16 < avivz78> I should say that we gained a lot from reading Meni Rosenfeld's work on the security analysis
16:18 < maaku> zooko: it's the same argument, just with bitcoin placed in the position of a low-value altcoin
16:18 < maaku> and to your friend, i'd say please give an example
16:19 < maaku> (and if it really does provide value, I'd be willing to bet that enterprising miners would find a way to profit from it)
16:22 < avivz78> Well, time to go get some sleep
16:22 < avivz78> thanks for the fruitful discussion
16:22 < avivz78> I've learned a lot!
16:23 < zooko> maaku: yes, that's an interesting question about if a public good can be made excludable.
16:23 < gmaxwell> zooko: 13:27 < gmaxwell> jtimon: the standard litany, most of those are not sufficiently cheap to verify (e.g. hurts spv nodes, zero knoweldge proofs of tx data, and initial syncup),  they tend to be inadequately proven to be trapdoor free, high hardware implementation complexity (so may lead to asic monopolies)... if the work is not work you could get paid for, then at least it should be free of some of the incentive concerns.
16:23 < zooko> Normally I'm wishing to figure out ways to make a public good excludable, but for this I would like to know a way to make it impossible to make it excludable. ☺
16:23 < gmaxwell> yes, if it's work you can't get paid for then it probably eliminates that particular concern.
16:23 < zooko> gmaxwell: yes, that quote from you is what I meant about you have already stupefied me.
16:24 < gmaxwell> zooko: did you see my timelock encryption ticking meta idea?
16:24 < zooko> gmaxwell: I did not! Do tell!
16:24 < gmaxwell> zooko: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas  search for "tick"
16:25 < andytoshi> zooko: the premise is that the POW involves finding private keys...so you encrypt something with a public key, knowing that the network will crack it at some point in the future
16:25 < maaku> gmaxwell: how do you prevent someone from just skipping ahead in the sequence and decrypting what they're interested in?
16:25 < gmaxwell> Discrete log isn't so great though, you really need an asymetric encrpytion scheme with no solution path better than the exponential search.  It would need a lot of details to be worked out.
16:25 < _ingsoc> I really wish we could get someone who's interested in implementing some of those ideas.
16:25 < _ingsoc> How hard can it be?
16:25 < gmaxwell> maaku: you encrypt with all future solutions.
16:25 < maaku> hrm i see
16:25 < andytoshi> _ingsoc: very hard, you need to understand the math and also the engineering stuff, and you have to be a good programmer, and you need to have the time
16:25 < zooko> gmaxwell: neat!
16:26 < gmaxwell> maaku: I don't claim that the engineering works out neatly. What struck me about the idea is that it enables a public good, which you can't get paid for, and yet we have no other way to provide that public good.
16:26 < andytoshi> and then you have to deal with #bitcoin-wizards ripping your stuff apart
16:26 < _ingsoc> andytoshi: How many people realistically are around competent enough to do it? Assuming money can be arranged for it.
16:26 < maaku> _ingsoc: i see 61 users in this channel
16:26 < gmaxwell> maaku: this was yet another idea I've had while in the middle of lecturing someone that it wasn't possible. :P
16:26 < zooko> _ingsoc: where are you going to get the money?
16:26 < andytoshi> there are probably a dozen or three people on here who are competent enough
16:26 < zooko> gmaxwell: Haha!
16:26 < andytoshi> they are all very busy
16:27 < gmaxwell> zooko: step 1. Start altcoin  step 2. ???  step 3. Profit!
16:27 < gmaxwell> :P
16:27 < _ingsoc> zooko: Tons of people want to see this stuff. It's easy to get it funded.
16:28 < zooko> _ingsoc: somewhat self-referentially, I think implementing a lot of this would be a public good...
16:28 < zooko> gmaxwell: yes, exactly!
16:28 < _ingsoc> Make X amount of coins available for people who are brave enough to fund it ("early adopters"). Whatever is traded for X goes to the developer(s).
16:28 < _ingsoc> Pretty simple really.
16:29 < _ingsoc> Set your boundary so that you have enough for a development fund.
16:29 < gmaxwell> This has long been one of the linchpins of cryptoanarchism— a lot of neat ideas depend on decenteralized trustless infrastructure which would be inherently a public good, and by virtue of being decenteralized and trustless, impossible to collect rents on which is the primary way that business monetize infrastructure.
16:30 < gmaxwell> the coin pump model has a lot of problems, in part because its hard to judge competence, so you see things like huge money flowing into coins which have developer signed blocks (feathercoin, ppcoin) and little to no technical innovation (feathercoin, for example but many others too).
16:31 < _ingsoc> gmaxwell: That's why I propose using the model for actual innovations. If you limit the amount of contribution per person, you get a little closer to make it fairer.
16:32 < _ingsoc> Ofc people will game it. Hell, people are gaming Bitcoin as we speak.
16:32 < _ingsoc> If at the end of the day every understands the risks and you end up with better tech, that's progress in my eyes.
16:32 < gmaxwell> the other problem you have is that if you do anything innovative in this space alternative coins will just copy it instantly. We even had a bit of problems with that in bitcoin-qt with altcoins being forumed out of draft features.
16:32 < zooko> gmaxwell: if you hit upon a hack to bypass that problem, please let me know.
16:33 < zooko> "that problem": the public good of a decentralized tech
16:33 < _ingsoc> gmaxwell: There's always the option to open source it after a while of maturation.
16:33 < amiller> ah cool aviv came here :)
16:34 < _ingsoc> gmaxwell: But if someone copies an open source coin, that's not bad in opinion. It's unlikely anyone is disadvantaged by that.
16:34 < gmaxwell> _ingsoc: sure they are, because then they get outmarketed by someone else who has thrown off the "unfair" premine baseload your funding model depended on.
16:35 < gmaxwell> why would I want coinX which had 10k coins premined for its creators when I can have coinY which is the same thing but without the premine?
16:35 < andytoshi> amiller: yeah, he was really cool
16:35 < _ingsoc> How long do you think that'll be sustainable for? Everyone will realise it's the contributors who made the coin happen in the first place.
16:36 < andytoshi> _ingsoc: bitcoin had some really good ideas, and it apparently has no inventor
16:36 < amiller> i am *so* happy that this thread is going on, this is how i was hoping academia and bitcoin devs would interact, and of course the eyal/sirer paper did not go that way
16:36 < andytoshi> so, the ideas hold up on their own
16:37 < zooko> What nym does aviv use for academic publications?
16:37 < amiller> Aviv Zohar?
16:37 < _ingsoc> gmaxwell: Satoshi pretty much premined Bitcoin to high heaven and nobody cared.
16:37 < andytoshi> amiller: aviv said, he was happy to find an audience with so much passion, this does not happen to most papers :P
16:37 < gmaxwell> _ingsoc: thats really not true at all.
16:38 < amiller> andytoshi, :)
16:38 < _ingsoc> gmaxwell: How?
16:38 < gmaxwell> _ingsoc: if thats the kind of garbage nonsense that people repeat when its not true, consider what happens when it is true.
16:38 < _ingsoc> gmaxwell: What incorrect about the statement?
16:38 < _ingsoc> What's*
16:39 < Emcy> are you serious
16:39 < gmaxwell> _ingsoc: Bitcoin was public from the very start and considerable effort was made to make that provable.  (including, for example, reaching out to likely initial users, as adam back can testify)
16:39 < Emcy> he crafted a block then mined one on it to check
16:39 < gmaxwell> _ingsoc: there were mutiple people using it from the first day.
16:39 < _ingsoc> gmaxwell: I'm not saying he did it in secret. I'm saying he mined it when nobody care about it.
16:40 < _ingsoc> gmaxwell: What I'm trying to say is that what people like to crap on today is not very different from how Bitcoin came to be.
16:40 < _ingsoc> gmaxwell: I'm talking about the underlying economics.
16:40 < gmaxwell> _ingsoc: I don't even thing you can establish that satoshi actually mined it in any non-trivial amounts, in fact.
16:40 < gmaxwell> _ingsoc: and you're factually incorrect.
16:40 < _ingsoc> gmaxwell: You don't know that.
16:41 < _ingsoc> gmaxwell: You believe I'm incorrect, and that's fine, but for a lot of this stuff, we simply don't have the answers.
16:41 < gmaxwell> You're factually incorrect in saying that it was premined or similar to the people who created a ton of coin in the first block. Thats a matter of fact, not uncertanty.
16:42 < _ingsoc> gmaxwell: Ofc that's factually incorrect, but that's not what I was trying to say.
16:42 < gmaxwell> You can say these things to try to justfy whatever scheme you want, I wish you luck. But as you can see people don't tolerate that stuff. They refuse to use primined coins _generally_ though there are some exceptions.
16:43 < _ingsoc> gmaxwell: That's a bit unfair.
16:44 < _ingsoc> gmaxwell: I'm not trying to go on the offensive.
16:45 < gmaxwell> They don't accuse people of behavior that many consider unethical.
16:45 < gwillen> gmaxwell: I don't know that you're right about people refusing to use premined coins; I think most people just don't care that much.
16:46 < gwillen> gmaxwell: I see a lot of loud noise from Luke about how awful they are, and a little bit of loud noise from people who aren't Luke, but I still see plenty of people using them.
16:46 < gmaxwell> gwillen: Which premined coins are people using now, except for ripple?
16:46 < pigeons> why do people use litecoin and not its direct predecessors. why did btc-e destroy a large number of "novacoins"
16:46 < gwillen> gmaxwell: Well, most of them were pointless for other reasons
16:46 < gmaxwell> gwillen: novacoin had to destroy their premine.
16:46 < gwillen> gmaxwell: I mean, you don't see people using ixcoin, but you also don't see people using i0coin
16:46 < gwillen> they're both just as dead
16:46 < gmaxwell> and the litecoine predecessors were heavily premined and are not used though they're functionally identical.
16:46 < gwillen> hmm.
16:47 < _ingsoc> That wasn't my intention at all. I should probably have used a better explanation of what I meant. What I meant to say was that Satoshi sat there mining it whilst nobody really cared, and that's no different than someone mining it for contributors. Satoshi mined it for the ideas he contributed, or whatever drive to support those ideas.
16:47 < gmaxwell> there is a long history of premined coins failing, and/or being forked into non-premine versions.
16:48 < gmaxwell> _ingsoc: even that much is an assumption that may not be true. and the oppturnity to do that— to mine where no one believed in even the _chance_ is probably gone, and never would have been a viable funding model in terms of net-expectation.
16:48 < gmaxwell> E.g. Satoshi wasn't doing an economically rational thing even though it may have turned out quite well for him.
16:49 < _ingsoc> gmaxwell: True, I can accept that. I'd have to add that we have no clue. God, Satoshi could be the CIA for all we know.
16:49 < gmaxwell> Probably a good assumption in terms of setting up the right defensive expectations.
16:49 < _ingsoc> Hah.
16:49 < Emcy> gwillen but premining a coin is such a blatant scheme that i feel the people who still get involved do so becuase they like the drama or some other werid psychological reasons?
16:50 < _ingsoc> Depends where the premine go to, Emcy.
16:50 < gmaxwell> _ingsoc: I mined bitcoin in 2009 and basically forgot about it, whatever coins I mined (which are probably now confused as being satoshi coins) back then got destroyed... bitcoin was so worthless that it wasn't worth keeping the software running.
16:51 < Emcy> shouldnt matter "where theyh go to", rationally
16:51 < _ingsoc> But it does.
16:51 < _ingsoc> All of this is in-group, out-group psychology.
16:51 < Emcy> yes, all that crap
16:52 < gmaxwell> I don't think it matters, you can just fork the coin remove the premine and tada, it's more "fair" .. and thats what people do.
16:52 < _ingsoc> Whatever succeeds Bitcoin will rise out of that crap.
16:52 < _ingsoc> It might be pretty good crap, but it's still crap.
16:52 < Emcy> i dont think it can be succeeded
16:52 < gmaxwell> maybe ripple soved it, but only through methods which have offended a lot of people.
16:52 < Emcy> not fairly
16:52 < _ingsoc> gmaxwell: That's success though - the tech propagates.
16:52 < _ingsoc> gmaxwell: Not Ripple, the fork.
16:53 < pigeons> well how do you distribute? you mean adding a mining mechanism to a system that doesnt mine or use PoW?
16:54 < gmaxwell> _ingsoc: yea, well it hasn't answered the question that started this discussion.  .. except "wait for someone to be stupid enough to think they can fund major public development with a premine; watch as the public forks their solution"
16:55 < _ingsoc> gmaxwell: I forgot the question. It's 6am here. :/
16:55 < Emcy> how do you fund anything with a premine. The coins are worthless.
16:55 < gmaxwell> :)
16:55 < _ingsoc> Emcy: The coins are sold for something of value.
16:55 < Emcy> unless you have exchanges ready to roll day 1 and stupid people pumping money in
16:55 < pigeons> mining may not be fair at all to distribute subsidy, but yea we don't know a better way, but any other ways will have loud objections of unfairness because it is the model for now
16:55 < Emcy> day 1 exhanges is another huge klaxon
16:56 < gmaxwell> Emcy: people have tried, the plan is "create premine coin, pump coin, coins gain value" and yes, it fails.
16:56 < _ingsoc> gmaxwell: That's not the plan at all!
16:56 < _ingsoc> gmaxwell: How would pumping something like that create any real value?
16:56 < gmaxwell> 'value'
16:56 < gmaxwell> _ingsoc: it's certantly the plan of some people, and anyone who has a distinctive plan is indistinguishable.
16:56 < Emcy> cos value is an illusion?
16:57 < _ingsoc> Value is better tech. That's the whole point of funding something like that.
16:57 < pigeons> heh new bitcoin forks list existing features as value-add. "Bitcoin fork with IPv6"
16:57 < _ingsoc> If the tech gets forked the tech is good (good enough for someone to fork it at least).
16:57 < _ingsoc> gmaxwell: People will always be full of shit.
16:58 < gmaxwell> _ingsoc: go explain to me the 12 million dollar feathercoin market cap. It's a copy of ltc with the blocktime set to a provably unsustainable value— it was suffering convergence problems, so they paid the PPcoin guy for code to do centeralized block signing (like ppcoin uses)
16:58 < Emcy> people have forked coins just for the troll factor
16:58 < gmaxwell> (suffering convergence problems from the blocks being too fast)
16:58 < _ingsoc> gmaxwell: There's no doubt it has technical problems.
16:59 < Emcy> $12m according to whom?
16:59 < pigeons> is that float of mined coins existing?
16:59 < pigeons> assuming no slippage of course
16:59 < _ingsoc> Someone here should just take me up on it, get paid, make better tech, and then we can all go back to arguing.
16:59 < _ingsoc> Seriously.
16:59 < gmaxwell> Emcy: 'market cap', which is a but airy— but you can still go extract a hundred thousand dollars instantly by emptying the orderbooks.
17:00 < Emcy> feathercoin has orderbooks? jesus wept
17:00 < gmaxwell> and in my opinion that coin should have a value of approximately nothing.
17:00 < pigeons> it even has apparent "true believers"
17:01 < Emcy> stuff like that makes me think even bitcoins "cap" of 4bn or whatever is bollox
17:01 < gmaxwell> Emcy: sure, its bollox, but the orderbooks at least are real.
17:02 < Emcy> the scheme i see a lot is people mining altcoins and cashing out to btc
17:02 < Emcy> since btc mining became impossible
17:02 < Emcy> thats kinda weird
17:02 < gmaxwell> Emcy: unless there are secret litcoin fpga/asic farms litecoin is probably using more electrical power now than bitcoin.
17:03 < Emcy> yeah thats bonkers
17:03 < Emcy> i prefer to think theres a secret fpga farm
17:04 < Emcy> yet i see threads the gist of which "check out my new 4 7790s for litecoin lol"
17:06 < gmaxwell> I think I pissed off people in #litecoin-dev suggesting otherwise. I find it hard to believe, if true it means there is a substantial multiple of gpus mining litecoin than ever mined bitcoin— surprising to me but not impossible.
17:07 < zooko> Hey gmaxwell are you still working on opus?
17:07 < zooko> I was happy to see the 1.1 release announcement today.
17:08 < gmaxwell> zooko: Yes.
17:08 < Emcy> not impossible. I think word got around of how people funded thier new $2000 rigs with GPU mining back in the 2011 excursion.........people seem to think thats happening again with ltc
17:08 < Emcy> at least on /g/
17:08 < zooko> gmaxwell: nice work!
17:09 < Emcy> when is steam gonna pick up opus for voice :(
17:09 < warren> gmaxwell: people are indeed still buying GPU's now.
17:11 < Emcy> and why didnt they use something better for the xbox. Im sure thier codec was some 64kbs cbr shit right up until last month. Everyone so scared of patents.
17:13 < zooko> patents are scary
17:14 < Emcy> yeah its a shame that a competitive free/libre/nopatents video codec will probably never happen cos of that shit
17:14 < zooko> HEy does anybody have a good list of patents that probably apply to NTRU cryptosystem?
17:15 < zooko> cryptosystems, I meant to type, i.e. PK encrypt and dig sig.
17:15 < gmaxwell> NTRU is such an engineering mess in general.
17:16 < gmaxwell> The history of commercial cryptosystems has been a sad one. No one wants patented crypto, even if its awesome.
17:16 < Emcy> i dont actually understand how you can patent maths
17:16 < zooko> OCB
17:17 < nsh> where's context-aware acronym-explainer-bot when you need her
17:17 < maaku> Emcy: you can certainly patent applications of math
17:18 < Emcy> but everything is applications of maths
17:18 < gmaxwell> if you can't patent applications of math then with enough layers of handwaving you can't patent anything, after all we could all just be running in a simulation.. and what is a cotton gin but a pattern of information? :P
17:19 < Emcy> thats one zinger of a reducto ad absurdum :P
17:20 < Emcy> but youre right, where does it end
17:20 < gmaxwell> well, so is saying that a pratical cryptosystem is "just math", in terms of the stuff the patent system was created to do— a cryptosystem is something people work hard at to invent... sooo.  Of course, it doesn't usually work out, because trust in these systems generally requires them to be public infrastructure... and public infrastructure abhors the toll tax.
17:21 < Emcy> only if you want to make money off your system?
17:22 < Emcy> yes, lots of unfortunate opposing imperatives trying to Something Good under capitalism......
17:22 < gmaxwell> well, so long as things cost money doing things with no prospect of making money may be somewhat ill-advised. ::shrugs:: no easy answers.
17:22 < Emcy> also true
17:23 < Emcy> we need crypto-patrons.......
17:23 < gmaxwell> amiller: in any case, I think relatively compact snarks of sum-difficulty could be produced.
17:23 < gmaxwell> amiller: as in circuits that only take minutes to make a difficulty proof for some whole blockchain.
17:24 < amiller> i think so too.
17:24 < gmaxwell> though I think you'd want to be commiting to blocks included in a fork that way, instead of just hoping they show up.
17:25 < gmaxwell> did you guys resolve the objection about convergence I started?
17:25 < amiller> i dunno
17:27 < gmaxwell> I think it's resolvable by commiting all the blocks used in the calculation. ... but I think it must be solved. otherwise you could have two subgraphs of great additional difficulty each decided by an additional diff1 orphan added early to the fork... so you must relay the darn things
17:28 < sipa> any opinions about that israeli paper yet?
17:28 < gmaxwell> we were just talking about that, I think you weren't included on the email thread, you probably should be.
17:28 < gmaxwell> its has a lot of similarity to amiller's early ideas about orphan rate targeting blockchains instead of block time targeting them
17:29 < gmaxwell> Major unambigious downside is a six hundred fold increase in SPV base cost (bandwidth/cpu). Though perhaps that could be solved by using snarks to prove difficulties.
17:30 < gmaxwell> there is so discussion over if their specific description is actually convergent or not, I don't think it is— though it's easily possible I'm missing something, as I have not read the paper yet—, but it could be fixed.
17:33 < nsh> i saw earlier that there's [some kind of] simulator. could that be used to test convergence?
17:34 < maaku> gmaxwell: they're suggesting lowering the interblock time, but i'm more interested in an apples-to-apples comparison: direct drop-in replacement for current fork-selection rules
17:38 < maaku> they seem to have focused on lowering the interblock time, but it's just as applicable to raising the block size
17:44 < amiller> nsh there's a nice simulator by ebfull that simulates mining and block propagation, especially to do the selfish mining simulation, and in your browser with a neat little visualization https://bitcointalk.org/index.php?topic=326559.0
17:45 < gmaxwell> maaku: ignoring the cost to lite nodes, why not increase the block size by lowering the time?
17:45 < amiller> it's basically fast enough with the graphics turned off to do simple monte carlo things
17:45 < gmaxwell> assuming you're willing to tolerate the reduction in goodput.
17:45 < nsh> amiller, ty
17:46 < gmaxwell> Probably the biggest thing to chase here is the goodput implications.
17:47 < maaku> gmaxwell: shorter cycles leading to centralizatoin, mainly
17:47 < maaku> goodput?
17:47 < gmaxwell> The impact on litenodes can be fixed by turning the linked list of the blockchain to a MMR or skiplist and by using snarks to prove difficulty.
17:48 < gmaxwell> maaku: goodput is the actual amount of useful block data you can send, after removing the overheads from sending around orphans.
17:49 < maaku> yes those are my objection to lowering the interblock times: lite client poor performance, decreased gootput, and centralization
17:49 < gmaxwell> maaku: yea, okay, low enough latency has centeralization issues, but so does large enough blocksizes. Figuring out how to navigate that is important.
17:49 < maaku> vs. the corresponding increase in block size
17:50 < gmaxwell> Yea, I think I already know how to solve liteclients well enough. The latter two are big open questions for me.
17:51 < maaku> i think we can probably get shorter intervals than 10 minutes. 1 second is ludicrous though
17:52 < andytoshi> fwiw, aviv says they looked at goodput in the paper, had calculated a worst case of 4%
17:52 < andytoshi> and he did some calcs which suggested that was tolerable
17:52 < andytoshi> from a bandwidth perspective
17:52 < gmaxwell> andytoshi: tolerlable for what?
17:52 < gmaxwell> tolerable on my DSL?
17:52 < gmaxwell> :P
17:52 < andytoshi> yeah, he was talking 320kbps
17:52 < andytoshi> so, tolerable if you are doing nothing else :P
17:53 < gmaxwell> 1 second is ludricrous just compared to the radius of the world. I am on a ssh right now with a 200ms rtt (to NZ)
17:53 < gmaxwell> but I don't think there is any reason to waste time worrying about the specific number.
17:53 < andytoshi> yeah, 1sec seems crazy, but his goal is to have massive scalability
17:53 < maaku> not to mention it cuts of the Moon from the economic sphere of the Earth ... but I'm probably the only one who cares about that ;)
17:54 < gmaxwell> maaku: it's probably better to do that. We've already excluded mars in any case.
17:54 < gmaxwell> maaku: good fenses make good neighbors. :P
17:56 < amiller> ahhh thanks gmaxwell i've been trying to think of what that quote was
17:57 < Emcy> are we really precluding economic warfare with the moon here? Wizards pls.
17:58 < amiller> bitcoins in spaaaaaace
17:58 < sipa> spacoins
17:59  * nsh is definitely in the pro-Moon-inclusion bloc
18:00 < nsh> it's the economic divisions that invariably lead to orbital colonies declaring independence
18:00 < maaku> well 10 minutes is inclusive of cislunar + l4/l5, so that's a pretty expansive area that would be able to participate in the bitcoin network
18:00 < Emcy> heh did you watch elysium too
18:02 < maaku> more seriously I'd love for someone to formalize the bang-for-buck advantages of increasing the block size vs. decreasing the interblock time
18:03 < maaku> my understanding is that we'd get higher tps for the same cost tradeoff by increasing the block size vs. faster blocks
18:04 < Emcy> the block interval is not changing ever
18:05 < maaku> Emcy: we'd be hard forking anyway to increase the block size
18:06 < Emcy> i just dont see it happening.
18:06 < maaku> I don't see the reason to lower the block interval either (unless you can get to to be sub-second, but relativity says that's not possible without centralization)
18:06 < Emcy> and i dont think the block size things is as much of a done deal as people assume either
18:06 < maaku> But that's what people want, and the hypothetical scenario being explored by aviv's paper
18:06 < maaku> So I'd kinda like a formal response
18:07 < Emcy> do it on testnet
18:07 < maaku> Emcy: either bitcoin will increase it's transaction throughput, or it will become irrelevant
18:08 < sipa> maaku: how do you see that happening?
18:08 < maaku> The only ways of doing that are decreasing the interblock time, increasing the block size, or moving to off-chain transactions (which eliminate the relevance of bitcoin-as-a-currency)
18:08 < sipa> no, they eliminate the relevance of bitcoin-the-network
18:08 < sipa> not of bitcoin-the-currency
18:08 < sipa> s/eliminate/reduce/
18:08 < nsh> why couldn't a second network be spawned?
18:09 < maaku> bitcoin-the-currency only has value because of bitcoin-the-network
18:09 < nsh> (not that this would be preferential to solving problems; just curious in theory)
18:09 < Emcy> i know which one id rather to fade in relevance
18:09 < sipa> maaku: i would like to agree with that, but i think that's completely untrue today
18:09 < nsh> why couldn't you have bitcoin-network-0 at saturation, and start another bitcoin-network-1 for spillover?
18:09 < sipa> what's the point?
18:10 < maaku> sipa: i think it's still true today. bitcoin-the-currency has speculative value because of the speculative future of bitcoin-the-network
18:10  * nsh shrugs
18:10 < sipa> maaku: i'm very unconvinced about that
18:10 < sipa> i think speculation happens because people see the value go up because of speculation because people see the value go up
18:11 < sipa> i think many, many speculators are actually very uncertain about the long term survival
18:11 < sipa> or maybe i'm just projecting my own opinion :)
18:11 < maaku> ok, the value bitcoin has which is beyond tulips then
18:12 < nsh> what if it's tulips all the way down, madam?
18:12 < maaku> then we're in for a crash to zero
18:12 < maaku> i don't think that's likely
18:12 < nsh> my favourite price :)
18:12 < nsh> no, there is a utility-based floor
18:13 < maaku> and if i introspect and say why it's not likely, it's because bitcoin-the-network has utility
18:13  * nsh nods
18:13 < nsh> and that utility is predicated on a non-zero price
18:13 < maaku> but you remove that utility (by moving 100% off chain to a currency-agnostic platform), then it really is tulips all the way down
18:14 < sipa> who said anything about 100%, and who said currency-agnostic?
18:15 < maaku> show me an off-chain solution which has the same security properties as bitcoin but doesn't require the expensive global consens protocol... and you will have demonstrated bitcoin's replacement
18:16 < sipa> it won't have the same security properties, but bitcoin isn't perfect either
18:16 < maaku> eather off-chain solutions are fundamentally weaker in some way, or they will replace bitcoin by virtue of being less costly and less burdonsome
18:16 < nsh> diversification is generally more useful than replacement
18:16 < sipa> bitcoin in particular is weak regarding privacy
18:16 < nsh> forms of travel have diversified a lot from walking, but none has ever fully replaced walking
18:17 < sipa> maaku: anyway, how do you see bitcoin being scaled up?
18:19 < maaku> sipa: increasing the block size in lock step with scalability improvements, to get a couple orders of magnitude more tps,
18:19 < maaku> and introduction of centralized but otherwise trust-free private accounting servers
18:19 < maaku> whch will handle a lot of traffic with a different security tradeoff
18:19 < sipa> any particular scalability improvements you're thinking of?
18:20 < maaku> but one which is suitable for self-issued assets
18:20 < Emcy> if increasing the TPS via blocksize creates any new points-of-control/regulation.whatever, they WILL be exploited
18:20 < Emcy> its as simple as that
18:20 < Emcy> maybe not even for 20 years, but it will happen
18:21 < maaku> indexes for lite clients, partial-pow for distributing transaction lists, and moving to proof-provided utxo validation
18:22 < maaku> like peter's mmr for example, but you can do almost as well without sacrificing lite clients with more traditional utxo structures
18:22 < sipa> well indexes certainly help light clients, but they certainly don't help performance of full nodes
18:22 < sipa> what is proof-provided utxo validation?
18:22 < maaku> it means updatable proofs are included with transactions
18:23 < maaku> so full nodes require only small constant-space data
18:24 < gmaxwell> maaku: split-mmr doesn't completely avoid screwing lite clients... since they still can't write a proof that their coin isn't spent.
18:24 < maaku> (pushes the maintenance work of validation from the full-node/miner onto the wallet)
18:24 < gmaxwell> (they still need help to write the proof)
18:24 < maaku> gmaxwell: yes but that can be outsourced
18:24 < gmaxwell> yes, agreed.
18:25 < gmaxwell> maaku: the other issue is shipping the proofs increases bandwidth.
18:25 < gmaxwell> though a tradeoff is possible like "don't send me proofs, I have all the data"
18:26 < sipa> sounds like a jehova's witness
18:26 < maaku> heh
20:49 < amiller> damn i don't think there's any way for my tournament idea to work with current bitcoin :/
20:55 < HM2> ok enough of that madhouse. thanks for the info gmaxwell
21:56 < nOgAn0o> Hi, me.
21:58 < Emcy> "Since Bitcoin's security relies primarily on the number of confirmations received instead of on elapsed time, we end up getting irreversibility of transactions with very high probability in far less than 10 minutes.
21:58 < Emcy> is that really true
21:59 < gmaxwell> no, it's not— it depends on your threat model.
22:00 < Emcy> the part before the comma i mean
22:00 < gmaxwell> no, it's not— it depends on your threat model.
22:01 < Emcy> so "longer" blocks are statistically a better confirmation of a txn than shorter ones?
22:03 < gmaxwell> Emcy: in some threat models, e.g. where the attacker is going to lease power to do a short reversal time after the first confirmation is basically all that matters... how much work must the attacker do to undo the confirmation.
22:05 < Emcy> right
22:05 < gmaxwell> Figuring out the safty in their revised selection algorithim isn't simple either. e.g. you could have a block with 10 confirms, but its really compeating with another subgroup which is only 1 confirm behind, and maybe its actually ahead but you've just not heard of one of the blocks required to make it win.
22:05 < gmaxwell> Fun attack in that model: "delayed announcement of your own stale blocks"
22:06 < Emcy> i want to try and read and understand enough to work out for myself if its viable or not
22:06 < Emcy> thought the immediate claim of 1 second blox makes me skeptic
22:06 < gmaxwell> well just ignore the actual numbers.
22:07 < gmaxwell> 1 second would give big advantages to consolidations.
22:07 < Emcy> consolidations?
22:08 < gmaxwell> hashing datacenters.
22:08 < gmaxwell> (or pools for that matter)
22:09 < Emcy> oh yes
22:10 < Emcy> its only a couple of times the causal diameter of the earth :/
22:10 < gmaxwell> delayed announcement attack— you're mining and you find your block stale. but instead of announcing it, you put it aside and hope that later there is less than one block of difference between a fork containing that block and another fork, and if that happens you start mining on it and delay announcing the tiebreaking stale that would let everyone else know that they'd best be mining on that subgroup, until you've found a block.
22:10 < gmaxwell> Emcy: right.
22:10 < gmaxwell> 1 second is almost certantly too fast... though it would take simulations to tell for sure.
22:11 < gmaxwell> not to mention that pratically all mining hardware today has multisecond latencies.
22:11 < Emcy> tahts why im skeptik...another paper leading with a fantastical claim
22:11 < gmaxwell> p2pool had to increase from 10 second shares to 30 second shares because of slow hardware responses.
22:12 < Emcy> did you see p2pool jumped to 3% power this week. hashpower doubled out of nowhere
22:12 < zooko> Hello, wizards.
22:12 < gmaxwell> also, if you wanted to talk about viable: more viable in the context of bitcoin would be basically makine p2pool a protocol requirement with a rule that new shares can't displace transactions in prior ones.
22:12 < Emcy> feelsgoodman.png
22:13 < gmaxwell> and doing that would avoid breaking the scalablity of lite clients.
22:13 < gmaxwell> (in fact, it would just be a soft fork)
22:13 < Emcy> zooko excuse me sir, im a warlock
22:14 < zooko> ☺
22:15 < Emcy> gmaxwell i dont see that happening either. If p2pool gets too big its just back to square one. Unless theres a way to split them in a decentralised way
22:15 < gmaxwell> Emcy: ...
22:15 < gmaxwell> Emcy: ::sigh::
22:15 < gmaxwell> Emcy: what I'm suggesting has nothing to do with p2pool.
22:15 < gmaxwell> Emcy: except using the same technique
22:16 < Emcy> in all but name then?
22:16 < gmaxwell> Emcy: I'm pointing out that you don't have to hardfork bitcoin to have a fast blockchain. We already have a 30 second blockchain, it's called p2pool.
22:16 < Emcy> ah thats true
22:16 < gmaxwell> The only distinctions are that (1) not everyone is forced to use it, (2) it allows later shares to reverse earlier ones— they don't accumulate.
22:17 < gmaxwell> those could be fixed. In such a world you could still have a p2pool mining that network which was a fraction of the size.
22:17 < gmaxwell> but the two level chain would give you fast confirmations.
22:18 < gmaxwell> also because its two level it wouldn't increase work for lite clients unless they were interested in hearing about fast confirms
22:18 < Emcy> could it work the other way?
22:19 < Emcy> bitcoin could become a subchain for something else
22:19 < gmaxwell> not without changing bitcoin's rules in a hardforking way.
22:20 < Emcy> perhaps 10 minuties was actually too fast for base chain then
22:20 < gmaxwell> Emcy: in any case, thanks, if I bring up that point again I'll be sure to not mention p2pool. :)
22:26 < Emcy> heh so im your litmus test for being able to properly explain your ideas to the masses :)
22:26 < Emcy> if thats how i help bitcoin so be it
22:27 < gmaxwell> hah. well if it confuses you, its going to confuse other people.
22:29 < Emcy> doesnt help ive got a foot inside migraine territory right now
22:29 < Emcy> in fact yeah i better go
22:29 < Emcy> later wizerds
22:34 < gwillen> Hello zooko, fancy seeing you here.
22:52 < zooko> Hello, gwillen.
--- Log closed Sat Dec 07 00:00:38 2013