| --- Log opened Thu Jan 01 00:00:10 2015 | ||
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Client Quit] | 00:00 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 00:00 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Client Quit] | 00:03 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 00:03 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Client Quit] | 00:06 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 00:48 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Client Quit] | 00:50 | |
| -!- andy-logbot [~bitcoin--@wpsoftware.net] has quit [Remote host closed the connection] | 01:05 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 01:05 | |
| -!- andy-logbot [~bitcoin--@wpsoftware.net] has joined #bitcoin-wizards | 01:05 | |
| * andy-logbot is logging | 01:05 | |
| -!- digitalmagus8 [~digitalma@s173-180-44-168.bc.hsia.telus.net] has joined #bitcoin-wizards | 01:29 | |
| -!- digitalmagus8 [~digitalma@s173-180-44-168.bc.hsia.telus.net] has quit [Changing host] | 01:29 | |
| -!- digitalmagus8 [~digitalma@unaffiliated/digitalmagus] has joined #bitcoin-wizards | 01:29 | |
| -!- digitalmagus [~digitalma@unaffiliated/digitalmagus] has quit [Ping timeout: 265 seconds] | 01:30 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards | 01:36 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] | 01:51 | |
| -!- shesek [~shesek@109.67.132.151] has joined #bitcoin-wizards | 01:56 | |
| -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-fsyrnkbfyjbhuuui] has quit [Ping timeout: 256 seconds] | 01:58 | |
| -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-ymvadbglnyvyrkdt] has joined #bitcoin-wizards | 02:00 | |
| adam3us | happy new year wizards :) may 2015 be even more interesting if thats possible without our heads popping from blockchain coolness overload. | 02:27 |
|---|---|---|
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Ping timeout: 265 seconds] | 02:27 | |
| adam3us | yeah anyway. so maybe people skimmed vitalik's latest attempt to repair proof of stake that he calls "weakly subjective". the idea is there is a stake (pre commit to some coins) and you are only allowed to vote on one branch of the chain, if anyone sees you double vote (and i guess your vote doesnt count unless you pre-commit to it to cast it) | 02:30 |
| op_mul | adam3us: you got snipped there. | 02:31 |
| gmaxwell | adam3us: the precommit and lose your coins part is something we've discussed here in the past. (IIRC Zooko was the first I heard propose it.) | 02:31 |
| -!- jtimon [~quassel@34.pool85-59-141.dynamic.orange.es] has joined #bitcoin-wizards | 02:31 | |
| adam3us | op_mul: really that was only 6 lines? | 02:31 |
| gmaxwell | But, e.g. it doesn't prevent getting rid of your bonded coins and the replacing the chain. | 02:32 |
| op_mul | was that the post that "solved" boostrapping nodes with ask-a-friend? | 02:32 |
| gmaxwell | adam3us: your line ended with "unless you pre-commit to it to cast it)" | 02:32 |
| -!- MoALTz__ [~no@user-188-33-7-126.play-internet.pl] has quit [Quit: Leaving] | 02:32 | |
| adam3us | yeah that was the end of it :) | 02:32 |
| -!- MoALTz [~no@user-188-33-7-126.play-internet.pl] has joined #bitcoin-wizards | 02:32 | |
| adam3us | then if they see your double vote they can prove it and you lose some of your stake. so then obviously as there's no mining cost, people can just create fake histories from further back repeatedly and it devolves to the usual nothing at stake, his attempt to repair that is to impose a kind of rolling auto-checkpoint | 02:33 |
| adam3us | where its defined you cant go further back than n-blocks. | 02:33 |
| op_mul | "auto checkpoint" really is a oxymoron. I wish altcoins wouldn't use that as a security feature. | 02:33 |
| adam3us | he didnt use that term, he calls it "weak subjectivity" but anyway i hope its clear; he calls it subjective because the side effect is there can be multiple equally valid looking chains if you look back further than n-blocks so he says you need to find a trustworthy party who is on the network longer than n-blocks to certify which is the correct chain | 02:34 |
| gmaxwell | I'll be very glad to get to a position where grep on "checkpoint" in bitcoin core returns nothing; so tired of awful centeralized features in altcoins being called "checkpoints" and justified on the basis that bitcoin core implements something largely unrelated under the same name. | 02:35 |
| op_mul | NXT has been quoting that as a solution to everything for quite a long time, they prevent large reorgs to some degree. | 02:35 |
| op_mul | "To keep an attacker from generating a new chain all the way from the genesis block, the network only allows chain re-organization 720 blocks behind the current block height. Any block submitted at a height lower than this threshold is rejected. This moving threshold may be viewed as Nxts only fixed checkpoint." | 02:36 |
| adam3us | gmaxwell: unsurprising that someone already thought of that (zooko). or that vitalik failed to quote them or ask if someone had already done that. PoS could be interesting if it could work, though I am not sure its very economically fair. if bitcoin had it form day 0 satoshi would own 90% not 10% as if you have 10% of coins, you keep that percent, as you get 10% of reward for free for holding. | 02:36 |
| adam3us | gmaxwell: thats an ongoing interest or rent for free supply inflation protection for any holders. | 02:38 |
| adam3us | so i wonder can people go all-in do lots of double-votes and maintain a lead and then purge history or suppress proofs they double voted until the rolling consensus window kicks in where i think its definitionally disallowed to revise which block won. and then other people have to engage in the same practice or they reliably lose, and then the whole thing devolves to nothing at stake grind the vote instead | 02:38 |
| adam3us | do y'all think that attack works? | 02:38 |
| gmaxwell | adam3us: wrt economically fair, you could make it as orthorgonal as you want. I mean, you could choose to do distribution some more fair way... (of course for every reason that it's not very fair for subsidy, it's not very fair for control of the consensus order either) | 02:39 |
| op_mul | adam3us: there's other "checkpoint" systems in altcoins too. peercoin and it's clones all rely on having a central person signing all of the new blocks on the network. that's not an outlier either, all the PoS coins have it to prevent their networks from fragmenting. | 02:39 |
| adam3us | op_mul: there is no one signing checkpoints in vPoS. i believe its just that there is a rule that reorgs are not allowed to be more than n-blocks deep. i am not sure how that wont endup in a consensus fork either | 02:40 |
| op_mul | vpos? | 02:41 |
| adam3us | gmaxwell: you mean vPoS for transaction confirmation, and bare mining for reward for example. i guess then there's no economic motive to confirm transactions but yes i thought of that also. that much is kind of good in that you can solo mine on fractions of coins with tiny bandwidth for keeping up with the network. | 02:41 |
| adam3us | op_mul: just short for vitalik PoS.. not sure what its name is probably dagger version 23 (he keeps changing it when people break it) | 02:42 |
| op_mul | adam3us: yes. he is good at that. | 02:43 |
| adam3us | op_mul: only i think dagger was his name for his evolving PoW, so maybe as this is a PoS repair attempt he has a diff name for it, i didnt notice him give it a name in the article. | 02:43 |
| op_mul | it doesn't really matter what it's called, it's all just marketing. I find his blog posts to be almost unreadable. | 02:46 |
| iddo | adam3us: you cannot start pure PoS from day 0, you must have other rules (checkpoints being a bad example), otherwise anyone can do a fork from genesis with no effort | 02:47 |
| op_mul | all of their stuff has so many random names assigned to it that it's impossible to follow what the hell is going on, and which umbrella a concept falls under (if at all). | 02:47 |
| iddo | and other proof-of-x too, e.g. proof-of-storage you need to be careful not to have same problem | 02:48 |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 02:48 | |
| adam3us | i am just wondering if the stake that is pre-committed to vote is actually a problem. presumably its not just a question of having a proof of double vote, you need to get that info into the blockchain, otherwise people can pretend to not receive it - like the difference between proof of publication and timestamping. committed tx have the same problem. | 02:48 |
| adam3us | if you can go nuts pre-commiting to billions of chain variants, and keep winning you can suppress the consensus knowledge of your double-voting. | 02:49 |
| gmaxwell | iddo: even if you solve some genesis, anything reduces to {from point X} where X in the past. Say you've bootstraped, then over time the original people leave the system. Becaues they've left their keys are wortless and the lose control of them or sell them. Now you can happily replace from that point. | 02:49 |
| adam3us | iddo: true for PoS (cant start from scratch) | 02:50 |
| gmaxwell | adam3us: yea you can be excluded from participating by the current participants. | 02:50 |
| adam3us | gmaxwell: but they dont want to fork the network or they have a consensus breakdown. they cant accept the proof of double-vote unless everyone receives it? ah i guess they could. they would only have a reason to ignore it if they were in on the conspiracy. that makes it a bit different to proof of publication. it is self-validatable, and they have an incentive to accept it without it being committed to consensus. | 02:52 |
| iddo | gmaxwell: yes you need an assumption on point X, such as assuming that majority of stake at point X is rational (not that i claim that then there is a good solution, just that with X=0 you cannot have pure PoS) | 02:52 |
| gmaxwell | iddo: rational isn't enough. It's rational, after you've spent all your coins to sell your past empty private keys. | 02:53 |
| adam3us | gmaxwell: i guess the other objection is if we say hypothetically it worked but the distribution is unfair. it seems the only fair distribution is PoW, and then there is no power saving and its strictly security weaker so a net loss. lets say it worked and bitcoin adopted it (phased in) then i suppose we could stop fresh coin mining, the existing volatility and distribution is good enough. | 02:54 |
| gmaxwell | adam3us: forget the double vote proof for a moment and consider the initial bonding they can just simply reject the bonding transactions from the consensus history, there is no fork. | 02:54 |
| iddo | gmaxwell: i don't understand what you mean? if majority got rid of their coins because they don't believe in the system, an minority is malicious, then this system should no longer exist anyway? | 02:55 |
| gmaxwell | adam3us: e.g. say I'm the only user of the system initially, with my premine. I sell you some of the coins. But when you try to mine, oops I never seem to hear your bonding transaction. | 02:55 |
| op_mul | iddo: private keys being empty doesn't mean you got rid of your coins, it just means you've moved them somewhere else. | 02:56 |
| adam3us | gmaxwell: so it seems everyone has an incentive to pretend to not hear anyone elses bonding transaction. thats kind of interesting. | 02:56 |
| gmaxwell | iddo: They do so _later_. at time >> X, after the majority at X has moved on to other things, the majority at X leaks/sells/gives away their keys. | 02:57 |
| iddo | adam3us: it's interesting question whether PoW gives fair distribution, the too extremes are unknown/unpopular new cryptocurrency, and a highly popular/hyped new cryptocurrency, whether you get fair distribution with PoW in these two cases? | 02:57 |
| gmaxwell | iddo: Then at time Y (Y>>X) someone replaces the history starting at X using those keys. | 02:57 |
| op_mul | iddo: it's more possible that the bitcoin bootstrapping only worked properly once. like a ring pull on a can of beans. | 02:57 |
| adam3us | iddo: i think gmaxwell means they can rollback the bonding transaction that originated the double-vote, however if they do that the flush the transaction confirmations and different transactions may be confirmed later so if this n-blocks is kind of long (which it must be to avoid frequent orphans) that would kind of suck for them. | 02:58 |
| gmaxwell | iddo: under certian assumptions it gives a distribution which is "fair" in a particular sense (mining for distribution is effectively a constant all-pay auction to get the next group of coins) | 02:58 |
| adam3us | iddo: i think PoW fair distribution can only happen once - in bitcoin. no future distribution can be fair as there is no surprise. nor electrically efficient as difficulty immediately ramps form speculators. | 02:59 |
| gmaxwell | adam3us: I'm not even talking about bonding there. I'm just pointing out that the initilization problem iddo spoke about is actually a problem at all points in time, not just 0. | 02:59 |
| iddo | gmaxwell: yes, i see you point, thinking about it now... | 03:00 |
| gmaxwell | Because even if you are rational, you have no incentive to not leak your keys after you've exited the system and no system of rewards/costs in the system can change that. | 03:00 |
| adam3us | gmaxwell: doesnt that imagine the exit of every initial holder? | 03:00 |
| adam3us | gmaxwell: but leaked keys wouldnt hurt after transfer is acknowledged past the n-block window, and reorgs arent accepted past it | 03:01 |
| gmaxwell | Someone in here proposed a bond that never runs out, that your stake is non-transferable and can only be used for mining and takes infinite time to return its costs... though in which case why would anyone ever mine, and I came up with a scheme that made the keys more or less securely transferable, even though the system fixes it to a single pubkey. | 03:01 |
| adam3us | gmaxwell: ok. i was focussed on the vitalik params to the idea. fair enough! | 03:02 |
| gmaxwell | adam3us: if you won't accpt reorgs past some height then consensus failure is guarenteed in at least some cases (though perhaps they're crazy ones and you'd rather the failure or handle it in other ways) | 03:02 |
| gmaxwell | but yea, I wasn't talking about the bonded coins idea specifically. | 03:02 |
| iddo | gmaxwell: yes, you need to assume that the majority at time X is rational at all future time Y, weaker assumption :( | 03:02 |
| adam3us | gmaxwell: yes i think so. use small stake you can afford to lose, vote multiple ways in the block before the n-window expires, keep doing it post your wins to different parts of the network, due to network latency some will see it and others not. ta-da fork!! | 03:03 |
| gmaxwell | iddo: actually that it is rational at X but _honest_ (altruistic) at all sufficiently far future times, so it's even stronger. | 03:03 |
| iddo | actually rational is unclear in this context, i meant that it will be rational for the majority of time X not to attack | 03:03 |
| gmaxwell | adam3us: yep. I think you're right. | 03:04 |
| op_mul | iddo: I don't think you really want to predicate security on rationality | 03:05 |
| gmaxwell | op_mul: in consensus systems you are limited in what you can do there. | 03:06 |
| gmaxwell | op_mul: ultimately there is no physical defintion of the right state, so any security argument has to involve the users. | 03:06 |
| gmaxwell | And the best you can probably argue for is that rational (if perhaps evil) users will prefer to go along with the rules. A weaker assumption involves 'honest' users -- ones who will follow the rules even if its more profitable to break them. | 03:07 |
| iddo | gmaxwell: maybe there are possibilities to mitigate this problem by having the majority of stake sign a checkpoint, this has some efficency drawbacks depending on details | 03:08 |
| gmaxwell | iddo: after they've done that they can leave the system (sell their coins), in which case it would be rational to then sell their useless-to-them old private keys to the highest bidder. | 03:08 |
| iddo | ok but they already signed a checkpoint, and users will prefer the older signed checkpoints (details are missing here, but it might be possible i think) | 03:09 |
| adam3us | gmaxwell: but i think selling should transfer both vote and coins simultaneously. and people wont accept sale where they dont get their coin private keys or you can respend it under them | 03:09 |
| gmaxwell | adam3us: uh, I think you misunderstood me. | 03:10 |
| gmaxwell | you sell your coins and your vote. sure. But that doesn't prevent your old private key from being used to forge an alternative history that branches back from when it was still yours. | 03:11 |
| adam3us | gmaxwell: you'd want to invalidate voting for a n-block period after sale. | 03:11 |
| op_mul | gmaxwell: I have some dissonance there. while I know that's the case, I don't like direct assertions that people won't do something that's against the ecosystem. people are, if at least in some portion, not predictable or rational. | 03:11 |
| adam3us | op_mul: sure people graffiti and spam and do crazy-ass stuff that actually costs money to no effect at times. schadenfreude paying to screw up someone elses day its a psychological effect. | 03:13 |
| iddo | adam3us: i don't see why n-block period matters, after you sold you can go back in history to whenever you want, and fork... | 03:13 |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 03:14 | |
| adam3us | iddo: yeah that was insufficient. you need the sale to take n-blocks maybe before its considered settled. thats kind of slow and frustrates trade however. as n is not 6 its like 1000s i think. | 03:14 |
| iddo | adam3us: i still don't see your point, what if majority at block that corresponds to one year after genesis decides to fork, while the current history is at year 2 after genesis ? | 03:15 |
| adam3us | gmaxwell: the sell and double-vote is a problem. | 03:15 |
| -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-ymvadbglnyvyrkdt] has quit [Ping timeout: 272 seconds] | 03:16 | |
| adam3us | iddo: that would take the majority. bitcoin could fork or rewrite history (eg to a snapshot before mtgox went bad) | 03:17 |
| iddo | adam3us: yes majority of those who already sold and no longer have any stake... weak assumption :( | 03:17 |
| adam3us | iddo: i mean there's a difference as vPoS assumes you ask the majority what is the correct chain, where as bitcoin (currently) assumes you pick the highest PoW chain | 03:17 |
| iddo | adam3us: i suggested majority to checkpoint to avoid this problem, it has tricky issues too | 03:18 |
| op_mul | s/highest/most difficulty/ | 03:18 |
| adam3us | iddo: i imagine vitalik would tell you to pick not from sybil random people but people you trust. hence weak subjectivity | 03:18 |
| op_mul | yes. | 03:18 |
| adam3us | op_mul: yeah thats what i meant, poor phrasing. | 03:18 |
| op_mul | and you can imagine how that will devalue. | 03:18 |
| op_mul | a central service that does the checking for you. | 03:19 |
| iddo | adam3us: gmaxwell and i were talking about any pure PoS system, not assuming particular ways that it behaves | 03:19 |
| adam3us | iddo: well pure PoS has nothing at stake so is buried and forgotten? | 03:19 |
| iddo | note that bitcoin PoW requires checkpointing too to avoid DoS, so that comparison is a bit unfair when we say that we checkpointing to also avoid other problems | 03:20 |
| op_mul | requires? | 03:20 |
| iddo | adam3us: i proposed a variant that tries to mitigate nothing-at-stake by only having single possible block that can extend the chain at any point | 03:21 |
| iddo | op_mul: yes see e.g. https://bitcointalk.org/index.php?topic=194078.msg2014204#msg2014204 | 03:22 |
| adam3us | iddo: "bitcoin PoW requires checkpointing too to avoid DoS" well a DoS resistant multi-path network is part of the bitcoin security assumption, so i think thats in scope. PoS has nothing at stake even without DoS | 03:22 |
| op_mul | iddo: that's not really a requirement. | 03:23 |
| iddo | adam3us: i meant to avoid creating easy-difficulty blocks at genesis and carry out DoS, eg. see bitcointalk link i pasted | 03:23 |
| adam3us | iddo: oh _that_ DoS, ok. | 03:23 |
| op_mul | iddo: slightly less important with headers first, too. | 03:24 |
| gmaxwell | iddo: Bitcoin core no longer requires checkpointing to avoid DOS. | 03:24 |
| adam3us | maybe compact SPV proofs could fix that. you fill the in backwards if presented with a compact SPV proof that is higher work. | 03:24 |
| iddo | gmaxwell: how come? | 03:25 |
| gmaxwell | Headers first almost completely eliminates that concern. | 03:25 |
| gmaxwell | (and compact SPV proofs could close it off further) | 03:25 |
| adam3us | iddo: "i proposed a variant that tries to mitigate nothing-at-stake by only having single possible block that can extend the chain at any point" how could you have consensus on what that block is in a decentralised system? | 03:26 |
| gmaxwell | iddo: At least sipa and I are in argreement to remove checkpoints in bitcoin core now that we use headers first sync; it just didn't make it into 0.10. | 03:26 |
| op_mul | gmaxwell: I thought your stance at one point was that they were still desirable? | 03:26 |
| gmaxwell | op_mul: huh? no. I have no clue what I would have said that might have indicated that! | 03:27 |
| iddo | gmaxwell: hmm with header first, couldn't you create extentions to genesis block and spam the network with that? | 03:27 |
| op_mul | gmaxwell: must have been someone else, don't worry I haven't been spreading that as "gmax says//" | 03:27 |
| adam3us | iddo: i guess the point is headers are small. | 03:27 |
| gmaxwell | iddo: you can only ask nodes to take 80 byte headers there. So the cost in Kw of power per kbit/sec of bandwidth is rather high. You're better off just doing an IP layer dos attack at that point. | 03:28 |
| iddo | gmaxwell: anyway thanks for pointing out this extra problem of PoS, i'll need to update my pure-PoS paper, it will be less attractive now:) http://www.cs.technion.ac.il/~idddo/CoA.pdf | 03:28 |
| gmaxwell | iddo: Not sure if you've seen, https://download.wpsoftware.net/bitcoin/pos.pdf | 03:29 |
| iddo | adam3us: this ^^ link is the construction that we proposed, it relies on randomized lottery among stakeholders | 03:29 |
| gmaxwell | iddo: which presents a number of generic POS issues. | 03:29 |
| iddo | gmaxwell: i've seen an old version, i don't think the problem that we discussed now is there? | 03:29 |
| gmaxwell | (while trying to avoid going into the weeds of any specific proposal; because the problem is that people making these proposals just keep making tweaks to dodge any concrete attack example; without clearly improving the security fundimentally) | 03:30 |
| gmaxwell | iddo: I think it is, but perhaps thats just because I see what we discuss as a specific example of the simulation argument in there. | 03:30 |
| iddo | ok | 03:31 |
| iddo | gmaxwell: ok so maybe the need for checkpoint in PoS isn't unfair if you can avoid it in Bitcoin | 03:31 |
| adam3us | so going back to this claim that after early people drop out and then you have another instance of the genesis problem. i'm not sure about that. the current people at that point learnt about the true chain from trusted others, and can carry the torch after they left. if you believe in WoT maybe they can make that work. | 03:31 |
| iddo | gmaxwell: but still, checkpoints to speed up performance to end-users is nice with PoW too, SNARKs can help | 03:32 |
| -!- e1782d11df4c9914 [~e1782d11d@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-wizards | 03:32 | |
| iddo | adam3us: yes, in my example they can because they will respect the original signd checkpoint instead of an attempt by malicious/rational stakeholders to create a competing checkpoint, i think that you say that it can be more simple, but try to specify exact rules and i might be tricky | 03:34 |
| iddo | s/i might/it might | 03:34 |
| adam3us | iddo: but its not really rule based - you make sure to learn about the best chain via your social connections to people you consider trustworthy. its pure WoT that you hope is fully connected, and if there's money at stake maybe people put enough effort in for once to make WoT actually work. | 03:36 |
| adam3us | iddo: it doesnt sound so terrible as an assumption to me really - it gives the world a one-true trust anchor to rally around. they can broadcast it, include it on news tickers, people sign it, any bitcoin company put on their web page beside the bitcoin price etc etc? | 03:37 |
| iddo | you'll need to mention at least some rules, if it's only WoT then it'd be similar to ripple proof-of-consensus, that doesn't seem to work as a decentralized system | 03:37 |
| gmaxwell | iddo: if you are invoking a snark though you don't need anything like a checkpoint. | 03:37 |
| gmaxwell | iddo: a peer can just prove to you some state is valid and hand it to you.. at that point it shouldn't be called a checkpoint at all as it has no resemblance to anything else people call checkpoints. :) | 03:38 |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] | 03:38 | |
| iddo | gmaxwell: ok maybe i used bad terminology, i meant using snark as a trust-free checkpoint | 03:38 |
| adam3us | iddo: well its one removed from ripple consensus i think. in ripple your trusted or blessed hierarchical transaction voters work to achieve teh definition of consensus. in vPoS the introduction is _only_ to get you started on the one true chain, once you're there you can stay there by yourself. | 03:39 |
| gmaxwell | iddo: I understood. You shouldn't use the word checkpoint there. Becuase, e.g. that doesn't vindicates trusty-checkpointing PoS schemes. :) | 03:40 |
| gmaxwell | adam3us: well you already pointed out why that doesn't work in the face of a byzantine attacker. | 03:40 |
| adam3us | gmaxwell: you mean the consensus is trivially forky? sure but thats another design area. iddo seemed to be equating the introduction to the ripple voting. well ok vPoS voting is forky too, just due to race conditions rather than trusting WoT convergence. | 03:42 |
| iddo | well the snark could be for the computation of the majority of stakeholders' signatures, but it's true that with PoS it's to solve a real security problem, not just optimization like in Bitcoin | 03:42 |
| gmaxwell | I think his comparison with ripple is apt. though because the forkyness you pointed out means that ultimately it reduces to trust your friends (if it doesn't just fail entirely with a byzantine attacker, I guess thats unclear) | 03:43 |
| adam3us | gmaxwell: btw I _love_ how people cant see race conditions. very funny. reminds me of someone i knew who tried to design distributed network protocols in a debugger. he'd watch it fail then tweak the algorithm. uh no you have to be mathemtically certain there is no undefined behavior and no fork scenario. | 03:43 |
| gmaxwell | iddo: it doesn't actually solve any security problem there, it's just an optimization regardless. | 03:43 |
| adam3us | gmaxwell: yeah there is some similarity in outcome for sure. | 03:44 |
| iddo | gmaxwell: if majority signed at time X, and then at later time Y build a competing chain, then that signature is supposed to mitigate the security problem | 03:44 |
| gmaxwell | iddo: sure but you can just expose the signatures, no snark needed. | 03:45 |
| iddo | yes, i meant the "checkpoint" is needed, snark is always just (maybe) an optimization | 03:45 |
| adam3us | i wonder if they think the fork you could easily create would have an eventual longest fork winner like bitcoins consensus convergence approach? with vPoS you could work to keep the forks continually balanced and then start an actual PoW race to break the tie. | 03:47 |
| adam3us | where the PoW would be double voting dust to nudge one or other fork to win. | 03:47 |
| gmaxwell | adam3us: related to debugging race condtitions; IIRC one feature of "rr" (A replay debugger: http://rr-project.org/ ; records all non-determinstic inputs to your program, including scheduling, so you can effectively go backwards in a debugger ) is that it can schedule your threads in a somewhat adversarial | 03:47 |
| adam3us | (no longer part of their protocol anyway, that probably counts as a fail) | 03:47 |
| gmaxwell | iddo: I dunno if you saw, but someone posted a tool with a new metalanguge wrapper around libsnark complete with circuits for sha256 and sha512. | 03:48 |
| gmaxwell | I'm pretty close to being able to demonstrate an actual zero knoweldge contingent payment in bitcoin using it. | 03:48 |
| adam3us | gmaxwell: eventually i had to rescue this situation and rewrite the entire thing in a week (6mo failed project:) he was puzzled why i would sit there and think about the protocol rather than reach for the debugger if anything failed. | 03:49 |
| iddo | gmaxwell: nice to know, alas it requires trusted setup, i'm working on non-trusted-setup variant (PCP proofs) now | 03:53 |
| iddo | gmaxwell: in the trusted-setup world that are new competitors too, like this one http://eprint.iacr.org/2014/976/20141201:093827 (not sure which system if the most efficent these days) | 03:54 |
| gmaxwell | iddo: well for a ZKCP there is no trust, because there is a designated verifier (the person buying the info) who can just do the setup. | 04:01 |
| gmaxwell | iddo: the non-trusted setup work is super important. Do you yet have any ideas on the concrete efficency? | 04:01 |
| -!- Starduster_ [~guest@unaffiliated/starduster] has joined #bitcoin-wizards | 04:03 | |
| -!- Starduster [~guest@unaffiliated/starduster] has quit [Ping timeout: 240 seconds] | 04:05 | |
| iddo | gmaxwell: yes the buyer/verifier can do the setup but then it isn't really a SNARK (no succinct verification, unless it's amortized over many proofs), so it's used just for non-interactive ZK proof in that case (and as you pointed out, interactive ZK proof can be even more efficient for ZK contingent payment) | 04:06 |
| gmaxwell | iddo: well I have a setup that is amortized. (assuming that you really like buying sudoko answers...) | 04:07 |
| iddo | nothing concrete yet:( jury is still out regarding whether it will be efficient in practice, but there are reasons to be optimistic... i'll update you when it becomes more clear, maybe soon | 04:07 |
| gmaxwell | it saves computation though even if you only use it once, because the thing inside the snark is a verification equation that is much faster than solving the problem you're buying the answer to. | 04:08 |
| iddo | but the verifier will also need to compute the keygen procedure... | 04:08 |
| gmaxwell | iddo: Right. For a ZKCP you do not put the hard problem inside a SNARK. Instead you put an admissable solution _verifier_ for the hard problem inside the SNARK. | 04:09 |
| gmaxwell | The seller of information does the hard problem solution totally external to the ZKP, finds a solution, encrypts it, and then uses the SNARK to prove to you that some data is the encryption of the solution you want, and the hash preimage of some value is the key to that encryption. | 04:10 |
| iddo | not sure that i understand, anyway the keygen is just some totally generic procedure that prepared random elements for bilinear pairings, or something | 04:11 |
| * gmaxwell forehead | 04:11 | |
| gmaxwell | iddo: Yes, I know how the system works. :P I'm pointing out that if it's applied in this way you still get an effectively succinct protocol (one which is not trivial and saves the verifier computation) even if the verifier must do keygen for each and every use. | 04:12 |
| iddo | BTW it needs snark circuit for AES, anyone wrote that yet? the zerocash people only wrote SHA256 | 04:13 |
| gmaxwell | iddo: I replaced the AES with more SHA256. Also the zerocash people haven't released any of their circuits; fortunately someone else did. | 04:13 |
| iddo | gmaxwell: i don't see how it is succinct, the verifier needs to run keygen for number of steps that's the same as the prover running time | 04:14 |
| gmaxwell | iddo: E.g. SHA256(secret||counter)^data is a nice enough stream cipher. | 04:14 |
| gmaxwell | iddo: because the vast majority of the computation is outside of the ZKP entirely. | 04:14 |
| iddo | ok, but still number of steps for encrypt+hash are needed | 04:15 |
| iddo | i.e. the proof needed for ZKCP isn't made more succinct that a non-snark ZK proof for this encrypt+hash computation | 04:16 |
| iddo | s/that/than | 04:16 |
| gmaxwell | Thats true. But the whole protocol is succinct, so it isn't pointless. And I have no implementation of _any_ succinct or not ZKP for sha256. (well except for my crappy one with enormous quadratic in the circuit size communications complexity) | 04:17 |
| iddo | hmm yes nice stream cipher, i guess no one uses that because AES is actually more efficient that SHA256, just nobody bothered to implement it in libsnark yet | 04:17 |
| gmaxwell | ZKCP doesn't need a succincy ZKP to be worth doing; it just needs to be pratical enough. | 04:18 |
| iddo | in the garbled circuits world i think the situation is reversed, there are AES implementations, and no one bothered to implement SHA2 | 04:19 |
| gmaxwell | iddo: yea, AES looks pretty easy in the circuits libsnark gives access to, indeed. But I can't justify spending weeks hand coding a boolean logic implementation of AES for something that just demonstrates the tech. | 04:19 |
| -!- MoALTz_ [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards | 04:20 | |
| gmaxwell | yea, seveal of the MPC programs I've seen have a semi-honest protocol that does AES. | 04:20 |
| iddo | maybe they also have cut-and-choose implementation to handle malicious case | 04:21 |
| gmaxwell | iddo: perhaps but the snark is nice because it's a two move protcol for the snark itself, the MPC like ways of doing this require heavy interaction. | 04:22 |
| iddo | not even implementation, just some automation i guess, it'd work because interactive is ok for ZKCP | 04:22 |
| gmaxwell | yea, interactive is okay, though engineering wise its better if there is less. | 04:23 |
| gmaxwell | e.g. SNARK ZKCP works over email. | 04:23 |
| -!- MoALTz [~no@user-188-33-7-126.play-internet.pl] has quit [Ping timeout: 272 seconds] | 04:23 | |
| gmaxwell | where as a MPC one wouldn't. | 04:23 |
| iddo | yes you'll need several rounds, to send garbled circuits, then open some circuits, then oblivious-transfer for the input wires... many emails to send:) | 04:24 |
| gmaxwell | so I think in general one can support N minutes of computation for each round of communication you eliminate; where N is however long it takes to copy some text into an email. :P | 04:26 |
| iddo | what about the verification circuit for sudoku or whatever, it's implemented as snark already? | 04:29 |
| iddo | 13:53 < iddo> gmaxwell: nice to know, alas it requires trusted setup, i'm | 04:30 |
| iddo | 13:53 < iddo> gmaxwell: nice to know, alas it requires trusted setup, i'm | 04:30 |
| iddo | oops paste, my keyboard sucks sorry :( | 04:30 |
| -!- Profreid [~Profreitt@gateway/vpn/privateinternetaccess/profreid] has joined #bitcoin-wizards | 04:30 | |
| gmaxwell | iddo: yea, I came up with a pretty simple construction (with some cluesticking by gwillen) that makes it require pretty much only addition and equality tests, linear in the number of cells in the puzzle. I still have some gluing to do to get it all running. | 04:33 |
| -!- llllllllll [~lllllllll@53-109.bbned.dsl.internl.net] has joined #bitcoin-wizards | 04:35 | |
| iddo | cool | 04:35 |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards | 04:39 | |
| -!- narwh4l [~michael@unaffiliated/thesnark] has joined #bitcoin-wizards | 04:40 | |
| -!- narwh4l [~michael@unaffiliated/thesnark] has quit [Remote host closed the connection] | 04:53 | |
| -!- e1782d11df4c9914 [~e1782d11d@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Ping timeout: 240 seconds] | 04:54 | |
| -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-vbpbkojhkdzsxuqy] has joined #bitcoin-wizards | 04:56 | |
| -!- luny [~luny@unaffiliated/luny] has joined #bitcoin-wizards | 05:32 | |
| -!- luny` [~luny@unaffiliated/luny] has quit [Ping timeout: 240 seconds] | 05:34 | |
| adam3us | is larger blocksizes (as gavinandresen was discussing) a hard fork? i presume it must be? | 05:42 |
| -!- luny` [~luny@unaffiliated/luny] has joined #bitcoin-wizards | 05:42 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 05:42 | |
| gmaxwell | Of course. (gosh if the system didn't control the maximum size...) | 05:43 |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Client Quit] | 05:44 | |
| adam3us | gmaxwell: so then for people worried about tx throughput being only 3-4x way from full blocks (more if you discount spam that'd go away if the space shortage pushed up the tx fee) - this idea of gavinandresen's is going to be real tricky to deploy. | 05:44 |
| -!- luny [~luny@unaffiliated/luny] has quit [Ping timeout: 265 seconds] | 05:45 | |
| Luke-Jr | adam3us: until we have regular full blocks, it's hard to speculate on when we might need to increase block size IMO | 05:46 |
| adam3us | gmaxwell: maybe you could intro a new address type that is only valid in an extension block (another 9MB of block committed to somewhere in the 1MB block) and existing coins can be paid to extension coins (with something that looks a bit PoB burn like to old clients for old utxo compaction), and extension coins can be paid to extension coins) then people who upgrade get more tx througput | 05:50 |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 05:50 | |
| adam3us | gmaxwell: to get a soft-forkable blocksize increase. | 05:50 |
| gmaxwell | you don't neven need that, you can just have the moved coins disappear. | 05:52 |
| adam3us | gmaxwell: you'd want the 1mb utxo to be compatible i think. | 05:53 |
| gmaxwell | and preclude their doublespends even though non-upgraded systems can't see the initial spends, its still a soft fork; In general anything that can be done in a hardfork can be made a softfork with enough rocket thrusters; though uh. most people who've realized this have though better than to promote the idea. | 05:53 |
| gmaxwell | adam3us: why? it doesn't matter: The coins just are invisibly unspendable to old nodes. | 05:53 |
| adam3us | gmaxwell: they dont know its unspendable so 1mb block utxo set grows. minor point. | 05:54 |
| gmaxwell | in any case I think thats a generally horrible idea (with or without the burn enhancements) since it's really just a hardfork in disguise, esp since it changes the social contract of the network for other participants somewhat. | 05:54 |
| gmaxwell | adam3us: well true though its rate of growth should fall since all future transactions from the moved coins can't be seen there at all. | 05:55 |
| adam3us | gmaxwell: rocket thrusters! (yeah i'm not sure its a good idea, just i heard "must be hard fork" which of course caused immediate oh really adversarial thinking to kick in and look for a way to soft-fork it). | 05:55 |
| adam3us | gmaxwell: why do u say it changes the social contract? its not like p2sh soft-fork where miners are basicaly lieing to old clients with an op_true | 05:56 |
| adam3us | gmaxwell: social contract of not having stupidly large blocks which then creates centralisation? agree. but if blocks really fill up with non-spam and transactions backup thats not cool either. | 05:57 |
| gmaxwell | adam3us: when some softfork adds some scripting rule anyone who the scripting rule effects opted into it for their own coins (ignoring perhaps a covenant). | 05:57 |
| gmaxwell | But a rule that changes, effectively, whom can actually run a node, isn't something that ought to be slipped in quietly on people via minor censorship of transactions. | 05:57 |
| adam3us | gmaxwell: the extension coins seem a bit opt-in no? | 05:58 |
| adam3us | gmaxwell: ok you're talking about blocksize, yes i agree. | 05:58 |
| adam3us | gmaxwell: (centralisation side-effects of) | 05:58 |
| gmaxwell | adam3us: yea, and I'm not saying it's good vs bad, just that soft forking is less good of a mechenism when something has more third party effects. I could argue either way how opt-in an extension block is; it depends on how it was implemented. E.g. I'd presume that it would be completely transparent in wallets that supported it, so if it was actually successful anyone who didn't like it would be | 05:59 |
| gmaxwell | very rapidly forced onto it. | 06:00 |
| adam3us | gmaxwell: yes, there is an avalanche effect with security soft-forks, eg p2sh where you are at ongoing risk until you upgrade. this isnt that but it does foist blocksize which is bad for centralisation. | 06:01 |
| -!- grandmaster [dansmith3@knows.the.cops.are.investigat.in] has joined #bitcoin-wizards | 06:01 | |
| adam3us | gmaxwell: if we strap on even more boosters perhaps you could make extended coins payable to non-extended ones, via a pool of op_true coins (dont delete via PoB but spend them to op_true <magic>). barf. | 06:02 |
| gmaxwell | adam3us: it's a bit different though, e.g. someone with a pre-p2sh client can still use the network, though their low confirm count security may be slightly lower than before. And upgrading to enforce the extra rule is cheap. Vs say a block extension softfork, where perhaps they can't recieve coins at all anymore quite quickly... and upgrading means large increases in operating cost. | 06:03 |
| gmaxwell | oh jeez, indeed, thats true. | 06:04 |
| gmaxwell | well I suppose that takes away the can't recieve at all point I was just making. | 06:04 |
| gmaxwell | At that point it's basically what we discribed in the sidechains whitepaper as "risk of softfork", but without the truth in advertising that the addition is something seperate which ought to be considered seperately. | 06:05 |
| gmaxwell | described* | 06:05 |
| -!- bit2017 [~linker@42.116.152.78] has joined #bitcoin-wizards | 06:06 | |
| adam3us | gmaxwell: hmm i wonder if we just described an alternate view of sidechains there? | 06:06 |
| adam3us | gmaxwell: make the extension block merge mined, something close & related anyway. | 06:07 |
| adam3us | gmaxwell: send the extension transactions over a different p2p port/magic number. | 06:07 |
| -!- coiner [~linker@58.186.142.128] has quit [Ping timeout: 265 seconds] | 06:08 | |
| gmaxwell | yes, I mean, we actually talk about this specifically in the sidechains whitepaper. The two distinctions are soft forking the validity of the extension, and interface papering over the system (Also before you mentioned the dummy pool, the inability to do the return peg) | 06:08 |
| adam3us | gmaxwell: re-reading it now :) kind of forgot that bit | 06:09 |
| adam3us | alright yes thats very related commentary. | 06:11 |
| gmaxwell | I actually do see that as a reasonable way to do system upgrades, but I'm unsure of the boundaries where its a fair and equitable thing to do... because when it comes to the technical aspect the social contract of bitcoin is unclear. | 06:12 |
| adam3us | gmaxwell:so i think i got my connection right now: with this model it could actually be main-chain mined (an actual-soft-fork) but because there are two coin types, it has a security firewall in the same way that sidechains do. so if the extension block has some additional rules, different contract language, zerocash etc. the coins with op_true <magic> are serving as a peg pool. | 06:16 |
| gmaxwell | yea, it's just a soft-forked sidechain at that point, from a technical perspective; but it also matters how it's presented to people. | 06:17 |
| adam3us | gmaxwell: the universes can co-exist and security defects do not leak from the extension coins to people who dont opt in. | 06:17 |
| adam3us | gmaxwell: so separate from increasing block size that seems actually kind of interesting. | 06:18 |
| gmaxwell | adam3us: reacall we had a similar discussion about sidechains before with enforced consensus and I pointed out that consensus instability in the (sidechain in that discussion) extension 'leaks' | 06:18 |
| adam3us | gmaxwell: yes you are right. thats the limitation. hmm. | 06:19 |
| gmaxwell | so if the code for the extension has a non-determinstic verifier failure; and the validity of the extension is soft-fork mandated in the main chain, then the main chain splits too. So the firewall is not as strong. | 06:19 |
| gmaxwell | adam3us: wumpus has been toying some with getting bitcoin consensus code running inside moxie box... which is partially an expirement around sandboxing the consensus code to turn it into a bytecode to be damn sure its implemented determinstically... | 06:20 |
| adam3us | gmaxwell: yeah i get it from first comment. my counter to that is to make a tight interpreter that is security provable and right the extensions in that. | 06:20 |
| adam3us | gmaxwell: yes. somehow coerce it into being deterministic now matter. | 06:21 |
| gmaxwell | yea, thats the goal of the thing I just mentioned, and I agree it may be adequate for this. | 06:21 |
| adam3us | gmaxwell: (i made that counter in the last discussion some months back) but yes its basically the same thing i guess as this moxie box that you mentioned before. | 06:22 |
| gmaxwell | yea, moxie is a simple virtual machine, it's implementable as a ~1kloc of C switch statement.. so it should be fairly straightforward to prove that an implementation of it is absolutely determinstic and memory safe, etc. and presumably people could make optimized versions which were provably consistent with the spec and so on. | 06:24 |
| adam3us | gmaxwell: and if you have that deterministic vm byte code you can also validate side-chains, or (for bandwidth saving) disprove claims about the sidechain if the sidechain must provide both an interpreter and a claim disproving script (in the same byte code). ie prove you do not own the returned coin according to sidechain more rules than validating the full chain of ownership in the sidechain | 06:24 |
| gmaxwell | adam3us: yes but without interaction those proofs may not be compat. | 06:25 |
| gmaxwell | compact* | 06:25 |
| adam3us | gmaxwell: which avoids the "and then 51% takes all the coins" and avoids the need for a bitcoin denominated fraud bounty (my other idea for imposing a counter-veiling disincentive to doggedly trying to take the coins) | 06:26 |
| adam3us | gmaxwell: yes. kind of like rusty seemed to be thinking of for disproving fraud in other shards in pettycoin | 06:26 |
| adam3us | gmaxwell: alright op_spv + op_moxie :) | 06:27 |
| adam3us | gmaxwell: maybe there are an interesting enough range of things that are compactly non-interactively disprovable. | 06:31 |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 06:36 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Client Quit] | 06:39 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 06:53 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] | 07:13 | |
| -!- orwx [~orw@bzq-148-168-31-177.red.bezeqint.net] has joined #bitcoin-wizards | 07:17 | |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Quit: fanquake] | 07:22 | |
| -!- MoALTz_ [~no@user-46-112-49-198.play-internet.pl] has quit [Quit: Leaving] | 07:47 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 07:47 | |
| -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-vbpbkojhkdzsxuqy] has quit [Ping timeout: 245 seconds] | 07:51 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] | 08:01 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 08:05 | |
| -!- shesek [~shesek@109.67.132.151] has quit [Ping timeout: 250 seconds] | 08:09 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 08:24 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer] | 08:32 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 08:34 | |
| atgreen | gmaxwell: re: optimized versions.. there's a QEMU port that is more performant. I was just hacking it this AM to bring up Linux port. | 08:53 |
| atgreen | uClinux, I mean. | 08:53 |
| gmaxwell | atgreen: hah, yea but I wouldn't consider touching QEMU for consensus criticial code in bitcoin; sorry, went through a fair bit of it and don't consider it even slightly trustworthy (not the moxie specific parts, but spent time looking at qemu arm code) | 08:54 |
| gmaxwell | For what I was talking about before an optimization wouldn't be reasonable consider without a machine checkable proof that it computed exactly the same function as the straight C version. | 08:55 |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang] | 09:02 | |
| -!- Tjopper [~Jop@dhcp-077-249-237-229.chello.nl] has joined #bitcoin-wizards | 09:07 | |
| -!- Tjopper1 [~Jop@dhcp-077-249-237-229.chello.nl] has quit [Ping timeout: 256 seconds] | 09:08 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards | 09:09 | |
| -!- e1782d11df4c9914 [~e1782d11d@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-wizards | 09:10 | |
| -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds] | 09:11 | |
| -!- Guest49039 is now known as mr_burdell | 09:13 | |
| -!- mr_burdell [~mr_burdel@hop.cryptolabs.net] has quit [Changing host] | 09:13 | |
| -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has joined #bitcoin-wizards | 09:13 | |
| -!- e1782d11df4c9914 [~e1782d11d@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Ping timeout: 264 seconds] | 09:18 | |
| -!- Tjopper1 [~Jop@dhcp-077-249-237-229.chello.nl] has joined #bitcoin-wizards | 09:27 | |
| -!- Tjopper [~Jop@dhcp-077-249-237-229.chello.nl] has quit [Ping timeout: 264 seconds] | 09:30 | |
| -!- tacotime [~mashkeys@198.52.200.63] has joined #bitcoin-wizards | 09:35 | |
| -!- Tjopper1 [~Jop@dhcp-077-249-237-229.chello.nl] has quit [Ping timeout: 256 seconds] | 09:40 | |
| -!- Tjopper [~Jop@dhcp-077-249-237-229.chello.nl] has joined #bitcoin-wizards | 09:41 | |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has quit [Read error: Connection reset by peer] | 09:41 | |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has joined #bitcoin-wizards | 09:42 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 09:48 | |
| -!- benten [~benten@unaffiliated/benten] has joined #bitcoin-wizards | 10:04 | |
| -!- koshii [~0@c-68-58-151-30.hsd1.in.comcast.net] has quit [Quit: leaving] | 10:04 | |
| -!- koshii [~0@c-68-58-151-30.hsd1.in.comcast.net] has joined #bitcoin-wizards | 10:05 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang] | 10:10 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards | 10:18 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] | 10:19 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] | 10:28 | |
| gmaxwell | petertodd: Building consensus code in very high level languages, demonstrated: https://www.youtube.com/watch?v=RkTvDjhImwo | 10:30 |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 10:31 | |
| -!- belcher [~belcher-s@5ec1ab86.skybroadband.com] has joined #bitcoin-wizards | 10:32 | |
| -!- belcher [~belcher-s@5ec1ab86.skybroadband.com] has quit [Changing host] | 10:32 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards | 10:32 | |
| -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Quit: Leaving] | 10:32 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] | 10:36 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 10:50 | |
| -!- narwh4l [~michael@unaffiliated/thesnark] has joined #bitcoin-wizards | 10:52 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] | 11:06 | |
| -!- mkarrer [~mkarrer@135.Red-83-52-38.dynamicIP.rima-tde.net] has quit [] | 11:19 | |
| -!- wallet42 [~wallet42@f052165145.adsl.alicedsl.de] has joined #bitcoin-wizards | 11:19 | |
| -!- wallet42 [~wallet42@f052165145.adsl.alicedsl.de] has quit [Changing host] | 11:19 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 11:19 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang] | 11:20 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] | 11:26 | |
| -!- MoALTz [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards | 11:28 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Ping timeout: 250 seconds] | 11:29 | |
| -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards | 11:36 | |
| petertodd | gmaxwell: heh, I didn't even need to hit play to know what that video was... | 11:50 |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards | 11:51 | |
| petertodd | gmaxwell: anyway, note that I didn't claim anything about building *consensus* code in high level languages, beyond the fact that C is too low-level to do it safely, and C++ probably is a decent choice in the current language ecosystem | 11:55 |
| -!- benten [~benten@unaffiliated/benten] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 12:00 | |
| -!- benten [~benten@unaffiliated/benten] has joined #bitcoin-wizards | 12:00 | |
| narwh4l | petertodd, don't shoot me, but serpent is a turing complete contract language, right? | 12:01 |
| narwh4l | petertodd, so a clone of that might suffice | 12:01 |
| narwh4l | petertodd, then you build you consensus system on top of that? Maybe? Just thinking out loud | 12:02 |
| michagogo | gmaxwell: uh, wtf is happening in that video | 12:03 |
| -!- benten [~benten@unaffiliated/benten] has quit [Ping timeout: 256 seconds] | 12:04 | |
| -!- kgk_ [~kgk@76.14.85.43] has joined #bitcoin-wizards | 12:04 | |
| michagogo | Ah, heavily modified components | 12:08 |
| michagogo | https://www.youtube.com/watch?v=mzDTZuFJYX4 | 12:08 |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang] | 12:10 | |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards | 12:17 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 12:18 | |
| -!- todays_tomorrow [~me@d114-78-106-45.bla803.nsw.optusnet.com.au] has quit [Read error: Connection reset by peer] | 12:26 | |
| -!- bitstein [~bitstein@unaffiliated/bitstein] has joined #bitcoin-wizards | 12:26 | |
| -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-ozzefriockavbufu] has joined #bitcoin-wizards | 12:32 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving] | 12:37 | |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has quit [Remote host closed the connection] | 12:40 | |
| -!- mortale [~mortale@gateway/tor-sasl/mortale] has joined #bitcoin-wizards | 12:40 | |
| -!- roconnor [~roconnor@e120-pool-d89a63c0.brdbnd.voicenetwork.ca] has joined #bitcoin-wizards | 12:50 | |
| -!- bektar [~jakob@c-46-162-82-69.cust.bredband2.com] has joined #bitcoin-wizards | 12:57 | |
| -!- roidster [~chatzilla@96-41-48-194.dhcp.mtpk.ca.charter.com] has joined #bitcoin-wizards | 13:02 | |
| -!- roidster [~chatzilla@96-41-48-194.dhcp.mtpk.ca.charter.com] has quit [Client Quit] | 13:03 | |
| -!- roidster [~chatzilla@96-41-48-194.dhcp.mtpk.ca.charter.com] has joined #bitcoin-wizards | 13:05 | |
| -!- roidster is now known as Guest66177 | 13:05 | |
| -!- Guest66177 [~chatzilla@96-41-48-194.dhcp.mtpk.ca.charter.com] has quit [Client Quit] | 13:05 | |
| petertodd | narwh4l: I believe credit goes to gmaxwell for suggestion that - make your consensus system be a codebase that can run in a much simpler virtual machine | 13:25 |
| adam3us | are the btcd guys on this channel? | 13:25 |
| adam3us | just got some reaction from davec on bitcointalk to the question of what btcd funding is and what the motivation / profit model is for that, and also about forking risk re-impleenting the consensus critical part of bitcoin and persuading people to use it. | 13:27 |
| adam3us | (who it seems is lead dev on btcd) | 13:27 |
| -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-ozzefriockavbufu] has quit [Ping timeout: 245 seconds] | 13:30 | |
| kanzure | well, i can think of many incentives, although i don't know if they have mentioned any in public (i wasn't paying attention) | 13:30 |
| -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-kuymeqzypvivcubp] has joined #bitcoin-wizards | 13:32 | |
| -!- bitstein [~bitstein@unaffiliated/bitstein] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 13:32 | |
| -!- cluckj [~cluckj@cpe-24-92-48-18.nycap.res.rr.com] has quit [Quit: Leaving] | 13:33 | |
| -!- ebfull [~ebfull@c-76-120-40-34.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] | 13:41 | |
| -!- ebfull [~ebfull@c-76-120-40-34.hsd1.co.comcast.net] has joined #bitcoin-wizards | 13:42 | |
| adam3us | kanzure: i thought it was a fair question. the answers i got werent very clear https://bitcointalk.org/index.php?topic=68655.msg9998070#msg9998070 and btcd second reply https://bitcointalk.org/index.php?topic=68655.msg9998327#msg9998327 | 13:42 |
| kanzure | "First, both of these are completely irrelevant. No one knows who Satoshi was/is, yet that isn't a problem for Bitcoin Core" arguably people did get to know satoshi in public | 13:43 |
| adam3us | they still dont seem to see the fork risk, or alternatively claim the see and understand it fine but its not a problem, or no more of a problem for btcd vs bitcoin fork compared to bitcoin vs itself — which is bollocks. | 13:45 |
| kanzure | oh, you think they do see the fork risk? | 13:45 |
| adam3us | kanzure: well read the second post he tried to refute my claim they had to be educated by quoting himself from his first announce before anyone knew about btcd to have educated them about the fork risk. | 13:46 |
| kanzure | they seem to be saying "as long as there is no fundamental improvement to the situation (e.g., other than "use bitcoind") to permanently avoid fork risks, it is perfectly acceptable for alternative implementations to lose user money" | 13:47 |
| fluffypony | adam3us: do you have the same concerns with Bits of Proof's client? | 13:47 |
| adam3us | fluffypony: the problem is when people use alternate consensus code in miners and clients simultaneously with a alt-consensus code < 50% or also a problem if its > 50% hashrate even if no clients use it. thats what i think but others spent more time analysing the problem. | 13:49 |
| fluffypony | sure, but the consensus rules are (and should be) clear and open, you can't prevent alternate clients on principle alone | 13:49 |
| adam3us | fluffypony: if someone finds a malicious divergence opportunity they can exploit the crap out of it to steal money from people using that fork. | 13:49 |
| kanzure | right | 13:50 |
| kanzure | or do things like "get a transaction signed on one fork, and then relay it on another" | 13:50 |
| adam3us | fluffypony: we cant stop people making home nukes either, doesnt make it any less ill-advisable :) also known as two wrongs dont make a right. | 13:50 |
| fluffypony | if one of those alternate clients (or Bitcoin core) has a bug unique to it...well, fuck, it's a bug, people who are risk averse won't be using a non-core client anyway | 13:51 |
| * narwh4l laughs at "home nukes" | 13:51 | |
| kanzure | nah we know how to protect ourselves from people making home nukes (= don't put all your eggs in one basket within the blast radius) | 13:51 |
| kanzure | (or the fallout zone) | 13:51 |
| kanzure | ((i asked elon for a space habitat for xmas but it hasn't arrived)) | 13:51 |
| fluffypony | I don't get the "one client to rule them all" logic, sounds more like control-freak logic to my ears but maybe I'm misunderstanding the sentiment | 13:51 |
| -!- hktud0 [ncidsk@unaffiliated/fluffybunny] has quit [Read error: Connection reset by peer] | 13:52 | |
| kanzure | "control freak" as in "you shouldn't expose your users to your incompetence"? | 13:53 |
| * fluffypony shakes his head | 13:53 | |
| kanzure | *possible incompetence | 13:53 |
| fluffypony | the very nature of a consensus system means that there may be consensus to use a client different to Bitcoin Core | 13:53 |
| fluffypony | and that should, at the very least, be respected | 13:53 |
| adam3us | fluffypony: it is both true that you should not do this (implement alternate consensus code AND encourage > 50% miners to use it OR ( encourage < 50% miners + clients) while also true that it would be better if bitcoin consensus was specification based with a tight formally verifable interpreter and a standardised "consensus byte code implementation" string. people would like to do that but | 13:53 |
| kanzure | adam3us: you are still experiencing cutoff methinks | 13:53 |
| adam3us | fluffypony: client alone, yes thats caveat emptor | 13:53 |
| adam3us | kanzure: clients) while also true that it would be better if bitcoin consensus was specification based with a tight formally verifable interpreter and a standardised "consensus byte code implementation" string. Â people would like to do that bu | 13:53 |
| fluffypony | yeah I saw cut off at "people would like to do that but" | 13:54 |
| -!- hktud0 [ncidsk@ip-188-121-63-164.ip.secureserver.net] has joined #bitcoin-wizards | 13:54 | |
| -!- hktud0 [ncidsk@ip-188-121-63-164.ip.secureserver.net] has quit [Changing host] | 13:54 | |
| -!- hktud0 [ncidsk@unaffiliated/fluffybunny] has joined #bitcoin-wizards | 13:54 | |
| adam3us | fluffypony: (yes i type six lines then go to next msg or i get chopped) but it doesnt help move us closer to that to blow up bitcion with a catastrophic fork while people are working towards that. | 13:54 |
| kanzure | there are some subtleties that would be missed here if "control freak" is the only explanation you can use | 13:54 |
| kanzure | adam3us: you should consider installing an irc client or a plugin for your irc client to split lines of text | 13:55 |
| adam3us | kanzure: yeah there is a plugin but lazy. | 13:55 |
| -!- Keefe [~Keefe@unaffiliated/keefe] has quit [Ping timeout: 256 seconds] | 13:57 | |
| -!- eslbaer [~eslbaer@p579E94C3.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds] | 13:58 | |
| -!- roasbeef [~root@104.131.26.124] has quit [Ping timeout: 256 seconds] | 13:59 | |
| -!- wiz [~sid1@d06f3063.wiz.network] has quit [Ping timeout: 256 seconds] | 13:59 | |
| -!- JonTitor [~superobse@unaffiliated/superobserver] has quit [Ping timeout: 256 seconds] | 13:59 | |
| -!- Fistful_of_Coins [~o3u@162.243.79.19] has quit [Ping timeout: 256 seconds] | 13:59 | |
| adam3us | kanzure: dont do that its dangerous seems like a fair comment no? | 14:05 |
| fluffypony | ok so maybe I'm oversimplifying, kanzure and adam3us, but how is it any different from everyone deciding not to update a version because of the inclusion of some rule or change they disagree with and the network forks as a result? | 14:05 |
| -!- kgk_ [~kgk@76.14.85.43] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 14:05 | |
| kanzure | "everyone deciding not to update a version"? | 14:05 |
| adam3us | fluffypony: that doesnt happen because upgrades are soft-forks for this reason | 14:05 |
| fluffypony | *update to a version | 14:05 |
| -!- cluckj [~cluckj@cpe-24-92-48-18.nycap.res.rr.com] has joined #bitcoin-wizards | 14:05 | |
| kanzure | "everyone deciding not to update to a version"? | 14:05 |
| kanzure | we were talking about forks i thought | 14:05 |
| adam3us | fluffypony: backwards compatible = soft-forks | 14:05 |
| fluffypony | so there will be no hard forks ever in future? | 14:05 |
| fluffypony | hearn won't be happy about that :-P | 14:05 |
| adam3us | fluffypony: they are much riskier and require a full-on flag day which is hard to enforce in a p2p network. | 14:05 |
| adam3us | whats the history - has bitcoin ever had a hard fork? | 14:05 |
| fluffypony | yes several | 14:06 |
| -!- wiz_ [~sid1@d06f3063.wiz.network] has joined #bitcoin-wizards | 14:06 | |
| adam3us | fluffypony: its not a principle thing - in many ways it would be nice to clean up some stuff, but its more dangerous to do a planned one (or unplanned) than soft-forks. | 14:06 |
| -!- Keefe_ [~Keefe@unaffiliated/keefe] has joined #bitcoin-wizards | 14:06 | |
| -!- Sub|afk [~SubCreati@c-76-121-19-166.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 14:06 | |
| kanzure | an unplanned fork caused by btcd miners would be pretty bad :/ | 14:06 |
| adam3us | fluffypony: i would presume all of them have been bug fixes. | 14:06 |
| kanzure | "unplanned" could also mean "indistinguishably adversarial" of course... | 14:06 |
| -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-kuymeqzypvivcubp] has quit [Ping timeout: 244 seconds] | 14:06 | |
| fluffypony | either way, a broadcast tx would be received by *both* sides of the fork, so in general you get the diminutive fork that ends up just petering off into non-existence | 14:06 |
| fluffypony | I also think that it's unavoidable - if someone releases a competing client and provides a compelling enough reason to switch, what are you going to do? | 14:06 |
| -!- roasbeef_ [~root@104.131.26.124] has joined #bitcoin-wizards | 14:06 | |
| kanzure | hmm, i'm not sure transactions are relayed between forks forever | 14:06 |
| -!- koshii_ [~0@c-68-58-151-30.hsd1.in.comcast.net] has joined #bitcoin-wizards | 14:06 | |
| kanzure | *between nodes running on different forks | 14:06 |
| kanzure | don't the nodes eventually permaban each other? | 14:06 |
| -!- o3u [~o3u@162.243.79.19] has joined #bitcoin-wizards | 14:06 | |
| -!- o3u [~o3u@162.243.79.19] has quit [Changing host] | 14:06 | |
| -!- o3u [~o3u@unaffiliated/o3u] has joined #bitcoin-wizards | 14:06 | |
| fluffypony | kanzure: afaik old clients will only reject broadcast transactions / blocks that fail validity, not standardness | 14:06 |
| adam3us | fluffypony: if the clients fork the risk is self-contained they either break (dont receive payments) or they get abused (if they misunderstand tx and they lose money and switch). they dont screw up the network. | 14:06 |
| -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-wsfmitseaigtaivo] has joined #bitcoin-wizards | 14:06 | |
| fluffypony | adam3us: so maybe I'm being dumb, but I'm not understanding how that scenario is different from a btcd-originated fork? | 14:06 |
| -!- OneFixt_ [~OneFixt@unaffiliated/onefixt] has joined #bitcoin-wizards | 14:06 | |
| -!- eslbaer_ [~eslbaer@p579E94C3.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 14:06 | |
| adam3us | fluffypony: say btcd gets > 50% of the mining network, they could screw up the network with confused tx that are exploitable and wreck things for everyone not just people who opted to use experimental software | 14:06 |
| kanzure | can you elaborate on "confused tx" specifically | 14:06 |
| michagogo | 00:02:02 <fluffypony> kanzure: afaik old clients will only reject broadcast transactions / blocks that fail validity, not standardness | 14:06 |
| fluffypony | I would hope that by the time they get to > 50% of the network their software is worthy of > 50%, which means it is significantly more robust than "experimental" | 14:06 |
| michagogo | There's no such thing as "standardness" for blocks | 14:06 |
| fluffypony | michagogo: I know | 14:06 |
| adam3us | fluffypony: confused but not so confused to fail validation or the rest of the network ignores them then you get a different outcome btcd clients and full nodes that will listen to one fork and the rest that listen to the other fork. | 14:06 |
| fluffypony | michagogo: but blocks contain transactions - the rules are the same for including a block that contains transactions that fail validity | 14:06 |
| -!- wiz_ is now known as wiz | 14:06 | |
| -!- llllllllll [~lllllllll@53-109.bbned.dsl.internl.net] has quit [Ping timeout: 264 seconds] | 14:06 | |
| -!- koshii [~0@c-68-58-151-30.hsd1.in.comcast.net] has quit [Ping timeout: 264 seconds] | 14:06 | |
| -!- SubCreative [~SubCreati@unaffiliated/cannacoin] has quit [Ping timeout: 264 seconds] | 14:06 | |
| -!- pi07r [~pi07r@f212009.upc-f.chello.nl] has quit [Ping timeout: 264 seconds] | 14:06 | |
| michagogo | Well, yeah | 14:06 |
| -!- pi07r_ [~pi07r@f212009.upc-f.chello.nl] has joined #bitcoin-wizards | 14:06 | |
| adam3us | fluffypony: theres a difference between "doesnt blow up when we fuzz test it" and the best someone adversarial can do to confuse it | 14:06 |
| michagogo | a block that includes an invalid transaction is, of course, invalid | 14:06 |
| -!- pigeons [~pigeons@titan.sysevolve.com] has quit [Ping timeout: 250 seconds] | 14:06 | |
| -!- pigeons [~pigeons@titan.sysevolve.com] has joined #bitcoin-wizards | 14:06 | |
| fluffypony | I'm uneasy about agreeing with your hypothesis, adam3us, as I think it's a non-issue, and if they garner > 50% of the network then clearly they have the superior client and deserve to do so | 14:07 |
| -!- pigeons is now known as Guest61644 | 14:07 | |
| -!- OneFixt [~OneFixt@unaffiliated/onefixt] has quit [Ping timeout: 250 seconds] | 14:07 | |
| adam3us | fluffypony: so you know how its hard to have complex sw without undefined or unusual or overflow etc behavior? its like that but worse - all the attacker has to do is find any difference in interpretation for something valid and constructible on bitcoin and they can steal money fast of btcd users. | 14:07 |
| fluffypony | I don't think that their client at the hypothetical 50% stage is more at-risk than Bitcoin Core is right now | 14:07 |
| adam3us | fluffypony: you're wrong i'm pretty sure. | 14:07 |
| kanzure | it's not their client, it's the people using the client, right? | 14:08 |
| -!- Dizzle [~Dizzle@2605:6000:1018:c0f5:e90b:3bb9:f53b:cf8d] has joined #bitcoin-wizards | 14:08 | |
| kanzure | i mean, it's the number of parallel forks increasing from 1 to >1 that is the real problem | 14:08 |
| adam3us | fluffypony: as i wrote above "they still dont seem to see the fork risk, or alternatively claim the see and understand it fine but its not a problem, or no more of a problem for btcd vs bitcoin fork compared to bitcoin vs itself — which is bollocks." | 14:09 |
| kanzure | that is not a good argument because someone will just say "arguably at x% of the network it is not bitcoind vs bitcoind it's btcd vs btcd" or something | 14:10 |
| -!- OneFixt_ is now known as OneFixt | 14:10 | |
| adam3us | fluffypony: the thing is bitcoin may have some weird behavior lurking in its consensus or other code, but its self-consistent - its weirdly behaving on all nodes. with btcd that automatically becomes a disastrous fork bug that could just about destroy bitcoin. i really doubt they'd have found them all that is really hard. anyone who knows anything about bitcoin core programming would tell you that. | 14:11 |
| -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-wsfmitseaigtaivo] has quit [Ping timeout: 255 seconds] | 14:11 | |
| adam3us | fluffypony: given from what i heard it took a long time to even get them to acknowledge fork risk as a problem - that doesnt exactly speak of top fight adversarial thinking nor security audit experience of the kind that finds zero days. not confident _at all_. | 14:12 |
| -!- JonTitor [~superobse@unaffiliated/superobserver] has joined #bitcoin-wizards | 14:12 | |
| fluffypony | adam3us: I don't disagree with that assertion, but I do think that it's a not worth making a fuss about - the majority of the network are too risk-averse to use their client, and if it's compelling enough to use that > 50% of the network uses it, well then all hail our great Conformal gods. | 14:12 |
| adam3us | fluffypony: if you add in that they're _still_ arguing its not a problem after people spent a bunch of time ELI5ing them.. its downright scary no? | 14:12 |
| -!- e1782d11df4c9914 [~e1782d11d@193.138.219.233] has joined #bitcoin-wizards | 14:13 | |
| -!- mkarrer [~mkarrer@135.Red-83-52-38.dynamicIP.rima-tde.net] has joined #bitcoin-wizards | 14:13 | |
| -!- ebfull [~ebfull@c-76-120-40-34.hsd1.co.comcast.net] has quit [Quit: cya] | 14:13 | |
| adam3us | fluffypony: that assumes miners are on their A-game. a lot of miners are not super sophisticated - plug in electricity - print bitcoins - profit | 14:13 |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 14:13 | |
| -!- ebfull [~ebfull@c-76-120-40-34.hsd1.co.comcast.net] has joined #bitcoin-wizards | 14:13 | |
| fluffypony | adam3us: the majority of miners don't have a say in the matter | 14:13 |
| kanzure | fluffypony: a fork like that would be very damaging, it's not about who gets to be god | 14:13 |
| adam3us | fluffypony: maybe a charm offensive or a side contract from conformal could fix that real fast. | 14:13 |
| -!- Guest61644 is now known as pigeons | 14:13 | |
| adam3us | fluffypony: they'd only have to convince 2 or 3 people. | 14:14 |
| adam3us | fluffypony: sure it does, if 50% of miners are running btcd and some people are using btcd related clients we have a live nuke ready to go | 14:14 |
| fluffypony | I'm not even sure what you're replying to anymore | 14:15 |
| fluffypony | IRC is a tough mechanism for this ;) | 14:15 |
| adam3us | fluffypony: you said "the majority of miners don't have a say in the matter" | 14:15 |
| adam3us | fluffypony: i said sure the miners control what software they are running | 14:15 |
| fluffypony | and you said "sure it does", which is either a grammatical faux pas or nonsensical, hence my confusion :) | 14:16 |
| fluffypony | miners *don't* control the software that mines the block | 14:16 |
| fluffypony | they use mining software | 14:16 |
| fluffypony | the mining pool is the thing that dictates it | 14:16 |
| kanzure | haha | 14:16 |
| adam3us | fluffypony: pedantic much? | 14:16 |
| fluffypony | no no, not pedantry - I'm actually acknowledging your earlier point about them having to convince "2 or 3 people" | 14:17 |
| -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards | 14:17 | |
| kanzure | large miners just operate their own pool, so that difference doesn't matter | 14:17 |
| adam3us | fluffypony: anyway i hope you see why its a reasonable question to ask btcd what they're trying to do. | 14:17 |
| fluffypony | sure | 14:17 |
| adam3us | kanzure: right | 14:17 |
| fluffypony | kanzure: nonsense, the "unknown" block is only 19% at the moment | 14:18 |
| adam3us | fluffypony: ok (I'm actually acknowledging your earlier point about them having to convince "2 or 3 people") | 14:18 |
| kanzure | fluffypony: huh? | 14:18 |
| fluffypony | 80% of miners mine at known pools, kanzure | 14:18 |
| fluffypony | https://blockchain.info/pools | 14:19 |
| kanzure | why would it matter if you already know the pool? wtf | 14:19 |
| adam3us | fluffypony: s/miners/pools/ same story | 14:19 |
| kanzure | there's a principle agent problem with mining software | 14:19 |
| kanzure | ... possibly not the right classification, but it's there heh | 14:19 |
| adam3us | kanzure: yeah Luke-Jr is working on fixing that. | 14:20 |
| kanzure | it's the mining software that is mining, not the miners that are paying the bills, etc. | 14:20 |
| kanzure | "do what i say not what i mean" or something | 14:20 |
| * kanzure pages larry wall for clarification | 14:20 | |
| adam3us | kanzure: meaning separating voting from hashrate, so you can pool while chosing your own blocks. | 14:21 |
| kanzure | oh, i am probably talking about something different | 14:21 |
| kanzure | a miner (person) can have whatever intentions, but still install software that does something contrary to whatever delusions | 14:21 |
| kanzure | oh, you're talking about principle agent problems with pools, that sounds neat | 14:23 |
| -!- bektar [~jakob@c-46-162-82-69.cust.bredband2.com] has quit [Quit: Lämnar] | 14:24 | |
| -!- belcher [~belcher-s@5ec1ab86.skybroadband.com] has joined #bitcoin-wizards | 14:26 | |
| -!- belcher [~belcher-s@5ec1ab86.skybroadband.com] has quit [Changing host] | 14:26 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards | 14:26 | |
| kanzure | adam3us: do you think it would be wise to advise users of btcd or other alternative implementations to wait for double all the typical recommended confirmation counts? or would that not be helpful | 14:27 |
| kanzure | i don't know why i picked double | 14:27 |
| adam3us | kanzure: its probably going to fail on human time and have devs up 40hrs straight trying to figure out a work-around. i dont think there's a safe usable parameter | 14:27 |
| -!- e1782d11df4c9914 [~e1782d11d@193.138.219.233] has quit [Ping timeout: 264 seconds] | 14:30 | |
| adam3us | kanzure: btcd could help work on libconsensus if they want to be useful. or use bitcoin consensus code. | 14:30 |
| kanzure | is libconsensus different from libbitcoinconsensus | 14:31 |
| adam3us | kanzure: i mean *that* what ever its called. | 14:32 |
| -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-uweidbluouduuyxn] has joined #bitcoin-wizards | 14:32 | |
| kanzure | right, okay. just keeping track and all. | 14:32 |
| -!- SDCDev [~quassel@unaffiliated/sdcdev] has joined #bitcoin-wizards | 14:37 | |
| -!- SDCDev [~quassel@unaffiliated/sdcdev] has quit [Read error: Connection reset by peer] | 14:37 | |
| -!- SDCDev [~quassel@unaffiliated/sdcdev] has joined #bitcoin-wizards | 14:38 | |
| -!- null_radix [Elite7851@gateway/shell/elitebnc/x-mawwowtwotvngbmy] has quit [Read error: Connection reset by peer] | 14:38 | |
| -!- null_radix [Elite7851@gateway/shell/elitebnc/x-qaupwlpaurmefgrc] has joined #bitcoin-wizards | 14:42 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards | 14:43 | |
| phantomcircuit | <fluffypony> if one of those alternate clients (or Bitcoin core) has a bug unique to it...well, fuck, it's a bug, people who are risk averse won't be using a non-core client anyway | 14:44 |
| phantomcircuit | iirc they have been actively attempting to get people to use btcd | 14:45 |
| adam3us | phantomcircuit: right i heard that somewhere probably here. so again it raises the question of why, and who funded them, and whats the profit or other motive. | 14:46 |
| adam3us | i guess one version of the counter is to go bleat to coindesk :) sort of what people do as an alternative to bleating to reddit :) | 14:46 |
| phantomcircuit | heh | 14:49 |
| -!- luny` is now known as luny | 14:51 | |
| -!- shesek [~shesek@IGLD-84-228-189-223.inter.net.il] has joined #bitcoin-wizards | 14:52 | |
| -!- benten [~benten@unaffiliated/benten] has joined #bitcoin-wizards | 14:53 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang] | 14:56 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards | 15:00 | |
| -!- Elio20 [~elio19@gateway/tor-sasl/elio19] has joined #bitcoin-wizards | 15:01 | |
| -!- Elio19 [~elio19@gateway/tor-sasl/elio19] has quit [Ping timeout: 250 seconds] | 15:04 | |
| -!- wiz_ [~sid1@d06f3063.wiz.network] has joined #bitcoin-wizards | 15:06 | |
| -!- wiz [~sid1@d06f3063.wiz.network] has quit [Ping timeout: 272 seconds] | 15:07 | |
| -!- wiz_ is now known as wiz | 15:07 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: This computer has gone to sleep] | 15:08 | |
| -!- pgokeeffe [~pgokeeffe@101.165.93.194] has joined #bitcoin-wizards | 15:12 | |
| op_mul | phantomcircuit: adam3us: I think part of the problem is that people don't know *why* running non-core software is dangerous. I'm sure all it would take to fork bitcoin-ruby or btcd off the network would be peter todd having a lazy weekend. | 15:14 |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 15:14 | |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards | 15:15 | |
| michagogo | op_mul: pretty sure the former has forked off several times | 15:16 |
| op_mul | oh heaps of times | 15:17 |
| -!- benten [~benten@unaffiliated/benten] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 15:18 | |
| -!- benten [~benten@unaffiliated/benten] has joined #bitcoin-wizards | 15:20 | |
| -!- pgokeeffe [~pgokeeffe@101.165.93.194] has quit [Quit: pgokeeffe] | 15:23 | |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards | 15:24 | |
| -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards | 15:36 | |
| -!- agorist0000 [~fircuser@97.95.172.50] has joined #bitcoin-wizards | 15:38 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Ping timeout: 256 seconds] | 15:39 | |
| -!- Aquent1 [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards | 15:42 | |
| -!- narwh4l [~michael@unaffiliated/thesnark] has quit [Remote host closed the connection] | 15:43 | |
| -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Ping timeout: 250 seconds] | 15:43 | |
| agorist0000 | Has anyone ever tried the second two party multisig escrow method described in this blogpost? http://opine.me/future-of-bitcoin-escrow/ | 15:45 |
| agorist0000 | I'm considering using it to construct a new marketplace project in the near future. | 15:46 |
| belcher | agorist0000 i havent used it for a real economic transaction, but its been pretty well known for more than a year | 15:46 |
| belcher | you can use this to do it http://coinb.in/multisig/ | 15:46 |
| belcher | www.bitrated.com is another project with it | 15:47 |
| agorist0000 | Would there be demand for such a market? Similar to Bitmarkets, but using this different escrow method. | 15:47 |
| belcher | you might want to look up the openbazaar project | 15:50 |
| -!- Profreid [~Profreitt@gateway/vpn/privateinternetaccess/profreid] has quit [Quit: Profreid] | 15:51 | |
| agorist0000 | Does open bazaar offer this type of 2party escrow? | 15:51 |
| belcher | yes | 15:52 |
| belcher | it does some other nice stuff, proof of burn to buy your reputation, so you send bitcoins to an unspendable address, and the more bitcoins a merchant has burned the more you can trust them, since they've invested a lot in their merchant identity | 15:52 |
| agorist0000 | Can you point me to any sources for this claim? | 15:52 |
| belcher | /join #openbazaar | 15:53 |
| -!- catlasshrugged [~satoshi-u@65.209.60.146] has joined #bitcoin-wizards | 15:53 | |
| op_mul | belcher: what. burning money gives you a reputation? | 15:53 |
| -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds] | 15:53 | |
| belcher | i think thats how it works | 15:53 |
| belcher | idea is it costs money for the merchant to constantly make new identities | 15:54 |
| gwillen | I assume there's also a way to rate merchants | 15:54 |
| belcher | oh yes | 15:54 |
| gwillen | that's necesasry for that kind of scheme to function | 15:54 |
| op_mul | right off the bat, I can tell you that those with the intent to defraud will be in the best position to do that. | 15:54 |
| belcher | you can start a merchant account without burning anything, give you real life identity perhaps to get reputation | 15:54 |
| belcher | or do small deals first to build rep | 15:54 |
| gwillen | op_mul: if people are smart, such a scheme should work well -- if someone has a perfect feedback record and a burn of 1 BTC, you should be pretty safe doing deals under 1 BTC with them | 15:55 |
| gwillen | op_mul: if you do a 10 BTC deal, of course that doesn't protect you | 15:55 |
| gwillen | (of course, people aren't smart, but.) | 15:55 |
| op_mul | I think that sort of system falls in the same way that hashcash failed. it hampers honest people if you make the difficulty high enough to be an obstruction to a professional. | 15:55 |
| gwillen | that could well be true | 15:56 |
| -!- SDCDev [~quassel@unaffiliated/sdcdev] has quit [Read error: Connection reset by peer] | 15:56 | |
| gwillen | I think more likely who it favors is large but honest businesses, over small but honest ones | 15:56 |
| gwillen | since the former can put up much larger burns (or bonds, in a bond system) than the latter | 15:56 |
| -!- MoALTz_ [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards | 16:00 | |
| -!- agorist0000 [~fircuser@97.95.172.50] has quit [Remote host closed the connection] | 16:00 | |
| -!- agorist0000 [~fircuser@97.95.172.50] has joined #bitcoin-wizards | 16:01 | |
| -!- MoALTz [~no@user-46-112-49-198.play-internet.pl] has quit [Ping timeout: 244 seconds] | 16:02 | |
| -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards | 16:05 | |
| -!- agorist0000 [~fircuser@97.95.172.50] has quit [Remote host closed the connection] | 16:15 | |
| -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds] | 16:18 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang] | 16:25 | |
| -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards | 16:35 | |
| -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 255 seconds] | 16:39 | |
| -!- Adlai` [~Adlai@gateway/tor-sasl/adlai] has joined #bitcoin-wizards | 16:44 | |
| -!- Adlai [~Adlai@gateway/tor-sasl/adlai] has quit [Ping timeout: 250 seconds] | 16:45 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards | 16:48 | |
| -!- jtimon [~quassel@34.pool85-59-141.dynamic.orange.es] has quit [Ping timeout: 244 seconds] | 16:51 | |
| adam3us | who made the first altcoin? | 16:51 |
| belcher | i believe it was namecoin | 16:52 |
| -!- cpacia [~chris@2601:6:1f81:6620:8508:8707:10ea:a953] has joined #bitcoin-wizards | 16:52 | |
| adam3us | hmm ok nm. not making my case as its non-clone. oh well. | 16:52 |
| belcher | litecoin is probably the second | 16:52 |
| adam3us | nah there was one before litecoin, litecoin is a clone of it, it was by artForz and called?? | 16:53 |
| op_mul | tenebrix. | 16:53 |
| adam3us | tenebrix | 16:53 |
| adam3us | there we go yes. | 16:53 |
| adam3us | but i was imagining there were many more before? | 16:53 |
| op_mul | http://mapofcoins.com/ | 16:53 |
| adam3us | oho solidcoin SC or IXC | 16:54 |
| adam3us | https://bitcointalk.org/index.php?topic=38453.0 | 16:55 |
| adam3us | that'll do solidcoin is kind of infamous the one Luke-Jr killed :) | 16:56 |
| op_mul | wasn't that coiled coin? | 16:56 |
| adam3us | op_mul: sorry yes you're right | 16:56 |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang] | 16:58 | |
| -!- catlasshrugged [~satoshi-u@65.209.60.146] has quit [Remote host closed the connection] | 17:02 | |
| -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards | 17:04 | |
| kanzure | adam3us: does testnet count as an altcoin? | 17:13 |
| michagogo | And how about Luke's TBC? | 17:21 |
| op_mul | TBC isn't an altcoin, it's just a client that changes the rendering of the values. | 17:21 |
| michagogo | op_mul: Luke would disagree :P | 17:22 |
| michagogo | (I think I agree with you, though) | 17:22 |
| Luke-Jr | gotta think it through :P | 17:25 |
| -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds] | 17:27 | |
| -!- koshii_ [~0@c-68-58-151-30.hsd1.in.comcast.net] has quit [Quit: leaving] | 17:33 | |
| -!- koshii [~0@c-68-58-151-30.hsd1.in.comcast.net] has joined #bitcoin-wizards | 17:35 | |
| -!- koshii [~0@c-68-58-151-30.hsd1.in.comcast.net] has quit [Client Quit] | 17:37 | |
| -!- koshii [~0@c-68-58-151-30.hsd1.in.comcast.net] has joined #bitcoin-wizards | 17:37 | |
| -!- benten [~benten@unaffiliated/benten] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 17:51 | |
| -!- pgokeeffe [~pgokeeffe@101.165.93.194] has joined #bitcoin-wizards | 17:58 | |
| adam3us | this was the reason why… https://bitcointalk.org/index.php?topic=911339.new#new | 17:59 |
| kanzure | adam3us: hmm, i thought the reason why people made these forks was because they wanted a separate ledger to take advantage of people's inability to keep track of which ledger or blockchain they should be using. the supply function parameter fiddling is separate, i think. | 18:07 |
| adam3us | kanzure: i'm pretty confident that if they were was no economic incentive they wouldnt have opened their compiler. | 18:08 |
| adam3us | kanzure: my point is you can scale bitcoin and its better to use a single unit of account for network effect reasons, and really there is a simple method to value a coins cost and compare that to bitcoins, and yet people are paying huge multiples of that cost for less utility. | 18:11 |
| kanzure | presumably they are paying those huge multiples because of the separate ledgers they are speculating on, not because they value proof-of-work bitcoin scarcity less than some speculative alternative they forgot to evaluate | 18:12 |
| adam3us | kanzure: you have to hope most people are speculating knowing its a zero sum thing and hoping to get out before it crashes as there is no way most of these things could last long. | 18:13 |
| kanzure | well, actually, it's quite possible that people are literally doing coin cost evaluations as you say, i suppose | 18:13 |
| adam3us | kanzure: most alts have no wallets, no merchant integration, no transactions (other than speculating on cryptsy etc) | 18:14 |
| kanzure | hmm so my alternative, which i admit i am not good at expressing, is related to how an onboarding user knows whether or not they are actually using the bitcoin blockchain (or any other blockchain) (or why they should prefer one blockchain to another for their commerce/transactions/business) | 18:14 |
| adam3us | the other point about the pacman game is the features of the coin are separable from it | 18:14 |
| kanzure | right, so basically it's obvious that they are hoping that others will also choose this other blockchain as a speculation on future integration | 18:15 |
| kanzure | and it's not so much about the cost per coin | 18:15 |
| adam3us | but the feature can be copied to any coin, so why would someone value a new coin | 18:15 |
| kanzure | oh, for the incentive reasons you identified above, right? speculation on integration/adoption | 18:16 |
| kanzure | *for the same | 18:16 |
| -!- pgokeeffe [~pgokeeffe@101.165.93.194] has quit [Quit: pgokeeffe] | 18:17 | |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 18:17 | |
| adam3us | wouldnt it make sense to go play roulette or synthetic stock wars or something? | 18:17 |
| kanzure | i agree with you that it's crazy, i'm just nitpicking about what they are probably thinking about (not so much the cost per coin specifically) | 18:17 |
| kanzure | yeah, probably, but i doubt people have ridiculously easy access to that often | 18:18 |
| adam3us | well if any of them are genuinely suckered into thinking black gold coin is going somewhere they're going to get ripped off. | 18:18 |
| kanzure | one anecdote i keep bringing up is a buddy of mine after being introduced to bitcoin on day two became a day trader for some reason, the guy never did any forex or currency day trading in his life before that point | 18:18 |
| adam3us | my wifes cousin got cold called by some boilerroomers trying to sell him black gold coin. he went to his bank and they told him they wouldnt send the money because the recipient account was blacklisted as probably fraud. (he's a bit of a sucker) | 18:19 |
| kanzure | (when i pointed this out to him he realized the error he had made and then promptly forgot why he did that) | 18:19 |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has joined #bitcoin-wizards | 18:19 | |
| adam3us | if you read the web page for black gold coin its talking crazy stuff, that the coin is backed by a virtual element called black gold. | 18:20 |
| kanzure | wait, i remember now, it was something about "well if you sell and then buy back, you can make money obviously, duh" (i'm paraphrasing) | 18:20 |
| adam3us | its gamified. cryptsy needs to unplug from actual coins and go pure synthetic virtual mining virtual coins that exist no where, and are not mined. | 18:20 |
| kanzure | right, i think zynga should look into that for sure | 18:21 |
| kanzure | that can be cryptsy's exit strategy! | 18:21 |
| kanzure | i'm trying to think of any way for me to dig up data to confirm my statements above regarding "it's more about speculation on alternative-blockchain integration/adoption" but i dunno where i would find that, maybe deep in some awful bitcointalk threads... | 18:23 |
| kanzure | i mean, clearly with on adoption the price per coin doesn't matter anyway, because you wont be able to sell it to anyone ever by definition | 18:24 |
| kanzure | *without adoption | 18:24 |
| adam3us | i mean it has to be one of 3 things or a combination right: knowing speculation, unknowing speculation/investment, or confusion about utility being attached to a coin as if code cant be copied. | 18:24 |
| kanzure | oh maybe i meant *with zero adoption | 18:24 |
| adam3us | yes. well a tell tale sign is spammy marketing drives. a guy jumped into the middle of a technical bitcointalk thread yesterday to pump som especial offer for getting stellar handouts. | 18:25 |
| adam3us | give aways, marketing stories, professionally edited videos, nice websites, etc its completely transparent. | 18:26 |
| kanzure | ah right, the giveaways are a good example to reason from | 18:26 |
| op_mul | kanzure: I don't think crypsty needs an exit strategy. they make bank from the fees alone. | 18:28 |
| -!- ysangkok [janus@hapy.0x90.dk] has joined #bitcoin-wizards | 18:33 | |
| kanzure | although, on the other hand, the integration speculation is much more obviously a bad bet | 18:34 |
| kanzure | so you'd have to ask why it happens if that's what's going on | 18:34 |
| kanzure | (compared to adam3us's notes about pricing of scarcity and quantum magic) | 18:35 |
| adam3us | kanzure: there are some real suckers. my wife's cousin tried to wire these black coin boiler room people money. his bank protected him. they're non technical and heard of bitcoin. or they feel the mised out on early adoption and maybe this one is different. | 18:35 |
| adam3us | kanzure: bryce weiner is a good example of a guy pumping stuff. he's always talking up some coin or other with faux analysis | 18:36 |
| op_mul | adam3us: shut up and read some published content on how to evaluate altcoins. https://github.com/aantonop/bitcoinbook/blob/develop/ch09.asciidoc | 18:37 |
| adam3us | op_mul: it must be right its written by bitcoin expert antonopoulos! | 18:38 |
| kanzure | someone should definitely do a writeup of an explanation of how to evaluate altcoin opportunities, and include a factor like "technicalities that i am not familiar with" that has like a 99.9999% weight | 18:38 |
| op_mul | adam3us: honestly give it a read, you'll be in tears. | 18:38 |
| op_mul | some of the altcoins suggested don't even have consensus methods at all. | 18:39 |
| -!- cpacia [~chris@2601:6:1f81:6620:8508:8707:10ea:a953] has left #bitcoin-wizards [] | 18:39 | |
| adam3us | op_mul: lol consensus innovation. i imagine its all broken. seriously someone should fork the crap out of it. or its completely centralised. | 18:39 |
| adam3us | kanzure: so reading that.. what do you think the author was thinking? | 18:40 |
| op_mul | "Since then, innovation in the consensus mechanism has continued at a frenetic pace. Several alt coins adopted a variety of algorithms such as scrypt, scrypt-N, Skein, Groestl, SHA3, X11, Blake, and others." | 18:40 |
| kanzure | adam3us: reading what, sorry? | 18:40 |
| adam3us | op_mul: link op_mul posted | 18:40 |
| kanzure | "i have to be careful writing about this topic or else my audience will lynch me and i will lose face" | 18:40 |
| kanzure | i'd imagine that some calculation like that went through his head for this section (are we sure he didn't just pay someone to write his book for him?) | 18:41 |
| adam3us | i mean either they unbelievably naive or they're like the like people selling cheap plastic stuff on those us tv channels with nothing but marketing fluff for useless junk that'll break within hours | 18:41 |
| op_mul | I think it's actually a list of the altcoins he has bought into. | 18:41 |
| adam3us | omfg u think? well the git checkin has another name so maybe it was ghost written | 18:42 |
| op_mul | adam3us: no, that's the "editor" (who missed spelling mistakes). | 18:42 |
| adam3us | https://github.com/myarbrough | 18:42 |
| kanzure | https://github.com/aantonop/bitcoinbook/commit/6d94cc23311ffa87289c9ad17cd4eec6c37db892 | 18:43 |
| kanzure | https://github.com/aantonop/bitcoinbook/commits/develop/ch09.asciidoc?page=2 | 18:43 |
| adam3us | Many are just get-rich-quick schemes by their creators. To evaluate alt coins, I look at their defining characteristics and their market metrics. | 18:44 |
| adam3us | Here are some of the key financial and market metrics to consider: | 18:44 |
| adam3us | •What is the total market capitalization of alt coin? | 18:44 |
| adam3us | •How many estimated users/wallets does the alt coin have? | 18:44 |
| adam3us | •How many merchants accept the alt coin? | 18:44 |
| adam3us | •How many daily transactions (volume) are executed on the alt coin? | 18:44 |
| adam3us | •How much value is transacted daily? | 18:44 |
| -!- benten [~benten@unaffiliated/benten] has joined #bitcoin-wizards | 18:44 | |
| adam3us | holy moly. | 18:45 |
| gmaxwell | Does that list have any item in it that cna't be trivially faked? | 18:45 |
| adam3us | sorry antonopoulos credibility just dropped | 18:45 |
| op_mul | he had any to begin with? | 18:45 |
| kanzure | op_mul: so do you think it is more likely that it is his list of altcoins he has bought/got paid in, or any chance that he was just trying to avoid getting lynched by altcoiners to keep them from torpedoing him? | 18:46 |
| -!- everettForth [~everett@c-69-181-97-171.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 18:47 | |
| adam3us | i think he maybe went through a pro-alt phase | 18:47 |
| gmaxwell | My expirence is that altcoiners will usually leave you alone if you leave them alone; you only get attacked if you mention something that might influence them... and deaththreats and such seem to take actually calling them out by name. | 18:48 |
| kanzure | ah | 18:48 |
| op_mul | kanzure: there was some comments on this from him when he published the first draft, lots of outcry that he didn't pump whatever altcoin. I think it's just a list of ones he owns, CureCoin and GridCoin for instance don't even have proof of work. | 18:48 |
| * adam3us sleeps | 18:48 | |
| op_mul | well they do, but it's not related to their stated aims of BOINC and folding@home. | 18:48 |
| kanzure | adam3us: i think that to outsiders the "control freak" label is warranted because never have people been exposed to people being so critical about the differences between connecting to one server implementation or another for "blockchain data" | 18:49 |
| kanzure | adam3us: it may be helpful to explain more generally why being on the same blockchain is so important. this may not be obvious to others. | 18:49 |
| kanzure | (important to users, i mean) | 18:49 |
| kanzure | or rather, why it should be important to users | 18:49 |
| gmaxwell | I've had pretty good luck in 1:1 discussions impressing on people some of the scope and challenge of consistency in consensus implementations; and the significant dangers of reimplementing. But 1:1 doesn't scale, and any time I've said anything not 1:1 I've been treated pretty rudely by people who zip to simpler assumptions about my motivations. | 18:51 |
| op_mul | can anybody actually defend implementations? as far as I can see it's all negatives. | 18:54 |
| kanzure | eh, learning tool? as long as nobody uses it | 18:54 |
| op_mul | pretty rough learning tool | 18:56 |
| kanzure | reimplementing something is often a good way to spot your own errors | 18:56 |
| gmaxwell | Like a lot of things, it's just not worth talking about. Somewhat similar to the issue with altcoins in fact; if I see some altcoin is doing something I think is incorrect or outright dishonest and I speak up; I'm taking a risk that I'll be attacked with things like death threats. About the most I can safely do is speak generically so that no one is threatened. (By expirement I've found some gene | 18:56 |
| gmaxwell | ral patterns where I can go beyond that without trouble, but it's generally true) ... and ... I personally gain _nothing_ from pointing out why this or that claim is probably spurrious; at least nothing beyond the amorphous feeling of maybe helping my fellow man not make a bad decision. | 18:56 |
| gmaxwell | kanzure: yes, its a great documentation excercise to rewrite something and throw the result out. Though I'm surprised and concerned that of the reimplementers only bluematt and roconnor seems to have discovered and reported a considerable amount of latent behavior. | 18:58 |
| BlueMatt | "considerable" | 18:58 |
| op_mul | kanzure: sure, but for something like bitcoin reimplementations it's a hell of a lot of work to get to the point where you can actually find anything interesting. | 18:58 |
| kanzure | what counts as considerable here, BlueMatt | 18:58 |
| BlueMatt | notice even minor things and actually report them | 18:59 |
| gmaxwell | kanzure: considerable may be basically more than zero. | 19:00 |
| kanzure | wonderful | 19:01 |
| -!- everettForth [~everett@c-69-181-97-171.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds] | 19:03 | |
| -!- benten [~benten@unaffiliated/benten] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 19:04 | |
| -!- jcluck [~cluckj@cpe-24-92-48-18.nycap.res.rr.com] has joined #bitcoin-wizards | 19:34 | |
| -!- cluckj [~cluckj@cpe-24-92-48-18.nycap.res.rr.com] has quit [Ping timeout: 255 seconds] | 19:37 | |
| -!- jcluck is now known as cluckj | 19:41 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving] | 19:41 | |
| -!- HaltingState [~HaltingSt@unaffiliated/haltingstate] has joined #bitcoin-wizards | 19:48 | |
| -!- eslbaer__ [~eslbaer@p57BCE1FC.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 19:49 | |
| -!- eslbaer_ [~eslbaer@p579E94C3.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] | 19:52 | |
| -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards | 19:55 | |
| -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving] | 19:58 | |
| -!- Tjopper1 [~Jop@dhcp-077-249-237-229.chello.nl] has joined #bitcoin-wizards | 20:06 | |
| -!- Tjopper [~Jop@dhcp-077-249-237-229.chello.nl] has quit [Ping timeout: 244 seconds] | 20:09 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 265 seconds] | 20:21 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 20:23 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] | 20:31 | |
| -!- HaltingState [~HaltingSt@unaffiliated/haltingstate] has quit [Quit: Leaving] | 20:35 | |
| -!- pgokeeffe [~pgokeeffe@101.165.93.194] has joined #bitcoin-wizards | 20:48 | |
| -!- pgokeeffe [~pgokeeffe@101.165.93.194] has quit [Quit: pgokeeffe] | 21:18 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 21:22 | |
| bramc | Hey everybody | 21:22 |
| kanzure | hello | 21:22 |
| bramc | It turns out there's an interesting approach to tackling the electricity problem | 21:24 |
| maaku | bramc: the electricity problem? | 21:25 |
| bramc | maaku, the problem that mining inevitably winds up producing economic waste equal to the value of the rewards because it gets spent on electricity | 21:25 |
| op_mul | I'd call that a core function rather than a problem | 21:26 |
| bramc | The potential loophole is to use a calculation which uses no electricity and no time | 21:26 |
| bramc | op_mul, The use of resources is a core function, but ideally the calculation would demonstrate depreciation of already extant resources rather than require the sinking of new resources | 21:27 |
| bramc | nobody seems curious about my idea | 21:31 |
| gwillen | I think we're all assuming you're about to provide it and we're waiting to hear it | 21:32 |
| bramc | gwillen, fair enough | 21:32 |
| kanzure | and i think you probably lost maaku already :p | 21:32 |
| kanzure | given his previous thoughts regarding the universal scarcity of entropy | 21:32 |
| maaku | i will hold off my cynacism until he at least explains his idea :P | 21:32 |
| gwillen | (I'm curious but skeptical of the idea of demonstrating consumption of an existing resource, in a way where that demonstration can't be reused, without wasting any new resources.) | 21:32 |
| kanzure | maaku: no, no, your cynacism amuses me and is totally necessary | 21:33 |
| bramc | The various attempts at asic resistance have focused on making the calculation use memory, which makes a fair amount of sense: If you spend time waiting for memory you aren't using electricity during that time, and memory is much more commodity than CPU calculations are | 21:34 |
| maaku | i've gotten enough use out of bittorrent to allow bramc a few cycles of my time in good faith | 21:34 |
| bramc | The other idea I suggested before is to use proofs of sequential work, aka proofs of time, as essentially placeholders where everybody sits around doing nothing until the proof of time is done | 21:35 |
| bramc | These both can do a probably pretty good job of asic resistance, but I think they don't go far enough | 21:36 |
| phantomcircuit | gmaxwell, fewer people getting burned by altcoin schemes leaves more people who are still interested in genuine advancements | 21:37 |
| phantomcircuit | ut | 21:37 |
| kanzure | what were your prior objections to the objections to asic resistance? | 21:37 |
| phantomcircuit | improvements to the commons at personal expense and what not | 21:37 |
| bramc | What you need is a proof of *storage*, because storage is vastly more commodity than even memory is: there's basically no way to optimize it more than is already done. and there's lots of it always sitting out there depreciating. And there's a simple proof of storage calculation which can be done. Embarassingly trivial, really. | 21:37 |
| phantomcircuit | bramc, except actually using storage is often very expensive | 21:37 |
| kanzure | salting isn't enough | 21:37 |
| bramc | kanzure, I have nothing against asic resistance, it's a worthy thing, the problem is that it doesn't fix the problem that electricity will be essentially wasted on mining, exactly in accordance with what the mining rewards are | 21:38 |
| kanzure | yes i know you have nothing against asic resistance | 21:38 |
| kanzure | i was asking about your objections to the objections to asic resistance | 21:39 |
| bramc | phantomcircuit, hold on, I'm getting to how to design the proofs of work so that basically nothing other than storage is useful | 21:39 |
| gmaxwell | bramc: do you mean https://bitcointalk.org/index.php?topic=310323.0 or more like permacoin? | 21:39 |
| bramc | gmaxwell, no nothing like any of those | 21:40 |
| phantomcircuit | bramc, so that the storage is useful, but not access times for that storage? | 21:41 |
| bramc | Now this gets into the part which is really weird. Absolutely central to my idea is alternation between proofs of storage and proofs of time, with essentially no time at all being used in the proofs of storage and all of it spent in the proofs of time, but the two interacting | 21:42 |
| -!- Dizzle [~Dizzle@2605:6000:1018:c0f5:e90b:3bb9:f53b:cf8d] has quit [Quit: brb] | 21:43 | |
| -!- kgk_ [~kgk@76.14.85.43] has joined #bitcoin-wizards | 21:43 | |
| bramc | Here's the proof of storage, which might help clarify or make what I'm saying even more mysterious: The proof of storage is a public key whose hash when xored to the hash of the previous proof of time is as small as possible | 21:43 |
| bramc | To initialize everything, you fill up all available storage with a list of public keys sorted by their secure hash, the more the better | 21:44 |
| bramc | (there are some constant factor improvements on that, but I'll skip over them for now because they don't change anything fundamentally) | 21:45 |
| bramc | After you find out the output of the previous proof of time, you go look up the best proof of storage you have locally, use it to sign a new set of transactions, and start giving these to your peers. You re-transmit any record breaking one which peers might send you | 21:46 |
| gmaxwell | bramc: I'm not folling your construction. From what you've described, I can work that function with no memory by grinding public keys instead of sequential POW. (e.g. compute one sequential POW, now generate unbounded pubkeys for a match) | 21:48 |
| bramc | Meanwhile some people out there have supercooled overclocked machines which are working on the proofs of time. They do a proof of time on the best proof of storage anybody puts out (there's no direct reward for finding a proof of time) | 21:48 |
| kanzure | wasn't there a vanitygen grinder proposal at some point | 21:49 |
| bramc | gmaxwell, Yes you can do the same calculation by grinding keys, the problem is that takes time, while doing a lookup of storage is instantaneous, and the interaction with the proofs of time makes the grinding approach lose badly, because it falls behind on time | 21:50 |
| op_mul | bramc: there is actually an altcoin that does proof of storage. | 21:51 |
| op_mul | it has users pre-compute tables of H(nonce + pubkey), and then uses that to salt the previous block hash. the more nonces you have in your lookup table, the more "hashpower" you have. | 21:53 |
| gmaxwell | bramc: uh access times are not at all instant; abstractly storage capacity scales much better than throughput/latency due to difference between volume and surface area. I can generate on the order of 20 million pubkeys per second on a single cpu. It's not that hard to beat out storage access times. | 21:54 |
| bramc | The interaction with proof of time is that there's a single composite difficulty function for proofs of storage and proofs of time, and alternating steps are paired and their combined value has to be over the threshold. The formula is you take the value of the hash of the mined value of the public key taken from proof of storage, xor it with the output of the last cycle, take 1/x, then multiply that by the number of iter | 21:55 |
| bramc | ations the proof of time went through. That gives a composite value which has to be greater than the target | 21:55 |
| op_mul | gmaxwell: burstcoin tries to get around that by splitting the table up into "plots" of 4096 based on some feature of the previous block hash. you only end up reading one 4096th of the total data as a result. in their case it's not faster to mine it PoW style, or at least not sensible. | 21:57 |
| bramc | gmaxwell, Let's say that a machine has a terabyte of data. With some optimizations that can effectively store 250 billion sorted keys. If you have 10 cpus generating 20 million keys per second, that's 200 million keys/second, so it will take you about 1000 seconds to grind through that amount of public keys. Time to look it up after it's pre-calculated: a few milliseconds | 21:57 |
| bramc | op_mul, I haven't heard of burstcoin before, I thought you were talking about permacoin, which does a completely different thing | 21:58 |
| phantomcircuit | gmaxwell, not to mention building custom systems optimized specifically for massive concurrent random io access is pretty trivial | 21:58 |
| bramc | Although that plots thing is much less effective than what I'm talking about | 21:58 |
| op_mul | bramc: be warned, it's a shitty NXT fork. https://bitcointalk.org/index.php?topic=731923.0 | 21:59 |
| gmaxwell | bramc: so what you're saying is that you do a sequential-POW and then you find the nearest pubkey to have to that output value, and the closeness of the match determines the work-factor of your composite solution? | 22:00 |
| phantomcircuit | bramc, asic resistance is whatever, but you really cant assume that other operations cannot be optimized just as much with custom hardware | 22:00 |
| bramc | gmaxwell, the closeness of the match determines how much work will be required in the next sequential-POW | 22:01 |
| -!- jps [~Jud@68.34.201.156] has joined #bitcoin-wizards | 22:01 | |
| -!- pgokeeffe [~pgokeeffe@101.165.93.194] has joined #bitcoin-wizards | 22:01 | |
| phantomcircuit | actually i wonder if there's a commercial solution available for that | 22:02 |
| bramc | phantomcircuit, the idea here is that it's dodging the whole issue, the only thing any time is spent on is the sequential-pow | 22:02 |
| gmaxwell | bramc: so there is a weird surface there of storage vs sequential speed that have the same apparent performance. | 22:02 |
| bramc | gmaxwell, not sure what you mean. The assumption is that the proof of storage is published and anyone running a sequential-pow runs it on whatever thing will result in them finishing fastest | 22:03 |
| bramc | and as soon as they finish they blast it out to everybody else | 22:03 |
| gmaxwell | So I can fork this to make it parallel. E.g. I make a step but then select the _two_ nearest pubkeys, and start two sequential processes. And then find four new solutions; and then I cull to pick the two best of those. | 22:03 |
| gmaxwell | (and of course that same idea expands to whatever level of parallelism I have available) | 22:04 |
| bramc | gmaxwell, yes that's what I'm working through now. If you make it so that the sequential-pow is done on the 50th best proof of storage that attack doesn't work very well | 22:05 |
| gmaxwell | bramc: the surface comment just meant that if someone had a N times faster sequential processor they would need less storage (not n times less, there is a sqrt somewhere in the formula, but I haven't bothered to figure it out) | 22:06 |
| bramc | Oh, yeah, of course you can mine faster if you have a faster sequential-pow. The idea is (a) the sequential-pow will be one which is hard to beat, and (b) to the extent that multiple counterparties all beat it, they wind up screwing each other in mutually assured destruction | 22:07 |
| gmaxwell | As far as publishing, well you can't guarentee that an adversarial party will publish anything, esp if it might not be in their interest to do so. | 22:07 |
| bramc | because whoever has the next-fastest sequential-pow publishes it as soon as they can to stop there being an advantage to the fastest sequential-pow | 22:08 |
| bramc | Sort of like all those VCs thinking they're going to make custom ASICs and get 60% of all mining capacity :-) | 22:08 |
| gmaxwell | as an aside this 'helpfully' incentivizes the construction of industrial scale capacity for cracking the public key cryptosystem. | 22:09 |
| bramc | Let's assume that the public key cryptosystem is secure | 22:09 |
| gmaxwell | assuming they use the capacity to publish instead of instead using it to explore alternative forks to find better hits on their own pubkeys. | 22:09 |
| -!- SDCDev [~quassel@unaffiliated/sdcdev] has joined #bitcoin-wizards | 22:10 | |
| bramc | They lose more from somebody else getting hits faster than they gain from finding faster hits themselves. At least I think that's how it works. I haven't finished analyzing this whole thing | 22:10 |
| bramc | I'm a little more concerned with attacks where somebody takes the nth best pubkey they have and uses that because it results in a much better next generation pubkey for themselves, hence my comment about the 50th best pubkey setting the work factor | 22:11 |
| gmaxwell | I thought your goal there was to achieve a state where basically anyone could run the sequential part about equally fast thus ensuring that basically no one runs it. Oh I see you want to advertise your hit as fast as possible to get other sequential parties working for you. | 22:12 |
| gmaxwell | yea, that was my comment about exploring multiple paths. I think you can use parallel lookahead to get an unbounded speedup in the overall game. | 22:13 |
| bramc | Yes the sequential part is designed to try to be asic resistant as well, although that of course has some level of attackability | 22:13 |
| bramc | I think I can get parallel lookahead to not work very well, and yeah the idea is that everybody should be incented to blast out their hits both on proof of storage and sequential proof of work as quickly as possible | 22:14 |
| bramc | I think if you use the nth best then someone who only has a fraction of the storage capacity loses fairly quickly | 22:14 |
| gmaxwell | e.g. say I'm an attacker divorced from the public system, for the moment, and I can run the sequential program just as fast as anyone else, and my storage is typical; but I also can run the sequential 10,000x in parallel, so I just keep exploring the top 10000 total cumulative work paths, hoping to find a very lucky enumeration that takes me further ahead of the network. | 22:14 |
| gmaxwell | I don't follow how you would enforce the Nth best? | 22:15 |
| op_mul | gmaxwell: I thought that might be possible for burst coin too. same sort of thing as stake grinding, in effect. | 22:16 |
| maaku | what are the supposed benefits of this scheme? | 22:16 |
| maaku | i thought it was supposed to avoid energy wastage, but we're down in the weeds talking about grinding strategies here | 22:16 |
| bramc | In addition to screaming out the very best storage hit, I co-sign it with my n-1 best matches, unless there are some better matches out there which have been sent to me, in which case I send those out. The work factor is determined by the value of the nth best | 22:17 |
| gmaxwell | it's energy efficient. The scheme rewards you according to the storage*time you have. ... at least if it prevented grinding strategies. | 22:17 |
| bramc | gmaxwell, Yes exactly, and I think I can block grinding strategies | 22:17 |
| bramc | if only the very best one is used then grinding works well, if the 50 best are used grinding just fails, because the 50th best match across one's own storage will always be roughly the same | 22:19 |
| gmaxwell | okay, but instead of my N-1 I skip every other one. and that allows me two solutions, one with my best and one with my second best, and one where the work factor is the 100th and one where it's the 101st. The fall-off is linear. I don't think it cancels out, because at the end you end up with four new solutiosn not two. | 22:19 |
| bramc | Now I'm really not following you | 22:20 |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has quit [Remote host closed the connection] | 22:21 | |
| gmaxwell | bramc: I generate two solutions, one with (1,3,5...100) and one with (2,4,6,..101). ~100 is half as good as 50, but I can double my storage and be exactly back where I started in terms of sequential throughput, but now I get an alternative history that might be better for me. | 22:21 |
| -!- benten [~benten@unaffiliated/benten] has joined #bitcoin-wizards | 22:21 | |
| bramc | I don't think I've made my 50th best idea clear | 22:22 |
| gmaxwell | I think you have? you don't just give your best, you give 50 monotonically worsening solutions, and the 50th is used for the difficulty of the next step. | 22:23 |
| -!- kgk_ [~kgk@76.14.85.43] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 22:23 | |
| bramc | The idea is that a proof of storage consists of a single very well matching key signing a transaction log, followed by 49 other not quite so well matching keys signing the same transaction log, and the amount of time which must be spent on the sequential-pow is based on the worst of those keys | 22:24 |
| gmaxwell | And I show that you can split your deck, taking the 100 top solutions and partitioning in two, to get two answers. And if your storage is doubled your 100th solution is as good as the 50th would have been, but now you get the parallel lookahead advantage. | 22:24 |
| bramc | Oh you don't need to partition them that way, you can just make one by 1, 2, 3 ... 50 and the other by 1, 2, 3 ... 48, 49, 51. You can then run lots of small variants in parallel to see which one is best for your own storage | 22:25 |
| gmaxwell | I don't think what they sign matters at all, why would you even bother signing with anything but the first? or the 50th? The matching formula has a strong one way function in it. | 22:25 |
| gmaxwell | bramc: ah, indeed, I was bogusly assuming that they needed to be disjoint. | 22:26 |
| bramc | The problem is that with the 50th best none of them will be a big standout. If you have a small fraction of the total storage capacity the chances of getting lucky with a major standout are like one in a trillion | 22:27 |
| bramc | I made up that one in a trillion. I'm running some simulations and really need to do some math at some point | 22:27 |
| gmaxwell | Oh I wasn't assuming a gain from the raw luck, I was assuming a gain from parallelism. | 22:27 |
| gmaxwell | E.g. what I was suggesting was a way to convert parallel computation into profit for your presumably sequential system. | 22:28 |
| bramc | The gain from parallelism has to do with what your chances of getting lucky are. | 22:28 |
| bramc | Yes and with the simple single best formula that approach wrecks everything. But with the nth best the parallelism only buys you a very modest advantage unless you almost have a majority to begin with | 22:29 |
| -!- SDCDev [~quassel@unaffiliated/sdcdev] has quit [Read error: Connection reset by peer] | 22:29 | |
| gmaxwell | in any case wrt luck the density of values withing distance X of something is a linear ramp. (it's (2*x)/N) | 22:30 |
| bramc | Yes, so if you have 10 times as much storage you expect it to be *on average* a tenth the value, what you get from the parallelism is the ability to pull out the best outlier for yourself. If it's enough samples in the outliers don't outly very much. | 22:31 |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has joined #bitcoin-wizards | 22:31 | |
| bramc | unless i make all my stored pubkeys be clustered... that might throw a spanner in the works | 22:32 |
| gmaxwell | yea, thats an interesting point. Make your pubkeys non-uniform. Well it's even worse, because you can probably build something that looks like a rainbow table spanning subspaces of pubkeys. E.g. disk index X begins a chain of pubkeys which are super rich in solutions near x. You need to do a bunch more computation for this but computation is cheap. | 22:34 |
| bramc | That would of course require a lot more generation time to fill my storage, but that doesn't sound terribly hard to deal with | 22:34 |
| gmaxwell | e.g. you start a key X and you determinstically step from one key to the next. And after some number of steps (say 100ms worth) you compute the centroid of the chainlet. and you store that chain root under that value. | 22:35 |
| gmaxwell | you might perform a K medians clustering and store multiple heads to it as well. | 22:35 |
| gmaxwell | e.g. this chunk of computation has good solutions for values near X, Y, or Z. | 22:35 |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has quit [Read error: Connection reset by peer] | 22:37 | |
| gmaxwell | and you do the lookup, repeat the computation, and tada, you get lots of solutions near your target, also this expensive computation is embarassingly parallel, since you can be grinding on many chunks at once. | 22:37 |
| bramc | Not sure what you mean, but the attacks are straightforward. If I spend as much cpu filling my storage as would be necessary to fill everybody else's storage, I can cluster my pubkeys well enough to do parallelism to find good matches for myself | 22:37 |
| gmaxwell | And you can update your storage over time with increasingly more optimized chainlet nodes. | 22:37 |
| gmaxwell | bramc: I'm explaining another kind of tradeoff that lets you do more computation to get a superlinear gain from your storage. | 22:38 |
| bramc | oh I'm not following. I'm worrying about the one I said because it seems fairly devastating but would like to know yours as well | 22:38 |
| gmaxwell | That instead of storing a map of hash->pubkey you store a map of hash->{family of pubkeys that are more near to hash than you'd expect}. | 22:38 |
| -!- HaltingState [~HaltingSt@2605:e000:1318:c1d2:3171:3db5:e035:7037] has joined #bitcoin-wizards | 22:39 | |
| gmaxwell | What I'm thinking about is kind of inspired by what you are thinking about (assuming I understood it) | 22:39 |
| -!- HaltingState [~HaltingSt@2605:e000:1318:c1d2:3171:3db5:e035:7037] has quit [Changing host] | 22:39 | |
| -!- HaltingState [~HaltingSt@unaffiliated/haltingstate] has joined #bitcoin-wizards | 22:39 | |
| bramc | Oh you keep everything sorted, the assumption is that everybody does that. You also do the optimization that instead of storing the whole public key, you have some personal secret salt which is used in your keygen, and what's stored is the four bytes which are combined with the salt to generate the pubkey | 22:40 |
| gmaxwell | no I don't. I'm not even storing the family. | 22:40 |
| bramc | I'm not following. I'm thinking you basically bucket sort and then look up your best match by going to the location, generating the pubkey, and seeing how good it is | 22:41 |
| bramc | Oh I know, the last hash can generate 50 points which you need to be close to instead of a single one | 22:44 |
| gmaxwell | E.g. a narrower version that might be easier to explain. I compute pubkeys, I pick a random pubkey and check its hash, then I use that first pubkey as a PRNG seed and generate many more pubkeys (perhaps a million of them) and I sort the set, and if position 50 is sufficiently near position 1, I accept this chainlet and store hash->pubkey in my database. | 22:44 |
| gmaxwell | or a million points where you require the best 50 to be close. | 22:45 |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has joined #bitcoin-wizards | 22:45 | |
| gmaxwell | and you can constantly refine your storage by running this process and once you're full replacing the nearest match to pubkey1's hash with your new chainlet if your new chainlet is better. | 22:45 |
| gmaxwell | kind of a beautiful algorithim. Wish I had a use for it. You should go deploy this system so I can profit from this optimization. :P | 22:46 |
| -!- HaltingState [~HaltingSt@unaffiliated/haltingstate] has quit [Quit: Leaving] | 22:46 | |
| bramc | Here's the thing: position 50 is never near position 1 | 22:46 |
| gmaxwell | and it's no worse than the boring way of doing it, since you can just try the 50 nearest tips too. | 22:46 |
| bramc | you basically never get particularly good outliers | 22:47 |
| gmaxwell | the only thing extra is the extra computation for the million derrived points which is just grinding. Also if the derriviation structure is right you get a sqrt() gain because every internal step can be P1 of a new chainlet. | 22:47 |
| bramc | and let's move on to my new idea: that the old sequential-pow specifies 50 positions, and you have to find a nearest match for those 50, and value is based on the worst one | 22:48 |
| bramc | The thing you're saying doesn't work, I was just running simulations of basically the same thing and position 50 is always way off. | 22:49 |
| gmaxwell | lol | 22:49 |
| gmaxwell | go ahead, deploy it then. | 22:49 |
| bramc | No I want to understand what you're saying | 22:49 |
| gmaxwell | It really does work. And it is strictly no worse for a given amount of computation. | 22:49 |
| gmaxwell | Think of if this way, say you have an already computed storage table. | 22:50 |
| bramc | A storage table being a sorted list of compressed pubkeys | 22:50 |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has quit [Remote host closed the connection] | 22:50 | |
| gmaxwell | You're out of space. Then you do some more computation and find a new pubkey for slot X in your storage table. You ask yourself, "is this pubkey the head of a family of pubkeys which is closer to slot X than the one there now?" If so, you replace it. If not you don't. | 22:51 |
| gmaxwell | When you do a lookup you don't just look at the nearest and its 50 neighbors, you also expand out (using parallel computation) the neighbors which have, over time, been refined to be closer to their named positions. | 22:52 |
| bramc | Yeah that doesn't work: the chances of the family being closer are basically nil. But also I decided to change from the '50th closest' approach because of the other attack I said, so now I'm thinking of using 50 separate points | 22:53 |
| gmaxwell | when you sort that list, it has the same 50 members the plain solution would have had, but it also has some additional close members from the process of refinement. | 22:53 |
| gmaxwell | it's only basically nil for a single computation run, but it increases the more computation you do for the exact same reason your storage increases. And the computation can be amortized, because each pubkey you generate in the family is another potential root. | 22:54 |
| bramc | That said, you might be onto something which makes for a reasonable constant factor improvement in your storage effectiveness, if you really are willing to grind a lot | 22:54 |
| gmaxwell | Yes, it's a constant factor related to your additional cumulative grinding time. | 22:54 |
| gmaxwell | it's like a rainbow table. | 22:54 |
| bramc | Let's forget about the clustering thing now and think about it just as points | 22:54 |
| bramc | Because I'm not going to use clustering, because of a much more devastating attack | 22:55 |
| bramc | At point k in my table I can either just put something which starts with k there, or I can put something which starts with k and has a hash which is also close to k | 22:55 |
| bramc | I mean, one of its near descendants is close to k | 22:56 |
| gmaxwell | so okay, what, your squential proof of work selects now 50 points for which you return the nearnest for each and sum their work to get the work of the next sequential? | 22:56 |
| bramc | not exactly, the sequential proof selects 50 points which then have to be paired to 50 public keys, where the amount of time for the next sequential is based on the worst match of the 50 | 22:57 |
| gmaxwell | If so, thats easy to break, becauase you can swap out each of the 50 with the next nearest one at a time and get 50 solutions with approximately the same goodness. | 22:57 |
| gmaxwell | okay so I take the worst and then replace it with the second best for that worst position, and get two solutions which are almost equally as hard, that I can explore in parallel. | 22:58 |
| bramc | my contention is that that won't particularly help you attack. | 22:58 |
| gmaxwell | getting another set of 50 points is like doubling my storage. | 22:58 |
| bramc | Right but you can only explore them in parallel on your own storage. I think the kind of attack you're describing is one which improves how much you're getting out of your own storage but doesn't particularly benefit from trying to make a fork | 22:58 |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has joined #bitcoin-wizards | 22:59 | |
| gmaxwell | bramc: your whole scheme is supposted to give authority proportional to storage, so if I can play stretegically using parallel computation, I get more authority in my alternative universe. | 22:59 |
| bramc | I believe what you're saying is basically at each point get double your utility by storing a value which when used to make multiple derived values has two of them which are very close to the desired value | 23:00 |
| gmaxwell | I've left that attack and I'm now talking about your 50 non-clustered points. | 23:00 |
| -!- jps [~Jud@68.34.201.156] has quit [Quit: jps] | 23:01 | |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has quit [Remote host closed the connection] | 23:01 | |
| gmaxwell | I'm not talking about any 'rainbow table gain' at this point (though I suppose that still remains) | 23:01 |
| bramc | Sorry I was just dealing with a kid having a meltdown, back again | 23:02 |
| gmaxwell | you have many instances of the fast sequential process running. when one yeids an answer you use your storage to produce many candidate solutions (by computing the 50 answers, finding the worst and then finding the next best around that wost which is only slightly worst than your prior worst)... you take all these and sort them, and update your parallel processor setup running the SPOW to continu | 23:03 |
| gmaxwell | e exploring the N best paths found so far. | 23:04 |
| bramc | I'm not sure what your attack is. I'm sure there's some amount of an 'attack' using the stuff I was just talking about, but whether that's a real attack or just reasonable best practices I don't know | 23:04 |
| gmaxwell | What I'm describing is somethign that lets someone who can run many copies of the SPOW in parallel gain a potential advantage. Perhaps one copy they'd use publically to keep partitipcating the the honest network, but they keep the others going privately. Maybe this is a "best practice" but then I think the scheme just reduces to convoluted POW. | 23:05 |
| bramc | Yes, so for some amount of running in parallel you can get some factor better than what your storage 'should' get based on its size | 23:05 |
| bramc | The thing I was just talking about is totally unrelated to running the spow | 23:07 |
| bramc | Let's say we take the most effective case for running parallel spows. There's some public thing which has just happened, giving 50 public keys, I can substitute any of those with my own next nearest, which might not be so far off (although if I only have a small fraction of storage it will be). I can use those small variants to get a whole bunch of spow outputs and see how well they'll work for me. | 23:09 |
| bramc | The problem is that those spow outputs aren't going to be good for me at all. If I have 1/10 the storage capacity, then my worst of 50 will essentially always be fairly close to 10 times worse than what the public network will generate | 23:10 |
| gmaxwell | forget 1/10th the storage. lets assume everyone is equal. equal storage. equal computation. equal spow speed. Except you have multiple spow processors and can run the spow in parallel. | 23:11 |
| bramc | so you have like 1/1000 of all storage | 23:11 |
| bramc | I understand what you just said, but don't see an attack under those circumstances | 23:12 |
| gmaxwell | I say you get a substantial benefit relative to other people from doing so. In fact, I think you get benefit linearly proportional to your spow parallelism. Lets make your parallelism unbounded. You have N entries in storage. When the network steps you compute the best solution and make it public, you then compute N-50 SPOWs. When any spow (network or local completes) you compute N-50 more candi | 23:15 |
| gmaxwell | date starting solutions, and you terminate replace any of your N-50 parallel processes that have lower expected returns than your new fodder. | 23:15 |
| bramc | Having an edge from a historical starting point doesn't really help. Everybody's ahead of you | 23:16 |
| gmaxwell | in the limit (assuming storage goes to infinity) your speedup from this strategy is infinite after one additional step (depth 1 reorg). | 23:16 |
| gmaxwell | because some lucky draw will be a BAD step, then a bunch of awesome steps, and you reorg the network. | 23:17 |
| bramc | Oh, ummm, an important point here: the SPOW is based on the hash of the previous proof of storage, you can't have them sitting around for use later | 23:18 |
| gmaxwell | I do agree that the storage in practice bounds your parallism but it means that parties with big cpu farms would have an advantage, and worse, part of that advantage can only be used for attacks, because it'll be late to the party. | 23:18 |
| gmaxwell | I know, thats why you're exploring many possibile futures. e.g. one where the step was X, one where it was the slightly worse solution Y, one where it was the slightly worse solution Z, and so on. | 23:19 |
| gmaxwell | Maybe unlucky Z's answer turns out to be a really lucky draw that yealds a very cheap SPOW for the step after that. Won't know unless you try it. | 23:20 |
| bramc | Yeah so you find those and they're all worse than what the public network has found, so if you're doing a spow yourself for the follow-on generation, and the network has already gotten ahead of you... | 23:21 |
| gmaxwell | if they're worse than what the network as found, thats okay. when the network finds something you check each of your brewing SPOWs and ask if network_next_work < work_left_on_this_one+average_work and if so replace it with a next step based on the network. | 23:22 |
| bramc | Even after the very first iteration of parallel spows every single one of those will finish behind the public network (unless you find one that's a bit ahead and give up your share of public mining rewards to play this little game) | 23:22 |
| gmaxwell | so yes, you'll often be replacing most of your parallel processes with work based on the network. | 23:22 |
| -!- kgk_ [~kgk@76.14.85.43] has joined #bitcoin-wizards | 23:24 | |
| bramc | That can only be done if you've hardly forked at all. Are you suggesting an attack where when the network is at generation X, you figure out a slightly worse version of generation X, which makes you personally able to do generation X+1 faster, and then you introduce that to the network? | 23:24 |
| gmaxwell | Yes, and then you make it to generation X+1 faster than the network, and so it reorgs onto your state... but not just X+1 you have many parallel processors and with exponenitally decreasing probablity you may be the network at X+2, or X+3 or so on. | 23:25 |
| -!- bit2017 [~linker@42.116.152.78] has quit [Ping timeout: 240 seconds] | 23:25 | |
| gmaxwell | Your goal: increase my density of blocks in the longest chain, at any cost. Your resources: fixed storage, same as anyone else, and the ability to buy as much parallel SPOW as you like. | 23:26 |
| bramc | There's some tradeoff here where based on what fraction of all mining capacity you have and how many parallel operations you have and what the N is which we've been discussing as 50 for arguments sake you can get some amount of advantage, but running the numbers myself the effect seems extremely weak | 23:26 |
| gmaxwell | What is the optimal strategy? I argue that its one that incentivizes producing reorgs (potentially long ones) based on using the parallel processing to consider alternative histories beyond the 'best' one that you and the network are also working on. | 23:27 |
| bramc | If I have 1/x of the total storage, and I run just 1 extra SPOW, it will result in me taking on average x times as long to do the next spow if I do everything based on my own storage | 23:29 |
| bramc | So the question becomes, how much more favorable does that get with using lots of extra parallel SPOW? And I think the answer is not very much | 23:30 |
| bramc | It certainly isn't the case that doubling the amount of parallel SPOW halves the amount of expected work. That would be the case if you were only using one point, hence using more points | 23:32 |
| gmaxwell | I think with infinite parallel spow the benefit is actually infinite at least when everone's storage is also infinite. Basically you lose this round, but one of your next steps which takes episilon longer than the honest network, ends up with a perfect match, and then do the next set of SPOW in time 0 and end up producing infinite blocks before the honest network has produces two. | 23:34 |
| gmaxwell | But perhaps thats the kind of crazy result when you look at the limits at infinity. :P | 23:34 |
| bramc | A rough example calculation is that the chances of getting less than half of your own expected difficulty of spow for the next generation is 1/2 for getting under the limit for each separate point, so that's 1/2**50 for even a speedup of 2, over your own expected difficulty much less the difficulty of everybody else | 23:35 |
| bramc | Yes infinite parallel spow yields infinite advantage, but you can't have infinite parallel spow, that requires resources | 23:35 |
| gmaxwell | Well the point of the infinite is to say that this process (at least when storage is sufficiently large) reduces to plain POW. | 23:36 |
| bramc | So we can guess that you don't have, say 2 ** 64 spow, and even that is completely ridiculous, you probably don't even have 2**32 parallel spow | 23:36 |
| bramc | It doesn't reduce to plain pow because the costs are such that you're burning more on spow than the value you're gaining from it. If a linear relationship held up that would be true, but it's set up so that running parallel spow is mostly just wasting resources unless you already have a majority of storage capacity | 23:39 |
| bramc | This part I can work out some more math on and justify straightforwardly. I need to do some serious thinking about cpu tradeoffs for getting more out of storage though. | 23:39 |
| -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Remote host closed the connection] | 23:41 | |
| -!- rasengan [rasengan@pdpc/corporate-sponsor/privateinternetaccess.com/rasengan] has joined #bitcoin-wizards | 23:50 | |
| bramc | Well, I have some tweaks to make and things to work through, thanks for the feedback | 23:51 |
| gmaxwell | Interesting discussion. I do think this class of algorithims gives me a useful solution to a different problem that I've been working on for some time. And that is creating an anonymous cumulative work hashcash. E.g. a hashcash which you can use up to N times concurrently, and infinite times sequentially; without anyone being able to link the work togeather (so long as you don't break the concur | 23:51 |
| gmaxwell | rency bound). I have a couple constuctions that achieve this to different levels, though the best are kinda ugly and require snarks. | 23:51 |
| gmaxwell | from this general class of ideas I can extract some better ones, though they do have unfriendly TMTO tradeoffs. | 23:51 |
| bramc | I'm not sure what you're describing, but it sounds interesting, and I'm happy if my thoughts help | 23:52 |
| gmaxwell | No problem on the feedback, good luck. | 23:53 |
| go1111111 | FYI, the last logs from this channel are from over 36 hours ago, at https://botbot.me/freenode/bitcoin-wizards/ (was thinking it'd be nice if the above discussion was logged) | 23:59 |
| op_mul | go1111111: https://download.wpsoftware.net/bitcoin/wizards/2015-01-02.html | 23:59 |
| --- Log closed Fri Jan 02 00:00:08 2015 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!