00:06:34CodeShark:could we gain anything from rolling back only bad transactions and dependencies but keeping the block for PoW?
00:06:50CodeShark:and for the other unaffected transaction chains
00:07:40CodeShark:so we don't need to do full block reorgs
00:10:08CodeShark:a repudiation mechanism that punishes validators that didn't catch the error and rewards validators that find it :)
00:10:59phantomcircuit:CodeShark, speed of light issues iirc
00:11:02CodeShark:or provers that find it, rather
00:12:02CodeShark:how is speed of light an issue? block propagation time is still far from relativistic timescale
00:13:47CodeShark: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:15CodeShark:the damage to the ledger as a whole would be minimal
00:15:41CodeShark:granted the error is caught sufficiently quickly
00:16:16CodeShark:perhaps it's a stupid idea...just pondering out loud :p
00:16:32phantomcircuit:CodeShark, how does having two blocks at the same height help you in anyway?
00:16:34phantomcircuit:i dont get it
00:16:59CodeShark:no, I think we're talking about different things perhaps
00:17:11CodeShark:you still have a well-ordered block chain
00:17:25CodeShark:presumably with very short side branches
00:18:25CodeShark:the motivation is not requiring full validation to still contribue PoW...but at the cost of risk...or something like that
00:18:57CodeShark:that's to say, reorgs only affect a very small number of transaction chains
00:19:49CodeShark:delegated validation...or blah, I don't know :p
00:20:12CodeShark:nvm...perhaps it doesn't make any sense at all
00:23:48CodeShark: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:59CodeShark:by "reorg" I'm not talking about two blocks competing for the same height
00:25:14CodeShark:I'm talking more generally some invalidation that has occured
00:25:35CodeShark:most difficult chain being surpassed is one such instance
00:31:28CodeShark: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:45CodeShark:because this is what makes reorgs so potentially costly
00:33:24kanzure:well, just wait for more confirmations- this will make the effects almost entirely irrelevant for the vast majority of all reorgs
00:38:50CodeShark:point is the more we can localize reorgs the less of the global history everyone needs to be aware of
00:39:43CodeShark:or rather...what I mean is the the less that the network as a whole is impacted and disrupted
00:53:50CodeShark:any chain invalidation is potentially costly...especially as the number of dependencies grows
00:55:02CodeShark:which makes the structure EXTREMELY brittle
00:56:04CodeShark:eventually we'll need consensus protocols that can be more fork-tolerant, I think ;)
01:09:27CodeShark:I'm also speaking of transaction replacement in mempool and other such instances of invalidation chins
01:10:51justanotherusr:CodeShark: how do you localize a reorg safely?
01:11:51CodeShark:you can start by considering the diffs
01:12:27CodeShark:what contracts remain in place?
01:15:17CodeShark: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:17CodeShark:it's something like a revocation mechanism
01:18:06CodeShark:but revocation or invalidation of a chain isn't necessarily free...it could come at a high cost
01:18:18CodeShark:question really is: who's paying the bill?
01:19:30CodeShark:and will there ultimately be convergence on consensus?
01:21:41CodeShark: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:21justanotherusr:how do you come to consensus on what should be in a reorg without a new consensus mechanism? :)
01:46:15CodeShark:you nuke it
01:46:30CodeShark:basically, "kids, solve it yourselves or lose it all" :p
01:48:21CodeShark:but everyone else's transactions continue to process on cue
01:49:46CodeShark:if there's a fundamental consensus incompatibility, the system is screwed anyway...
01:49:59CodeShark:but at least it could recover gracefully from relatively small glitches
01:50:54CodeShark:it would be nice for it not to be quite so fragile - to be able to support a little more uncertainty
01:54:42CodeShark:and to find ways to contain disputes to be as local as possible
01:57:22justanotherusr:the solution is making a reorg unlikely by waiting
01:57:38CodeShark:from the perspective of an end user, sure
01:58:18CodeShark:from the perspective of a protocol designer that's still a crapload of overhead
01:58:46justanotherusr:Are you proposing there is another solution? I don't see one in the scrollback
01:59:07CodeShark:you can make it possible to invalidate specific transaction chains
02:05:59CodeShark:invalidate by signature, not by censorship :p
02:06:32CodeShark:with a settlement
02:13:21CodeShark:the real solution to RBF seems to be to provide for transaction repudiation
02:14:40CodeShark:the existence of transaction X makes the existence of Y irrelevant
02:15:22CodeShark:so if both get published on the block chain, X wins out...and Y potentially costs the miner money
02:16:29CodeShark:this would allow for deterministic fee updates after-the-fact
02:18:01CodeShark:and ultimately doesn't depend on any particular relay policy
02:20:44CodeShark:or perhaps clever uses of locktime :p
02:21:41CodeShark:nah, the real solution to fees starts by separating the fee as an explicit output :)
02:22:26rusty:rusty has left #bitcoin-wizards
02:25:19moa:it's explicitly the difference between the inputs and the outputs isn't it?
02:26:03CodeShark:yes...but the current structures are horrendous at making this easy to calculate :p
02:27:07CodeShark:also, it's nice to have the local symmetry...the sum of all edges is zero
02:32:22CodeShark:currently, you really do need the whole mempool to make basic fee calculations :p
02:32:32CodeShark:as well as the transactions that anchor it into the blockchain
02:32:56CodeShark:it's stupid, really - lol
02:39:44CodeShark:or perhaps stupid isn't the right adjective - let's say frustrating :)
02:43:08CodeShark:it limits our tools to devices that have at least a certain amount of resources and a decent quality network connection
02:43:54CodeShark:to perform an operation that is practically trivial ;)
02:45:34CodeShark: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:42GGuyZ_:GGuyZ_ is now known as GGuyZ
03:49:34GGuyZ_:GGuyZ_ is now known as GGuyZ
05:51:42Aesthetic:Aesthetic is now known as Logicwax
07:01:15the_last:the_last has left #bitcoin-wizards
08:05:14orwell.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:14orwell.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:14orwell.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:15orwell.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:15orwell.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:15orwell.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:31amiller:the new "Enigma" project from MIT media lab... it's multi-party computation on the blockchain http://enigma.media.mit.edu/
08:45:54amiller:whitepaper [x] scholarly paper [ ] code [ ]
08:47:52amiller: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:01gmaxwell:you can tell by the 'media' in the URL.
08:48:26gmaxwell:amiller: there is a trivial way to compress it down, as discussed here before in the past; dunno what they suggest.
08:49:27gmaxwell:(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:08amiller: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:51:08M-_mis:' "invalidate by signature, not by censorship" —@CodeShark
08:51:51gmaxwell: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:18midnightmagic:lol, DHT rises again
09:10:41amiller:yeah that's the next big problem
09:10:49amiller:there's just a DHT thats assumed to work
09:13:49amiller:another problem is they don't seem to put much thought into protecting your data from colluding nodes
09:14:27amiller:this is from the wired article: "If enough Enigma nodes work together, they can team up to decrypt and steal the user’s data. But that kind of collusion isn’t likely, says Zyskind."
09:15:50amiller: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:34gmaxwell:makes me think of that torcoin paper where they just defined out sybil attacks.
09:17:24CodeShark:if you can't change the theory change the facts :p
09:18:08CodeShark:and pretend like someone's done the math but don't want to bore them with the details if anyone asks
09:19:04CodeShark:decentralization without proper incentives == centralization with a lot of extra headache
09:22:45gmaxwell:sounds like an interesting effort in any case, I've queued it to actually read.
09:34:11nsh:DHT plus secret-sharing plus threshold computation plus blockchain for access and reference
09:34:21nsh:plus a lot of hyperbole
09:35:37amiller: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:32CodeShark:ehm...what can I say...I encourage people to think about these kinds of issues :)
09:38:37amiller:yeah, definitely
09:39:43nsh:it's all grist [and probably unpruneable UTXOs] to the mill
09:55:44CodeShark:oh he's even got Gentry's "Fully homomorphic encryption using ideal lattices." in his biblio :p
09:56:20CodeShark:or they, I should say
09:58:49amiller: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:08bedeho2:bedeho2 is now known as bedeho
10:32:51amiller:"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:18amiller:so, the other academic papers on multiparty computing in Bitcoin, including [22, 23] are way further along
10:34:50amiller: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:43amiller: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:19amiller:but that's exactly the thing that seems (unless we missed something surprising!) to add totally impractical on-chain costs
10:40:07amiller: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:57amiller:all of these feature *off chain multi-party computations*!
10:41:42amiller:and thats a great idea
10:45:31nsh:those last two papers (and talks at simons inst.) were pretty impressive
10:59:54amiller: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:54nsh:was that recorded?
11:02:16amiller:i thought it was. but i can't find it on here http://www.meetup.com/SF-Bitcoin-Devs/events/223291673/
11:05:46nsh:.wik Pebble motion problems
11:05:47yoleaux:"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:17amiller:pebbling is a proof technique in cryptography, it's good for showing that there's no space-time tradeoff in various ways
11:08:02amiller:i guess its always used to show something about time-memory tradeoffs
11:08:20amiller:the hard-to-parallelize ones i think don't use that proof technique
11:10:15nsh:.wik Pebble game
11:10:16yoleaux:"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:32amiller: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:29nsh:and this comes up: High Parallel Complexity Graphs and Memory-Hard Functions -- https://eprint.iacr.org/2014/238.pdf
11:12:56amiller:yup, would you believe that was also a talk at simons isnt. but it went unrecorded
11:18:13nsh:"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:34zveda:zveda has left #bitcoin-wizards
13:30:38nsh:what was the wizardly-wisdom on the darkleaks concept? i seem to recall some theoretical issue with the random reveal scheme maybe
13:30:42nsh:( https://github.com/darkwallet/darkleaks )
13:31:43nsh: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:06nsh: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:18wallet42:wallet42 is now known as Guest48499
14:04:18wallet421:wallet421 is now known as wallet42
14:48:33platinuum_:platinuum_ is now known as platinuum
14:49:49sturles_:sturles_ is now known as sturles
14:50:43btcdrak_:btcdrak_ is now known as btcdrak
14:51:51dasource_:dasource_ is now known as dasource
14:52:46artifexd_:artifexd_ is now known as artifexd
14:54:59yrashk_:yrashk_ is now known as yrashk
14:55:44CryptoGoon_:CryptoGoon_ is now known as CryptoGoon
15:00:05kumavis_:kumavis_ is now known as kumavis
15:03:48mariorz_:mariorz_ is now known as mariorz
15:05:30c0rw1n:c0rw1n is now known as c0rw|away
17:47:09wallet421:wallet421 is now known as wallet42
18:09:29Taek:Is there a good definition for the idea of a 'political entity'?
18:10:00b_lumenkraft_:b_lumenkraft_ is now known as b_lumenkraft
18:10:02Taek:i.e., Google, while composed of 10,000s of people, is generally considered as 1 entity, because everyone acts with united purpose
18:10:47Taek:and so Google owning 51% mining power would be very bad
18:11:20Taek:even if no particular person is controlling more than 20% of the mining rigs within Google
18:12:24Taek: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:08ThinThread:is humanity a (possibly galactic) political entity?
18:13:08Taek:they are 1 entity as far as their cooperation around 8mb blocks is concerned, but beyond that they can be considered separate
18:13:36Taek:I think it depends on what set of goals you are considering
18:14:12ThinThread:i like to focus on our similarities instead of our differences
18:15:22Taek:that's great, but understanding our differences is useful for constructing threat models
19:24:05waxwing:nsh: one issue with that repo was use of ECB mode :)
19:25:41theymos_:theymos_ is now known as theymos
19:27:52waxwing: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:13waxwing:but maybe that's too pessimistic, one could imagine other use cases perhaps
20:08:14LeMiner2:LeMiner2 is now known as LeMiner
20:13:53GGuyZ_:GGuyZ_ is now known as GGuyZ
20:14:02LeMiner2:LeMiner2 is now known as LeMiner
20:32:42petertod1:petertod1 is now known as petertodd
22:11:33lnovy_:lnovy_ is now known as lnovy
22:49:14phantomcircuit_:phantomcircuit_ is now known as phantomcircuit
22:50:13c0rw|away:c0rw|away is now known as c0rw1n
23:28:36c0rw1n:c0rw1n is now known as c0rw|zZz
23:47:52DougieBot5000_:DougieBot5000_ is now known as DougieBot5000