00:46:46	jbenet_:	jbenet_ is now known as jbenet
01:33:05	op_mul:	tacotime: the reason I don't like that too much is that it means you can't recover a wallet just with a BIP32 seed. you need to go digging around for metadata you may or may not have retained.
01:33:52	op_mul:	"you know that ephemeral key I emailed to your hotmail address like 5 years ago?" "er"
02:22:10	beamlaser:	the code for cspace has been released https://github.com/jmcvetta/cspace in case anyone wants to audit it.
02:50:35	samson2:	samson2 is now known as samson_
02:59:42	Guest61341:	Guest61341 is now known as s1w
03:05:43	pgokeeffe_:	pgokeeffe_ is now known as pgokeeffe
03:14:22	pgokeeffe_:	pgokeeffe_ is now known as pgokeeffe
04:08:16	otoburb_:	otoburb_ is now known as otoburb
05:19:01	rusty:	rusty has left #bitcoin-wizards
09:05:16	kornbluth.freenode.net:	topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
09:05:16	kornbluth.freenode.net:	Users on #bitcoin-wizards: andy-logbot damethos digitalmagus eslbaer MoALTz__ Aquent Transisto TheSeven e1782d11df4c9914 Emcy Starduster op_mul hollandais BigBitz_ Adlai Elio19 dgenr8 [\\\] michagogo Muis_ mappum ryanxcharles epscy koshii gnusha poggy _Iriez roasbeef Meeh_ otoburb Guest49039 s1w go1111111 moa bsm117532 HM2 ebfull Apocalyptic coiner sdaftuar luny` waxwing atgreen btcdrak CryptOprah kumavis btc__ jbenet nuke1989 samson_ nsh hashtag wiz adam3us
09:05:16	kornbluth.freenode.net:	Users on #bitcoin-wizards: HarusameNyanko Guest19027 jcorgan cluckj OneFixt wizkid057 PaulCapestany maaku forrestv jgarzik bitbumper Luke-Jr rfreeman_w todays_tomorrow tromp_ PRab null_radix SubCreative c0rw1n hashtagg LarsLarsen pi07r optimator_ Greed Dyaheon Tjopper1 lclc_bnc sl01 spinza harrow gmaxwell gavinandresen NikolaiToryzin Cory copumpkin isis iddo jaekwon sadgit brand0 eric hktud0 Krellan fanquake berndj @ChanServ jaromil petertodd tromp DougieBot5000 helo
09:05:16	kornbluth.freenode.net:	Users on #bitcoin-wizards: v3Rve midnightmagic espes__ fluffypony butters nickler Logicwax lnovy ahmed_ warren fenn mkarrer phantomcircuit Graet morcos kanzure gribble MRL-Relay Graftec bobke huseby [d__d] BananaLotus amiller artifexd coryfields coutts BlueMatt cfields Anduck Eliel nanotube hguux_ AdrianG gwillen wumpus stonecoldpat dansmith_btc toddf heath bbrittain DoctorBTC EasyAt starsoccer danneu catcow TD-Linux ryan-c smooth mmozeiko Alanius JonTitor asoltys_
09:05:16	kornbluth.freenode.net:	Users on #bitcoin-wizards: K1773R a5m0 comboy Nightwolf pigeons andytoshi lechuga_ warptangent Fistful_of_Coins Guest38445 kinlo azariah yoleaux sneak harrigan sipa livegnik burcin Taek throughnothing crescendo so Keefe phedny BrainOverfl0w
10:27:42	adam3us:	happy new year wizards :) may 2015 be even more interesting if thats possible without our heads popping from blockchain coolness overload.
10:30:05	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)
10:31:09	op_mul:	adam3us: you got snipped there.
10:31:17	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.)
10:31:56	adam3us:	op_mul: really that was only 6 lines?
10:32:03	gmaxwell:	But, e.g. it doesn't prevent getting rid of your bonded coins and the replacing the chain.
10:32:12	op_mul:	was that the post that "solved" boostrapping nodes with ask-a-friend?
10:32:13	gmaxwell:	adam3us: your line ended with "unless you pre-commit to it to cast it)"
10:32:23	adam3us:	yeah that was the end of it :)
10:32:59	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
10:33:17	adam3us:	where its defined you cant go further back than n-blocks.
10:33:32	op_mul:	"auto checkpoint" really is a oxymoron. I wish altcoins wouldn't use that as a security feature.
10:34:51	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
10:35:14	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.
10:35:25	op_mul:	NXT has been quoting that as a solution to everything for quite a long time, they prevent large reorgs to some degree.
10:36:21	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."
10:36:40	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.
10:38:01	adam3us:	gmaxwell: thats an ongoing interest or rent for free supply inflation protection for any holders.
10:38:41	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
10:38:49	adam3us:	do y'all think that attack works?
10:39:02	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)
10:39:08	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.
10:40:35	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
10:41:16	op_mul:	vpos?
10:41:56	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.
10:42:48	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)
10:43:29	op_mul:	adam3us: yes. he is good at that.
10:43:44	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.
10:46:15	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.
10:47:19	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
10:47:35	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).
10:48:02	iddo:	and other proof-of-x too, e.g. proof-of-storage you need to be careful not to have same problem
10:48:59	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.
10:49:32	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.
10:49:38	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.
10:49:59	adam3us:	iddo: true for PoS (cant start from scratch)
10:50:00	gmaxwell:	adam3us: yea you can be excluded from participating by the current participants.
10:52:16	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.
10:52:19	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)
10:53:40	gmaxwell:	iddo: rational isn't enough. It's rational, after you've spent all your coins to sell your past empty private keys.
10:54:43	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.
10:54:44	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.
10:55:39	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?
10:55:52	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.
10:56:34	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.
10:56:59	adam3us:	gmaxwell: so it seems everyone has an incentive to pretend to not hear anyone elses bonding transaction. thats kind of interesting.
10:57:00	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.
10:57:24	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?
10:57:36	gmaxwell:	iddo: Then at time Y (Y>>X) someone replaces the history starting at X using those keys.
10:57: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.
10:58:24	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.
10:58:55	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)
10:59:13	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.
10:59:36	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.
11:00:12	iddo:	gmaxwell: yes, i see you point, thinking about it now...
11:00:23	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.
11:00:33	adam3us:	gmaxwell: doesnt that imagine the exit of every initial holder?
11:01:20	adam3us:	gmaxwell: but leaked keys wouldnt hurt after transfer is acknowledged past the n-block window, and reorgs arent accepted past it
11:01:30	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.
11:02:06	adam3us:	gmaxwell: ok. i was focussed on the vitalik params to the idea. fair enough!
11:02:13	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)
11:02:41	gmaxwell:	but yea, I wasn't talking about the bonded coins idea specifically.
11:02:43	iddo:	gmaxwell: yes, you need to assume that the majority at time X is rational at all future time Y, weaker assumption :(
11:03:29	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!!
11:03:38	gmaxwell:	iddo: actually that it is rational at X but _honest_ (altruistic) at all sufficiently far future times, so it's even stronger.
11:03:41	iddo:	actually rational is unclear in this context, i meant that it will be rational for the majority of time X not to attack
11:04:47	gmaxwell:	adam3us: yep. I think you're right.
11:05:54	op_mul:	iddo: I don't think you really want to predicate security on rationality
11:06:24	gmaxwell:	op_mul: in consensus systems you are limited in what you can do there.
11:06:49	gmaxwell:	op_mul: ultimately there is no physical defintion of the right state, so any security argument has to involve the users.
11:07:34	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.
11:08:03	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
11:08:53	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.
11:09:47	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)
11:09:51	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
11:10:25	gmaxwell:	adam3us: uh, I think you misunderstood me.
11:11:03	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.
11:11:47	adam3us:	gmaxwell: you'd want to invalidate voting for a n-block period after sale.
11:11:51	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.
11:13:14	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.
11:13:20	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...
11:14:05	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.
11:15:46	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 ?
11:15:48	adam3us:	gmaxwell: the sell and double-vote is a problem.
11:17:06	adam3us:	iddo: that would take the majority. bitcoin could fork or rewrite history (eg to a snapshot before mtgox went bad)
11:17:48	iddo:	adam3us: yes majority of those who already sold and no longer have any stake... weak assumption :(
11:17:58	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
11:18:18	iddo:	adam3us: i suggested majority to checkpoint to avoid this problem, it has tricky issues too
11:18:27	op_mul:	s/highest/most difficulty/
11:18:30	adam3us:	iddo: i imagine vitalik would tell you to pick not from sybil random people but people you trust. hence weak subjectivity
11:18:45	op_mul:	yes.
11:18:50	adam3us:	op_mul: yeah thats what i meant, poor phrasing.
11:18:56	op_mul:	and you can imagine how that will devalue.
11:19:15	op_mul:	a central service that does the checking for you.
11:19:16	iddo:	adam3us: gmaxwell and i were talking about any pure PoS system, not assuming particular ways that it behaves
11:19:41	adam3us:	iddo: well pure PoS has nothing at stake so is buried and forgotten?
11:20:27	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
11:20:39	op_mul:	requires?
11:21:35	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
11:22:49	iddo:	op_mul: yes see e.g. https://bitcointalk.org/index.php?topic=194078.msg2014204#msg2014204
11:22:49	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
11:23:36	op_mul:	iddo: that's not really a requirement.
11:23:55	iddo:	adam3us: i meant to avoid creating easy-difficulty blocks at genesis and carry out DoS, eg. see bitcointalk link i pasted
11:23:56	adam3us:	iddo: oh _that_ DoS, ok.
11:24:39	op_mul:	iddo: slightly less important with headers first, too.
11:24:52	gmaxwell:	iddo: Bitcoin core no longer requires checkpointing to avoid DOS.
11:24:56	adam3us:	maybe compact SPV proofs could fix that. you fill the in backwards if presented with a compact SPV proof that is higher work.
11:25:09	iddo:	gmaxwell: how come?
11:25:21	gmaxwell:	Headers first almost completely eliminates that concern.
11:25:41	gmaxwell:	(and compact SPV proofs could close it off further)
11:26:09	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?
11:26:19	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.
11:26:53	op_mul:	gmaxwell: I thought your stance at one point was that they were still desirable?
11:27:16	gmaxwell:	op_mul: huh? no. I have no clue what I would have said that might have indicated that!
11:27:21	iddo:	gmaxwell: hmm with header first, couldn't you create extentions to genesis block and spam the network with that?
11:27:43	op_mul:	gmaxwell: must have been someone else, don't worry I haven't been spreading that as "gmax says//"
11:27:43	adam3us:	iddo: i guess the point is headers are small.
11:28:31	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.
11:28:36	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
11:29:08	gmaxwell:	iddo: Not sure if you've seen, https://download.wpsoftware.net/bitcoin/pos.pdf
11:29:12	iddo:	adam3us: this ^^ link is the construction that we proposed, it relies on randomized lottery among stakeholders
11:29:21	gmaxwell:	iddo: which presents a number of generic POS issues.
11:29:58	iddo:	gmaxwell: i've seen an old version, i don't think the problem that we discussed now is there?
11:30:08	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)
11:30:49	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.
11:31:07	iddo:	ok
11:31:36	iddo:	gmaxwell: ok so maybe the need for checkpoint in PoS isn't unfair if you can avoid it in Bitcoin
11:31:40	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.
11:32:19	iddo:	gmaxwell: but still, checkpoints to speed up performance to end-users is nice with PoW too, SNARKs can help
11:34:15	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
11:34:38	iddo:	s/i might/it might
11:36:14	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.
11:37:27	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?
11:37:38	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
11:37:44	gmaxwell:	iddo: if you are invoking a snark though you don't need anything like a checkpoint.
11:38:19	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. :)
11:38:56	iddo:	gmaxwell: ok maybe i used bad terminology, i meant using snark as a trust-free checkpoint
11:39:08	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.
11:40:07	gmaxwell:	iddo: I understood. You shouldn't use the word checkpoint there. Becuase, e.g. that doesn't vindicates trusty-checkpointing PoS schemes. :)
11:40:42	gmaxwell:	adam3us: well you already pointed out why that doesn't work in the face of a byzantine attacker.
11:42:02	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.
11:42:40	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
11:43:06	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)
11:43:28	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.
11:43:30	gmaxwell:	iddo: it doesn't actually solve any security problem there, it's just an optimization regardless.
11:44:01	adam3us:	gmaxwell: yeah there is some similarity in outcome for sure.
11:44:40	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
11:45:05	gmaxwell:	iddo: sure but you can just expose the signatures, no snark needed.
11:45:56	iddo:	yes, i meant the "checkpoint" is needed, snark is always just (maybe) an optimization
11:47:02	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.
11:47:21	adam3us:	where the PoW would be double voting dust to nudge one or other fork to win.
11:47:36	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
11:47:43	adam3us:	(no longer part of their protocol anyway, that probably counts as a fail)
11:48:16	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.
11:48:48	gmaxwell:	I'm pretty close to being able to demonstrate an actual zero knoweldge contingent payment in bitcoin using it.
11:49:06	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.
11:53:34	iddo:	gmaxwell: nice to know, alas it requires trusted setup, i'm working on non-trusted-setup variant (PCP proofs) now
11:54:46	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)
12:01:03	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.
12:01:37	gmaxwell:	iddo: the non-trusted setup work is super important. Do you yet have any ideas on the concrete efficency?
12:06:48	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)
12:07:41	gmaxwell:	iddo: well I have a setup that is amortized. (assuming that you really like buying sudoko answers...)
12:07:51	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
12:08:19	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.
12:08:57	iddo:	but the verifier will also need to compute the keygen procedure...
12:09:56	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.
12:10:50	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.
12:11:29	iddo:	not sure that i understand, anyway the keygen is just some totally generic procedure that prepared random elements for bilinear pairings, or something
12:11:44	gmaxwell:	* gmaxwell forehead
12:12:44	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.
12:13:10	iddo:	BTW it needs snark circuit for AES, anyone wrote that yet? the zerocash people only wrote SHA256
12:13:53	gmaxwell:	iddo: I replaced the AES with more SHA256. Also the zerocash people haven't released any of their circuits; fortunately someone else did.
12:14:07	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
12:14:14	gmaxwell:	iddo: E.g. SHA256(secret||counter)^data is a nice enough stream cipher.
12:14:39	gmaxwell:	iddo: because the vast majority of the computation is outside of the ZKP entirely.
12:15:07	iddo:	ok, but still number of steps for encrypt+hash are needed
12:16:04	iddo:	i.e. the proof needed for ZKCP isn't made more succinct that a non-snark ZK proof for this encrypt+hash computation
12:16:19	iddo:	s/that/than
12:17:33	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)
12:17:58	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
12:18:49	gmaxwell:	ZKCP doesn't need a succincy ZKP to be worth doing; it just needs to be pratical enough.
12:19:47	iddo:	in the garbled circuits world i think the situation is reversed, there are AES implementations, and no one bothered to implement SHA2
12:19:58	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.
12:20:27	gmaxwell:	yea, seveal of the MPC programs I've seen have a semi-honest protocol that does AES.
12:21:24	iddo:	maybe they also have cut-and-choose implementation to handle malicious case
12:22:30	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.
12:22:42	iddo:	not even implementation, just some automation i guess, it'd work because interactive is ok for ZKCP
12:23:05	gmaxwell:	yea, interactive is okay, though engineering wise its better if there is less.
12:23:16	gmaxwell:	e.g. SNARK ZKCP works over email.
12:23:36	gmaxwell:	where as a MPC one wouldn't.
12:24:25	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:)
12:26:22	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
12:29:27	iddo:	what about the verification circuit for sudoku or whatever, it's implemented as snark already?
12:30:02	iddo:	13:53 < iddo> gmaxwell: nice to know, alas it requires trusted setup, i'm
12:30:05	iddo:	13:53 < iddo> gmaxwell: nice to know, alas it requires trusted setup, i'm
12:30:19	iddo:	oops paste, my keyboard sucks sorry :(
12:33:18	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.
12:35:25	iddo:	cool
13:42:11	adam3us:	is larger blocksizes (as gavinandresen was discussing) a hard fork? i presume it must be?
13:43:19	gmaxwell:	Of course. (gosh if the system didn't control the maximum size...)
13:44:53	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.
13:46:04	Luke-Jr:	adam3us: until we have regular full blocks, it's hard to speculate on when we might need to increase block size IMO
13:50:27	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
13:50:51	adam3us:	gmaxwell: to get a soft-forkable blocksize increase.
13:52:20	gmaxwell:	you don't neven need that, you can just have the moved coins disappear.
13:53:10	adam3us:	gmaxwell: you'd want the 1mb utxo to be compatible i think.
13:53:23	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.
13:53:52	gmaxwell:	adam3us: why? it doesn't matter: The coins just are invisibly unspendable to old nodes.
13:54:29	adam3us:	gmaxwell: they dont know its unspendable so 1mb block utxo set grows. minor point.
13:54:42	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.
13:55:00	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.
13:55:13	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).
13:56:08	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
13:57:24	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.
13:57:25	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).
13:57:56	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.
13:58:04	adam3us:	gmaxwell: the extension coins seem a bit opt-in no?
13:58:32	adam3us:	gmaxwell: ok you're talking about blocksize, yes i agree.
13:58:58	adam3us:	gmaxwell: (centralisation side-effects of)
13:59:53	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
13:59:59	gmaxwell:	very rapidly forced onto it.
14:01:39	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.
14:02:45	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 ). barf.
14:03:59	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.
14:04:05	gmaxwell:	oh jeez, indeed, thats true.
14:04:28	gmaxwell:	well I suppose that takes away the can't recieve at all point I was just making.
14:05:15	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.
14:05:36	gmaxwell:	described*
14:06:41	adam3us:	gmaxwell: hmm i wonder if we just described an alternate view of sidechains there?
14:07:08	adam3us:	gmaxwell: make the extension block merge mined, something close & related anyway.
14:07:31	adam3us:	gmaxwell: send the extension transactions over a different p2p port/magic number.
14:08:48	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)
14:09:29	adam3us:	gmaxwell: re-reading it now :) kind of forgot that bit
14:11:25	adam3us:	alright yes thats very related commentary.
14:12:45	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.
14:16:27	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 are serving as a peg pool.
14:17:27	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.
14:17:47	adam3us:	gmaxwell: the universes can co-exist and security defects do not leak from the extension coins to people who dont opt in.
14:18:10	adam3us:	gmaxwell: so separate from increasing block size that seems actually kind of interesting.
14:18:58	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'
14:19:39	adam3us:	gmaxwell: yes you are right. thats the limitation. hmm.
14:19:43	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.
14:20:31	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...
14:20:42	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.
14:21:11	adam3us:	gmaxwell: yes. somehow coerce it into being deterministic now matter.
14:21:15	gmaxwell:	yea, thats the goal of the thing I just mentioned, and I agree it may be adequate for this.
14:22:01	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.
14:24:24	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.
14:24:37	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
14:25:38	gmaxwell:	adam3us: yes but without interaction those proofs may not be compat.
14:25:45	gmaxwell:	compact*
14:26:04	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)
14:26:53	adam3us:	gmaxwell: yes. kind of like rusty seemed to be thinking of for disproving fraud in other shards in pettycoin
14:27:30	adam3us:	gmaxwell: alright op_spv + op_moxie :)
14:31:46	adam3us:	gmaxwell: maybe there are an interesting enough range of things that are compactly non-interactively disprovable.
16:53:25	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.
16:53:33	atgreen:	uClinux, I mean.
16:54:25	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)
16:55:12	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.
17:13:32	Guest49039:	Guest49039 is now known as mr_burdell
18:30:50	gmaxwell:	petertodd: Building consensus code in very high level languages, demonstrated: https://www.youtube.com/watch?v=RkTvDjhImwo
19:50:33	petertodd:	gmaxwell: heh, I didn't even need to hit play to know what that video was...
19:55:28	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
20:01:15	narwh4l:	petertodd, don't shoot me, but serpent is a turing complete contract language, right?
20:01:31	narwh4l:	petertodd, so a clone of that might suffice
20:02:02	narwh4l:	petertodd, then you build you consensus system on top of that? Maybe? Just thinking out loud
20:03:34	michagogo:	gmaxwell: uh, wtf is happening in that video
20:08:26	michagogo:	Ah, heavily modified components
20:08:26	michagogo:	https://www.youtube.com/watch?v=mzDTZuFJYX4
21:05:23	roidster:	roidster is now known as Guest66177
21:25:27	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
21:25:59	adam3us:	are the btcd guys on this channel?
21:27:22	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.
21:27:38	adam3us:	(who it seems is lead dev on btcd)
21:30:41	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)
21:42:49	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
21:43:50	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
21:45:00	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.
21:45:59	kanzure:	oh, you think they do see the fork risk?
21:46:37	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.
21:47:07	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"
21:47:24	fluffypony:	adam3us: do you have the same concerns with Bits of Proof's client?
21:49:17	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.
21:49:54	fluffypony:	sure, but the consensus rules are (and should be) clear and open, you can't prevent alternate clients on principle alone
21:49:58	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.
21:50:05	kanzure:	right
21:50:35	kanzure:	or do things like "get a transaction signed on one fork, and then relay it on another"
21:50:36	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.
21:51:01	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
21:51:04	narwh4l:	* narwh4l laughs at "home nukes"
21:51:07	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)
21:51:16	kanzure:	(or the fallout zone)
21:51:43	kanzure:	((i asked elon for a space habitat for xmas but it hasn't arrived))
21:51:58	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
21:52:44	kanzure:	"control freak" as in "you shouldn't expose your users to your incompetence"?
21:52:54	fluffypony:	* fluffypony shakes his head
21:53:03	kanzure:	*possible incompetence
21:53:07	fluffypony:	the very nature of a consensus system means that there may be consensus to use a client different to Bitcoin Core
21:53:11	fluffypony:	and that should, at the very least, be respected
21:53:13	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
21:53:30	kanzure:	adam3us: you are still experiencing cutoff methinks
21:53:32	adam3us:	fluffypony: client alone, yes thats caveat emptor
21:53:51	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
21:53:55	fluffypony:	yeah I saw cut off at "people would like to do that but"
21:54:53	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.
21:54:55	kanzure:	there are some subtleties that would be missed here if "control freak" is the only explanation you can use
21:55:14	kanzure:	adam3us: you should consider installing an irc client or a plugin for your irc client to split lines of text
21:55:28	adam3us:	kanzure: yeah there is a plugin but lazy.
21:56:08	adam3us:	kanzure: dont do that its dangerous seems like a fair comment no?
21:56:08	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?
21:56:25	kanzure:	"everyone deciding not to update a version"?
21:56:31	adam3us:	fluffypony: that doesnt happen because upgrades are soft-forks for this reason
21:56:34	fluffypony:	*update to a version
21:56:43	kanzure:	"everyone deciding not to update to a version"?
21:56:54	kanzure:	we were talking about forks i thought
21:56:58	adam3us:	fluffypony: backwards compatible = soft-forks
21:57:20	fluffypony:	so there will be no hard forks ever in future?
21:57:41	fluffypony:	hearn won't be happy about that :-P
21:57:42	adam3us:	fluffypony: they are much riskier and require a full-on flag day which is hard to enforce in a p2p network.
21:58:11	adam3us:	whats the history - has bitcoin ever had a hard fork?
21:58:36	fluffypony:	yes several
21:59:02	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.
21:59:22	kanzure:	an unplanned fork caused by btcd miners would be pretty bad :/
21:59:26	adam3us:	fluffypony: i would presume all of them have been bug fixes.
21:59:51	kanzure:	"unplanned" could also mean "indistinguishably adversarial" of course...
22:00:44	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
22:01:09	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?
22:01:10	kanzure:	hmm, i'm not sure transactions are relayed between forks forever
22:01:17	kanzure:	*between nodes running on different forks
22:01:23	kanzure:	don't the nodes eventually permaban each other?
22:02:18	fluffypony:	kanzure: afaik old clients will only reject broadcast transactions / blocks that fail validity, not standardness
22:02:29	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.
22:03:27	fluffypony:	adam3us: so maybe I'm being dumb, but I'm not understanding how that scenario is different from a btcd-originated fork?
22:04:10	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
22:04:46	kanzure:	can you elaborate on "confused tx" specifically
22:04:50	michagogo:	00:02:02 kanzure: afaik old clients will only reject broadcast transactions / blocks that fail validity, not standardness
22:05:15	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"
22:05:15	michagogo:	There's no such thing as "standardness" for blocks
22:05:15	fluffypony:	michagogo: I know
22:05:19	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.
22:05:42	fluffypony:	michagogo: but blocks contain transactions - the rules are the same for including a block that contains transactions that fail validity
22:06:09	wiz_:	wiz_ is now known as wiz
22:06:10	michagogo:	Well, yeah
22:06:10	adam3us:	fluffypony: theres a difference between "doesnt blow up when we fuzz test it" and the best someone adversarial can do to confuse it
22:06:13	michagogo:	a block that includes an invalid transaction is, of course, invalid
22:07:19	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
22:07:19	pigeons:	pigeons is now known as Guest61644
22:07:34	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.
22:07:40	fluffypony:	I don't think that their client at the hypothetical 50% stage is more at-risk than Bitcoin Core is right now
22:07:59	adam3us:	fluffypony: you're wrong i'm pretty sure.
22:08:06	kanzure:	it's not their client, it's the people using the client, right?
22:08:26	kanzure:	i mean, it's the number of parallel forks increasing from 1 to >1 that is the real problem
22:09:32	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."
22:10:07	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
22:10:40	OneFixt_:	OneFixt_ is now known as OneFixt
22:11:04	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.
22:12:01	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_.
22:12:36	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.
22:12:41	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?
22:13:31	adam3us:	fluffypony: that assumes miners are on their A-game. a lot of miners are not super sophisticated - plug in electricity - print bitcoins - profit
22:13:46	fluffypony:	adam3us: the majority of miners don't have a say in the matter
22:13:47	kanzure:	fluffypony: a fork like that would be very damaging, it's not about who gets to be god
22:13:49	adam3us:	fluffypony: maybe a charm offensive or a side contract from conformal could fix that real fast.
22:13:54	Guest61644:	Guest61644 is now known as pigeons
22:14:10	adam3us:	fluffypony: they'd only have to convince 2 or 3 people.
22:14:53	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
22:15:10	fluffypony:	I'm not even sure what you're replying to anymore
22:15:21	fluffypony:	IRC is a tough mechanism for this ;)
22:15:35	adam3us:	fluffypony: you said "the majority of miners don't have a say in the matter"
22:15:52	adam3us:	fluffypony: i said sure the miners control what software they are running
22:16:10	fluffypony:	and you said "sure it does", which is either a grammatical faux pas or nonsensical, hence my confusion :)
22:16:33	fluffypony:	miners *don't* control the software that mines the block
22:16:37	fluffypony:	they use mining software
22:16:50	fluffypony:	the mining pool is the thing that dictates it
22:16:53	kanzure:	haha
22:16:56	adam3us:	fluffypony: pedantic much?
22:17:25	fluffypony:	no no, not pedantry - I'm actually acknowledging your earlier point about them having to convince "2 or 3 people"
22:17:29	kanzure:	large miners just operate their own pool, so that difference doesn't matter
22:17:34	adam3us:	fluffypony: anyway i hope you see why its a reasonable question to ask btcd what they're trying to do.
22:17:38	fluffypony:	sure
22:17:42	adam3us:	kanzure: right
22:18:39	fluffypony:	kanzure: nonsense, the "unknown" block is only 19% at the moment
22:18:39	adam3us:	fluffypony: ok (I'm actually acknowledging your earlier point about them having to convince "2 or 3 people")
22:18:44	kanzure:	fluffypony: huh?
22:18:59	fluffypony:	80% of miners mine at known pools, kanzure
22:19:02	fluffypony:	https://blockchain.info/pools
22:19:06	kanzure:	why would it matter if you already know the pool? wtf
22:19:21	adam3us:	fluffypony: s/miners/pools/ same story
22:19:29	kanzure:	there's a principle agent problem with mining software
22:19:43	kanzure:	... possibly not the right classification, but it's there heh
22:20:22	adam3us:	kanzure: yeah Luke-Jr is working on fixing that.
22:20:29	kanzure:	it's the mining software that is mining, not the miners that are paying the bills, etc.
22:20:35	kanzure:	"do what i say not what i mean" or something
22:20:59	kanzure:	* kanzure pages larry wall for clarification
22:21:01	adam3us:	kanzure: meaning separating voting from hashrate, so you can pool while chosing your own blocks.
22:21:16	kanzure:	oh, i am probably talking about something different
22:21:30	kanzure:	a miner (person) can have whatever intentions, but still install software that does something contrary to whatever delusions
22:23:24	kanzure:	oh, you're talking about principle agent problems with pools, that sounds neat
22:27:03	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
22:27:32	kanzure:	i don't know why i picked double
22:27:58	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
22:30:56	adam3us:	kanzure: btcd could help work on libconsensus if they want to be useful. or use bitcoin consensus code.
22:31:54	kanzure:	is libconsensus different from libbitcoinconsensus
22:32:19	adam3us:	kanzure: i mean *that* what ever its called.
22:32:33	kanzure:	right, okay. just keeping track and all.
22:44:52	phantomcircuit:	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
22:45:03	phantomcircuit:	iirc they have been actively attempting to get people to use btcd
22:46:03	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.
22:46:54	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 :)
22:49:35	phantomcircuit:	heh
22:51:27	luny`:	luny` is now known as luny
23:07:30	wiz_:	wiz_ is now known as wiz
23:14:32	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.
23:16:51	michagogo:	op_mul: pretty sure the former has forked off several times
23:17:04	op_mul:	oh heaps of times
23:45:04	agorist0000:	Has anyone ever tried the second two party multisig escrow method described in this blogpost? http://opine.me/future-of-bitcoin-escrow/
23:46:14	agorist0000:	I'm considering using it to construct a new marketplace project in the near future.
23:46:16	belcher:	agorist0000 i havent used it for a real economic transaction, but its been pretty well known for more than a year
23:46:37	belcher:	you can use this to do it http://coinb.in/multisig/
23:47:11	belcher:	www.bitrated.com is another project with it
23:47:43	agorist0000:	Would there be demand for such a market? Similar to Bitmarkets, but using this different escrow method.
23:50:30	belcher:	you might want to look up the openbazaar project
23:51:38	agorist0000:	Does open bazaar offer this type of 2party escrow?
23:52:16	belcher:	yes
23:52:48	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
23:52:54	agorist0000:	Can you point me to any sources for this claim?
23:53:12	belcher:	/join #openbazaar
23:53:36	op_mul:	belcher: what. burning money gives you a reputation?
23:53:50	belcher:	i think thats how it works
23:54:05	belcher:	idea is it costs money for the merchant to constantly make new identities
23:54:10	gwillen:	I assume there's also a way to rate merchants
23:54:15	belcher:	oh yes
23:54:16	gwillen:	that's necesasry for that kind of scheme to function
23:54:24	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.
23:54:36	belcher:	you can start a merchant account without burning anything, give you real life identity perhaps to get reputation
23:54:40	belcher:	or do small deals first to build rep
23:55:06	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
23:55:13	gwillen:	op_mul: if you do a 10 BTC deal, of course that doesn't protect you
23:55:35	gwillen:	(of course, people aren't smart, but.)
23:55:57	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.
23:56:17	gwillen:	that could well be true
23:56:37	gwillen:	I think more likely who it favors is large but honest businesses, over small but honest ones
23:56:49	gwillen:	since the former can put up much larger burns (or bonds, in a bond system) than the latter