| 00:54:14 | ThinThread: | 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:25 | ThinThread: | i was thinking i could multiply each tweet by cipher text with homomorphic encryption |
| 00:55:57 | ThinThread: | dont really see how to impelement the desired functionality as matrix multiplies but maybe is possible |
| 01:44:19 | c0rw1n: | c0rw1n is now known as c0rw|zZz |
| 02:13:31 | gmaxwell: | ThinThread: you want a wet paper code. |
| 02:13:59 | gmaxwell: | though temporal sequencing, if visible to the attacker can break the privacy. |
| 02:15:15 | gmaxwell: | 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:54 | amiller: | 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:59 | amiller: | Cryptocurrencies and Smart Contracts |
| 03:22:57 | amiller: | nsh, ^ |
| 03:24:29 | kanzure: | .title |
| 03:24:29 | yoleaux: | Cryptocurrencies and Smart Contracts - YouTube |
| 03:24:32 | kanzure: | oh. |
| 06:33:58 | andytoshi: | waxwing: baller! :) |
| 08:05:14 | sinisalo.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:14 | sinisalo.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:14 | sinisalo.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:14 | sinisalo.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:14 | sinisalo.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:14 | sinisalo.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:43 | antanst: | antanst has left #bitcoin-wizards |
| 09:32:04 | justanotheruser: | justanotheruser is now known as justanotherusr |
| 10:18:08 | cadenadelabloque: | 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:25 | cadenadelabloque: | 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:45 | cadenadelabloque: | 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:50 | midnightmagic: | .. not really topical.. |
| 10:22:18 | cadenadelabloque: | 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:57 | cadenadelabloque: | 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:41 | cadenadelabloque: | 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:22 | cadenadelabloque: | 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:46 | midnightmagic: | cadenadelabloque: Consider making job offers in a place like #bitcoin-otc or one of the bitcoin job boards. |
| 10:27:04 | cadenadelabloque: | 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:50 | cadenadelabloque: | I was also under the impression #bitcoin-otc was mostly for traders. I'll check it out. |
| 10:36:25 | nsh: | amiller, thanks! |
| 11:40:30 | antanst: | antanst has left #bitcoin-wizards |
| 12:52:45 | Mably_: | Mably_ is now known as Mably |
| 13:38:32 | JackH: | !seen hearn |
| 13:38:32 | gribble: | 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:06 | nsh: | * nsh is somewhat surprised by how seriously amiller's advisor appears to be taking ethereum |
| 14:36:40 | ThinThread: | ah damn didnt see if anyone answered my question yesterday |
| 14:37:28 | nsh: | ThinThread: you want a wet paper code. |
| 14:37:28 | nsh: | though temporal sequencing, if visible to the attacker can break the privacy. |
| 14:37:28 | nsh: | 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:29 | fluffypony: | nsh: sometimes clever people don't realise they're being duped if there's enough technical hand-waving |
| 14:37:46 | nsh: | mebbes |
| 14:37:54 | ThinThread: | thanks nsh! |
| 14:37:56 | nsh: | np |
| 14:38:52 | nickler: | nsh: "They have real cryptographers in their board: Koblitz and Merkle." - Nicolas Courtois |
| 14:40:29 | nsh: | 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:38 | nsh: | so i don't demean any of it, i just have theoretical reservations |
| 15:53:27 | nwilcox: | 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:45 | nsh: | * nsh nods |
| 16:05:51 | ThinThread: | 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:25 | ThinThread: | 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 |
| 16:25:50 | ThinThread: | http://www.cs.columbia.edu/2015/chasing-real-security/ |
| 17:35:17 | bramc: | Good morning everybody |
| 17:37:16 | tromp_: | afternoon, Bram |
| 17:38:37 | zooko: | Howdy bramc and tromp_. |
| 17:40:47 | bramc: | Bitcoin seems to be hurtling rapidly towards a completely self-inflicted crisis |
| 17:44:34 | fluffypony: | 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:35 | fluffypony: | it really exemplifies the sort of hivemind, horse-blinker commentary that's spearheading things |
| 17:49:15 | midnightmagic: | What's a horse-blinker? |
| 17:51:24 | zooko: | midnightmagic: https://en.wikipedia.org/wiki/Blinkers_%28horse_tack%29 |
| 17:51:47 | nwilcox_: | nwilcox_ is now known as nwilcox |
| 17:52:37 | midnightmagic: | I have never seen them referred to as blinkers. Cool. |
| 17:55:48 | bramc: | Looks like full nodes have about 1800 transactions, or about 3/sec |
| 17:56:30 | bramc: | or rather, would be 3/sec if they represented 10 minutes each |
| 18:05:07 | tromp_: | you mean full blocks:) |
| 18:05:40 | tromp_: | did you read BIP 100, bramc? |
| 18:27:16 | jtrag: | jtrag is now known as jtrag[away] |
| 19:08:25 | nsh: | 'blinkered' is pretty common as an adjective in the UK to refer to that sort of narrow-minded headlong rushing confidence |
| 19:08:39 | nsh: | or politics, as it's colloquially termed |
| 19:09:26 | gmaxwell: | It was familar to me too. :) |
| 19:10:13 | nsh: | (aye, didn't mean to suggest exclusively, just can't talk for other anglolands) |
| 19:10:22 | nsh: | (due to not having stayed in any extensively) |
| 19:10:46 | gmaxwell: | 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:12 | fluffypony: | nsh: well South Africa still retains its colony tattoo :-P |
| 19:13:30 | gmaxwell: | 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:53 | nsh: | 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:43 | nsh: | .title https://www.youtube.com/watch?v=HZlIRr6Xwe8 |
| 19:17:44 | yoleaux: | How to use Bitcoin to Enhance Secure Computation - YouTube |
| 19:19:07 | nsh: | (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:16 | nsh: | sorry, claim-or-refund is what they call their primitive |
| 19:30:01 | nsh: | this might be interesting: 'Modeling bitcoin contracts by timed automata' -- http://arxiv.org/pdf/1405.1861.pdf |
| 19:31:33 | nsh: | .wik Uppaal Model Checker |
| 19:31:34 | yoleaux: | "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:53 | bramc: | What have gavin and mhearn said about bip100? |
| 19:35:22 | bramc: | Aside from this, I mean: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07938.html |
| 19:35:41 | gmaxwell: | nsh: yea, it's a somewhat obvious approach once you think about it, thus my quotes around invented. |
| 19:35:46 | nsh: | * nsh nods |
| 19:36:15 | kanzure: | what if someone writes a patch that rejects blocks iwth the other version number in it |
| 19:36:43 | kanzure: | i guess that's just an early fork |
| 19:36:54 | kanzure: | but it's better than a delayed hard-fork |
| 19:36:55 | nsh: | what if everybody writes their own consensus-breaking fork proposal and we all dance around a bonfire and throw them all in |
| 19:36:58 | nsh: | and then be done with it |
| 19:37:05 | kanzure: | i don't know what bonfires have to do with it |
| 19:37:13 | nsh: | they make things go away |
| 19:37:17 | nsh: | when used appropriately |
| 19:37:18 | kanzure: | writing and deploying a patch to stop a contentious hard-fork would be pretty helpful i think |
| 19:37:42 | nsh: | also there's some sort of reference to fighting fire with fire :) |
| 19:38:03 | kanzure: | well if nobody relays the new version number then there's no last-minute game of chicken regarding a hard-fork |
| 19:38:07 | kanzure: | (during the "grace period") |
| 19:38:49 | nsh: | it's arguably as bad as the threat it intends to mitigate |
| 19:39:48 | kanzure: | could you attempt to make that argument please |
| 19:40:56 | nsh: | 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:39 | nsh: | retrospective cynicism is sometimes appropriate. speculative cynicism is usually bad |
| 19:41:40 | bramc: | gmaxwell, Has anybody figured out the issues of needing a trusted setup for ZK? |
| 19:41:46 | kanzure: | yes, well you will never see the peanut gallery telling you "we are proceeding with it anyway" (actually they have, oops!) |
| 19:42:17 | bramc: | kanzure, nsh I'm not sure what you're saying |
| 19:42:42 | kanzure: | 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:52 | nsh: | kanzure is suggesting that an update is released that preempts and prevents a nonconsensus hard-fork attempt |
| 19:42:52 | gmaxwell: | 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:21 | kanzure: | 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:32 | nsh: | which is a very conservative/protectionist move and will be taken as badly as you can imagine anything being taken |
| 19:43:37 | bramc: | There's already something which 'prevents' a nonconsensus hard-fork update. It's called the bitcoin codebase :-P |
| 19:43:40 | kanzure: | however, i am not advocating for this solution, just contemplating or speculating its possibility |
| 19:43:49 | nsh: | and will not help us achieve a consensus process for adding headroom in blocksize |
| 19:43:51 | kanzure: | bramc: can you explain how it does that? |
| 19:44:04 | nsh: | unless consensus-by-virtue-of-alienation counts, which it shouldn't |
| 19:44:08 | bramc: | kanzure, the bitcoin codebase rejects hard forks. That's why they're called hard forks. |
| 19:44:11 | kanzure: | 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:22 | kanzure: | bramc: yes, well not everyone runs that code base |
| 19:44:29 | bramc: | kanzure, Has Gavin said that in so many words? |
| 19:44:37 | kanzure: | !!! |
| 19:44:37 | gribble: | Error: "!!" is not a valid command. |
| 19:45:16 | nsh: | 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:33 | nsh: | there was an attempt to soften this position yesterday but it didn't seem to get anywhere |
| 19:45:47 | kanzure: | bramc: http://sourceforge.net/p/bitcoin/mailman/message/34155307/ |
| 19:46:10 | bramc: | 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:44 | nsh: | can we hardfork dogecoin for didactic purposes? |
| 19:46:52 | nsh: | people would probably get upset |
| 19:47:25 | kanzure: | there have been some other hard-forks in the past, like elielcoin or something? that's a recent one. |
| 19:47:44 | bramc: | 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:59 | kanzure: | er there's also the other g man |
| 19:48:18 | kanzure: | wait, that's ambiguous |
| 19:48:24 | bramc: | 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:36 | kanzure: | (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:03 | gmaxwell: | The prior on "dumb shit happens" is so amazingly high that its hard to give any other theory credibility. |
| 19:49:23 | kanzure: | yeah, i think that "oops" is still a reasonable explanation, although not the only possible explanation |
| 19:50:43 | bramc: | Can anyone think of a case of a bdfl getting kicked out? |
| 19:50:55 | kanzure: | 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:03 | kanzure: | bramc: we don't have a bdfl |
| 19:51:22 | bramc: | kanzure, The media portrays gavin as the bdfl |
| 19:51:29 | kanzure: | the media also portrays bitcoin as anonymous |
| 19:51:45 | bramc: | I didn't say they're right. |
| 19:53:08 | bramc: | 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:24 | maaku: | bramc: we never had a bdfl |
| 19:54:00 | maaku: | bramc: sure, double spend |
| 19:54:24 | maaku: | bramc: generate a transaction >1MB in size |
| 19:55:18 | bramc: | 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:35 | maaku: | bramc: a >1MB transaction won't bridge |
| 19:55:49 | gmaxwell: | bramc: you can also derrive your transaction out of coinbase outputs made post-fork. |
| 19:56:06 | bramc: | maaku, Let's assume that a >1mb transaction is unacceptable generally |
| 19:56:13 | kanzure: | 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:35 | bramc: | gmaxwell, There's a chance that transactions will usually be applied to both, even if they don't mean to. |
| 19:57:06 | bramc: | kanzure, the inevitable result of a hard fork is two separate cryptocurrencies both called bitcoin |
| 19:57:29 | ajweiss: | 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:41 | kanzure: | ajweiss: that's a misrepresentation of what's going on |
| 19:57:46 | ajweiss: | it's a joke. |
| 19:57:58 | kanzure: | don't those have to be funny |
| 19:57:59 | bramc: | Is there anything in mhearn's patch besides changing a constant? |
| 19:58:16 | kanzure: | bramc: there's a "grace period" after blocks with the version number show up |
| 19:58:35 | kanzure: | bramc: http://www.reddit.com/r/Bitcoin/comments/39ziy6/eli5_what_will_happen_if_there_is_a_hard_fork/cs7xxhe?context=1 |
| 19:58:59 | nwilcox: | 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:09 | kanzure: | there's a long list of problems that arise |
| 19:59:19 | nwilcox: | -but that's just one of many problems. |
| 20:00:40 | nsh: | 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:48 | nsh: | and intends to draft a BIP |
| 20:00:50 | kanzure: | (see the link) |
| 20:00:55 | morcos: | 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:14 | nsh: | morcos, feel free to wonder about that in depth, in a public blog post |
| 20:01:14 | nsh: | :) |
| 20:01:33 | zooko: | nwilcox: this is the genesis of Ian Grigg's notion of the Ricardian Contract, I think. |
| 20:02:11 | fluffypony: | nsh: on medium |
| 20:02:14 | nsh: | * nsh smiles |
| 20:02:29 | zooko: | 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:29 | fluffypony: | because that's the best forum for it |
| 20:04:19 | bramc: | Forks are a Bad Thing |
| 20:04:39 | ThinThread: | can i spent my bitcoin twice on each branch of fork? |
| 20:04:48 | kanzure: | not always |
| 20:04:59 | morcos: | and once on each branch might be easier |
| 20:05:02 | nsh: | not even once on each branch, except in some circumstances :) |
| 20:05:32 | ThinThread: | so are bitcoin forks basically like stock splits |
| 20:05:39 | maaku: | what? no |
| 20:05:48 | maaku: | they are nothing like stock splits |
| 20:05:59 | bramc: | 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:14 | gwillen: | 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:35 | ThinThread: | ah i see |
| 20:06:38 | gwillen: | 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:49 | bramc: | 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:00 | gwillen: | so you'll have a mixture of coins on one side, the other, or both, depending on where they came from |
| 20:07:03 | gmaxwell: | zooko: there is an old proposal of mine that transactions should be able to 'checkpoint' what chains their fees are payable in. |
| 20:07:05 | nwilcox: | 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:20 | kanzure: | gmaxwell: yes that would help, although of course a fork could ignore those rules, heh |
| 20:07:25 | nwilcox: | They'll probably be currencies which are in catastrophic economic collapse, though... |
| 20:07:28 | gmaxwell: | 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:40 | kanzure: | it is wrong to think about two currencies really; there's no way that will be a stable result of this |
| 20:07:53 | bramc: | oh, here's a thought: Once the two chains get slightly out of sync on time, you can use timelock and malleability |
| 20:07:55 | gmaxwell: | kanzure: yes, it wasn't a tool intended against hardforks, just against reorg attacks. |
| 20:07:55 | kanzure: | i mean yes that will technically exist for a few minutes or hours or something |
| 20:08:02 | zooko: | gmaxwell: neat! |
| 20:08:06 | gwillen: | 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:15 | gwillen: | in practice it's not and you will have a big fucking mess |
| 20:08:17 | nwilcox: | ThinThread: However, without code changes: people won't be clear on forks and (some) txns can be replayed between forks. |
| 20:08:23 | zooko: | gmaxwell: will add that to my big book of maybes. |
| 20:08:32 | kanzure: | zooko: it's mentioned on the wiki |
| 20:08:37 | bramc: | gwillen, inevitably it would get there eventually, but yeah big fucking mess for a long time |
| 20:08:59 | gwillen: | bramc: I expect one or both of them would die before then |
| 20:09:13 | nwilcox: | kanzure: Yes, I agree that the two currenies ideas is very unlikely. |
| 20:09:22 | kanzure: | and also there might be more than two blockchain forks during this time |
| 20:09:28 | kanzure: | because perhaps the network is not well-connected |
| 20:09:31 | gwillen: | also, one of the sides would presuambly be limping along with negligible hashpower |
| 20:09:38 | gwillen: | which would make it extremely prone to attacks |
| 20:09:49 | kanzure: | 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:52 | bramc: | 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:01 | kanzure: | e.g. especially if nodes start dropping connections due to non-rule-following |
| 20:10:11 | bramc: | gwillen, The hashpower of each side will be directly proportional to their rewards |
| 20:10:33 | bramc: | Also notably, there's no proposal to allow merge-mining. Gavin seemed confused when I suggested it. |
| 20:10:42 | gwillen: | 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:53 | bramc: | kanzure, There's likely to be two separate networks due to dropping for non-rule-following |
| 20:11:00 | kanzure: | or more than 2 |
| 20:11:23 | bramc: | gwillen, Its not like one side wins over the other. They each get hashpower proportional to their value. |
| 20:11:54 | kanzure: | why would it be proportional to anything? why not "proportional to the hashrate that was pointed at that chain and rule set"? |
| 20:12:32 | gwillen: | kanzure: if both sides' generated coins are trading at independent values, people will mine them proportional to the values they trade at |
| 20:12:38 | gwillen: | for optimum reward |
| 20:12:42 | bramc: | 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:10 | gwillen: | I expect we will not end up with both sides trading at stable independent values though |
| 20:13:18 | bramc: | It seems likely, of course, that the value of both forks would tank rapidly. |
| 20:13:22 | gwillen: | yeah |
| 20:13:29 | ajweiss: | depends on what the exchanges do |
| 20:13:55 | ThinThread: | are bitcoin forks the only way to see what the consensus really is? ie whose fork has most miners |
| 20:14:13 | kanzure: | "most miners" is not the way to decide anything |
| 20:14:26 | kanzure: | the absolute number of miners is non-detectable in this system anyway |
| 20:14:34 | ThinThread: | well theres no good way to decide anything |
| 20:14:36 | jposner: | "most difficulty" |
| 20:14:39 | ThinThread: | the supreme court is crap |
| 20:17:01 | bramc: | 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:28 | kanzure: | 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:35 | kanzure: | nsh: you might be right, but i would need your elaboration |
| 20:18:45 | jposner: | bramc, but even with a hard fork, there will only be 1 chain with the most work |
| 20:19:08 | kanzure: | jposner: it's most work plus validity |
| 20:19:09 | bramc: | jposner, That won't result in the other dieing though |
| 20:19:20 | kanzure: | one of them will not be valid according to various rules |
| 20:19:24 | fluffypony: | jposner: for valid blocks yes, but that's also "eventually" |
| 20:19:33 | jposner: | bramc, no it won't kill the others, just as bitcoin hasn't killed alts |
| 20:19:35 | fluffypony: | which could take hours or days or weeks to resolve if the split is quite fine |
| 20:20:14 | gwillen: | 13:14:34 < ThinThread> well theres no good way to decide anything |
| 20:20:22 | kanzure: | proof-of-work |
| 20:20:27 | gwillen: | ThinThread: you have identified the fundamental problem inherent in organizing humans together for a common task ;-) |
| 20:20:32 | bramc: | 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:50 | zooko: | 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:51 | fluffypony: | bramc: here: http://i.imgur.com/JUnQcue.jpg |
| 20:20:56 | kanzure: | 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:05 | gwillen: | 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:16 | bramc: | fluffypony, Is there a transation? I don't speak or read chinese |
| 20:21:31 | ajweiss: | woah cool chinese stamps! |
| 20:21:45 | jposner: | one cpu, one vote |
| 20:21:56 | kanzure: | 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:02 | fluffypony: | jposner: what do you do about virtual CPUs, then? |
| 20:22:03 | kanzure: | jposner: it's nothing about cpus or votes |
| 20:22:08 | rusty: | rusty has left #bitcoin-wizards |
| 20:22:16 | gwillen: | kanzure: sorry, I'm being a little bit glib |
| 20:22:32 | fluffypony: | bramc: https://imgur.com/a/LlDRr |
| 20:22:37 | kanzure: | bramc: there is a translation on reddit |
| 20:22:58 | gwillen: | 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:18 | kanzure: | "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:23 | kanzure: | but reorgs are not hard forks |
| 20:23:36 | gwillen: | 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:00 | kanzure: | 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:22 | jposner: | fluffypony, it's just a way of describing proof-of-work from the white paper |
| 20:24:34 | kanzure: | jposner: it's a poor (and wrong) description |
| 20:24:41 | fluffypony: | ^^ |
| 20:24:56 | jposner: | glad you guys are smarter than satoshi |
| 20:25:02 | bramc: | 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:39 | bramc: | jposner, I don't know what you're trying to say, but knock it off with the attitude |
| 20:26:59 | kanzure: | jposner: that's an argument from authority, and that sort of breaks bitcoin (if you wanted authority, go use a centralized design) |
| 20:27:10 | ThinThread: | TIL gavin is gmaxwell |
| 20:27:24 | ThinThread: | im building dossiers |
| 20:27:27 | fluffypony: | 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:57 | bramc: | 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:21 | jposner: | I simply think it takes some hubris to call Satoshi's description of proof-of-work |
| 20:28:22 | gmaxwell: | zooko: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas third top-level bullet. |
| 20:28:24 | jposner: | poor and wrong |
| 20:28:30 | fluffypony: | to believe that Satoshi Nakamoto was somehow perfectly able to foresee every eventuality, every possibility, every change, is naïve at best |
| 20:28:48 | kanzure: | and is disproven by the existence of soft-forks |
| 20:28:49 | ThinThread: | did Gavin short bitcoin on bitfinex or something? |
| 20:28:57 | ThinThread: | im trying to figure out how to trade this |
| 20:29:11 | zooko: | gmaxwell: thanks. |
| 20:29:28 | fluffypony: | jposner: you're misquoting him, you're making the same mistake the CryptoNote authors made |
| 20:29:39 | fluffypony: | he does say "Proof-of-work is essentially one-CPU-one-vote" |
| 20:29:47 | fluffypony: | but the following sentence explains |
| 20:29:53 | gmaxwell: | 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:56 | fluffypony: | "The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it." |
| 20:30:07 | ThinThread: | its hard to rollout technology improvements without interrupting outstanding demands of customers |
| 20:30:21 | kanzure: | what is wrong with hubris, again? especially in a no-authority system design? |
| 20:30:27 | fluffypony: | clearly that represents "majority processing power", not literally "one-CPU-one-vote" |
| 20:30:55 | kanzure: | fluffypony: and even that is unclear and ambiguous; he naturally means "the longest valid chain, which has the" |
| 20:31:09 | fluffypony: | 100% |
| 20:31:10 | gmaxwell: | 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:14 | ThinThread: | any link to manifestos for both sides of the issue? |
| 20:31:31 | fluffypony: | manifestos? on what, a blog post? |
| 20:31:33 | ThinThread: | better yet summarized in few sentences |
| 20:31:35 | kanzure: | the issue of contentious hard-forks? |
| 20:32:39 | ThinThread: | hm yeah. |
| 20:32:46 | ThinThread: | i guess the blocksize dispute is secondary to that |
| 20:33:15 | ThinThread: | 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:44 | ThinThread: | i guess this day was inevitable, birds leaving nest etc |
| 20:33:58 | gmaxwell: | gmaxwell has left #bitcoin-wizards |
| 20:35:18 | jposner: | 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:21 | bramc: | 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:54 | jposner: | gmaxwell, there are admittedly many ways to interpret that statement |
| 20:36:06 | ThinThread: | go i wish satoshi would release a signed message of guidance |
| 20:36:08 | kanzure: | yes the first way to interpret it is by reading the next sentence |
| 20:36:31 | zooko: | zooko has left #bitcoin-wizards |
| 20:40:43 | kanzure: | 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:47 | kanzure: | or the other link, i mean |
| 20:41:53 | kanzure: | "Does anyone worry that this shows mining pool collusion is entirely realistic?" |
| 20:58:01 | tdryja: | tdryja has left #bitcoin-wizards |
| 21:09:25 | rusty: | rusty has left #bitcoin-wizards |
| 22:02:54 | tdryja: | tdryja has left #bitcoin-wizards |
| 22:12:01 | maaku: | kanzure: what's seemingly entirely lost is that the mining pools in China want smaller blocks to protect non-Chinese miners |
| 22:12:25 | nsh: | heh |
| 22:12:47 | nsh: | they should be disqualified for not acting as rational actors :) |
| 22:12:54 | nsh: | *behaving |
| 22:15:46 | phantomcircuit: | nsh, it's meta rational to project their capital investment |
| 22:16:05 | nsh: | indeed |
| 22:16:05 | phantomcircuit: | damn now im making the same bizarre arguments as the others |
| 22:16:11 | nsh: | * nsh smiles |
| 22:16:21 | phantomcircuit: | (note you cant rely on this behavior as it's unstable) |
| 22:16:34 | nsh: | * nsh nods |
| 22:23:37 | jae: | jae is now known as Guest99295 |
| 22:27:32 | Guest99295: | Guest99295 is now known as jaekwon |
| 22:48:10 | c0rw|zZz: | c0rw|zZz is now known as c0rw1n |