| 02:02:00 | c0rw1n: | c0rw1n is now known as c0rw|zZz |
| 02:11:30 | kanzure: | http://research.microsoft.com/en-us/people/mickens/thesaddestmoment.pdf |
| 02:11:30 | kanzure: | "“How can you make a reliable computer service?” the presenter will ask in an innocent voice before continuing, “It may be difficult if you can’t trust anything and the entire concept of happiness is a lie designed by unseen overlords of endless deceptive power.” The presenter never explicitly says that last part, but everybody understands what’s happening. Making distributed systems reliable is inherently impossible; we ... |
| 02:11:34 | kanzure: | ... cling to Byzantine fault tolerance like Charlton Heston clings to his guns, hoping that a series of complex software protocols will somehow protect us from the oncoming storm of furious apes who have somehow learned how to wear pants and maliciously tamper with our network packets." |
| 02:12:00 | kanzure: | "Figure 1: Typical Figure 2 from Byzantine fault paper: Our network protocol" |
| 02:12:13 | kanzure: | "Figure 2: Our new protocol is clearly better." |
| 02:13:04 | kanzure: | "The caption will say something like “Figure 2: Our network protocol.” The caption should really say, “One day, a computer wanted to issue a command to an online service. This simple dream resulted in the generation of 16 gajillion messages. An attacker may try to interfere with the reception of 1/f of these messages. Luckily, 1/f is much less than a gajillion for any reasonable value of f. Thus, at least 15 gajillion messages ... |
| 02:13:10 | kanzure: | ... will survive the attacker’s interference. These messages will do things that only Cthulu understands; we are at peace with his dreadful mysteries, and we hope that you feel the same way." |
| 02:14:48 | zooko: | ☺ |
| 02:15:11 | kanzure: | "Every paper on Byzantine fault tolerance introduces a new kind of data consistency. This new type of consistency will have an ostensibly straightforward yet practically inscrutable name like “leap year triple-writer dirty-mirror asynchronous semiconsistency.” In Section 3.2 (“An Intuitive Overview”), the authors will provide some plainspoken, spiritually appealing arguments about why their system prevents triple-conflicted ... |
| 02:15:17 | kanzure: | ... write hazards in the presence of malicious servers and unexpected outbreaks of the bubonic plague. “Intuitively, a malicious server cannot lie to a client because each message is an encrypted, nested, signed, mutually-attested log entry with pointers to other encrypted and nested (but not signed) log entries.”" |
| 02:15:47 | nsh: | (it's probably easier to read from the pdf) |
| 02:17:20 | kanzure: | too bad that this is from 2013 |
| 02:20:14 | gmaxwell: | kanzure: I mentioned it here when it was first published I think. |
| 02:20:38 | kanzure: | i wonder if this brand of humor goes over the head of altcoin designers |
| 02:22:36 | kanzure: | definitely needs to be a cryptocurrency version. lots to be said... |
| 02:36:16 | nsh: | * nsh smiles |
| 02:42:24 | op_null: | op_null has left #bitcoin-wizards |
| 03:22:30 | kyletorpey: | kyletorpey has left #bitcoin-wizards |
| 03:32:27 | petertodd: | sipa: I'm already booked to speak at the o'reilly bitcoin conference |
| 03:32:53 | petertodd: | sipa: (re: financial crypto conf) |
| 03:39:39 | gmaxwell: | o'ra is running a bitcoin conference in parallel to FC? :-/ |
| 03:40:08 | kanzure: | this is why we invented simultaneous streaming to two conferences at once |
| 03:40:12 | kanzure: | just got to get the schedules aligned for your slot |
| 03:40:48 | tromp_: | not in parallel, it ends jan 18 |
| 03:41:15 | kanzure: | if it was in parallel and your speaking schedule was aligned then you could even accept questions over irc from both conferences |
| 03:41:22 | tromp_: | well before fc starts on jan 26 |
| 04:23:53 | amiller: | oh i didn't realize fc was that early |
| 04:55:41 | petertodd: | tromp_: I'm talking about this one: http://conferences.oreilly.com/bitcoin-blockchain-2015 |
| 04:56:08 | petertodd: | gmaxwell: even worse, they're paying expenses... $2.5k vs. $0 isn't that hard of a decision... |
| 04:56:54 | petertodd: | kanzure: heh, I was supposed to be talking at some virtual conference, on the same day as I'll be in London at a real conference... but I wound up cancelling the former because I got sick and ran out of free time |
| 05:04:55 | kanzure: | "sorry i couldn't make it to your conference, i have sent a giant stick figure instead i hope that's okay" |
| 05:05:30 | kanzure: | stick figure: http://www3.pcmag.com/media/images/343623-double-telepresence-robot.jpg |
| 05:06:13 | petertodd: | kanzure: lol |
| 05:06:14 | op_null: | kanzure: you'd do better to send a life sized cardboard cutout of yourself. |
| 05:08:44 | petertodd: | kanzure: in all honesty I probably could pull it off... but ending up in hospital briefly, followed by talking to a friend whose partner just got diagnosed with likely incurable cancer kinda puts you in a "fuck it, why did I schedule four talks in a week?" mood :/ |
| 05:09:47 | gmaxwell: | petertodd: yes, pleae do not kill yourself. Suicide by tour schedule ... most unglamorous way to go. |
| 05:10:27 | petertodd: | gmaxwell: I like to remind people there's nothing glamorous about spending a week in paris... and not once seeing the eiffel tower |
| 05:10:54 | gmaxwell: | I've done that. |
| 05:11:05 | op_null: | there's better things to do than look at the eiffel tower anyway. |
| 05:11:29 | op_null: | if you go to another country for the tourist things you might as well just buy the coffee table book and be done with it. |
| 05:11:35 | kanzure: | which cancer? |
| 05:11:44 | gmaxwell: | I managed to do a work trip through europe for a week where I never managed to see sunlight. |
| 05:11:59 | petertodd: | kanzure: more than one now - why it's likely incurable :( |
| 05:12:30 | kanzure: | one of my favorite things is telling people with incurable brain cancer about directed radiation and ultrasound ablation of deep brain tumors |
| 05:12:30 | gmaxwell: | op_null: AGREED. (it seems no one seems to understand my view that I'd rather read about the touristy stuff than visit it... reading about it so much more efficient and comprehensive) |
| 05:13:06 | kanzure: | "giant brain cyst? no problem! just melt your brain using this fancy apparatus" |
| 05:13:45 | petertodd: | op_null: I've very, very rarely done touristy things, and find them actually something I dislike - just feels weird to me when you're not getting "something done" in a country |
| 05:14:28 | kanzure: | i tried billing for plane time once |
| 05:15:34 | gmaxwell: | I did some zipline tour thing in hawaii which was actually fun, but otherwise? "I can relax when I'm dead" |
| 05:15:59 | kanzure: | pfft, somehow i doubt that. you seem like the type that would be relaxed by a good programming problem. (not the throw a laptop out the window kind) |
| 05:16:12 | op_null: | petertodd: it's not traveling unless you've butchered somebodies language. I held up a supermarket queue once because the shopkeeper made me pronounce the word over and over again until I got it right. |
| 05:16:38 | gmaxwell: | kanzure: well right, the touristy crap is mostly not relaxing to me at all. |
| 05:16:43 | kanzure: | s/window kind/window kind of problem |
| 05:16:57 | petertodd: | gmaxwell: see, for me hiking/caving/etc. are mentally "doing stuff", so they don't feel touristy - but trying to "immerse yourself in culture", fuck off |
| 05:17:20 | petertodd: | gmaxwell: vietnam was really weird for me that way |
| 05:17:26 | op_null: | petertodd: do you count "trying to fit in" in all of that? |
| 05:17:26 | kanzure: | i spent some time in vietnam |
| 05:17:39 | petertodd: | op_null: only if I'm trying to steal something |
| 05:17:54 | op_null: | huh |
| 05:18:13 | Pasha: | Pasha is now known as Cory |
| 05:19:05 | petertodd: | op_null: quite seriously, if you're trying to fit in because of *another* reason you want to be there, that's fine by me, but doing that for it's own sake is weird to me |
| 05:19:42 | op_null: | petertodd: in that case I was hungry and wanted to eat. |
| 05:19:54 | petertodd: | op_null: e.g. when I was in paris last I stayed for some of it by one of amirs squats near the sewage treatment plant - no-one there could speak any english - felt totally normal to me |
| 05:20:12 | kanzure: | petertodd: what would be a good alternative to the current format or structure of txin? |
| 05:21:09 | petertodd: | kanzure: serialization structure or *cryptographic* structure? |
| 05:21:54 | kanzure: | in very generic and vague terms i mean: some data structure suitable for referencing amounts of bitcoin that you want to be spent in some way |
| 05:22:24 | kanzure: | specifically this question came up earlier today (in here) because of me wondering about ways of not relying on merely (txid, vout) |
| 05:22:27 | kanzure: | because txid can change |
| 05:22:33 | petertodd: | kanzure: referencing txin by hash is a really, really, really good idea because it enforces determinism... but beyond that gets really complex |
| 05:22:49 | lechuga_: | i'd prob use a DHT |
| 05:22:51 | petertodd: | kanzure: see, you're talking about signatures, where some applications demand different sigs than others |
| 05:22:55 | kanzure: | txid in txin can change, so that doesn't sound like determinism to me |
| 05:23:00 | petertodd: | lechuga_: DHT gives me great trips too |
| 05:23:02 | op_null: | kanzure: the TX hash ideally won't be able to change soon. |
| 05:23:05 | lechuga_: | lol |
| 05:23:19 | lechuga_: | 5meo-DHT |
| 05:23:20 | op_null: | other than if the signer decides to, that is. |
| 05:23:20 | petertodd: | op_null: emphasis on "ideally" - I think that BIP is somewhat misguided |
| 05:23:43 | petertodd: | kanzure: but that's non-deterministic for the wallet - it is fully deterministic for the blockchain, in a sense |
| 05:23:58 | kanzure: | wallet determinism would be nice |
| 05:24:05 | petertodd: | kanzure: like, when you follow transactions back in time, you know *exactly* what data/txs went into proving that txout is real |
| 05:24:24 | petertodd: | kanzure: wallet's aren't consensus critical, so I'm happy for them to lose in favor of the important stuff |
| 05:24:24 | kanzure: | sure, i think preserving that is critical |
| 05:24:47 | kanzure: | right, i am not advocating a regression of consensus critical features |
| 05:25:02 | kanzure: | rather i think it may be possible to pick a method that is even more deterministic than present |
| 05:25:09 | petertodd: | kanzure: the only time tx mutability really matters is a) contracts and b) strings of transactions closely spaced enough for reorgs to matter. |
| 05:25:46 | op_null: | petertodd: and chains of unconfirmed transactions. |
| 05:25:58 | petertodd: | kanzure: the former can use other things, CHECKLOCKTIMEVERIFY/H(prevout.txout.scriptPubKey) hashing and the later can be largely mitigated with things like tx replacement |
| 05:25:58 | kanzure: | that seems to be b |
| 05:26:06 | petertodd: | op_null: which are by definition close enough for reorgs to matter :) |
| 05:26:33 | op_null: | hm? doesn't need a reorg. just needs a mutant to get into the next block to kill the chain. |
| 05:26:59 | petertodd: | op_null: I think you the joke ;) |
| 05:27:11 | kanzure: | presumably one block also counts as not spaced far enough |
| 05:27:25 | op_null: | petertodd: quite possibly |
| 05:27:32 | petertodd: | op_null: my mitigation suggestions work just fine for unconfirmed is the point |
| 05:27:40 | kanzure: | i don't really like the trend of "well if there's a large reorg we're all fucked anyway" thinking |
| 05:27:45 | kanzure: | no, it is definitively better to make good systems |
| 05:28:16 | petertodd: | kanzure: the alternatives to H(txid) are very likely worse for general purpose usage |
| 05:28:16 | kanzure: | you're not the only one to express that opinion of course |
| 05:28:17 | op_null: | well we are. 0.9 nodes can't handle very deep reorgs. |
| 05:28:46 | petertodd: | a deep reorg should damn well break the system from a social point of view, regardless of what it does from a technical point of view |
| 05:29:23 | kanzure: | from a social point of view i don't care if the blockchain changes as long as all of my transactions of interest are in the right spots and my chains aren't totally broken |
| 05:29:31 | kanzure: | and that i am not left waiting for others to sign new mutated transaction chains |
| 05:29:41 | gmaxwell: | things should handle them technically or risk introducing a corner case vulnerability; but yea.. I mean, you can't simply rewrite history and expect things to not be pear shaped as a result. |
| 05:29:51 | gmaxwell: | kanzure: then don't make #@$# malleable transactions? |
| 05:29:56 | petertodd: | kanzure: and if the reorg happened because of a *delibrate* technical decision, miners can easilly ensure tx's don't get broken |
| 05:30:08 | kanzure: | gmaxwell: i thought any transaction can be mutated by anyone? |
| 05:30:10 | petertodd: | kanzure: but if it happens because of an attack, yeah, bitcoin's fucked |
| 05:30:49 | gmaxwell: | kanzure: yes/no. For normal transactions there is only one piece of malleability left to anyone but miners, and BIP62 will close that. |
| 05:30:49 | op_null: | today *most* wallet software doesn't even rebroadcast it's own transactions after a reorganisation, or at all really. pretty sure a deep reorg would break lots of peoples systems. |
| 05:31:05 | kanzure: | gmaxwell: oh, then i will read BIP62. |
| 05:31:14 | lechuga_: | so it's assumed all potential sources are known? |
| 05:31:29 | petertodd: | op_null: yeah, getting txs back into the blockchain after a reorg is dodgy |
| 05:31:51 | gmaxwell: | kanzure: For standard transactions we're reasonably confident. |
| 05:31:52 | petertodd: | op_null: having explicit code that big pools could run to do it in a delibrate way wouldn't be an insane idea |
| 05:32:01 | op_null: | not rebroadcasting ever it a pretty stupid thing though |
| 05:32:23 | kanzure: | gmaxwell: so suppose there is a miner that is mining a reorg for whatever reason. someone else has a transaction they want to mutate. if bip62 is in universal use, can this non-miner send a mutant to the miner? |
| 05:32:53 | kanzure: | *a valid mutant to the miner |
| 05:32:59 | gmaxwell: | kanzure: _what_ mutant? |
| 05:33:00 | petertodd: | op_null: you know, not rebroadcasting probably makes big reorgs *more* likely to result in all previously confirmed txs getting into the chain again |
| 05:33:11 | kanzure: | okay cool |
| 05:33:32 | petertodd: | op_null: there's lots of wallets out there that double-spend accidentally, and with coinjoin we've got lots of mixing happening - any double-spend breaks all subsiquent txs after all |
| 05:33:54 | op_null: | lots of mixing happening where exactly? |
| 05:34:10 | kanzure: | weird how wallets aren't told to watch their own double spends |
| 05:34:13 | kanzure: | isn't that a good way to lose money? |
| 05:34:21 | petertodd: | op_null: coinjoin - darkwallet has auto-mixing now |
| 05:34:25 | petertodd: | kanzure: huh? |
| 05:34:30 | gmaxwell: | There are indeed non-trivial amounts of non-malicious double spends. |
| 05:34:35 | gmaxwell: | kanzure: huh? |
| 05:34:51 | op_null: | petertodd: I didn't think it was in anywhere near common use. I mean the software has huge warnings on the front not to use it at all. |
| 05:34:51 | kanzure: | oh sorry, i was thinking of double spends in the wallet sense, not outputs |
| 05:34:56 | kanzure: | sorry |
| 05:35:25 | kanzure: | i don't know how obvious it is but i have been in wallet land for a few weeks now :) |
| 05:35:45 | petertodd: | op_null: I'd guess there's mid five figures - maybe even six figures USD - of coins online being automixed on darkwallet right now in a given day |
| 05:36:24 | petertodd: | op_null: pretty reliable actually - haven't ever had a report of anyone losing money from it permanently, though there were a few issues where you needed a manual rescan |
| 05:36:25 | kanzure: | i also wasn't aware of the breakage with 0.9 about reorgs |
| 05:36:41 | kanzure: | so that does significantly entice me to consider any deep reorg to totally break everything |
| 05:36:52 | op_null: | petertodd: weird, didn't know it was that popular. |
| 05:36:55 | gmaxwell: | kanzure: well it won't reorg deeper than 750. It's fixed in 0.10. |
| 05:37:04 | kanzure: | oh. hrm. |
| 05:37:11 | petertodd: | op_null: doesn't take many people to get five figures... |
| 05:37:30 | petertodd: | op_null: probably still has in the realm of 100 regular users or something |
| 05:38:21 | op_null: | petertodd: still wish they hadn't written it in javascript. |
| 05:39:14 | gmaxwell: | op_null: well all software is broken, regardless of the language. :( |
| 05:39:46 | op_null: | in a browser extension though!@? |
| 05:39:46 | petertodd: | op_null: something we agreed on was to do up a CLI-based mixer in python that used bitcoin core as the wallet |
| 05:40:03 | petertodd: | op_null: the old vs debate |
| 05:40:20 | op_null: | no, it's just sloppy. |
| 05:40:22 | petertodd: | op_null: personally I would have written a python library first, followed by a delibrately ugly CLI, followed by... |
| 05:40:53 | petertodd: | op_null: software distribution is fucked, sorry. writing browser extensions is a good way to get to a huge number of people quickly |
| 05:41:09 | petertodd: | again, I wouldn't have done that... but the logic is sound for that team's goal |
| 05:42:51 | op_null: | petertodd: that sort of logic is why we have people fawning over the blockchain.info wallet which has probably lost millions of dollars easily. |
| 05:43:19 | op_null: | there's no "move fast and break things" in cryptography. |
| 05:43:45 | petertodd: | ...you're totally missing my point... |
| 05:44:07 | petertodd: | there *is* a move fast and break things, and the *unfortunate* thing is it works great far too often |
| 05:44:16 | op_null: | I know what you're saying. |
| 05:45:10 | petertodd: | darkwallet is interesting because they both did that wrong, and also aren't using a strategy that results in actually moving fast - to do that strategy right they'd have included far fewer features and gotten a v1.0 shipped months ago |
| 05:46:17 | petertodd: | also writing libbitcoin - a rewrite of bitcoin core - was insane |
| 05:50:21 | lechuga_: | but fun i'm sure |
| 05:51:16 | petertodd: | lechuga_: yeah... so I found yet another consensus-critical detail we weren't testing for just the other day... and I figured out how to use it to implement rivests paywords! |
| 05:51:32 | op_null: | why did they even do that? |
| 05:51:42 | op_null: | seems like the dumbest thing they could have done with their time |
| 05:51:57 | petertodd: | (use OP_CODESEPARATOR to control which pre-made signature is valid - because OP_CODESEPARATOR is evaluated, not declaritive, so you can turn it off with OP_IF) |
| 05:52:28 | petertodd: | op_null: amir is a good programmer, but his understanding of consensus politics is shit, as is his understanding of *consesnsus* programming |
| 05:52:32 | lechuga_: | can u share your test case? :) |
| 05:53:41 | lechuga_: | op_null: it's at the very least a remarkable learning exercise |
| 05:53:53 | op_null: | no, no it's not. |
| 05:54:21 | op_null: | you do a learning exercise in the sandbox, you don't build systems working with other people's money on top of it. |
| 05:54:22 | gmaxwell: | op_null: pft be nice. Who are you to define how other people learn? :) |
| 05:54:33 | gmaxwell: | oh that point. |
| 05:54:36 | gmaxwell: | * gmaxwell quiets down |
| 05:54:37 | lechuga_: | fair |
| 05:55:06 | petertodd: | lechuga_: https://github.com/bitcoin/bitcoin/pull/5421 |
| 05:55:54 | lechuga_: | ah sweet |
| 05:55:54 | lechuga_: | thx |
| 05:56:21 | petertodd: | gmaxwell: fuck yeah, I mean, we need to have standards and shit. You wouldn't want something crazy like, say, some loud-mouthed fine arts grad to start hacking on the core consensus code of a multi-billion financial system would you? |
| 05:56:49 | petertodd: | lechuga_: double-check those test cases 'eh? I'm pretty sure that code was finished... |
| 05:57:00 | lechuga_: | k |
| 05:57:22 | gmaxwell: | lechuga_: please feel free to review petertodd's pull req. |
| 05:57:29 | lechuga_: | nod |
| 05:58:48 | petertodd: | thanks, bbl, got a flight to catch |
| 05:59:06 | lechuga_: | safe travels |
| 05:59:15 | kanzure: | seeya |
| 06:29:01 | lclc_bnc: | lclc_bnc is now known as lclc |
| 07:37:01 | wallet421: | wallet421 is now known as wallet42 |
| 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 soundx damethos vmatekole Luke-Jr wallet42 koeppelmann fenn webdeli RoboTeddy paveljanik d4de rusty Cory shesek op_null prodatalab_ bit2017 bosma TheSeven bitbumper ryanxcharles super3 atgreen Starduster hashtagg_ luny tdlfbx koshii iambernie nubbins` go1111111 OneFixt mr_burdell hguux_ dgenr8 adlai devrandom Graftec Baz__ tacotime jgarzik davejh69 mkarrer Greed zibbo Emcy_ lnovy nsh_ c0rw|zZz yoleaux btc__ Graet roconnor |
| 09:05:16 | kornbluth.freenode.net: | Users on #bitcoin-wizards: Logicwax Baz___ Transisto gues samson_ warptangent andytoshi pi07r prepost SDCDev ybit Meeh_ starsoccer PaulCape_ DoctorBTC NikolaiToryzin nsh stonecoldpat waxwing btcdrak mappum tromp Guest45626 K1773R ahmed_ artifexd LarsLarsen nuke1989 iddo nanotube dansmith_ kanzure spinza Flyer33 arowser1 SubCreative Anduck null_radix Nightwolf hollandais berndj epscy jaekwon_ Hunger- HaltingState Pan0ram1x jaekwon lclc s1w Eliel_ bobke LaptopZZ isis |
| 09:05:16 | kornbluth.freenode.net: | Users on #bitcoin-wizards: sneak harrigan michagogo gavinandresen JonTitor phantomcircuit sl01 Grishnakh sipa Alanius jbenet HM kumavis Muis azariah4 MRL-Relay fluffypony BlueMatt a5m0 gazab AdrianG gwillen livegnik BananaLotus @ChanServ burcin coutts wizkid057 Dyaheon bbrittain forrestv nickler tromp_ Krellan poggy comboy mmozeiko Taek optimator_ [\\\] Apocalyptic throughnothing petertodd crescendo CryptOprah cfields-away Fistful_of_Coins gmaxwell kinlo so [d__d] |
| 09:05:16 | kornbluth.freenode.net: | Users on #bitcoin-wizards: espes BigBitz otoburb wumpus jaromil helo Keefe Iriez huseby phedny midnightmagic coryfields BrainOverfl0w warren pigeons asoltys gribble smooth amiller danneu catcow TD-Linux ryan-c roasbeef harrow lechuga_ |
| 09:13:15 | dansmith_: | dansmith_ is now known as dansmith_btc |
| 09:17:05 | lclc: | lclc is now known as lclc_bnc |
| 09:19:23 | lclc_bnc: | lclc_bnc is now known as lclc |
| 10:00:29 | Profreid_: | Profreid_ is now known as Profreid |
| 14:58:44 | Meeh_: | Meeh_ is now known as Meeh |
| 15:05:35 | lclc: | lclc is now known as lclc_bnc |
| 16:02:22 | Pan0ram1x: | Pan0ram1x is now known as Guest6066 |
| 16:19:21 | kinlo_: | kinlo_ is now known as kinlo |
| 16:40:31 | andytoshi: | o.O http://www.theregister.co.uk/2014/12/04/boffins_we_factored_143_no_you_factored_56153/ original paper http://arxiv.org/abs/1411.6758 |
| 16:44:46 | andytoshi: | ah, here we go: in the arxiv paper they exploit the fact that the factors differ at only two bits, which ofc will be very unlikely for any non-cherry-picked numbers |
| 16:46:57 | tdlfbx: | Yep |
| 16:47:08 | andytoshi: | the math here is super straightforward, it is almost all elementary school arithmetic (well, in base 2), so it's worthwhile to read the paper |
| 16:47:26 | tacotime: | might be a good target for cherry picking if you plan to have a quantum computer before everyone else. |
| 16:48:10 | andytoshi: | a fun candidate for the underhanded crypto contest: try to generate an RSA modulus whose "random factors" differ in very few bits |
| 16:54:59 | tdlfbx: | Hmmm...bitcoin codes that e.g. steal funds would be a fun candidate for that contest... |
| 16:55:25 | tdlfbx: | Darn, submissions closed 2 days ago. |
| 16:58:41 | nsh: | andytoshi, i would be slow to scoff, progress is progress :) |
| 16:58:52 | nsh: | (not suggesting anyone's scoffing, but there's some temptation) |
| 17:00:31 | andytoshi: | nsh: there is a temptation, after all with assumption of such small bit-distances you can solve these classically very quickly :) |
| 17:00:48 | nsh: | well, right |
| 17:00:50 | andytoshi: | they point out you can brute-force it in 2^16 time. but agreed, progress is progress, this is really neat |
| 17:00:54 | nsh: | * nsh nods |
| 17:19:16 | gmaxwell: | andytoshi: that popular press article is ... uhh. |
| 17:21:02 | hearn: | any headline with "boffins" in it gets immediate credibility points with me |
| 17:21:13 | helo: | lol |
| 17:21:19 | helo: | i hate that word so much |
| 17:21:59 | hearn: | you know what i hate? multi-dimensional state machines with a GUI and lots of things happening in parallel. |
| 17:56:43 | gmaxwell: | sipa: After we get through the 0.10 RC stuff, if you'd like to rebase the schnorr I can start seriously reviewing it. |
| 17:56:52 | sipa: | ack |
| 17:59:53 | gmaxwell: | I wonder if we should implement the threshold ecdsa ... it needs a trusted dealer, so I lost interest in it. ... but indeed it's not worthless. |
| 18:05:52 | hearn: | it'll probably end up being used for specialised tasks that aren't obvious to us at the moment |
| 18:06:08 | hearn: | they've implemented it for bitcoinj and told me they plan to open source the code |
| 18:06:23 | hearn: | so we could just wait and see if anyone does something interesting with it, and then do a native version in libsecp256k1 later |
| 18:07:14 | amiller: | gmaxwell, have you followed steven foldfeders progress on it at all |
| 18:07:29 | amiller: | goldfeder* |
| 18:08:34 | andytoshi: | gmaxwell: re the popular press article, yeah, wtf, i posted it before i read the paper and was expecting the paper to be way more opaque and impressive |
| 18:09:38 | andytoshi: | had they not said "the math is beyond us" i'd have read it first :/ |
| 18:42:26 | amiller: | is there a place that public discussion about sidechains happens, besides here? |
| 18:42:54 | amiller: | anyway, i have a sidechains question i can see resolved in one of two ways |
| 18:43:35 | amiller: | the question is, what is the recommended behavior on the sidechain in the unfortunate event that there's a revision attack on the sidechain that effectively steals some money from its bitcoin reserve |
| 18:44:32 | amiller: | for example, suppose this is a 1:1 peg chain, and at the moment there are 100 sidecoins and 100 bitcoins in its reserve -- now an attacker somehow exfiltrates (just) 1 of the bitcoin reserves so there are 99 btc in reserve and 100 sidechain coins outstanding |
| 18:45:46 | amiller: | there are two easy policies i can imagine, A) is that sidechains are still redeemed for bitcoins from the reserve at 1:1 rate, except that if 99 of them are exchanged this way, there's someone left at the end who can't exchange his and is stuck with a sidecoin he can't redeem for btc |
| 18:46:51 | amiller: | B) is that the sidechain keeps track of its reserve funds, accounting for not just the 'valid-in-main-fork' withdrawal transactions, but also accounting for the bitcoin chain's view of history which may have processed double spends, and diminishes proportionally |
| 18:47:22 | tromp_: | the KISS principle says A |
| 18:47:24 | amiller: | now as long as there are no further double spends, there are 99 bitcoins in reserve and 100 sidecoins and you can exchange a sidecoin for 99 bitcents |
| 18:47:37 | amiller: | that's subjective these are both pretty simple |
| 18:47:53 | amiller: | let me discharge a few caveats i'm ancitipcaintg quickly before this conversation goes off the rails |
| 18:48:42 | amiller: | - i'm aware that an attacker doesn't just hve to do a *double spend* but could probably take all 100 bitcoin reserves at once, maybe there are ways around that, let me just assume that that kind of attack is somehow limited and it only happens for 1 coin |
| 18:50:39 | amiller: | maybe that was the only caveat i can't think of anything else |
| 18:52:44 | amiller: | the main simplicity advantage of option A is that the sidechain doesn't seem even to need to monitor the bitcoin fund account for this purpose |
| 19:02:54 | andytoshi: | amiller: the concern there is it'd cause a "bank run", it is not a dramatic increase in complexity to do (B) |
| 19:03:45 | andytoshi: | amiller: basically once we have the primitives in place to do things like reorg proofs (which are needed for the peg anyway) it is easy to provide the sidechain with a "proof of theft" |
| 19:05:06 | amiller: | yeah that makes sense |
| 19:05:11 | kanzure: | so some proof-of-theft has to invalidate chains of transactions on the sidechain? |
| 19:05:29 | amiller: | kanzure, if it's the same B) i'm talking about, it wouldn't invalidate anything |
| 19:05:37 | andytoshi: | kanzure: no, it would only change the peg exchange rate |
| 19:05:39 | amiller: | it would simply acknowledge that bitcoin thinks there are now 99 coins, yet there are 100 sidecoins |
| 19:05:47 | amiller: | therefore the new exchange rate is 0.99:1 |
| 19:06:13 | amiller: | this ruleset is still 1:1 *as long as there are no huge history revisions* (or false spv proofs that go un-challenged) |
| 19:07:18 | andytoshi: | yup. fwiw there's a ton of design space for limiting this sort of attack (e.g. throttling the peg, increasing the conf times for large transfers, etc) |
| 19:08:00 | amiller: | yup, i meant to allude to those with my caveat :) |
| 19:08:21 | andytoshi: | yes, i caught that, thx for doing so :) |
| 19:09:41 | andytoshi: | so given the caveat (A) might not be as drastic ... after all, there is always some proportion of "lost coins" |
| 19:10:01 | andytoshi: | and if the theft can be throttled to always be less than that, and somehow everyone believes this, maybe there is no bank run |
| 19:12:50 | zooko: | * zooko reads with interest |
| 19:13:46 | amiller: | perhaps it can be a little-bit-of-bank-run and a little-bit-of-dillution |
| 19:14:37 | andytoshi: | mm, gmaxwell had an idea along those lines of temporarily charging withdrawal fees so the "bank runners" end up making up the theft |
| 19:14:55 | andytoshi: | i.e. you are punished for being a panicked pete |
| 19:15:15 | andytoshi: | which would discourage an avalanche effect |
| 19:15:23 | amiller: | that's good |
| 19:16:38 | gmaxwell: | This is actually covered in the paper, I thought. Or am I in draft-space-zone. |
| 19:17:35 | andytoshi: | oh, it is indeed |
| 19:22:11 | amiller: | hrm, yeah you're right, section 4.2 in the paper covers roughly all of these |
| 19:22:15 | amiller: | i don't know why i didn't remember that, sorry! |
| 19:22:25 | kanzure: | huh, why don't non-cryptocurrency-related-bank-runs do withdrawal fees during bank runs? |
| 19:22:30 | kanzure: | *do increased withdrawal fees |
| 19:22:35 | kanzure: | panic penalties, i mean |
| 19:22:41 | andytoshi: | might be illegal |
| 19:22:44 | kanzure: | haha |
| 19:22:45 | gmaxwell: | thanks for finding the section number; didn't have the document on this system and on a slow link |
| 19:40:21 | bramm: | Hey everybody |
| 19:40:28 | amiller: | hi bramm |
| 19:40:40 | bramm: | amiller! Just the person I have questions for |
| 19:41:42 | bramm: | amiller, I'm reading through your nonoutsorceable paper and am having trouble figuring out figure 2 (I have trouble with math-style notation) |
| 19:42:06 | amiller: | okay, i can probably hash it out in words here... |
| 19:42:29 | bramm: | There's something about a merkle tree. What do you put into the leaves of the merkle tree? |
| 19:42:51 | amiller: | the leaves of the merkle tree just contain random strings |
| 19:43:44 | amiller: | more accurately, the hash of a random string |
| 19:44:08 | bramm: | Okay, and then you come up with some nonce which picks some number of leaves and then you do... something with them |
| 19:44:28 | amiller: | right the nonce picks some number of leaves, and you *hash them all up* |
| 19:44:37 | amiller: | then you check to see if you win |
| 19:44:51 | amiller: | slightly more complicated than that - you hash up all the leaves/branches that get picked |
| 19:45:44 | bramm: | Okay that I follow, but how is this any different from an ordinary proof of work? Where does the nonoutsourceability come in? |
| 19:46:49 | amiller: | the main difference is that the *destination* of the reward is not committed to when you are doing the work, but instead is bound *after* you find a solution |
| 19:47:23 | bramm: | That I really don't follow |
| 19:47:26 | amiller: | in bitcoin you commit to a coinbase transaction before mining, each attempt only has a chance of winning a block that pays out to that transaction |
| 19:47:40 | bramm: | right |
| 19:47:49 | amiller: | this is why pools work, you can show that you're doing work that would pay out to the pool operator |
| 19:47:57 | bramm: | right |
| 19:48:02 | amiller: | (or, in p2pool, to the stack of other peers) |
| 19:48:07 | amiller: | okay so here, ... you don't do that |
| 19:48:25 | bramm: | I'm not following what your construction does. What you're saying sounds impossible to me. |
| 19:48:37 | amiller: | basically the structure of this puzzle is meant to guarantee that if you are doing the mining work, you have the private key |
| 19:48:43 | amiller: | when you are doing work for a pool, you don't have the pool operators private key |
| 19:48:57 | amiller: | you commit to paying out to a public key that *you* don't have the correpsonding key for, and that works fine |
| 19:49:15 | amiller: | here, you commit to the root of a merkle tree which acts as a finite-use-signature scheme, |
| 19:49:30 | amiller: | and to actually do the mining work you have to know (a significant portion of) the private key |
| 19:50:03 | bramm: | Okay, I'm familiar with merkle trees as signature schemes |
| 19:50:33 | bramm: | How is the destination selected/revealed at the end? |
| 19:51:17 | amiller: | it's selected by the miner who finds the solution, and it's shown to the world by creating a signed message with that merkle-tree-key |
| 19:53:02 | bramm: | So you're using the merkle tree twice, once to verify that your mining was successful, and once to reveal/sign the destination? |
| 19:54:00 | bramm: | What's wrong with using a more common signature scheme, where you hash a public key to see if your mining attempt was successful, and then sign it something with it? |
| 19:54:38 | amiller: | if you hash a public key, you might not know the corresponding private key |
| 19:55:03 | bramm: | Oh right, a pool might send you then private key |
| 19:55:07 | amiller: | that means you can do some work while provably waiving your ability to steer the reward at the end |
| 19:58:08 | bramm: | I'm trying to think how this would interact with something like cuckoo |
| 19:58:44 | amiller: | so sirer and eyal came up with this two-phase thing |
| 19:59:04 | amiller: | that combines an ordinary scratch-off puzzle with a nonoutsourceable puzzle |
| 19:59:07 | amiller: | and is sort of best of both |
| 19:59:15 | bramm: | Got a link? |
| 19:59:31 | amiller: | http://hackingdistributed.com/2014/06/18/how-to-disincentivize-large-bitcoin-mining-pools/ |
| 19:59:42 | amiller: | the idea is that you just have two phases |
| 19:59:43 | amiller: | pick a nonce |
| 19:59:54 | amiller: | use the nonce to pick some leaves in this merkle tree as the first phase |
| 20:00:08 | amiller: | when you compute the hash, you don't immediately check to see if it's below a threshold, you use it as a nonce for a second phase |
| 20:00:19 | amiller: | e.g., as the macrononce for cuckoo cycle |
| 20:01:14 | bramm: | Couldn't the first phase be done by the pool and then the second phase farmed out to pool members? |
| 20:01:28 | amiller: | yes, but you have to do this roughly for *each attempt* |
| 20:01:32 | amiller: | so that would require a ton of bandwidth |
| 20:01:51 | bramm: | hmmm |
| 20:02:05 | bramm: | It would be nice to find something stronger than that |
| 20:02:10 | amiller: | i tried to write it out clearly so that it doesn't seem like this alternative bad scheme that i'm *not* describing, which is where you *first* try to grind out the first phase |
| 20:02:27 | amiller: | and *then*, having first found a phase1 solution, try to grind out a phase2 solution..... its' not that |
| 20:02:52 | amiller: | i don't think it's possible/necessary to find something stronger that, that's pretty goo |
| 20:03:48 | bramm: | I'll need to at least think about how to maximize the amount of bandwidth which needs to be used there |
| 20:04:37 | amiller: | okay so the way i described it is slightly simpler than what i described, and is *the maximized* setting |
| 20:04:46 | amiller: | slightly simpler than what *they* described i mean |
| 20:04:57 | amiller: | what they described there is a sort of difficulty balance parameter between phase 1 and phase 2 |
| 20:05:33 | amiller: | that means, sometimes after having made half of an attempt, you can compare it against some weak threshold and figure out that that nonce definintely isn't a winner without having to do the phase 2 step |
| 20:05:36 | bramm: | I don't see any reason to put work difficulty in phase 1 |
| 20:05:50 | sipa: | gmaxwell: rebased the schnorr implementation already |
| 20:06:06 | amiller: | bramm, the reason has to do with their motivation for this in the first place, |
| 20:06:26 | amiller: | which is to.... actually i kind of agree i don't know why you'd ever want to do that |
| 20:06:52 | amiller: | well okay the reason is |
| 20:07:10 | amiller: | suppose that one cuckoo attempt is still a lot faster than doing this signature thing |
| 20:07:23 | bramm: | ... which it isn't |
| 20:07:28 | amiller: | then you're not really getting the benefit of cuckoo making ram dominate the costs |
| 20:07:33 | amiller: | okay well |
| 20:07:46 | amiller: | keep in mind their expressed motivation was to make existing miner asics compatible with the new scheme |
| 20:07:52 | amiller: | so clearly making one hash attempt is a lot faster than anything else |
| 20:08:00 | amiller: | *if* you buy that motivation, |
| 20:08:12 | amiller: | then the solution is to make the hash attempt the phase1 and the nonoutsourceable signature thing the phase2 |
| 20:08:28 | bramm: | Changing the proofs of work in existing Bitcoin is in the list of Things Which Aren't Going To Happen |
| 20:08:52 | amiller: | then to set this phase1 difficulty parameter so that you spend sufficient amount of your time doing the phase 1 work |
| 20:09:02 | amiller: | bramm, yeah yeah yeah that's why we're in -wizards :) |
| 20:09:52 | amiller: | if i had to poll everyone's opinion about whether an idea was politically realizable or not i'd not have nearly as much fun doing research |
| 20:10:03 | bramm: | Also, if you're relying primarily and bandwidth costs killing miners, then a regular public/private key pair will have the same effect |
| 20:10:11 | sipa: | bramm: the purpose of this channel is pretty specifically not about Bitcoin itself |
| 20:10:17 | amiller: | bramm, maybe |
| 20:10:19 | kanzure: | i suspect that a good implementation would have a chance of adoption |
| 20:10:50 | amiller: | bramm, my first version of this just used arbitrary signatures like deterministic ecdsa or rsa |
| 20:10:53 | sipa: | doesn't mean that nothing here might end up in Bitcoin, or can't be intended as a "maybe one day Bitcoin should adopt this", but it's more about research/development than about actual production changes now |
| 20:11:46 | amiller: | bramm, but i wasn't able to prove anything because signatures don't generally guarantee that you can't make a defective private/public keypair that lets you do this kind of outsourcing thing somehow |
| 20:12:18 | bramm: | What do you mean by 'defective'? |
| 20:12:22 | amiller: | now that i use random oracles all my proofs work and no one really seems to feel excited enough to criticize it |
| 20:12:45 | amiller: | with a correctly generated public/private keypair, a signature is a proof of knowledge of the key |
| 20:13:18 | amiller: | however there is definition that guarantees that there is no alternate generation algorithm that gives you a private keypair that can only sign transactions that pay out to a pool |
| 20:13:23 | gmaxwell: | amiller: see the threshold ecdsa paper, it's possible to make delegatable signing with trusted setup... |
| 20:14:37 | amiller: | http://www.cs.princeton.edu/~stevenag/bitcoin_threshold_signatures.pdf this one i think you mean, for the self-containedness of the log transcript here |
| 20:15:27 | amiller: | anyway that's not exactly practical for this... |
| 20:16:17 | amiller: | i don't think there's any actual problem with using ordinary asymmetric crypto and having each scratch off attempt involve a signature |
| 20:16:35 | bramm: | I have a wonderful horrible idea |
| 20:16:46 | amiller: | on the other hand, the merkle tree one might be faster, and that makes it easier to tip the work balance towards cuckoo or whatever |
| 20:16:49 | amiller: | which i think is good |
| 20:17:38 | bramm: | A hash-based digital signature scheme involves selectively revealing some information based on a hash |
| 20:17:39 | amiller: | also its post quantum |
| 20:17:56 | gmaxwell: | bramm: we could call it... a lamport signature. |
| 20:18:33 | bramm: | cuckoo involves selectively revealing a selection of where some edges came from |
| 20:19:16 | amiller: | i guess you're suggesting intertwingling those two steps somehow... |
| 20:19:33 | bramm: | How about if we make each of the leaves of our tree responsible for some of the edges of the cuckoo? |
| 20:20:29 | kanzure: | for-pay remailers http://web.archive.org/web/20130513050640/http://finney.org/~hal/pay_remail.html |
| 20:20:32 | kanzure: | cc andytoshi |
| 20:20:39 | kanzure: | and bram i guess. but bram knows remailers. |
| 20:21:01 | amiller: | bramm, it seems like it would be tedious to work out that there isn't any gaming here or something, but it seems like it would work.... what is the goal you're hoping to get out of this thouhg? |
| 20:21:05 | bramm: | remailers unfortunately don't matter. People don't use email any more. |
| 20:21:10 | amiller: | just fewer steps or something compared to doing one then the other/ |
| 20:21:50 | bramm: | amiller, trying to make it so that the amount of bandwidth which is necessary for outsourcing is nuts |
| 20:22:44 | amiller: | bandwidth is expensive and this requires a ton of it, i think you're doing a premature/unnecessary optimization |
| 20:23:07 | amiller: | bramm, i have a bunch of calculations about how this kind of pow scheme affects bandwidth and costs in the permacoin paper http://cs.umd.edu/~amiller/permacoin.pdf |
| 20:23:26 | kanzure: | why remailers 1 http://web.archive.org/web/20120216180743/http://finney.org/~hal/why_rem1.html |
| 20:23:29 | kanzure: | why remailers 2 http://web.archive.org/web/20130513043044/http://finney.org/~hal/why_rem2.html |
| 20:23:39 | amiller: | upshot: roughly at any parameter setting, the cost of bandwidth is through the roof even when you assume you're using like, industrialbulk peering rates |
| 20:24:08 | bramm: | amiller, I don't think my suggestion of mixing has any real downside |
| 20:24:31 | amiller: | bramm, okay fair enough |
| 20:25:13 | kanzure: | "detecting double spending" http://web.archive.org/web/20021106004752/http://www.finney.org/~hal/chcash1.html |
| 20:25:14 | [Tristan]: | [Tristan] is now known as Guest38445 |
| 20:26:18 | amiller: | anyway, one way or the other we seem to agree it's plausible to combine cuckoo and nonoutsourceable and thereby get a pow that's hopefully both anti-delegation and anti-asic... |
| 20:26:35 | bramm: | Yeah the main problem is the size of the signatures |
| 20:26:54 | amiller: | why? just because they eat into the blocksize? |
| 20:27:04 | bramm: | Yeah |
| 20:27:18 | amiller: | 40*32 bytes = >1k or so, i guess yeah |
| 20:27:53 | kanzure: | does anyone have a backup of rpow.net? |
| 20:27:54 | amiller: | (the 40 there comes from permacoin parameters which isn't necessarily a safe choice, could be worse) |
| 20:28:28 | amiller: | smaller signatures would be a good reason to want to use d-ecdsa vs hash-based-signature |
| 20:28:30 | bramm: | There are tricks for reducing the size of hash-based signatures which may be applicable |
| 20:29:07 | amiller: | yeah like winternitz compression |
| 20:29:15 | amiller: | i don't think nay of those buy you anything in this setting |
| 20:29:24 | bramm: | I'll have to think about it |
| 20:29:28 | andytoshi: | thx kanzure, unfortunately i don't have any spare cycles to think about high-latency mixers for the forseeable future |
| 20:30:20 | amiller: | actually here's the biggest problem i think with this cuckoo approach |
| 20:30:28 | amiller: | busting pools this way means we need to tolerate faster shares somehow |
| 20:30:39 | amiller: | and good parameters for cuckoo are already starting to require long attempts |
| 20:31:02 | amiller: | like, tens of seconds per attempt or something |
| 20:31:11 | amiller: | that definitely starts to interfere with the costly bandwidth argument |
| 20:31:19 | bramm: | Not sure what you mean. Cuckoo's long attempts are something which needs to be taken into consideration regardless. |
| 20:31:32 | amiller: | i guess that's true |
| 20:31:51 | bramm: | Long attempts are not in and of themselves disastrous because they can be done in parallel. Does create a minimum time between blocks, which might not be a bad thing. |
| 20:32:03 | amiller: | does it affect p2pool |
| 20:32:07 | amiller: | or any other way of lowering variance |
| 20:32:22 | bramm: | probably affects them a lot, I haven't thought it through yet |
| 20:32:34 | bramm: | And anyway, the idea is to fuck their shit up |
| 20:32:38 | amiller: | its one thing to compare it to the interblock time, but lower variance is achieved by having someone find a solution every few seconds or something |
| 20:33:18 | amiller: | yeah yeah but you have to provide low variance somehow, and the only way i know of how, even if pools are busted up, involves having frequent shares |
| 20:33:27 | bramm: | I'm liking this nonoutsourcing thing a lot more now that I know that it obliterates partials, that will really mess up pools something good. |
| 20:34:26 | amiller: | great :D |
| 20:34:38 | amiller: | although, i think pools aren't nearly as scary as hosted mining. |
| 20:34:59 | bramm: | There's another trick where you make there be two levels of mining success - one of which makes a new block and the other of which is a mining success. That can add a lot more rewards. |
| 20:35:10 | amiller: | bramm, yeah definitely |
| 20:35:24 | amiller: | bramm, but... actually i guess that doesn't hurt the progress free thing as much |
| 20:35:51 | amiller: | like if it takes 10 seconds to make an attempt, and several people win "shares" at the same time, they can still get some reward for it maybe |
| 20:36:10 | bramm: | It seems there's a long list of things which can be done to fuck with miners/asics/hosting/pools. No single one of them really fixes the problem, but all of them help a bit. If you're starting from scratch you can pull out all the stops |
| 20:36:31 | amiller: | yeah |
| 20:36:42 | bramm: | There's another really neat thing which I'm keeping secret for now |
| 20:36:53 | amiller: | what is it |
| 20:36:58 | bramm: | It's a secret :-) |
| 20:37:02 | amiller: | you can tell us |
| 20:37:05 | kanzure: | the previous arguments about being ignorant in secret didn't work on you? |
| 20:37:13 | amiller: | why would you bother announcing a secret like that |
| 20:37:16 | amiller: | kinda rude! |
| 20:37:18 | kanzure: | yep |
| 20:37:39 | bramm: | I've sort of announced it already. I posted about how I've found a more practical proof of sequential work |
| 20:37:50 | amiller: | proof of sequential work? |
| 20:38:02 | bramm: | https://eprint.iacr.org/2011/553.pdf |
| 20:38:09 | amiller: | like this one ?http://www.cs.virginia.edu/~mohammad/files/papers/15%20TimeStamp.pdf |
| 20:38:29 | amiller: | yeah those links coincide :) |
| 20:38:36 | bramm: | Yes, like that one, I figured out an improvement on it and something neat which can be done with it |
| 20:38:55 | amiller: | okay well i'm interested in that |
| 20:39:18 | amiller: | maybe you'll tell me in confidence if it's that big of a trade secret but you don't want to make me feel bad and waste time wondering about what it might be |
| 20:39:46 | bramm: | I'm sorry I mentioned it really, I didn't mean to taunt |
| 20:39:54 | bramm: | Just saying there are lots of things which can be done |
| 20:40:01 | amiller: | do you have a good undersatnding of that paper? |
| 20:40:09 | amiller: | i can't intuitively imagine what the structure of that expander graph thing looks like |
| 20:40:35 | bramm: | amiller, reasonably good, I have a much better intuitive understanding of my improved construction |
| 20:40:41 | amiller: | i get the idea that it's building up a dag of some kind with long paths through it and pretty low width but i can't figure out what it looks like and i haven't implemented the stupid zig zag expander thing |
| 20:40:47 | bramm: | Like, I forgot their construction after figuring out a better one |
| 20:40:47 | amiller: | okay |
| 20:40:52 | Eliel_: | I wonder if pools are actually necessary... I mean, individual miners could easily do optimistic tit for tat between themselves. The valuable thing being lower difficulty shares for blocks that'd pay the cooperating miners if it was a real block. |
| 20:40:59 | amiller: | is the thing that can be done with it also part of the secret? |
| 20:41:06 | amiller: | i'm not going to stay up at night wondering about the improved construction |
| 20:41:49 | bramm: | Yes the thing which can be done with it is the real secret. Although I feel silly talking about it as a secret, it was the first thing I thought of when the structure of bitcoin was explained to me. |
| 20:42:39 | amiller: | okwell i look forward to hearing about it later, you can rest your conscience because i've sort of stopped caring as much already, maybe i just have better discipline than last time this happened :) |
| 20:43:53 | bramm: | not sure what you mean about last time this happened |
| 20:44:22 | amiller: | last time someone told me there was a secret and i was butthurt for a wihle because i really wanted to know what it was |
| 20:45:01 | amiller: | btw i know a secret that you would probably pay like 10btc to know so there |
| 20:46:43 | bramm: | I'm being fairly open about ideas that I have, because in many cases other people have already thought of them, and even if they haven't they can often improve on them. I'm just keeping something particularly clever and particularly well buttoned down so I'm not so worried about screwing it up as a secret for now. All will be revealed in time. |
| 20:48:13 | bramm: | The question of how to have separate, or somewhat separate, mining rewards and block minting when you have a long cycle time like cuckoo is an interesting one |
| 20:48:43 | bramm: | I'm all ears about peoples's suggestions about that one. I've enumerated different approaches and am not particularly sold on any of them. |
| 20:55:11 | bramm: | Like, what's the incentive for including mining rewards for others in a new block? Does it make getting a new block more likely? Does it give a greater reward to the block maker? |
| 20:56:40 | phantomcircuit: | bramm, if you dont reference the actual current tip you increase the risk of an orphan substantially |
| 20:57:40 | bramm: | phantomcircuit, Well yes all successful mining operations have to reference either the most recent of a fairly recent head |
| 20:57:58 | bramm: | Otherwise you aren't really doing anything useful |
| 21:01:03 | bramm: | But there is a question of how long mining rewards which don't create a new block can sit around before being included and rewarded. |
| 21:10:07 | bramm: | I'm surprised that this sort of stuff hasn't been written about extensively already. It seems like a good way to reduce mining pooling is to make rewards more distributed to begin with. |
| 21:13:32 | kanzure: | was there a name for the sometimes-the-reward-is-10x proposal? |
| 21:15:51 | phantomcircuit: | bramm, i dont follow |
| 21:16:08 | phantomcircuit: | mining rewards are when a new block is created |
| 21:19:21 | bramm: | phantomcircuit, If you're making a new protocol from scratch you can make it so that near misses get credit |
| 21:19:44 | bramm: | kanzure, That's the opposite of what I'm suggesting |
| 21:19:53 | Luke-Jr: | bramm: if you're making a new protocol from scratch, then it's off-topic here; see ##altcoin-dev |
| 21:19:55 | phantomcircuit: | ah right |
| 21:20:24 | kanzure: | bramm: i didn't mean to claim it was your idea, or related, whoops |
| 21:20:27 | phantomcircuit: | Luke-Jr, eh i think it's on topic (this stuff easily applies to sidechains) |
| 21:20:37 | kanzure: | keeping secrets is off-topic and hostile |
| 21:21:23 | Luke-Jr: | phantomcircuit: not really if it's "from scratch" (and incompatible with bitcoin's existing financial commitments) |
| 21:21:28 | bramm: | Yeah side-chains can have whatever mining system they want |
| 21:22:14 | Luke-Jr: | I suppose demurrage could be done for this, but that'd be.. ugly |
| 21:22:26 | bramm: | demurrage? |
| 21:23:17 | Luke-Jr: | bramm: sidechains can't just create bitcoins from thin air |
| 21:23:55 | bramm: | sidechains can create sidechain coins all they want and then have some mechanism for deciding how bitcoins get assigned to them |
| 21:25:21 | bramm: | And anyway, I am happy to discuss rejiggering mining rewards as a thing to be done to bitcoin, it's no more implausible than 90% of the other stuff we've been discussing |
| 21:26:39 | c0rw|zZz_: | c0rw|zZz_ is now known as c0rw1n |
| 21:27:45 | phantomcircuit: | Luke-Jr, afaik a sidechain could be implemented using close to arbitrary rules as long as you can generate a compact spv proof which works with whatever the op code does |
| 21:28:21 | Luke-Jr: | phantomcircuit: yeah, but that's just implementation - in the end, the bitcoins it has available are set |
| 21:28:58 | bramm: | phantomcircuit, doesn't even have to strongly justify itself to the main chain directly, just show that it's been consistent about a certain transaction for a while |
| 21:32:36 | bramm: | so anyway, if one were to have a policy of rewarding partials directly in new blocks in bitcoin, how would you incentivize it? |
| 21:33:12 | bramm: | One thing to do is count partials as affecting height |
| 21:33:57 | bramm: | So if you don't reward any partials in your block, it will wind up an orphan |
| 21:36:03 | kanzure: | they would just reward their own partials |
| 21:36:38 | bramm: | The idea is that everybody is incented to reward all partials |
| 21:36:55 | bramm: | although obviously you're more incented to reward your own |
| 21:37:31 | andytoshi: | you should hoard partials, then when a block appears you can copy all the partials from it, add your hoarded ones, then publish a conflict |
| 21:37:40 | andytoshi: | since you will have strictly more partials, if these affect height then you win |
| 21:38:13 | bramm: | andytoshi, There can be a rule that partials must be rewarded in the same or next block |
| 21:38:45 | gmaxwell: | would be the same block in what andytoshi is saying. |
| 21:40:32 | bramm: | Well, there is a potential problem that if partials are counted as part of height you can withhold them for a while and use that to reorg but hopefully by then something else already has greater depth and the height formula is such that it won't work any more |
| 21:41:10 | bramm: | The idea is that partials should be broadcast out to everyone in the same way that transactions are |
| 21:41:42 | amiller: | kanzure, i dunno, i think a phrase like "jackpot" or "high variance reward component" should evoke it pretty unambiguously |
| 21:41:51 | amiller: | "powerball-style bitcoin rewards" |
| 21:42:15 | bramm: | The ways in which partial inclusion can be rewarded are: direct reward amount, increased chances of success, and increased height |
| 21:42:31 | bramm: | I'm not even sure which one of them works best in principle |
| 21:42:42 | andytoshi: | "hopefully by then something else already has greater depth" i described an attack where you take the current greatest depth and create a reorg to a chain with your block with strictly greater depth |
| 21:43:09 | bramm: | andytoshi, I'm not sure what attack you're describing |
| 21:43:35 | amiller: | andytoshi, link? |
| 21:44:01 | andytoshi: | amiller: bramm: my two-line comment above |
| 21:44:12 | andytoshi: | "you should hoard partials..." is the attack |
| 21:44:24 | andytoshi: | because now you've got a situation where "last to publish their block wins" |
| 21:44:27 | amiller: | oh okay i understand |
| 21:45:09 | bramm: | We can have a system where, for example, partials are 1/128 and blocks which don't give rewards to at least 128 partials are treated as orphan. Then everybody posts their partials as if they're transactions, and peers glom up as many partials as they can to meet the threshold |
| 21:45:36 | andytoshi: | then by withholding partials you make it less likely that other miners can get a block |
| 21:45:45 | andytoshi: | so everyone only has their own partials, and that's not progress free |
| 21:46:28 | bramm: | But by hoarding partials you won't get the kickbacks for them when others make new blocks, and they become worthless as soon as a new block is hit |
| 21:47:11 | bramm: | The incentives are highly dependent on exact subtle details of the rules about what counts |
| 21:47:18 | bramm: | As are the potential attacks |
| 21:50:48 | bramm: | If you have less than 50% of the mining capacity then hoarding becomes a net loss |
| 21:50:56 | bramm: | At least in a simple threshold scheme |
| 21:56:34 | bramm: | Hey zooko |
| 22:05:14 | Dizzle__: | Dizzle__ is now known as Dizzle |
| 22:24:15 | zooko: | Hiya bramm! |
| 22:26:07 | tromp_: | hi, guys. what does the 2nd m in bramm stand for? |
| 22:26:25 | helo: | i hope it's muffins |
| 22:26:31 | kanzure: | probably stands for "someone else registered bram" |
| 22:28:40 | tromp_: | then i'd expect bramc. bramm smells of bram moolenaar (vim author) |
| 22:29:04 | bramm: | tromp_, It stands for 'I lost the bram login, along with all ops of any kind for #bittorrent disappearing, because I hadn't logged in in too long' |
| 22:29:17 | bramm: | oh, that didn't occur to me, I should use bramc |
| 22:29:20 | bramm: | bramm is now known as bramc |
| 22:31:40 | zooko: | * zooko reads IRC backlog and laughs |
| 22:36:25 | bramc: | zooko, How is that funny? |
| 22:36:35 | zooko: | I definitely think you should pay amiller 10Kⓑ quick, before it is too late. |
| 22:37:07 | nsh: | * nsh smiles |
| 23:43:42 | c0rw1n: | c0rw1n is now known as c0rw|zZz |