00:22:50 gmaxwell: Do you guys plan to decentralize BTC when the blockchain grows to multiple terabytes? 00:23:37 gavinandresen 00:23:56 like, in 100 years? 00:24:05 I thought it was gonna be only a few years 00:24:30 it's growing at well under 10gb/year 00:25:06 With increased use it will grow faster I think. 00:25:50 the block limit is 1mb, let's suppose that each one takes 1mb on disk, and that the blocks come every 10 minutes 00:26:08 that's 144 per day, 52560 per year 00:26:12 52.5 gb 00:26:27 so 20 years minimum 00:26:44 nOgAnOo: Bitcoin already is decenteralized, so I'm confused by your question. 00:31:18 gmaxwell, i think he means storage of old blocks 00:31:47 andytoshi: yes, but there is broad consensus that we will need to increase the max blocksize soon-ish. 00:31:57 Centralize.. I meant.. I'm sorry, I'm a little slow. 00:32:13 One sec I'll get you the link I just seen. 00:32:33 http://www.youtube.com/watch?v=PfeA94BedQI 00:32:56 "Bitcoin: what you're not being told" 00:33:16 nOgAnOo, nobody is going to watch that 00:33:18 mmm. it is on youtube, it must be correct. 00:33:39 you might as well have just asked us to stare at the wall for 5 minutes 00:33:56 nOgAnOo: there are lots of plans for how to scale up bitcoin while keeping it decentralized. 00:34:16 nOgAnOo: actually IMPLEMENTING them will take time, careful thought, etc. 00:34:45 In any case, scaling up is in the category of "good problem to have" 00:36:38 * andytoshi is actually watching the video.. 00:36:46 Ok thank you for your answer, soon to be King of the World. :) I am sorry to disturb you all but I thought it was a worthwhile question. Thank you for your time and God bless you and have a great night. <3 00:37:22 "250 gigabytes within 2 years" 00:38:09 andytoshi, otherwise known as "i pulled this number out of my ass" 00:38:15 mmhmm 00:38:32 after that it sorta crumbles from lies into incoherency 00:38:57 to answer your question nOgAnOo, there is thought going into blockchain expansion, but no concrete plans 00:39:14 and it's not even close to as urgent as that video claims 00:40:05 Ok I am just a Christian researcher.. trying to figure out how cryptos may fit into the New World Order future currency. Thanks for your time, Andy. 00:40:21 * nsh smiles 00:40:41 nOgAnOo: if you listen to this channel you'll see links to research drifting by 00:40:55 following them would involve a -lot- of background research i'm afraid 00:40:55 so you're a moron asking why you're a moron that doesn't understand a different moron, good show 00:40:59 good show indeed 00:41:33 but you're not going to get a coherent picture of anything from youtubers 00:42:13 lol 00:42:58 andytoshi: or "christian" researchers ... or any "religious sect" researchers, for that matter 00:43:01 andytoshi: "<3 00:43:44 did I read christian researcher in bitcoin-wizards? makes sense, mixing different kind of magic 00:44:35 jrmithdobbs: i recently moved to america, was caught off guard by the amount of "god bless"s that go on between strangers here 00:44:40 so i give them all the benefit of the doubt 00:45:08 gesundheit 00:45:17 andytoshi: where i grew up in texas and have developed a 7th sense for the bullshit and know exactly when to start mocking instead of attempting to teach 00:45:21 andytoshi: ;p 00:46:11 well, i'm still learning ;) 00:46:30 nOgAnOo: in the new world order, maybe vatican opens the next mtgox :p 00:51:58 there are sci-fi precendents for this 00:52:18 (deranged-seeming religious beliefs inspiring technological uptake from strange quarters) 00:52:36 also historical precedents :) 00:52:44 but the sci-fi ones are more fun 00:53:06 we don't need sci-fi examples, we've got luke! ;p 00:59:26 * nsh smiles 01:20:07 i'm trying to think of how to explain what's significant about the choices made about how much deposits are needed for the lottery game 01:20:14 in N player lottery game from this paper 01:20:21 say each party puts in 1 coin 01:20:29 the point is that one person is supposed to win N coins 01:20:37 first just note that the expected utility is zero 01:21:13 expected money payout anyway 01:21:41 if the other party goes away you don't necessarily learn the result 01:21:45 one of the parties i mean 01:22:13 but who cares if he has already put in his money 01:22:42 there's a sort of common problem in protocols like this where you show fairness is impossible 01:22:57 suppose you *could* carry out the protocol fairly if someone doesn't send their message in time 01:23:08 that means that last parties message is optional and he might as well not send it 01:23:24 but then the second to last party's input must have mattered 01:23:48 so you follow that back and either you already knew the outcome for the beginning, or someone's participation makes a difference whether it's fair or not 01:23:59 and so the solution is to overcompensate 01:24:59 each party places down a *security deposit*, in addition to their bet, that is used to patch over the lack of computational ability in case one party doesn't cooperate 01:25:16 so the choice in this paper is to make each deposit equal to N(N-1) 01:25:50 in other words, the deposit is one *whole jackpot for every player* 01:26:01 that's a pretty extreme deposit 01:26:41 but it is giving the pretty much best possible guarantee, which is pretty cool 01:26:43 Texas Holdem is what's needed, sir. 01:27:17 I searched thine internet far and wide.. no working Texas Holdem BTC games on the net.. 01:40:27 i think i can do better 01:40:36 i think there's a way to improve on the total amount of liquidity needed in their scheme 01:41:32 suppose you're willing to wait for t rounds 01:42:03 the first party puts in N coins, the second party puts in N-1 coins, the third party puts in N-2 and so on 01:42:39 and you release people from their obligations in rounds :o 01:44:00 so if parties do not show up, the number of rounds is reduced? 01:50:02 tl;dr 09:09:14 Fistful_of_LTC is now known as Fistful_of_AFK 09:48:33 TD[away] is now known as TD 11:06:05 lianj_ is now known as lianj 11:09:34 Guest8739 is now known as jarpiain 12:00:01 sorry about that. was drunk as fuck last night :-) 13:01:57 nsh- is now known as nsh 13:46:13 cool paper! https://bitcointalk.org/index.php?topic=359582.20 13:46:18 would love to hear gmaxwell's opinion when he gets up 13:46:22 and has time to read 13:49:00 <_ingsoc> Mike_B: Would it have to operate as an alt? 13:49:47 well, it seems like he's proposing a different way of considering transactions confirmed - orphaned blocks should also count as confirming tx's 13:49:55 so you could adopt that rule in btc i guess 13:50:22 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 13:50:33 <_ingsoc> Unlikely before getting some real-world data. 13:50:39 right, i'm also skeptical 13:50:57 i'm also curious if there are holes that can be poked in that... not entirely sure it's impossible to game it 14:47:36 Fistful_of_AFK is now known as Fistful_of_LTC 15:20:56 typex, probably the least regrettable drunk IRC posting I've seen.. 15:23:17 every bifurcation in a tree represents a halving of computing power, no? 15:23:21 i'll have to read tho paper.. 15:24:25 and having one block per second is going to cause massive network split effects 16:26:28 <_ingsoc> _ingsoc is now known as Guest58726 16:29:12 Muis_ is now known as Muis 16:35:17 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 16:35:54 so you are still thinking in terms of chains, but your "which chain is best" algorithm considers all active forks along the way 16:37:17 they prove that each block is eventually accepted or rejected (i.e. this does not cause permanent network splits) 16:38:38 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 16:38:51 they claim that this does not affect their system as badly 16:39:20 these are all proven, but the statements and proofs are technical and i don't have the time for a detailed analysis 16:41:19 anyway my impression is that this is worth taking seriously 16:43:24 andytoshi what if two inputs are spent differently in two different chains ? 16:45:05 eventually one side of the fork will "collapse" as there is a greater subtree weight on that 16:45:35 and as blocks are piled on the usual more-time-means-more-confirmation heuristic applies 16:45:49 ah 16:46:14 because everybody looks at the greatest subtree weight to decide what to mine on, there is an avalanche 16:56:45 hm 16:56:51 are there any risks of using this? 16:57:03 i feel like we had a reason not to want to do it this way but maybe it's fine? 16:59:11 i'm trying to read an undersatnd the security definitions... 16:59:47 that was my thought too, but on a cursory review the math holds up 17:00:10 so i'm trying to think about practical attacks, potential for DoS, storage/bandwidth usage.. 17:00:34 amiller had suggested this before. 17:00:50 (or things substantially similar) 17:00:53 so how did you talk me out of it, i don't remember :p 17:01:13 * andytoshi-logbot is already logging 17:01:31 A couple reason, one is that its an enormous cost increase to lite codes (e.g. hundreds fold more bandwidth, potentially) 17:01:39 s/codes/nodes/ 17:02:48 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. 17:03:09 no, blocks commit only to a single parent 17:03:36 i'm not clear how the parent is chosen when there are multiple options with no existing subtree 17:04:00 andytoshi: uh, so why do you and someone who joined the system later than you pick the same solution at all? 17:04:37 e.g. you and I get the same longest tree, but different forrests, and so now later we choose different longest trees. 17:04:39 after some time, new blocks will be mined on top of one or more of the options 17:04:54 hmm, everyone starts from the same genesis.. 17:04:57 i think they say that each block does point to its 17:05:03 ancestors 17:05:22 maybe just for lite nodes optimization hmm 17:05:25 it has to be all of the ancestors needed to compute the highest difficulty, if they do that, then its what amiller proposed before. 17:05:49 for a given leaf node, there is only one ancestor (and only one chain back to the genesis) 17:05:56 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. 17:06:15 so, algorithm 1 on page 18 says what i'm saying here, it's like 5 lines and a bit more precise 17:07:00 there is an assumption that everybody eventually hears about every block, and synchronization happens because long-term forks are unstable 17:07:22 one or the other will have a stronger POW on its subtree, and then everyone will mine on that 17:08:10 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. 17:08:33 no such mechanism 17:08:38 well, none that i saw 17:08:53 the assumption is that every block propogates eventually 17:09:29 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 17:10:14 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 17:10:22 how do you prevent denial of service then? e.g. I constantly feed you difficulty 1 orphans for block 1? 17:10:51 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. 17:10:57 right, exactly 17:11:16 i'm not sure 17:11:37 hmmm 17:12:30 also, what about problems with goodput? lets imagine this with blocktimes of 1ms (e.g. way below the latency betwen nodes) 17:12:54 not sure, i skipped over the propogation-time analysis 17:13:06 you would eventually converge on sufficiently old history, but you're spending all your bandwidth sending orphans. 17:13:25 i think that's correct, my impression is that they did not look at bandwidth usage 17:14:08 i wish they had published a shorter version that did not spend so much time discussing common knowledge about bitcoin.. 17:14:10 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. 17:14:37 the opposite of solidcoin ;) 17:16:03 same as geistgeld but geistgeld was sha256 liquidcoin scrypt 17:16:06 i expect if you were to ask the authors this, they would try to come up with some heuristic for ignoring spam blocks 17:17:05 in the limit, you ignore all but the highest-difficulty chain, and you get bitcoin 17:17:45 and it seems like anything weaker than that has the potential to cause forks when peoples' definition of "spam" diverges 17:17:56 so you'd need to just accept everything, which is what this paper proposes 17:18:01 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 17:18:19 ...and then gmaxwell's "spam a trillion diff-1 blocks" attack would work 17:18:54 andytoshi: yea you could have any amount of difference between two subtrees. 17:19:39 iddo: if a node doesn't know everything, he can't prove or disprove that a certain subtree will win 17:19:54 and that'd certainly be the case for every node in a high-block-rate network 17:20:15 so if you ignored blocks just because the sender couldn't prove they were worthwhile, you'd end up ignoring everything. 17:20:37 and again your ignoring heuristic creates potential for a long-term split 17:21:21 maybe this is an important thing to simulate? 17:21:31 they've gone through the trouble of formalizing what the algorithm should be 17:21:45 the ddos behavior to implement seems straightforward to describe too 17:22:00 do we have a simulator yet? there was some serious bounty.. 17:22:01 so what i'd expect is that the ordinary algorithm gets horribly overloaded by easy ddos 17:22:20 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 17:22:40 https://bitcointalk.org/index.php?topic=326559.0 17:23:06 pay it? 17:23:32 call the bounty claimed 17:23:47 kjj first posted the bounty i mean 17:23:59 ahh 18:28:53 <_ingsoc> Chicago has given up. :( 18:29:24 ? 18:47:51 hi :-) 18:51:50 <_ingsoc> sipa: -!- Chicago [~Chicago@2001:558:6033:ff:4450:74c5:b55:35d3] has quit [Quit: Leaving] 18:51:55 <_ingsoc> It was a lame joke. 18:59:32 sigh, i bought in at 1050, was gonna just hold indefinitely 19:00:24 * andytoshi takes a 20% bath 19:03:12 sorry, wrong channel 19:36:35 enjoy your haircut andytoshi 19:46:18 coryfields is now known as cfields 19:52:24 perhaps this channel should require login too 19:52:27 -dev has improved 19:53:32 just keep it on the dl 19:54:08 Emcy: too late for that 19:55:21 well ive never told anyone....... 19:55:33 never knew if this room was supposed to be quiet 19:55:46 quiet isn't the goal. relevant is. 19:57:01 i thought this was the place where we do some blu sky thinking, generate some thought showers and synergise dem paradigms 19:57:49 Emcy: you tell people privately, when you think it'd benefit the channel for them to be here 19:59:49 am I blind or does this new paper not actually address any of the scalability concerns which necessitate a long interblock time? 20:02:06 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 20:02:23 and they fix that specific problem by using the forks to determine which block to mine on 20:03:26 so ignorance, it seems 20:03:31 someone should invite them here 20:04:12 might be worthwhile, there was a conversation a bit earlier where gmaxwell pointed out a simple dos attack 20:04:47 and it seemed to me that any attempt to fix it short of just throwing out the whole idea, would cause forks to happen 20:06:21 there's all sorts of DoS vulnerabilities and bad incentive structures that emerge when you lower the interblock time to 1 second 20:07:20 doesn't stop "most-work chain of the most-work tree" being a possibly good heuristic though 20:07:42 but as usual with academic papers, there are claims blown way out of proportion :( 20:08:12 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 20:08:27 and they have to keep them around, just in case they wind up totalling more than the "real" chain 20:08:51 maaku: yeah, and the forum posts are absurd 20:11:37 andytoshi: no, they don't have to keep them around because there doesn't have to be global consensus on the forks 20:11:51 they just decide locally how many they want to keep around 20:12:02 and garbage remove the rest 20:12:29 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 20:13:02 permanently? no 20:13:36 temporarily, yes, but it's no different than when a fork occurs now, and nodes stay on the most recently heard block 20:14:11 here all forks are involved in the decision as to what is the definitive chain 20:14:54 yes, and eventually the chain with the most hash power behind it will overcome all those itsy bitsy forks 20:15:42 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 20:15:43 ok, but until then, the DOS'd node needs to keep all the forks around 20:15:51 why? 20:16:06 because the node doesn't know that the chain with the most hashpower will overcome the forks 20:16:17 or if it does, that it'll continue to overcome 20:16:25 so what? 20:16:47 so how does it decide what's garbage and what's not? 20:16:59 all forks are garbage 20:17:30 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 20:17:44 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 20:17:55 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 20:18:05 if you're using information from the forks, you need to hold the forks 20:18:22 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 20:18:33 *and that is not a problem* 20:18:36 and if you keep them all, you get DOS'd, if you keep none of them, you have bitcoin 20:18:47 you already make decisions differently from other nodes 20:19:05 when you receive an orphan block, you choose the block you already have 20:19:14 that's based on local knowledge, namely the arrival times of the two blocks 20:19:18 which are different from node to node 20:19:31 yes 20:19:33 this is no different than when a GHOST protocol node chooses which orphan forks to keep around for 20:20:01 you can't get permanently stuck on a fork because you have a few orphans lying around 20:20:17 not unless someone is using more nethash than the entire network to create those orphans 20:20:31 in which case this is another instance of the 51% attack 20:20:34 the problem is that you don't know if somebody has more nethash than the entire network 20:21:31 andytoshi: again, so what. that describes bitcoin currently 20:22:17 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 20:22:35 the problem is that you don't know if somebody has more nethash than the entire network 20:22:53 ^^ that's nothing more than the majority-nethash attacker scenario 20:22:54 whereas here you might be receiving orphans from many parties, none of whom individually have enough POW to overcome the main chain 20:23:00 which already trivially defeats bitcoin 20:23:11 mmmm Hi guys 20:23:27 seems like you're talking about our paper? 20:23:31 yes 20:23:34 hi avivz78, yes 20:23:36 (was away at another window) 20:23:58 I'd be happy to respond / discuss 20:24:57 can someone explain to me how bitcoin proposes to handle low difficulty ddos attacks? 20:24:59 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 20:25:22 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. 20:25:25 partially, the checkpointing mechanism 20:25:49 As I see it, bitcoin has to handle this too 20:25:56 avivz78: can you explain "low difficulty ddos attacks" (there's more than one thing you could be referring to) 20:26:03 well, it is hard to create enormous fraudulent individual chains 20:26:45 \msg avivz78 mmm 20:26:48 nope 20:27:02 I'm on a web client not sure I can privatemessage 20:27:25 andy - isn't it just as hard to create large fraudulent trees? 20:27:40 <_ingsoc> azariah4: Can we contact you via e-mail? 20:28:15 avivz78: not quite, because you can avoid difficulty increases by staying at low depth 20:29:17 avivz78: yes it is just as hard, that's what I was trying to tell andytoshi 20:29:28 andytoshi: most-work, not longest 20:29:38 yes, i understand that 20:33:00 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 20:33:08 but i'm not clear on how bitcoin solves this problem 20:33:18 aside from checkpointing, which is a kluge 20:34:30 so i guess, i tentatively cede my point 20:34:37 sorry guys :} 20:34:41 I think these are all the same issue basically. I'd certainly like to learn a bit more about this as well. 20:36:47 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 20:37:22 which has more to do with validation and propogration times 20:38:47 both have the same effect 20:39:02 larger blocks imply more propagation time, imply more orphans 20:39:13 higher block rates imply more orphans too 20:39:25 We make the connection in the paper 20:39:48 most of the first half of the paper is about scalability alone. GHOST comes in at section 8 20:39:53 1 second blocks? 20:40:06 no, larger blocks come with efficiencies that aren't seen with smaller, more frequent blocks 20:42:01 like what? 20:42:14 (besides the headers) 20:42:34 batch validation 20:42:56 mempool gossiping and partial proof-of-work to "pre-validate" transactions of a large block 20:44:00 these can lead to very low propogation times for large, intermittant blocks 20:44:19 you'll need to explain those :-) 20:45:43 batch validation for example,how do you get a speedup? 20:47:47 well this is more software engineering, but there's ECDSA batch verification engines that are able to process signatures faster in a large group 20:48:30 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.) 20:49:17 mempool gossiping and partial proof-of-work is allowing miners to send blocks which almost meet the threshold 20:50:06 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) 20:50:49 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 20:54:52 can't you pre validate transactions upon reception even if they're not in blocks? 20:55:27 if you have them 20:56:05 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) 20:57:51 I thought the fees took care of DOSing in this case. Am I missing something? 21:04:26 fees are collected by miners not nodes 21:05:16 true, but they are anti-spam because the spammer would lose the fee if a miner includes the transaction 21:11:16 avivz78: i think the work you all have done is very valuable 21:11:23 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. 21:11:32 So I've been pondering it. I'm not sure I buy the argument yet. 21:11:35 but what it will do is allow bitcoin to scale to larger block sizes, not smaller interblock times 21:11:58 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." 21:12:04 zooko: do you understand the argument that a merged-mined altcoin can be attacked by bitcoin pools? 21:12:13 I thought that was pretty brilliant, so I decided to throw it out there even though I haven't really grokked the original argument. 21:13:06 * zooko thinks about maaku's question. 21:14:02 maaku: thanks! 21:16:00 I should say that we gained a lot from reading Meni Rosenfeld's work on the security analysis 21:18:27 zooko: it's the same argument, just with bitcoin placed in the position of a low-value altcoin 21:18:56 and to your friend, i'd say please give an example 21:19:14 (and if it really does provide value, I'd be willing to bet that enterprising miners would find a way to profit from it) 21:22:10 Well, time to go get some sleep 21:22:18 thanks for the fruitful discussion 21:22:23 I've learned a lot! 21:23:09 maaku: yes, that's an interesting question about if a public good can be made excludable. 21:23:20 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. 21:23:29 avivz78 has left #bitcoin-wizards 21:23:40 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. ☺ 21:23:42 yes, if it's work you can't get paid for then it probably eliminates that particular concern. 21:23:56 gmaxwell: yes, that quote from you is what I meant about you have already stupefied me. 21:24:00 zooko: did you see my timelock encryption ticking meta idea? 21:24:09 gmaxwell: I did not! Do tell! 21:24:35 zooko: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas search for "tick" 21:25:02 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 21:25:02 gmaxwell: how do you prevent someone from just skipping ahead in the sequence and decrypting what they're interested in? 21:25:07 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. 21:25:08 <_ingsoc> I really wish we could get someone who's interested in implementing some of those ideas. 21:25:12 <_ingsoc> How hard can it be? 21:25:14 maaku: you encrypt with all future solutions. 21:25:27 hrm i see 21:25:48 _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 21:25:59 gmaxwell: neat! 21:26:01 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. 21:26:05 and then you have to deal with #bitcoin-wizards ripping your stuff apart 21:26:23 <_ingsoc> andytoshi: How many people realistically are around competent enough to do it? Assuming money can be arranged for it. 21:26:39 _ingsoc: i see 61 users in this channel 21:26:40 maaku: this was yet another idea I've had while in the middle of lecturing someone that it wasn't possible. :P 21:26:46 _ingsoc: where are you going to get the money? 21:26:52 there are probably a dozen or three people on here who are competent enough 21:26:52 gmaxwell: Haha! 21:26:56 they are all very busy 21:27:08 zooko: step 1. Start altcoin step 2. ??? step 3. Profit! 21:27:12 :P 21:27:17 <_ingsoc> zooko: Tons of people want to see this stuff. It's easy to get it funded. 21:28:09 _ingsoc: somewhat self-referentially, I think implementing a lot of this would be a public good... 21:28:18 gmaxwell: yes, exactly! 21:28:43 <_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). 21:28:47 <_ingsoc> Pretty simple really. 21:29:36 <_ingsoc> Set your boundary so that you have enough for a development fund. 21:29:50 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. 21:30:44 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). 21:31:47 <_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. 21:32:11 <_ingsoc> Ofc people will game it. Hell, people are gaming Bitcoin as we speak. 21:32:33 <_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. 21:32:49 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. 21:32:57 gmaxwell: if you hit upon a hack to bypass that problem, please let me know. 21:33:27 "that problem": the public good of a decentralized tech 21:33:44 <_ingsoc> gmaxwell: There's always the option to open source it after a while of maturation. 21:33:50 ah cool aviv came here :) 21:34:26 <_ingsoc> gmaxwell: But if someone copies an open source coin, that's not bad in opinion. It's unlikely anyone is disadvantaged by that. 21:34:59 _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. 21:35:21 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? 21:35:23 amiller: yeah, he was really cool 21:35:53 <_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. 21:36:17 _ingsoc: bitcoin had some really good ideas, and it apparently has no inventor 21:36:19 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 21:36:22 so, the ideas hold up on their own 21:37:02 What nym does aviv use for academic publications? 21:37:20 Aviv Zohar? 21:37:28 <_ingsoc> gmaxwell: Satoshi pretty much premined Bitcoin to high heaven and nobody cared. 21:37:52 amiller: aviv said, he was happy to find an audience with so much passion, this does not happen to most papers :P 21:37:57 _ingsoc: thats really not true at all. 21:38:01 andytoshi, :) 21:38:06 <_ingsoc> gmaxwell: How? 21:38:24 _ingsoc: if thats the kind of garbage nonsense that people repeat when its not true, consider what happens when it is true. 21:38:48 <_ingsoc> gmaxwell: What incorrect about the statement? 21:38:52 <_ingsoc> What's* 21:39:10 are you serious 21:39:13 _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) 21:39:32 he crafted a block then mined one on it to check 21:39:39 _ingsoc: there were mutiple people using it from the first day. 21:39:45 <_ingsoc> gmaxwell: I'm not saying he did it in secret. I'm saying he mined it when nobody care about it. 21:40:20 <_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. 21:40:31 <_ingsoc> gmaxwell: I'm talking about the underlying economics. 21:40:37 _ingsoc: I don't even thing you can establish that satoshi actually mined it in any non-trivial amounts, in fact. 21:40:44 _ingsoc: and you're factually incorrect. 21:40:56 <_ingsoc> gmaxwell: You don't know that. 21:41:26 <_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. 21:41:37 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. 21:42:00 <_ingsoc> gmaxwell: Ofc that's factually incorrect, but that's not what I was trying to say. 21:42:11 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. 21:43:38 <_ingsoc> gmaxwell: That's a bit unfair. 21:44:34 <_ingsoc> gmaxwell: I'm not trying to go on the offensive. 21:45:13 They don't accuse people of behavior that many consider unethical. 21:45:45 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. 21:46:14 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. 21:46:19 gwillen: Which premined coins are people using now, except for ripple? 21:46:28 why do people use litecoin and not its direct predecessors. why did btc-e destroy a large number of "novacoins" 21:46:32 gmaxwell: Well, most of them were pointless for other reasons 21:46:34 gwillen: novacoin had to destroy their premine. 21:46:46 gmaxwell: I mean, you don't see people using ixcoin, but you also don't see people using i0coin 21:46:49 they're both just as dead 21:46:50 and the litecoine predecessors were heavily premined and are not used though they're functionally identical. 21:46:55 hmm. 21:47:17 <_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. 21:47:22 there is a long history of premined coins failing, and/or being forked into non-premine versions. 21:48:17 _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. 21:48:49 E.g. Satoshi wasn't doing an economically rational thing even though it may have turned out quite well for him. 21:49:12 <_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. 21:49:38 Probably a good assumption in terms of setting up the right defensive expectations. 21:49:46 <_ingsoc> Hah. 21:49:51 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? 21:50:43 <_ingsoc> Depends where the premine go to, Emcy. 21:50:47 _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. 21:51:12 shouldnt matter "where theyh go to", rationally 21:51:21 <_ingsoc> But it does. 21:51:38 <_ingsoc> All of this is in-group, out-group psychology. 21:51:54 yes, all that crap 21:52:11 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. 21:52:17 <_ingsoc> Whatever succeeds Bitcoin will rise out of that crap. 21:52:24 <_ingsoc> It might be pretty good crap, but it's still crap. 21:52:36 i dont think it can be succeeded 21:52:37 maybe ripple soved it, but only through methods which have offended a lot of people. 21:52:41 not fairly 21:52:46 <_ingsoc> gmaxwell: That's success though - the tech propagates. 21:52:54 <_ingsoc> gmaxwell: Not Ripple, the fork. 21:53:49 well how do you distribute? you mean adding a mining mechanism to a system that doesnt mine or use PoW? 21:54:21 _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" 21:55:15 <_ingsoc> gmaxwell: I forgot the question. It's 6am here. :/ 21:55:17 how do you fund anything with a premine. The coins are worthless. 21:55:19 :) 21:55:33 <_ingsoc> Emcy: The coins are sold for something of value. 21:55:36 unless you have exchanges ready to roll day 1 and stupid people pumping money in 21:55:45 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 21:55:55 day 1 exhanges is another huge klaxon 21:56:03 Emcy: people have tried, the plan is "create premine coin, pump coin, coins gain value" and yes, it fails. 21:56:19 <_ingsoc> gmaxwell: That's not the plan at all! 21:56:34 <_ingsoc> gmaxwell: How would pumping something like that create any real value? 21:56:43 'value' 21:56:49 _ingsoc: it's certantly the plan of some people, and anyone who has a distinctive plan is indistinguishable. 21:56:50 cos value is an illusion? 21:57:04 <_ingsoc> Value is better tech. That's the whole point of funding something like that. 21:57:13 heh new bitcoin forks list existing features as value-add. "Bitcoin fork with IPv6" 21:57:25 <_ingsoc> If the tech gets forked the tech is good (good enough for someone to fork it at least). 21:57:59 <_ingsoc> gmaxwell: People will always be full of shit. 21:58:00 _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) 21:58:13 people have forked coins just for the troll factor 21:58:17 (suffering convergence problems from the blocks being too fast) 21:58:35 <_ingsoc> gmaxwell: There's no doubt it has technical problems. 21:59:03 $12m according to whom? 21:59:26 is that float of mined coins existing? 21:59:33 assuming no slippage of course 21:59:34 <_ingsoc> Someone here should just take me up on it, get paid, make better tech, and then we can all go back to arguing. 21:59:37 <_ingsoc> Seriously. 21:59:47 Emcy: 'market cap', which is a but airy— but you can still go extract a hundred thousand dollars instantly by emptying the orderbooks. 22:00:07 feathercoin has orderbooks? jesus wept 22:00:28 and in my opinion that coin should have a value of approximately nothing. 22:00:55 it even has apparent "true believers" 22:01:01 stuff like that makes me think even bitcoins "cap" of 4bn or whatever is bollox 22:01:32 Emcy: sure, its bollox, but the orderbooks at least are real. 22:02:07 the scheme i see a lot is people mining altcoins and cashing out to btc 22:02:20 since btc mining became impossible 22:02:28 thats kinda weird 22:02:53 joecool_ is now known as joecool 22:02:55 Emcy: unless there are secret litcoin fpga/asic farms litecoin is probably using more electrical power now than bitcoin. 22:03:29 yeah thats bonkers 22:03:58 i prefer to think theres a secret fpga farm 22:04:39 yet i see threads the gist of which "check out my new 4 7790s for litecoin lol" 22:06:08 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. 22:07:42 Hey gmaxwell are you still working on opus? 22:07:49 I was happy to see the 1.1 release announcement today. 22:08:31 zooko: Yes. 22:08:32 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 22:08:35 at least on /g/ 22:08:40 gmaxwell: nice work! 22:09:42 when is steam gonna pick up opus for voice :( 22:09:59 gmaxwell: people are indeed still buying GPU's now. 22:11:18 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. 22:13:11 patents are scary 22:14:21 yeah its a shame that a competitive free/libre/nopatents video codec will probably never happen cos of that shit 22:14:50 HEy does anybody have a good list of patents that probably apply to NTRU cryptosystem? 22:15:05 cryptosystems, I meant to type, i.e. PK encrypt and dig sig. 22:15:20 NTRU is such an engineering mess in general. 22:16:04 The history of commercial cryptosystems has been a sad one. No one wants patented crypto, even if its awesome. 22:16:39 i dont actually understand how you can patent maths 22:16:42 OCB 22:17:10 where's context-aware acronym-explainer-bot when you need her 22:17:28 Emcy: you can certainly patent applications of math 22:18:08 but everything is applications of maths 22:18:31 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 22:19:39 thats one zinger of a reducto ad absurdum :P 22:20:40 but youre right, where does it end 22:20:56 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. 22:21:36 only if you want to make money off your system? 22:22:17 yes, lots of unfortunate opposing imperatives trying to Something Good under capitalism...... 22:22:33 well, so long as things cost money doing things with no prospect of making money may be somewhat ill-advised. ::shrugs:: no easy answers. 22:22:54 also true 22:23:05 we need crypto-patrons....... 22:23:33 amiller: in any case, I think relatively compact snarks of sum-difficulty could be produced. 22:23:53 amiller: as in circuits that only take minutes to make a difficulty proof for some whole blockchain. 22:24:06 i think so too. 22:24:43 though I think you'd want to be commiting to blocks included in a fork that way, instead of just hoping they show up. 22:25:03 did you guys resolve the objection about convergence I started? 22:25:53 i dunno 22:27:32 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 22:28:04 any opinions about that israeli paper yet? 22:28:23 we were just talking about that, I think you weren't included on the email thread, you probably should be. 22:28:56 its has a lot of similarity to amiller's early ideas about orphan rate targeting blockchains instead of block time targeting them 22:29:40 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. 22:30:27 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. 22:33:43 i saw earlier that there's [some kind of] simulator. could that be used to test convergence? 22:34:30 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 22:38:40 they seem to have focused on lowering the interblock time, but it's just as applicable to raising the block size 22:44:02 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 22:45:06 maaku: ignoring the cost to lite nodes, why not increase the block size by lowering the time? 22:45:17 it's basically fast enough with the graphics turned off to do simple monte carlo things 22:45:20 assuming you're willing to tolerate the reduction in goodput. 22:45:36 amiller, ty 22:46:20 Probably the biggest thing to chase here is the goodput implications. 22:47:37 gmaxwell: shorter cycles leading to centralizatoin, mainly 22:47:38 goodput? 22:47:45 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. 22:48:20 maaku: goodput is the actual amount of useful block data you can send, after removing the overheads from sending around orphans. 22:49:16 yes those are my objection to lowering the interblock times: lite client poor performance, decreased gootput, and centralization 22:49:23 maaku: yea, okay, low enough latency has centeralization issues, but so does large enough blocksizes. Figuring out how to navigate that is important. 22:49:30 vs. the corresponding increase in block size 22:50:04 Yea, I think I already know how to solve liteclients well enough. The latter two are big open questions for me. 22:51:00 i think we can probably get shorter intervals than 10 minutes. 1 second is ludicrous though 22:52:03 fwiw, aviv says they looked at goodput in the paper, had calculated a worst case of 4% 22:52:12 and he did some calcs which suggested that was tolerable 22:52:19 from a bandwidth perspective 22:52:30 andytoshi: tolerlable for what? 22:52:35 tolerable on my DSL? 22:52:36 :P 22:52:51 yeah, he was talking 320kbps 22:52:59 so, tolerable if you are doing nothing else :P 22:53:12 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) 22:53:37 but I don't think there is any reason to waste time worrying about the specific number. 22:53:46 yeah, 1sec seems crazy, but his goal is to have massive scalability 22:53:52 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 ;) 22:54:14 maaku: it's probably better to do that. We've already excluded mars in any case. 22:54:24 maaku: good fenses make good neighbors. :P 22:56:24 ahhh thanks gmaxwell i've been trying to think of what that quote was 22:57:46 are we really precluding economic warfare with the moon here? Wizards pls. 22:58:23 bitcoins in spaaaaaace 22:58:33 spacoins 22:59:33 * nsh is definitely in the pro-Moon-inclusion bloc 23:00:04 it's the economic divisions that invariably lead to orbital colonies declaring independence 23:00:43 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 23:00:46 heh did you watch elysium too 23:02:11 more seriously I'd love for someone to formalize the bang-for-buck advantages of increasing the block size vs. decreasing the interblock time 23:03:04 my understanding is that we'd get higher tps for the same cost tradeoff by increasing the block size vs. faster blocks 23:04:39 the block interval is not changing ever 23:05:27 Emcy: we'd be hard forking anyway to increase the block size 23:06:01 i just dont see it happening. 23:06:27 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) 23:06:30 and i dont think the block size things is as much of a done deal as people assume either 23:06:42 But that's what people want, and the hypothetical scenario being explored by aviv's paper 23:06:51 So I'd kinda like a formal response 23:07:24 do it on testnet 23:07:34 Emcy: either bitcoin will increase it's transaction throughput, or it will become irrelevant 23:08:20 maaku: how do you see that happening? 23:08:21 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) 23:08:38 no, they eliminate the relevance of bitcoin-the-network 23:08:43 not of bitcoin-the-currency 23:08:55 s/eliminate/reduce/ 23:08:59 why couldn't a second network be spawned? 23:09:06 bitcoin-the-currency only has value because of bitcoin-the-network 23:09:15 (not that this would be preferential to solving problems; just curious in theory) 23:09:26 i know which one id rather to fade in relevance 23:09:29 maaku: i would like to agree with that, but i think that's completely untrue today 23:09:43 why couldn't you have bitcoin-network-0 at saturation, and start another bitcoin-network-1 for spillover? 23:09:55 what's the point? 23:10:16 sipa: i think it's still true today. bitcoin-the-currency has speculative value because of the speculative future of bitcoin-the-network 23:10:20 * nsh shrugs 23:10:27 maaku: i'm very unconvinced about that 23:10:48 i think speculation happens because people see the value go up because of speculation because people see the value go up 23:11:21 i think many, many speculators are actually very uncertain about the long term survival 23:11:44 or maybe i'm just projecting my own opinion :) 23:11:44 ok, the value bitcoin has which is beyond tulips then 23:12:08 what if it's tulips all the way down, madam? 23:12:26 then we're in for a crash to zero 23:12:35 i don't think that's likely 23:12:35 my favourite price :) 23:12:52 no, there is a utility-based floor 23:13:02 and if i introspect and say why it's not likely, it's because bitcoin-the-network has utility 23:13:07 * nsh nods 23:13:16 and that utility is predicated on a non-zero price 23:13:56 but you remove that utility (by moving 100% off chain to a currency-agnostic platform), then it really is tulips all the way down 23:14:18 who said anything about 100%, and who said currency-agnostic? 23:15:22 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 23:16:03 it won't have the same security properties, but bitcoin isn't perfect either 23:16:04 eather off-chain solutions are fundamentally weaker in some way, or they will replace bitcoin by virtue of being less costly and less burdonsome 23:16:08 diversification is generally more useful than replacement 23:16:19 bitcoin in particular is weak regarding privacy 23:16:29 forms of travel have diversified a lot from walking, but none has ever fully replaced walking 23:17:11 maaku: anyway, how do you see bitcoin being scaled up? 23:19:23 sipa: increasing the block size in lock step with scalability improvements, to get a couple orders of magnitude more tps, 23:19:32 and introduction of centralized but otherwise trust-free private accounting servers 23:19:48 whch will handle a lot of traffic with a different security tradeoff 23:19:59 any particular scalability improvements you're thinking of? 23:20:01 but one which is suitable for self-issued assets 23:20:19 if increasing the TPS via blocksize creates any new points-of-control/regulation.whatever, they WILL be exploited 23:20:23 its as simple as that 23:20:47 maybe not even for 20 years, but it will happen 23:21:31 indexes for lite clients, partial-pow for distributing transaction lists, and moving to proof-provided utxo validation 23:22:12 like peter's mmr for example, but you can do almost as well without sacrificing lite clients with more traditional utxo structures 23:22:24 well indexes certainly help light clients, but they certainly don't help performance of full nodes 23:22:36 what is proof-provided utxo validation? 23:22:59 it means updatable proofs are included with transactions 23:23:11 so full nodes require only small constant-space data 23:24:04 maaku: split-mmr doesn't completely avoid screwing lite clients... since they still can't write a proof that their coin isn't spent. 23:24:09 (pushes the maintenance work of validation from the full-node/miner onto the wallet) 23:24:14 (they still need help to write the proof) 23:24:31 gmaxwell: yes but that can be outsourced 23:24:39 yes, agreed. 23:25:20 maaku: the other issue is shipping the proofs increases bandwidth. 23:25:44 though a tradeoff is possible like "don't send me proofs, I have all the data" 23:26:26 sounds like a jehova's witness 23:26:35 heh