| 00:40:34 | zooko`: | zooko` is now known as zooko |
| 00:43:12 | gmaxwell: | gmaxwell is now known as Guest17803 |
| 00:46:14 | Guest17803: | Guest17803 is now known as gmaxwell |
| 01:53:55 | amiller: | okay i'm thikning about variations on nonoutsourceable puzzle arrangements |
| 01:54:15 | amiller: | as i try vainly/desperately to fix my paper so it can get published. |
| 01:54:45 | nsh: | can you define nonoutsourceable puzzle arrangements a little more? |
| 01:54:54 | nsh: | as in merkle puzzles? |
| 01:55:11 | amiller: | okay to recap, the basic structure i have is a puzzle with an optional zk proof |
| 01:55:37 | nsh: | puzzle being something that's computationally hard to determine from the inputs? |
| 01:56:11 | amiller: | where you can prove, "i know a puzzle solution pointing to previous block P" without indicating what it is |
| 01:56:29 | nsh: | * nsh nods |
| 01:56:31 | amiller: | er you reveal the prevhash P, but nothing about any transactions you may have committed to, nothing about the nonce |
| 01:56:58 | amiller: | now, i make it the zk thing optional because it's a pain to actually have to produce these proofs, but it can be done in say 15 seconds if you have enough parallel cpu |
| 01:57:18 | amiller: | but, |
| 01:57:40 | amiller: | if there are no pools, and everything else is the same, then no one would want to play at all. |
| 01:57:54 | amiller: | since the variance is so high, you spend $2k on a rig you're still not seeing a block in the next year most likely |
| 01:58:13 | amiller: | now my handwavy solution so far has been, well lets lower the block time |
| 01:59:08 | amiller: | but that's really not that good a solutino |
| 01:59:24 | amiller: | if the block time were put that low, then that 15 second time would be kind of prohibitive |
| 02:00:05 | amiller: | so here are some of the basic options i'm considering now: |
| 02:00:58 | amiller: | 1) suppose there's some chance of winning a "lucky" block, and the lucky block might count for a little bit more difficulty (to offset the time it takes to make a zk proof) and a lot more reward |
| 02:01:52 | amiller: | like, one out of 4096 blocks gets a 100x reward, and counts for 10x difficulty |
| 02:02:25 | amiller: | (measures of the average difficulty rate and expected reward would need to take that into account) |
| 02:02:38 | amiller: | okay that's one component not a whole solution. |
| 02:03:09 | nsh: | [phonecall, bbiab] |
| 02:03:38 | amiller: | component 2) what if you can basically reveal some information more than the prevhash, but only if that extra information is itself a sub-difficulty proof of work chain? |
| 02:03:44 | amiller: | or to put it another way, |
| 02:03:53 | amiller: | you can reveal enough information that you can participate in p2pool |
| 02:05:33 | amiller: | let me recap the two extremes and why i've previously settled on one. |
| 02:06:14 | amiller: | the first extreme is that you reveal the prevhash, and the merkle root of transactions you were committing to, but use zk proofs to hide the nonce and maybe some details that would ordinarily be in the coinbase tx |
| 02:06:23 | amiller: | the reason this defeats the nonoutsourceability premise is that |
| 02:06:52 | amiller: | a pool could catch defectors by basically assigning a unique sentinel transaction in the merkle root of the work it hands out to each different user |
| 02:07:49 | gmaxwell: | If a pool is handing out tx sets that depending on a old model of pooling that really should go away. |
| 02:08:15 | gmaxwell: | (there is no reason for pools to manage the consensus, miners should be able to pick the chain/tx sets themselves and have pools pay them on the basis of coinbase outputs) |
| 02:09:27 | amiller: | yeah but that doesn't matter in this context |
| 02:09:53 | amiller: | the scenario here is, suppose pools are trying to find ways of still existing despite a nonoutsourceable puzzle that tries to make them not work |
| 02:10:21 | gmaxwell: | oh sorry, yea, my error there. |
| 02:10:28 | gmaxwell: | (I was reading LIFO) |
| 02:10:49 | amiller: | heh, now that you know what i'm trying to talk about again you may want to tune out :p |
| 02:11:51 | amiller: | okay so the other extreme, which is the main assumption i've been working in for describing nonoutsourceable puzzles, is you reveal as little about any committed informaiton as you possibly can |
| 02:12:16 | amiller: | no merkle root, no nonce, no timestamp, just the prevhash, which seems unavoidable. |
| 02:12:33 | amiller: | okay so this extreme sucks because it breaks P2Pool |
| 02:12:40 | amiller: | throwing the baby out with the bathwater so to speak |
| 02:13:57 | amiller: | that's becuase p2pool works by showing other people your near-miss work shares, and showing that the work you were doing would have paid out to them if you had won. |
| 02:20:18 | amiller: | okay so, |
| 02:20:28 | amiller: | a compromise between those extremes |
| 02:20:42 | amiller: | is to allow the zk proof to reveal more than just the prevhash, |
| 02:21:16 | amiller: | but something that makes adding per-user watermarks harder. |
| 02:21:37 | amiller: | you could allow the zk proof to reveal a p2pool-like shares-chain |
| 02:22:10 | amiller: | since it has to come with some valid work, it wouldn't be possible to freely farm out different ones to different pool members |
| 02:22:23 | amiller: | you'd have to solve a proof-of-work puzzles just to do that! |
| 02:22:53 | fanquake_: | fanquake_ is now known as fanquake |
| 02:35:47 | zooko`: | zooko` is now known as zooko |
| 02:42:47 | amiller: | ugh well, that's the key observation, it might be safe to commit to some informaiton you're oging to later reveal even though the rest is in zk, because at least that thwarts pools easily making different values for every person |
| 02:42:57 | amiller: | i'm having a hard time thinking through how to use that to best effect |
| 02:45:42 | amiller: | the difference between the total hash rate (350M gigahertz) vs a $50 mining device (10Ghz) is still 35 million. It would be impossible to make p2pool parameters such that someone with the 10ghz right wins a 'share' every day... that would be 35M shares and therefore as many txoutputs |
| 02:58:34 | amiller: | p2pool has like 2M GH/s so that's still 300k of the 10GH/s chips.... yet only like 3k p2pool shares are found in a day so still pretty far off, let alone if everyone used p2pool |
| 03:11:26 | zooko: | * zooko has read with interest and with partial comprehension. |
| 03:12:59 | maaku: | maaku is now known as Guest39123 |
| 03:19:20 | amiller: | i duno now i'm having second thoughts about whether this is feasible at even a high level |
| 03:19:40 | amiller: | the harm in pooling comes from letting someone else decide what you work on |
| 03:19:46 | amiller: | it still costs nothing to do that, even if you are solo mining |
| 03:21:52 | amiller: | furthermore if you are committing to prevhash, which i think you must be doing, then a coercer could still bribe you to do work reverting some history |
| 03:27:08 | amiller: | in general, the reason to follow 'soft fork' rules is that majority of miners won't build on your block if you don't |
| 03:27:28 | amiller: | that rule by majority is assumed 'ok' |
| 03:28:33 | amiller: | some subbehavior, like a black list enforced by a few pool operators, is a problem, although if its effective its because its still a majority behavior |
| 03:46:11 | amiller: | so i guess what i want is to make it encouraged to defect from any *small* coalition but still to do what the majority wants |
| 04:03:39 | bosma_: | bosma_ is now known as bosma |
| 08:12:48 | maaku: | maaku is now known as Guest1366 |
| 09:05:18 | 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 |
| 09:05:18 | sinisalo.freenode.net: | Users on #bitcoin-wizards: andy-logbot warren Guest1366 SDCDev jtimon jaekwon_ coiner Emcy hktud0 roconnor Mably flower adam3us moa PaulCapestany TheSeven bosma antgreen justanotheruser fanquake espes__ zooko d1ggy_ berndj gmaxwell orik hashtag melvster Luke-Jr oujh MoALTz_ btcdrak koshii nuke1989 hashtag_ Starduster qwopqwop GAit dc17523be3 execut3 Dr-G2 embicoin p15 Logicwax bedeho Pan0ram1x copumpkin PRab prodatalab OneFixt wizkid057 xabbix grandmaster |
| 09:05:18 | sinisalo.freenode.net: | Users on #bitcoin-wizards: binaryatrocity Adlai hollandais Adrian_G devrandom arubi waxwing alawson Iriez delll__ lechuga_ [d__d] cornus_ammonis null_radix GreenIsMyPepper ebfull elevatio1 starsoccer ryanxcharles grubles dignork Krellan kinlo Cory jessepollak ahmed_ luny Graet ryan-c s1w Eliel veox amiller warptangent indolering huseby tromp K1773R TD-Linux LarsLarsen go1111111 airbreather iddo midnightmagic leakypat mariorz CryptOprah sdaftuar_ Apocalyptic tromp_ |
| 09:05:18 | sinisalo.freenode.net: | Users on #bitcoin-wizards: coryfields Xzibit17 platinuum artifexd epscy_ Muis kumavis dasource guruvan cluckj spinza Anduck brad__ burcin dansmith_btc paperbot sipa fenn dgenr8 jbenet Oizopower mappum harrow Visheate a5m0 SubCreative Zouppen comboy yoleaux forrestv d9b4bef9 weex_ nanotube nsh DoctorBTC bliljerk101 mr_burdell tripleslash NeatBasis Hunger- davout wiz Alanius michagogo cursive PFate yrashk BlueMatt brand0 @ChanServ throughnothing andytoshi helo |
| 09:05:18 | sinisalo.freenode.net: | Users on #bitcoin-wizards: NikolaiToryzin catcow btc___ HM2 azariah MRL-Relay morcos cryptowest gavinandresen gnusha_ Meeh otoburb hguux__ so phedny stonecoldpat roasbeef gwillen isis BrainOverfl0w wumpus nickler phantomcircuit sl01 bobke_ fluffypony dardasaba gribble optimator jcorgan Fistful_of_Coins jaromil cfields Keefe bbrittain petertodd BananaLotus smooth ajweiss JonTitor heath kanzure catlasshrugged pigeons asoltys_ livegnik eric Taek crescendo sneak |
| 09:17:57 | nsh: | om |
| 09:18:05 | nsh: | (oops) |
| 10:43:37 | embicoin_: | embicoin_ is now known as embicoin |
| 10:47:46 | grubles: | grubles is now known as Guest70615 |
| 11:43:44 | wiz_: | wiz_ is now known as wiz |
| 14:04:21 | Guest70615: | Guest70615 is now known as grubles |
| 17:39:24 | fluffypony: | http://blackkettle.org/blog/2015/02/19/youve-got-to-trust-your-vm-host/ |
| 17:39:27 | fluffypony: | great article |
| 18:17:59 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 19:33:55 | Guest1366: | Guest1366 is now known as maaku |
| 19:57:12 | bosma_: | bosma_ is now known as bosma |
| 22:25:26 | jcluck: | jcluck is now known as cluckj |
| 23:29:28 | e_0: | can anyone point me to resources talking about block race engineering to split mining power? I've been searching around bitcointalk, but I'm probably just using the wrong terminology. |
| 23:32:04 | kanzure: | e_0: you may be interested in the term "fork" |
| 23:32:55 | kanzure: | there's also been lots of words written regarding block size influencing block propagation and saturation time |
| 23:35:23 | e_0: | kanzure: I've read a few papers in that area, but I've yet to see any mention of adversarial delaying of blocks for the purposes of causing a fork and splitting the total mining power. |
| 23:43:50 | orik_: | orik_ is now known as orik |
| 23:53:54 | zooko: | I'm not expert, e_0, but I haven't previously thought about that idea in much detail, and it seems like potentially a good attack. |
| 23:54:07 | zooko: | I think I've heard gmaxwell and others talking about similar things. |
| 23:56:32 | kanzure: | also block withholding |
| 23:57:00 | e_0: | I've had conversations about it with people in the past as well, I was just hoping someone wrote it first and I could give them credit. |
| 23:58:16 | e_0: | yeah, two 33% selfish miners cooking off would make for an interesting day in the blockchain. |