00:54:14ThinThread:can i make a relay program that listens to public channel like twitter hashtag for covert control messages that adversary who siezes machine relay program running cannot determine controller?
00:55:25ThinThread:i was thinking i could multiply each tweet by cipher text with homomorphic encryption
00:55:57ThinThread:dont really see how to impelement the desired functionality as matrix multiplies but maybe is possible
01:44:19c0rw1n:c0rw1n is now known as c0rw|zZz
02:13:31gmaxwell:ThinThread: you want a wet paper code.
02:13:59gmaxwell:though temporal sequencing, if visible to the attacker can break the privacy.
02:15:15gmaxwell:but if you assume that the attacker can't tell what order messages were authored in, then you can make it so that it's undecidable which message conveyed the secret message, even if there is only a small amount of malleability.
03:21:54amiller:here's my advisor elaine giving a talk at the same thing, on work i helped a lot with https://www.youtube.com/watch?v=FQ6Hii69b5U
03:21:59amiller:Cryptocurrencies and Smart Contracts
03:22:57amiller:nsh, ^
03:24:29yoleaux:Cryptocurrencies and Smart Contracts - YouTube
06:33:58andytoshi:waxwing: baller! :)
08:05:14sinisalo.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
08:05:14sinisalo.freenode.net:Users on #bitcoin-wizards: andy-logbot damethos Mably dEBRUYNE luny devrandom _biO_ gill3s hktud0 antanst priidu kgk Xh1pher www justanotheruser p15 someguy alephbet RoboTeddy [7] go1111111 goregrind AlexStraunoff Dr-G ThinThread darwin_ jouke PRab d1ggy_ adam3us1 SDCDev Tebbo` jmcn_ melvster dc17523be3 sparetire_ cluckj Emcy SubCreative jgarzik badmofo kyuupichan Giszmo Madars fanquake helo MrTratta Tiraspol Logicwax sl01 jrayhawk grandmaster OneFixt shesek Adlai
08:05:14sinisalo.freenode.net:Users on #bitcoin-wizards: mengine tromp_ alferz dgenr8 spinza hashtag_ c0rw|zZz tucenaber sneak gielbier sadoshi andytoshi hulkhogan_ MoALTz maaku jcorgan _whitelogger sparetire Starduster bosma sundance heath bsm117532 CodeShark copumpkin K1773R ttttemp cryptowest_ @gmaxwell gwillen waxwing lclc koshii STRML catlasshrugged akstunt600 kanzure midnightmagic @Luke-Jr Iriez LeMiner fenn bliljerk101 gnusha bedeho wizkid057 akrmn mariorz mikolalysenko Meeh Krellan ajweiss
08:05:14sinisalo.freenode.net:Users on #bitcoin-wizards: Cory so cornusammonis s1w elastoma poggy PaulCapestany lnovy HM dansmith_btc tromp catcow btcdrak Xzibit17 prosodyContext vonzipper adams__ michagogo dasource yrashk CryptoGoon mappum artifexd Muis runeks kumavis platinuum jbenet phantomcircuit yorick mm_1 amiller fluffypony livegnik mountaingoat a5m0 Apocalyptic triazo wiz wumpus EasyAt Alanius iddo forrestv theymos Taek null_radix smooth lmatteis narwh4l thrasher` otoburb Keefe weex pigeons
08:05:14sinisalo.freenode.net:Users on #bitcoin-wizards: sturles nephyrin [d__d] rasengan berndj harrow qawap superobserver stonecoldpat davout jessepollak huseby espes veox yoleaux comboy stevenroose kinlo gavinandresen nickler cdecker ggreer isis harrigan scoria brand0 larraboj nsh jonasschnelli leakypat epscy cfields coryfields azariah warptangent TD-Linux crescend1 Zouppen binaryatrocity BananaLotus optimator Eliel mr_burdell throughnothing_ Fistful_of_Coins Jaamg xabbix dignork petertodd
08:05:14sinisalo.freenode.net:Users on #bitcoin-wizards: richardus afdudley SwedFTP guruvan nanotube warren sdaftuar eric roasbeef morcos merlincorey [ace] jaromil Graet indolering ryan-c gribble d9b4bef9 starsoccer BlueMatt Anduck AdrianG BrainOverfl0w @ChanServ
08:07:43antanst:antanst has left #bitcoin-wizards
09:32:04justanotheruser:justanotheruser is now known as justanotherusr
10:18:08cadenadelabloque:I've been doing some reading up on zero knowledge contingent payments, computational complexity theory, PSPACE(interactive proof systems), secure multiparty computations, and bitcoin contracts in general and I'm in need of some help from someone with working knowledge of them.
10:18:25cadenadelabloque:From what I can tell, gmaxwell (who proposed CoinSwap) is likely to not only understand these concepts but have actually written code for them, but I can't seem to find any examples or samples online anywhere from him or anyone else, only theories and discussions.
10:20:45cadenadelabloque:I've got a job offer for anyone who has experience in these areas and can write some "simple" code to allow a trustless agreement to pay based on user supplied data or random input.
10:21:50midnightmagic:.. not really topical..
10:22:18cadenadelabloque:Ideally what I want is some code that allows 2 or more parties to perform rock-scissors-paper and force the loser's funds to the winner, cryptographically.
10:22:57cadenadelabloque:According to this whitepaper (http://eprint.iacr.org/2013/784.pdf), it's already been done to a degree, I just don't understand how it was done.
10:24:41cadenadelabloque:I gather it's done using hashes of choices and some OP_CODE that incorporates a multiparty transaction of sorts(?), but to put that into a code that can be generated on the fly is beyon my pay grade.
10:25:22cadenadelabloque:Rather, I'd prefer paying someone whos pay grade it is not beyond so that it doesn't take me 20 years to accomplish it! :)
10:25:46midnightmagic:cadenadelabloque: Consider making job offers in a place like #bitcoin-otc or one of the bitcoin job boards.
10:27:04cadenadelabloque:I was actually referred here because of the specific needs. I'm pretty sure if anyone can do it, it'll be someone here.
10:27:50cadenadelabloque:I was also under the impression #bitcoin-otc was mostly for traders. I'll check it out.
10:36:25nsh:amiller, thanks!
11:40:30antanst:antanst has left #bitcoin-wizards
12:52:45Mably_:Mably_ is now known as Mably
13:38:32JackH:!seen hearn
13:38:32gribble:hearn was last seen in #bitcoin-wizards 22 hours, 36 minutes, and 50 seconds ago: yeah, i'm getting rather tired of it myself.
14:30:06nsh:* nsh is somewhat surprised by how seriously amiller's advisor appears to be taking ethereum
14:36:40ThinThread:ah damn didnt see if anyone answered my question yesterday
14:37:28nsh: ThinThread: you want a wet paper code.
14:37:28nsh: though temporal sequencing, if visible to the attacker can break the privacy.
14:37:28nsh: but if you assume that the attacker can't tell what order messages were authored in, then you can make it so that it's undecidable which message conveyed the secret message, even if there is only a small amount of malleability.
14:37:29fluffypony:nsh: sometimes clever people don't realise they're being duped if there's enough technical hand-waving
14:37:54ThinThread:thanks nsh!
14:38:52nickler:nsh: "They have real cryptographers in their board: Koblitz and Merkle." - Nicolas Courtois
14:40:29nsh:my position is that it's all grist for the mill, and even if it doesn't work out as currently envisioned, there will be useful results
14:40:38nsh:so i don't demean any of it, i just have theoretical reservations
15:53:27nwilcox:nsh: Just my guess, but amiller's advisor's research interests include programming language security, so the PL interface to Ethereum is probably attractive to experiment with.
15:53:45nsh:* nsh nods
16:05:51ThinThread:gmaxwell; nice @ wet paper codes. yeah temporal sequencing is a problem. i was thinking that the trigger when multiplied by ciphertext could put it into a countdown state, where each successive tweets multiplication would only advance countdown towards ciphertext assuming trigger value
16:06:25ThinThread:but dunno how you can actually do that. i dont see any results about how you can make a turing machine with matrix multiplies or anything close
17:35:17bramc:Good morning everybody
17:37:16tromp_:afternoon, Bram
17:38:37zooko:Howdy bramc and tromp_.
17:40:47bramc:Bitcoin seems to be hurtling rapidly towards a completely self-inflicted crisis
17:44:34fluffypony:bramc: this is my favourite recent post on it: http://www.reddit.com/r/Bitcoin/comments/3a58z9/why_the_hell_are_people_against_increasing_block/cs9egkq?context=2
17:45:35fluffypony:it really exemplifies the sort of hivemind, horse-blinker commentary that's spearheading things
17:49:15midnightmagic:What's a horse-blinker?
17:51:24zooko:midnightmagic: https://en.wikipedia.org/wiki/Blinkers_%28horse_tack%29
17:51:47nwilcox_:nwilcox_ is now known as nwilcox
17:52:37midnightmagic:I have never seen them referred to as blinkers. Cool.
17:55:48bramc:Looks like full nodes have about 1800 transactions, or about 3/sec
17:56:30bramc:or rather, would be 3/sec if they represented 10 minutes each
18:05:07tromp_:you mean full blocks:)
18:05:40tromp_:did you read BIP 100, bramc?
18:27:16jtrag:jtrag is now known as jtrag[away]
19:08:25nsh:'blinkered' is pretty common as an adjective in the UK to refer to that sort of narrow-minded headlong rushing confidence
19:08:39nsh:or politics, as it's colloquially termed
19:09:26gmaxwell:It was familar to me too. :)
19:10:13nsh:(aye, didn't mean to suggest exclusively, just can't talk for other anglolands)
19:10:22nsh:(due to not having stayed in any extensively)
19:10:46gmaxwell:cadenadelabloque: The ZKCP protocol was my 'invention' too. It's not actually been put into production yet; though as the page now reflects the science is ready for it.
19:11:12fluffypony:nsh: well South Africa still retains its colony tattoo :-P
19:13:30gmaxwell:cadenadelabloque: I've also seperately described an efficient protocol that is not ZK for fair contracts for certian kinds of games (e.g. determinstic ordered turn games without secret state); but not fully implemented it yet; though I hope to do so somewhat soon.
19:16:53nsh:gmaxwell, neat. one of the videos from simons institute i posted yesterday (and some pdfs by the same folk) was quite similar sounding. secure computing through an ideal refund-with-penalty multisig timeloack predicate and complex n-party protocols composed from 2-party stateless protocols
19:17:43nsh:.title https://www.youtube.com/watch?v=HZlIRr6Xwe8
19:17:44yoleaux:How to use Bitcoin to Enhance Secure Computation - YouTube
19:19:07nsh:(uses SNARKS for some constructions, and something about currently-disabled bitcoin opcodes, or a slightly vague 'miners do it for increased fees' alternative which may be more dubious)
19:20:16nsh:sorry, claim-or-refund is what they call their primitive
19:30:01nsh:this might be interesting: 'Modeling bitcoin contracts by timed automata' -- http://arxiv.org/pdf/1405.1861.pdf
19:31:33nsh:.wik Uppaal Model Checker
19:31:34yoleaux:"UPPAAL is an integrated tool environment for modeling, validation and verification of real-time systems modeled as networks of timed automata, extended with data types (bounded integers, arrays etc.)." — https://en.wikipedia.org/wiki/Uppaal_Model_Checker
19:34:53bramc:What have gavin and mhearn said about bip100?
19:35:22bramc:Aside from this, I mean: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07938.html
19:35:41gmaxwell:nsh: yea, it's a somewhat obvious approach once you think about it, thus my quotes around invented.
19:35:46nsh:* nsh nods
19:36:15kanzure:what if someone writes a patch that rejects blocks iwth the other version number in it
19:36:43kanzure:i guess that's just an early fork
19:36:54kanzure:but it's better than a delayed hard-fork
19:36:55nsh:what if everybody writes their own consensus-breaking fork proposal and we all dance around a bonfire and throw them all in
19:36:58nsh:and then be done with it
19:37:05kanzure:i don't know what bonfires have to do with it
19:37:13nsh:they make things go away
19:37:17nsh:when used appropriately
19:37:18kanzure:writing and deploying a patch to stop a contentious hard-fork would be pretty helpful i think
19:37:42nsh:also there's some sort of reference to fighting fire with fire :)
19:38:03kanzure:well if nobody relays the new version number then there's no last-minute game of chicken regarding a hard-fork
19:38:07kanzure:(during the "grace period")
19:38:49nsh:it's arguably as bad as the threat it intends to mitigate
19:39:48kanzure:could you attempt to make that argument please
19:40:56nsh:because obviously gavin and mike would NACK such a version lock-up update, if they were asked, and to do it anyway is just as much an abandonment of process as the unilateral fork proposal (threat)
19:41:39nsh:retrospective cynicism is sometimes appropriate. speculative cynicism is usually bad
19:41:40bramc:gmaxwell, Has anybody figured out the issues of needing a trusted setup for ZK?
19:41:46kanzure:yes, well you will never see the peanut gallery telling you "we are proceeding with it anyway" (actually they have, oops!)
19:42:17bramc:kanzure, nsh I'm not sure what you're saying
19:42:42kanzure:so in the context of a hostile contentious hard-fork, rolling out something faster to protect the system from multi-chains seems prudent. the companies that they convince will operate the patch that has the grace period, and everyone else will reject their version number blocks in the mean time anyway.
19:42:52nsh:kanzure is suggesting that an update is released that preempts and prevents a nonconsensus hard-fork attempt
19:42:52gmaxwell:bramc: for SNAKRS? there are other candidate constructions outside of the CRS model, though they'll be less efficient (larger proofs, like tens of kb). And AFAIK haven't yet been build but people are working on it.
19:43:21kanzure:nsh: right, something that breaks down the scheduling of the hard-fork patch's "activation" (it's already activated, of course, the moment it goes in)
19:43:32nsh:which is a very conservative/protectionist move and will be taken as badly as you can imagine anything being taken
19:43:37bramc:There's already something which 'prevents' a nonconsensus hard-fork update. It's called the bitcoin codebase :-P
19:43:40kanzure:however, i am not advocating for this solution, just contemplating or speculating its possibility
19:43:49nsh:and will not help us achieve a consensus process for adding headroom in blocksize
19:43:51kanzure:bramc: can you explain how it does that?
19:44:04nsh:unless consensus-by-virtue-of-alienation counts, which it shouldn't
19:44:08bramc:kanzure, the bitcoin codebase rejects hard forks. That's why they're called hard forks.
19:44:11kanzure:bramc: specifically the context here is someone has said "i have convinced companies to run my patch, i'm doing this anyway, see you later"
19:44:22kanzure:bramc: yes, well not everyone runs that code base
19:44:29bramc:kanzure, Has Gavin said that in so many words?
19:44:37gribble:Error: "!!" is not a valid command.
19:45:16nsh:bramc, the current position seems to be that they will make BIP proposal, with working code, and give some time for it to be evaluated, but reserve the right afterwads to go ahead unilaterally
19:45:33nsh:there was an attempt to soften this position yesterday but it didn't seem to get anywhere
19:45:47kanzure:bramc: http://sourceforge.net/p/bitcoin/mailman/message/34155307/
19:46:10bramc:We need to start explaining to journalists what a clusterfuck a hard fork is. There *will* be two chains, they *will* both survive, and both wallets and exchanges *will* need to start treating them as sort of two separate currencies.
19:46:44nsh:can we hardfork dogecoin for didactic purposes?
19:46:52nsh:people would probably get upset
19:47:25kanzure:there have been some other hard-forks in the past, like elielcoin or something? that's a recent one.
19:47:44bramc:It's funny the conspiracy theories which don't exist. We don't believe that openssl was created to sneak security problems into things. We don't believe that Applied Cryptography was written to get people to design insecure protocols. And we don't believe that Gavin is trying to tank bitcoin
19:47:59kanzure:er there's also the other g man
19:48:18kanzure:wait, that's ambiguous
19:48:24bramc:Although there's so much obvious evidence for all these things. They only require one conspirator, and if that conspirator was really conspirating they sure did a shitty job of covering their tracks.
19:48:36kanzure:(it's not just gavin; and the other one doesn't have a g in his name, so that doesn't work. oops.)
19:49:03gmaxwell:The prior on "dumb shit happens" is so amazingly high that its hard to give any other theory credibility.
19:49:23kanzure:yeah, i think that "oops" is still a reasonable explanation, although not the only possible explanation
19:50:43bramc:Can anyone think of a case of a bdfl getting kicked out?
19:50:55kanzure:nsh: so your argument is that we should relay blocks that are communicating support for a hard-fork that has a high likelihood of fragmenting the network. why?
19:51:03kanzure:bramc: we don't have a bdfl
19:51:22bramc:kanzure, The media portrays gavin as the bdfl
19:51:29kanzure:the media also portrays bitcoin as anonymous
19:51:45bramc:I didn't say they're right.
19:53:08bramc:If there is a fork between big-bitcoin and little-bitcoin, is there a way of crafting transactions so they'll get accepted by one but not the other?
19:53:24maaku:bramc: we never had a bdfl
19:54:00maaku:bramc: sure, double spend
19:54:24maaku:bramc: generate a transaction >1MB in size
19:55:18bramc:maaku, the frequency with which double spend works depends on whether the two networks manage to separate completely or there's a transactions bridge between them
19:55:35maaku:bramc: a >1MB transaction won't bridge
19:55:49gmaxwell:bramc: you can also derrive your transaction out of coinbase outputs made post-fork.
19:56:06bramc:maaku, Let's assume that a >1mb transaction is unacceptable generally
19:56:13kanzure:crafting transactions out of two blockchains only solves parts of the problem; ther'es also ledger reconciliation issues to be aware of, incompatible software, fragmentation of the business ecosystem, etc.
19:56:35bramc:gmaxwell, There's a chance that transactions will usually be applied to both, even if they don't mean to.
19:57:06bramc:kanzure, the inevitable result of a hard fork is two separate cryptocurrencies both called bitcoin
19:57:29ajweiss:no bdfl, more like a central committee of cryptophile programmers who shepherd and lead the cryptoproleteriat in building the one true ledger state
19:57:41kanzure:ajweiss: that's a misrepresentation of what's going on
19:57:46ajweiss:it's a joke.
19:57:58kanzure:don't those have to be funny
19:57:59bramc:Is there anything in mhearn's patch besides changing a constant?
19:58:16kanzure:bramc: there's a "grace period" after blocks with the version number show up
19:58:35kanzure:bramc: http://www.reddit.com/r/Bitcoin/comments/39ziy6/eli5_what_will_happen_if_there_is_a_hard_fork/cs7xxhe?context=1
19:58:59nwilcox:bramc: If there is a hard fork, and no way for users to differentiate the units on different forks, seems bad for users.
19:59:09kanzure:there's a long list of problems that arise
19:59:19nwilcox:-but that's just one of many problems.
20:00:40nsh:bramc, mike isn't making a patch, as i understand it, gavin is, and presumably it's more complex than that as he's still in testing phase
20:00:48nsh:and intends to draft a BIP
20:00:50kanzure:(see the link)
20:00:55morcos:one of the issues i've been wondering about is what will the legal implications be for companies holding bitcoin balances for users, they will probably have to support both forks
20:01:14nsh:morcos, feel free to wonder about that in depth, in a public blog post
20:01:33zooko:nwilcox: this is the genesis of Ian Grigg's notion of the Ricardian Contract, I think.
20:02:11fluffypony:nsh: on medium
20:02:14nsh:* nsh smiles
20:02:29zooko:nwilcox: Sorry if I was dismissive earlier, but actually now that I'm less grumpy, your idea of using the earliest unique block id as the fork id is excellent!
20:02:29fluffypony:because that's the best forum for it
20:04:19bramc:Forks are a Bad Thing
20:04:39ThinThread:can i spent my bitcoin twice on each branch of fork?
20:04:48kanzure:not always
20:04:59morcos:and once on each branch might be easier
20:05:02nsh:not even once on each branch, except in some circumstances :)
20:05:32ThinThread:so are bitcoin forks basically like stock splits
20:05:39maaku:what? no
20:05:48maaku:they are nothing like stock splits
20:05:59bramc:Gavin is really sounding out of control. His approach to dealing with the rancor against his proposed hard fork is to make the limit go up exponentially in perpetuity? Yeah, great way to get people on your side.
20:06:14gwillen:ThinThread: there's not a clean separateion of the two sides. Some transactions will go through on one side only, some will go through on both.
20:06:35ThinThread:ah i see
20:06:38gwillen:ThinThread: initially coins will be "in sync" on both sides, but as transactions fail to clear on both sides (e.g. because you mix in some coins generated after the form), they will fall "out of sync"
20:06:49bramc:ThinThread, Yes each coin basically splits in two, but it isn't clear how easy it might be to actually get your coins to separate, hence my earlier question about getting accepted on either side
20:07:00gwillen:so you'll have a mixture of coins on one side, the other, or both, depending on where they came from
20:07:03gmaxwell:zooko: there is an old proposal of mine that transactions should be able to 'checkpoint' what chains their fees are payable in.
20:07:05nwilcox:ThinThread: Imagine every user and exchange and miner was clear which fork a txn "belonged" to. Then you could treat the two forks as two currencies.
20:07:20kanzure:gmaxwell: yes that would help, although of course a fork could ignore those rules, heh
20:07:25nwilcox:They'll probably be currencies which are in catastrophic economic collapse, though...
20:07:28gmaxwell:zooko: which was intended to address the problem that your transaction pays the honest network and a forking attacker equally. (assuming it can be mined in both)
20:07:40kanzure:it is wrong to think about two currencies really; there's no way that will be a stable result of this
20:07:53bramc:oh, here's a thought: Once the two chains get slightly out of sync on time, you can use timelock and malleability
20:07:55gmaxwell:kanzure: yes, it wasn't a tool intended against hardforks, just against reorg attacks.
20:07:55kanzure:i mean yes that will technically exist for a few minutes or hours or something
20:08:02zooko:gmaxwell: neat!
20:08:06gwillen:in principle, if all the software were designed to treat coins carefully with regard to which chain recognizes them, you could have two currencies
20:08:15gwillen:in practice it's not and you will have a big fucking mess
20:08:17nwilcox:ThinThread: However, without code changes: people won't be clear on forks and (some) txns can be replayed between forks.
20:08:23zooko:gmaxwell: will add that to my big book of maybes.
20:08:32kanzure:zooko: it's mentioned on the wiki
20:08:37bramc:gwillen, inevitably it would get there eventually, but yeah big fucking mess for a long time
20:08:59gwillen:bramc: I expect one or both of them would die before then
20:09:13nwilcox:kanzure: Yes, I agree that the two currenies ideas is very unlikely.
20:09:22kanzure:and also there might be more than two blockchain forks during this time
20:09:28kanzure:because perhaps the network is not well-connected
20:09:31gwillen:also, one of the sides would presuambly be limping along with negligible hashpower
20:09:38gwillen:which would make it extremely prone to attacks
20:09:49kanzure:e.g. the topology of the network after the hard-fork could be such that different forks start happening for hours in different segments of the network
20:09:52bramc:gwillen, It's extremely difficult for either of them to completely die once they have any momentum, and people will hang onto whatever coins they have as long as they're worth *something*
20:10:01kanzure:e.g. especially if nodes start dropping connections due to non-rule-following
20:10:11bramc:gwillen, The hashpower of each side will be directly proportional to their rewards
20:10:33bramc:Also notably, there's no proposal to allow merge-mining. Gavin seemed confused when I suggested it.
20:10:42gwillen:bramc: rewards as denominated in external currency, though. So whichever side has more valuable coins will get more hashpower, but probably whichever side has more hashpower will get more valuable coins
20:10:53bramc:kanzure, There's likely to be two separate networks due to dropping for non-rule-following
20:11:00kanzure:or more than 2
20:11:23bramc:gwillen, Its not like one side wins over the other. They each get hashpower proportional to their value.
20:11:54kanzure:why would it be proportional to anything? why not "proportional to the hashrate that was pointed at that chain and rule set"?
20:12:32gwillen:kanzure: if both sides' generated coins are trading at independent values, people will mine them proportional to the values they trade at
20:12:38gwillen:for optimum reward
20:12:42bramc:kanzure, for any altcoin its hashpower will wind up being about proportional to its rewards, because that's the point at which ROI of doing more goes negative
20:13:10gwillen:I expect we will not end up with both sides trading at stable independent values though
20:13:18bramc:It seems likely, of course, that the value of both forks would tank rapidly.
20:13:29ajweiss:depends on what the exchanges do
20:13:55ThinThread:are bitcoin forks the only way to see what the consensus really is? ie whose fork has most miners
20:14:13kanzure:"most miners" is not the way to decide anything
20:14:26kanzure:the absolute number of miners is non-detectable in this system anyway
20:14:34ThinThread:well theres no good way to decide anything
20:14:36jposner:"most difficulty"
20:14:39ThinThread:the supreme court is crap
20:17:01bramc:ThinThread, For multiple forks on the same chain, which happen all the time, the rule is that greater work total wins. For hard forks, they're different chains, and there's no way any of them can kill off the other
20:17:28kanzure:nsh: so your argument is that we should relay blocks that are communicating support for a hard-fork that has a high likelihood of fragmenting the network. why?
20:17:35kanzure:nsh: you might be right, but i would need your elaboration
20:18:45jposner:bramc, but even with a hard fork, there will only be 1 chain with the most work
20:19:08kanzure:jposner: it's most work plus validity
20:19:09bramc:jposner, That won't result in the other dieing though
20:19:20kanzure:one of them will not be valid according to various rules
20:19:24fluffypony:jposner: for valid blocks yes, but that's also "eventually"
20:19:33jposner:bramc, no it won't kill the others, just as bitcoin hasn't killed alts
20:19:35fluffypony:which could take hours or days or weeks to resolve if the split is quite fine
20:20:14gwillen:13:14:34 < ThinThread> well theres no good way to decide anything
20:20:27gwillen:ThinThread: you have identified the fundamental problem inherent in organizing humans together for a common task ;-)
20:20:32bramc:There's something about the miners in china having met and 'decided' on 8mb, presumably as a 'compromise', does anybody have a source for this?
20:20:50zooko:gmaxwell, kanzure: could you give me a link to the documentation of the idea of transactions being required to include the hash of a recent block?
20:20:51fluffypony:bramc: here: http://i.imgur.com/JUnQcue.jpg
20:20:56kanzure:bramc: started with a few emails on bitcoin-development; then there was some statement posted to reddit; then there was some news article.
20:21:05gwillen:ThinThread: the choices are "democracy", "dictatorship", and "shrug, let's see what happens", and we're currently working our way through the third one
20:21:16bramc:fluffypony, Is there a transation? I don't speak or read chinese
20:21:31ajweiss:woah cool chinese stamps!
20:21:45jposner:one cpu, one vote
20:21:56kanzure:gwillen: that's not right; there are far more options than that. and it's wrong to describe this as "let's see what happens"... bitcoin.pdf basically describes this as "the only way to know is to see all the transactions and run the rules". spv is mentioned, sure, but that's different.
20:22:02fluffypony:jposner: what do you do about virtual CPUs, then?
20:22:03kanzure:jposner: it's nothing about cpus or votes
20:22:08rusty:rusty has left #bitcoin-wizards
20:22:16gwillen:kanzure: sorry, I'm being a little bit glib
20:22:32fluffypony:bramc: https://imgur.com/a/LlDRr
20:22:37kanzure:bramc: there is a translation on reddit
20:22:58gwillen:kanzure: and I'm not really talking about how bitcoin itself decides things, but rather about how we as a community make meta-decisions about bitcoin
20:23:18kanzure:"high orphan rate leading to hard forks down the road".. oh i guess they mean if they hard-fork it to a lower max size. well, whatever. that's true.
20:23:23kanzure:but reorgs are not hard forks
20:23:36gwillen:kanzure: historically the answer seems to have been 'consensus', but now we're having to answer questions like "what is consensus" and "consensus of who"
20:24:00kanzure:gwillen: that's still the wrong representation of this; the way that bitcoin works is that everyone is personally responsible for validating the rules. it's not a consensus. it's a matter of correctness.
20:24:22jposner:fluffypony, it's just a way of describing proof-of-work from the white paper
20:24:34kanzure:jposner: it's a poor (and wrong) description
20:24:56jposner:glad you guys are smarter than satoshi
20:25:02bramc:It's fair at this point to say that Gavin's gone rogue. He's preemptively going to vendors and presenting himself as the voice of sanity and reasonableness when he's in a tiny minority of those who are technically informed.
20:26:39bramc:jposner, I don't know what you're trying to say, but knock it off with the attitude
20:26:59kanzure:jposner: that's an argument from authority, and that sort of breaks bitcoin (if you wanted authority, go use a centralized design)
20:27:10ThinThread:TIL gavin is gmaxwell
20:27:24ThinThread:im building dossiers
20:27:27fluffypony:jposner: if you asked me to design a massively distributed system 5 years ago I would say things and conclude things that *would* be wrong in the face of data and hindsight
20:27:57bramc:ThinThread, Yeah it's ironic because Gavin is supposed to be the diplomatic one who gets everybody to play nice and he's doing the exact opposite.
20:28:21jposner:I simply think it takes some hubris to call Satoshi's description of proof-of-work
20:28:22gmaxwell:zooko: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas third top-level bullet.
20:28:24jposner:poor and wrong
20:28:30fluffypony:to believe that Satoshi Nakamoto was somehow perfectly able to foresee every eventuality, every possibility, every change, is naïve at best
20:28:48kanzure:and is disproven by the existence of soft-forks
20:28:49ThinThread:did Gavin short bitcoin on bitfinex or something?
20:28:57ThinThread:im trying to figure out how to trade this
20:29:11zooko:gmaxwell: thanks.
20:29:28fluffypony:jposner: you're misquoting him, you're making the same mistake the CryptoNote authors made
20:29:39fluffypony:he does say "Proof-of-work is essentially one-CPU-one-vote"
20:29:47fluffypony:but the following sentence explains
20:29:53gmaxwell:jposner: If you'd like to talk about hubris, I suggest that you start with thinking you can fradulently claim that someone supported something they didn't support, in a discussion they are not a part of (as far as you know).
20:29:56fluffypony:"The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it."
20:30:07ThinThread:its hard to rollout technology improvements without interrupting outstanding demands of customers
20:30:21kanzure:what is wrong with hubris, again? especially in a no-authority system design?
20:30:27fluffypony:clearly that represents "majority processing power", not literally "one-CPU-one-vote"
20:30:55kanzure:fluffypony: and even that is unclear and ambiguous; he naturally means "the longest valid chain, which has the"
20:31:10gmaxwell:jposner: while it's impossible to say for sure what someone who hasn't entered into the discussion would say; I can easily point to where I've made the same arguments and clarify what I meant. But thats all I can do, I don't speak for anyone but myself.
20:31:14ThinThread:any link to manifestos for both sides of the issue?
20:31:31fluffypony:manifestos? on what, a blog post?
20:31:33ThinThread:better yet summarized in few sentences
20:31:35kanzure:the issue of contentious hard-forks?
20:32:39ThinThread:hm yeah.
20:32:46ThinThread:i guess the blocksize dispute is secondary to that
20:33:15ThinThread:so most people are like hey dont fork stay in this together, and someone else is like no we really need this improvement were forking
20:33:44ThinThread:i guess this day was inevitable, birds leaving nest etc
20:33:58gmaxwell:gmaxwell has left #bitcoin-wizards
20:35:18jposner:gmaxwell, I'm not trying to claim what Satoshi would say, I was simply trying to reference his statement from the white paper that "Proof-of-work is essentially one-CPU-one-vote."
20:35:21bramc:ThinThread, No there's nothing inevitable about what's going on now, it's completely self-inflicted and ridiculous, with the overwhelming majority of people in the know being adamantly against it.
20:35:54jposner:gmaxwell, there are admittedly many ways to interpret that statement
20:36:06ThinThread:go i wish satoshi would release a signed message of guidance
20:36:08kanzure:yes the first way to interpret it is by reading the next sentence
20:36:31zooko:zooko has left #bitcoin-wizards
20:40:43kanzure:bramc: the link for the signed statement was http://www.reddit.com/r/Bitcoin/comments/3a5qj5/draft_signed_by_f2pool_antpool_bw_btcchina_huobi/
20:40:47kanzure:or the other link, i mean
20:41:53kanzure:"Does anyone worry that this shows mining pool collusion is entirely realistic?"
20:58:01tdryja:tdryja has left #bitcoin-wizards
21:09:25rusty:rusty has left #bitcoin-wizards
22:02:54tdryja:tdryja has left #bitcoin-wizards
22:12:01maaku:kanzure: what's seemingly entirely lost is that the mining pools in China want smaller blocks to protect non-Chinese miners
22:12:47nsh:they should be disqualified for not acting as rational actors :)
22:15:46phantomcircuit:nsh, it's meta rational to project their capital investment
22:16:05phantomcircuit:damn now im making the same bizarre arguments as the others
22:16:11nsh:* nsh smiles
22:16:21phantomcircuit:(note you cant rely on this behavior as it's unstable)
22:16:34nsh:* nsh nods
22:23:37jae:jae is now known as Guest99295
22:27:32Guest99295:Guest99295 is now known as jaekwon
22:48:10c0rw|zZz:c0rw|zZz is now known as c0rw1n