| 00:06:34 | CodeShark: | could we gain anything from rolling back only bad transactions and dependencies but keeping the block for PoW? |
| 00:06:50 | CodeShark: | and for the other unaffected transaction chains |
| 00:07:40 | CodeShark: | so we don't need to do full block reorgs |
| 00:10:08 | CodeShark: | a repudiation mechanism that punishes validators that didn't catch the error and rewards validators that find it :) |
| 00:10:59 | phantomcircuit: | CodeShark, speed of light issues iirc |
| 00:11:02 | CodeShark: | or provers that find it, rather |
| 00:12:02 | CodeShark: | how is speed of light an issue? block propagation time is still far from relativistic timescale |
| 00:13:47 | CodeShark: | the idea is if a particular block propagates, the network could tolerate the case of one or two specific transactions in the block being bad and not being immediately detected |
| 00:14:15 | CodeShark: | the damage to the ledger as a whole would be minimal |
| 00:15:41 | CodeShark: | granted the error is caught sufficiently quickly |
| 00:16:16 | CodeShark: | perhaps it's a stupid idea...just pondering out loud :p |
| 00:16:32 | phantomcircuit: | CodeShark, how does having two blocks at the same height help you in anyway? |
| 00:16:34 | phantomcircuit: | i dont get it |
| 00:16:59 | CodeShark: | no, I think we're talking about different things perhaps |
| 00:17:11 | CodeShark: | you still have a well-ordered block chain |
| 00:17:25 | CodeShark: | presumably with very short side branches |
| 00:18:25 | CodeShark: | the motivation is not requiring full validation to still contribue PoW...but at the cost of risk...or something like that |
| 00:18:57 | CodeShark: | that's to say, reorgs only affect a very small number of transaction chains |
| 00:19:49 | CodeShark: | delegated validation...or blah, I don't know :p |
| 00:20:12 | CodeShark: | nvm...perhaps it doesn't make any sense at all |
| 00:23:48 | CodeShark: | I guess at a more fundamental level, I'm talking about adding a little more fault tolerance to validation with economic levers that strongly incentivize cooperation |
| 00:24:59 | CodeShark: | by "reorg" I'm not talking about two blocks competing for the same height |
| 00:25:14 | CodeShark: | I'm talking more generally some invalidation that has occured |
| 00:25:35 | CodeShark: | most difficult chain being surpassed is one such instance |
| 00:31:28 | CodeShark: | from a structural perspective it would be nice if the effects of chain invalidation (at whatever level of abstraction) could be isolated and made not to affect much of the global transaction settlement |
| 00:31:45 | CodeShark: | because this is what makes reorgs so potentially costly |
| 00:33:24 | kanzure: | well, just wait for more confirmations- this will make the effects almost entirely irrelevant for the vast majority of all reorgs |
| 00:38:50 | CodeShark: | point is the more we can localize reorgs the less of the global history everyone needs to be aware of |
| 00:39:43 | CodeShark: | or rather...what I mean is the the less that the network as a whole is impacted and disrupted |
| 00:53:50 | CodeShark: | any chain invalidation is potentially costly...especially as the number of dependencies grows |
| 00:55:02 | CodeShark: | which makes the structure EXTREMELY brittle |
| 00:56:04 | CodeShark: | eventually we'll need consensus protocols that can be more fork-tolerant, I think ;) |
| 01:09:27 | CodeShark: | I'm also speaking of transaction replacement in mempool and other such instances of invalidation chins |
| 01:09:29 | CodeShark: | *chains |
| 01:10:51 | justanotherusr: | CodeShark: how do you localize a reorg safely? |
| 01:11:51 | CodeShark: | you can start by considering the diffs |
| 01:12:27 | CodeShark: | what contracts remain in place? |
| 01:15:17 | CodeShark: | if only a relatively small portion of the network is affected by a change, perhaps it isn't necessary to make it matter at all to people who don't care about those differences |
| 01:16:17 | CodeShark: | it's something like a revocation mechanism |
| 01:18:06 | CodeShark: | but revocation or invalidation of a chain isn't necessarily free...it could come at a high cost |
| 01:18:18 | CodeShark: | question really is: who's paying the bill? |
| 01:19:30 | CodeShark: | and will there ultimately be convergence on consensus? |
| 01:21:41 | CodeShark: | any such mechanism inherently carries risks...but if we can quantify the risks and allocate them algorithmically I think we're doing great :) |
| 01:42:21 | justanotherusr: | how do you come to consensus on what should be in a reorg without a new consensus mechanism? :) |
| 01:46:15 | CodeShark: | you nuke it |
| 01:46:30 | CodeShark: | basically, "kids, solve it yourselves or lose it all" :p |
| 01:48:21 | CodeShark: | but everyone else's transactions continue to process on cue |
| 01:49:46 | CodeShark: | if there's a fundamental consensus incompatibility, the system is screwed anyway... |
| 01:49:59 | CodeShark: | but at least it could recover gracefully from relatively small glitches |
| 01:50:54 | CodeShark: | it would be nice for it not to be quite so fragile - to be able to support a little more uncertainty |
| 01:54:42 | CodeShark: | and to find ways to contain disputes to be as local as possible |
| 01:57:22 | justanotherusr: | the solution is making a reorg unlikely by waiting |
| 01:57:38 | CodeShark: | from the perspective of an end user, sure |
| 01:58:18 | CodeShark: | from the perspective of a protocol designer that's still a crapload of overhead |
| 01:58:46 | justanotherusr: | Are you proposing there is another solution? I don't see one in the scrollback |
| 01:59:07 | CodeShark: | you can make it possible to invalidate specific transaction chains |
| 02:05:59 | CodeShark: | invalidate by signature, not by censorship :p |
| 02:06:32 | CodeShark: | with a settlement |
| 02:13:21 | CodeShark: | the real solution to RBF seems to be to provide for transaction repudiation |
| 02:14:40 | CodeShark: | the existence of transaction X makes the existence of Y irrelevant |
| 02:15:22 | CodeShark: | so if both get published on the block chain, X wins out...and Y potentially costs the miner money |
| 02:16:29 | CodeShark: | this would allow for deterministic fee updates after-the-fact |
| 02:18:01 | CodeShark: | and ultimately doesn't depend on any particular relay policy |
| 02:20:44 | CodeShark: | or perhaps clever uses of locktime :p |
| 02:21:41 | CodeShark: | nah, the real solution to fees starts by separating the fee as an explicit output :) |
| 02:22:26 | rusty: | rusty has left #bitcoin-wizards |
| 02:25:19 | moa: | it's explicitly the difference between the inputs and the outputs isn't it? |
| 02:26:03 | CodeShark: | yes...but the current structures are horrendous at making this easy to calculate :p |
| 02:27:07 | CodeShark: | also, it's nice to have the local symmetry...the sum of all edges is zero |
| 02:32:22 | CodeShark: | currently, you really do need the whole mempool to make basic fee calculations :p |
| 02:32:32 | CodeShark: | as well as the transactions that anchor it into the blockchain |
| 02:32:56 | CodeShark: | it's stupid, really - lol |
| 02:39:44 | CodeShark: | or perhaps stupid isn't the right adjective - let's say frustrating :) |
| 02:43:08 | CodeShark: | it limits our tools to devices that have at least a certain amount of resources and a decent quality network connection |
| 02:43:54 | CodeShark: | to perform an operation that is practically trivial ;) |
| 02:45:34 | CodeShark: | or, of course, it breaks our trust model (I sometimes wonder whether people in this space really care about this one anymore, though) |
| 03:19:42 | GGuyZ_: | GGuyZ_ is now known as GGuyZ |
| 03:49:34 | GGuyZ_: | GGuyZ_ is now known as GGuyZ |
| 05:51:42 | Aesthetic: | Aesthetic is now known as Logicwax |
| 07:01:15 | the_last: | the_last has left #bitcoin-wizards |
| 08:05:14 | orwell.freenode.net: | topic is: This channel is is for discussing theoretical ideas with regard to cryptocurrencies, 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 | orwell.freenode.net: | Users on #bitcoin-wizards: andy-logbot Starduster wallet42 mountaingoat Mably fanquake damethos ThomasV chmod755 zooko huseby d1ggy_ Logicwax airbreather espes__ alawson EasyAt TheSeven ttttemp p15x gielbier warptangent helo Dr-G2 copumpkin [d__d] petertod1 guruvan humd1ng3r otoburb Tiraspol moa ebfull CodeArtix akrmn MoALTz__ spinza roybadami jmcn justanotherusr tromp_ frenchie1 PaulCapestany sparetire_ CodeShark Tebbo Guest27737 SubCreative MatrixBridge2401 Alanius |
| 08:05:14 | orwell.freenode.net: | Users on #bitcoin-wizards: cdecker SDCDev melvster hashtag MatrixBridge MrTratta LeMiner fkhan berndj gregeh Emcy_ bedeho2 mkarrer se3000 Luke-Jr dc17523be3 Taek gribble Tenhi HM goregrind isis alferz qawap BigBitz superobserver Iriez sundance leakypat wiz binaryatrocity OneFixt sneak gmaxwell amiller thrasher` btcdrak SwedFTP bosma c0rw1n nsh AlexStraunoff Graet veox UllrSkis K1773R sparetire luny mengine devrandom sdaftuar narwh4l adam3us badmofo Madars waxwing lnovy |
| 08:05:15 | orwell.freenode.net: | Users on #bitcoin-wizards: MRL-Relay theymos stonecoldpat epscy dgenr8 pollux-bts Jaamg rustyn forrestv gnusha Cory tucenaber bliljerk101 elastoma ThinThread jonasschnelli null_radix catcow adams__ rasengan cfields phantomcircuit kanzure TD-Linux richardus sl01 michagogo kinlo nephyrin` Krellan vonzipper larraboj_ mariorz coryfields_ optimator stevenroose BlueMatt eric afdudley ryan-c crescendo prosodyContext mappum nickler_ jbenet kyuupichan livegnik pigeons davout |
| 08:05:15 | orwell.freenode.net: | Users on #bitcoin-wizards: Fistful_of_Coins mikolalysenko fluffypony BananaLotus scoria andytoshi STRML jouke jaromil fenn nanotube mr_burdell indolering BrainOverfl0w [ace] catlasshrugged throughnothing poggy dignork yoleaux gavinandresen Anduck grubles heath roasbeef ggreer starsoccer Muis Xzibit17 comboy wumpus a5m0 jessepollak dansmith_ sturles midnightmagic merlincorey warren azariah_ jrayhawk Meeh_ mm_1 koshii _whitelogger dasource jcorgan bsm117532 gwillen lclc |
| 08:05:15 | orwell.freenode.net: | Users on #bitcoin-wizards: wizkid057 ajweiss so @ChanServ AdrianG morcos xabbix Eliel brand0 harrigan harrow weex smooth iddo Apocalyptic platinuum kumavis runeks artifexd CryptoGoon yrashk s1w |
| 08:45:31 | amiller: | the new "Enigma" project from MIT media lab... it's multi-party computation on the blockchain http://enigma.media.mit.edu/ |
| 08:45:54 | amiller: | whitepaper [x] scholarly paper [ ] code [ ] |
| 08:47:52 | amiller: | i can't figure it out: are they just proposing to put the entire transcript of a generic multi-party computation on the blockchain? or is there some fancy way of compressing that down |
| 08:48:01 | gmaxwell: | you can tell by the 'media' in the URL. |
| 08:48:26 | gmaxwell: | amiller: there is a trivial way to compress it down, as discussed here before in the past; dunno what they suggest. |
| 08:49:27 | gmaxwell: | (any turn based MPC you have the players sign off at each step with a state commitment, so you can truncate the transcript.. if they complete and all sign the final step, you can just elide the whole transcript) |
| 08:50:08 | amiller: | gmaxwell, ok i know what you mean - they're claiming this defends against users/clients/public against ALL of the MPC nodes going bad |
| 08:50:26 | amiller: | but |
| 08:51:08 | M-_mis: | ' "invalidate by signature, not by censorship" —@CodeShark |
| 08:51:51 | gmaxwell: | uhh. not sure how that works unless the MPC is active secure and produces ZKPs as a side effect (many active secure ideas are just passive secure plus a ZKP, so thats not far fetched). |
| 09:06:18 | midnightmagic: | lol, DHT rises again |
| 09:10:41 | amiller: | yeah that's the next big problem |
| 09:10:49 | amiller: | there's just a DHT thats assumed to work |
| 09:13:49 | amiller: | another problem is they don't seem to put much thought into protecting your data from colluding nodes |
| 09:14:27 | amiller: | this is from the wired article: "If enough Enigma nodes work together, they can team up to decrypt and steal the users data. But that kind of collusion isnt likely, says Zyskind." |
| 09:15:01 | gmaxwell: | :-/ |
| 09:15:50 | amiller: | but section 5.3 "network reduction" actually makes that much worse: "a random subset of the entire network is selected to perform a computation" |
| 09:16:34 | gmaxwell: | makes me think of that torcoin paper where they just defined out sybil attacks. |
| 09:17:24 | CodeShark: | if you can't change the theory change the facts :p |
| 09:18:08 | CodeShark: | and pretend like someone's done the math but don't want to bore them with the details if anyone asks |
| 09:19:04 | CodeShark: | decentralization without proper incentives == centralization with a lot of extra headache |
| 09:22:45 | gmaxwell: | sounds like an interesting effort in any case, I've queued it to actually read. |
| 09:34:11 | nsh: | DHT plus secret-sharing plus threshold computation plus blockchain for access and reference |
| 09:34:21 | nsh: | plus a lot of hyperbole |
| 09:35:37 | amiller: | they have a peer-reviewed workshop paper (paper) http://web.media.mit.edu/~guyzys/data/ZNP15.pdf (slides) http://ieee-security.org/TC/SPW2015/IWPE/5.pdf |
| 09:36:32 | CodeShark: | ehm...what can I say...I encourage people to think about these kinds of issues :) |
| 09:38:37 | amiller: | yeah, definitely |
| 09:39:43 | nsh: | it's all grist [and probably unpruneable UTXOs] to the mill |
| 09:55:44 | CodeShark: | oh he's even got Gentry's "Fully homomorphic encryption using ideal lattices." in his biblio :p |
| 09:56:20 | CodeShark: | or they, I should say |
| 09:58:49 | amiller: | that's fine, it doesn't overstate anything about FHE... although the wired article makes it seem like FHE is what they're doing :) |
| 10:18:08 | bedeho2: | bedeho2 is now known as bedeho |
| 10:32:51 | amiller: | "Using Bitcoin security deposits for punishing malicious nodes in MPC has been investigated by several scholars recently [22, 23]. We use a similar model, and extend it to penalize other malicious behaviors such as breaking correctness" |
| 10:33:18 | amiller: | so, the other academic papers on multiparty computing in Bitcoin, including [22, 23] are way further along |
| 10:34:50 | amiller: | these are peer reviewed a lot more strictly... viciously might be the best word... in the most selective conferences like Crypto and Oakland |
| 10:36:43 | amiller: | the main novelty Enigma is claiming compared to those is enforcing correctness even if a majority of the nodes in a computation are corrupted |
| 10:37:19 | amiller: | but that's exactly the thing that seems (unless we missed something surprising!) to add totally impractical on-chain costs |
| 10:40:07 | amiller: | they forgot a subsequent CCS paper (another elite conference) by authors of [22] http://people.csail.mit.edu/ranjit/papers/incentives.pdf and a new preprint by other authors http://eprint.iacr.org/2015/574 |
| 10:40:57 | amiller: | all of these feature *off chain multi-party computations*! |
| 10:41:42 | amiller: | and thats a great idea |
| 10:45:31 | nsh: | those last two papers (and talks at simons inst.) were pretty impressive |
| 10:59:54 | amiller: | speaking of which... the "spacecoin" author also visited simons inst. i appreciate the spacecoin paper way more now after watching its author bash with bramc at the sf bitcoin dev meetup |
| 11:00:54 | nsh: | was that recorded? |
| 11:02:16 | amiller: | i thought it was. but i can't find it on here http://www.meetup.com/SF-Bitcoin-Devs/events/223291673/ |
| 11:02:37 | nsh: | ah |
| 11:05:46 | nsh: | .wik Pebble motion problems |
| 11:05:47 | yoleaux: | "The pebble motion problems, or pebble motion on graphs, are a set of related problems in graph theory dealing with the movement of multiple objects ("pebbles") from vertex to vertex in a graph with a constraint on the number of pebbles that can occupy a vertex at any time. Pebble motion problems occur in domains such as multi-robot motion …" — https://en.wikipedia.org/wiki/Pebble_motion_problems |
| 11:07:17 | amiller: | pebbling is a proof technique in cryptography, it's good for showing that there's no space-time tradeoff in various ways |
| 11:08:02 | amiller: | i guess its always used to show something about time-memory tradeoffs |
| 11:08:20 | amiller: | the hard-to-parallelize ones i think don't use that proof technique |
| 11:09:22 | nsh: | ah |
| 11:10:15 | nsh: | .wik Pebble game |
| 11:10:16 | yoleaux: | "In mathematics and computer science, a pebble game is a type of mathematical game played by moving "pebbles" or "markers" on a directed graph. A variety of different pebble games exist. A general definition of pebbling is given below." — https://en.wikipedia.org/wiki/Pebble_game |
| 11:11:32 | amiller: | here's i think the first one to do that http://www.cs.columbia.edu/~hoeteck/pubs/pebble-crypto05.pdf to do that |
| 11:12:29 | nsh: | and this comes up: High Parallel Complexity Graphs and Memory-Hard Functions -- https://eprint.iacr.org/2014/238.pdf |
| 11:12:56 | amiller: | yup, would you believe that was also a talk at simons isnt. but it went unrecorded |
| 11:13:20 | nsh: | shame |
| 11:18:13 | nsh: | "Commonly G describes the dependencies between inputs, intermediate values and the outputs involved in computing f_G." # interesting. i wonder what a pebbling of a hash collision looks like |
| 13:30:34 | zveda: | zveda has left #bitcoin-wizards |
| 13:30:38 | nsh: | what was the wizardly-wisdom on the darkleaks concept? i seem to recall some theoretical issue with the random reveal scheme maybe |
| 13:30:42 | nsh: | ( https://github.com/darkwallet/darkleaks ) |
| 13:31:43 | nsh: | wow, google sure updates the logs for this channel with gusto... 20s after writing that line it was a result in a search. |
| 13:33:06 | nsh: | ah, found " though sadly the utility is kind of narrow. The class of information where a random sample doesn't stand a risk of giving away all the value, and where the value can't be sapped by a few careful redactions which sampling is unlikely to reveal (even if it hits them, you can't tell what was missing), I think is not so broad." -- gmax |
| 14:04:18 | wallet42: | wallet42 is now known as Guest48499 |
| 14:04:18 | wallet421: | wallet421 is now known as wallet42 |
| 14:48:33 | platinuum_: | platinuum_ is now known as platinuum |
| 14:49:49 | sturles_: | sturles_ is now known as sturles |
| 14:50:43 | btcdrak_: | btcdrak_ is now known as btcdrak |
| 14:51:51 | dasource_: | dasource_ is now known as dasource |
| 14:52:46 | artifexd_: | artifexd_ is now known as artifexd |
| 14:54:59 | yrashk_: | yrashk_ is now known as yrashk |
| 14:55:44 | CryptoGoon_: | CryptoGoon_ is now known as CryptoGoon |
| 15:00:05 | kumavis_: | kumavis_ is now known as kumavis |
| 15:03:48 | mariorz_: | mariorz_ is now known as mariorz |
| 15:05:30 | c0rw1n: | c0rw1n is now known as c0rw|away |
| 17:47:09 | wallet421: | wallet421 is now known as wallet42 |
| 18:09:29 | Taek: | Is there a good definition for the idea of a 'political entity'? |
| 18:10:00 | b_lumenkraft_: | b_lumenkraft_ is now known as b_lumenkraft |
| 18:10:02 | Taek: | i.e., Google, while composed of 10,000s of people, is generally considered as 1 entity, because everyone acts with united purpose |
| 18:10:47 | Taek: | and so Google owning 51% mining power would be very bad |
| 18:11:20 | Taek: | even if no particular person is controlling more than 20% of the mining rigs within Google |
| 18:12:24 | Taek: | something like the coalition of mining pools in China wouldn't necessarily be considered 1 political entity though, because their common goals are under very constrained terms |
| 18:13:08 | ThinThread: | is humanity a (possibly galactic) political entity? |
| 18:13:08 | Taek: | they are 1 entity as far as their cooperation around 8mb blocks is concerned, but beyond that they can be considered separate |
| 18:13:36 | Taek: | I think it depends on what set of goals you are considering |
| 18:14:12 | ThinThread: | i like to focus on our similarities instead of our differences |
| 18:15:22 | Taek: | that's great, but understanding our differences is useful for constructing threat models |
| 19:24:05 | waxwing: | nsh: one issue with that repo was use of ECB mode :) |
| 19:24:39 | nsh: | darkleaks? |
| 19:24:45 | waxwing: | yeah |
| 19:24:53 | nsh: | :/ |
| 19:25:41 | theymos_: | theymos_ is now known as theymos |
| 19:27:52 | waxwing: | the kind of issue you mention in the quote above, yeah that's an issue. the most obvious application, given that limitation, seems like the most depressing: password database leaks |
| 19:28:13 | waxwing: | but maybe that's too pessimistic, one could imagine other use cases perhaps |
| 20:08:14 | LeMiner2: | LeMiner2 is now known as LeMiner |
| 20:13:53 | GGuyZ_: | GGuyZ_ is now known as GGuyZ |
| 20:14:02 | LeMiner2: | LeMiner2 is now known as LeMiner |
| 20:32:42 | petertod1: | petertod1 is now known as petertodd |
| 22:11:33 | lnovy_: | lnovy_ is now known as lnovy |
| 22:49:14 | phantomcircuit_: | phantomcircuit_ is now known as phantomcircuit |
| 22:50:13 | c0rw|away: | c0rw|away is now known as c0rw1n |
| 23:28:36 | c0rw1n: | c0rw1n is now known as c0rw|zZz |
| 23:47:52 | DougieBot5000_: | DougieBot5000_ is now known as DougieBot5000 |