| 02:42:19 | kanzure: | recreational reading http://www.scottaaronson.com/writings/bignumbers.html |
| 02:44:06 | nsh: | *skips to end, adds one, declares victory* |
| 02:44:57 | nsh: | for extra credit, think deeply about that 'whoever had the deeper paradigm' then read godels paper on the lengths of proofs |
| 02:45:13 | nsh: | (i have attempted this exercise about six times and not made it to the end of the paper) |
| 02:45:40 | kanzure: | nah i will just read chaitin and pretend |
| 02:46:32 | nsh: | have to pretend pretty hard to out-chaitin chaitin |
| 02:52:25 | tromp_: | i tried as much in my paper http://tromp.github.io/cl/LC.pdf |
| 02:52:51 | tromp_: | "our program is less than a quarter the size of Chaitin's when measured in bits." |
| 02:53:27 | tromp_: | in a proof of one side of Symmetry of information |
| 02:53:27 | nsh: | oh, neat |
| 02:54:23 | nsh: | i should try and mash that paper with the weird freaky stuff someone is going with graph theory and sinful programmatic generation of parsers and other things that make me not want to think about it too hard |
| 02:54:28 | nsh: | *doing |
| 02:55:23 | kanzure: | tromp_: so is this channel secretly the leibniz fan club or what |
| 02:55:46 | nsh: | ixnay on the eibnizlay! |
| 02:56:02 | tromp_: | count me in:) |
| 02:56:18 | nsh: | tromp_, do you end up with actual manageable godel numbers with your scheme? |
| 02:56:40 | tromp_: | my godel numbers are simly binary encoded lambda terms |
| 02:56:55 | tromp_: | and as such more manageable |
| 02:57:00 | nsh: | interesting |
| 02:57:19 | tromp_: | see http://www.ioccc.org/2012/tromp/hint.html for some sample programs |
| 02:57:35 | nsh: | i had a very esoteric idea about the security of hash functions in terms of what happens if you try to use hashes as proxies of full godel encodings |
| 02:57:40 | nsh: | and see what the algebraic results are |
| 02:57:51 | nsh: | but it's probably too left-field to actually lead anywhere |
| 02:58:16 | tromp_: | what do you mean by proxies in that context? |
| 02:58:29 | kanzure: | yeah and why would you pick one hash function over another in that context |
| 02:59:05 | nsh: | mmm |
| 02:59:28 | nsh: | so godel encoding puts all possible formulations into correspondence with the integers |
| 02:59:31 | tromp_: | the whole point of godel encoding is that you can decode it; which you cannot with hashes:( |
| 02:59:39 | nsh: | hashing would put them into correspondence with a smaller set of integers |
| 02:59:42 | nsh: | (with collisions) |
| 02:59:48 | nsh: | those collisions should then have algebraic properties |
| 02:59:52 | nsh: | which relate to the hash function itself |
| 02:59:53 | gmaxwell: | kanzure: I'm kinda disappointed that I had his answer at the start. |
| 02:59:55 | nsh: | and its security |
| 03:00:53 | nsh: | (so which equivalence class of formulas is related by collisions in the hash should have some meaning, but beyond that i can't imagine) |
| 03:01:14 | nsh: | it's also relative to your encoding choices though, which may be hard to disentangle |
| 03:02:34 | Taek: | I would have used Graham's number notation; g(g(g(...g64)))... |
| 03:04:03 | gmaxwell: | really the answer is just a test for what classes of function you know about. |
| 03:04:06 | tromp_: | i like Goodstein sequences |
| 03:04:28 | tromp_: | kind of miraculous how they converge |
| 03:04:38 | tromp_: | against all odds |
| 03:05:01 | tromp_: | https://en.wikipedia.org/wiki/Goodstein%27s_theorem#Goodstein_sequences |
| 03:05:15 | kanzure: | .wik goldstein's theorem |
| 03:05:15 | yoleaux: | "In mathematical logic, Goodstein's theorem is a statement about the natural numbers, proved by Reuben Goodstein in 1944, which states that every Goodstein sequence eventually terminates at 0. Kirby and Paris showed that it is unprovable in Peano arithmetic (but it can be proven in stronger systems, such as second order arithmetic)." — http://en.wikipedia.org/wiki/Goldstein%27s_theorem |
| 03:05:51 | nsh: | * nsh nods |
| 03:06:18 | tromp_: | funny how you get the right entry despite mis-spelling his name:) |
| 03:07:52 | gmaxwell: | I like out the WP article uses ackermann numbers to abbrivate the larger entries. |
| 03:08:33 | nsh: | google helps with that (thankfully, because mediawiki search was always... hit and miss) |
| 03:10:11 | Pasha: | Pasha is now known as Cory |
| 03:25:53 | zooko: | w |
| 03:35:24 | zooko: | oops. |
| 04:14:13 | maaku: | anyone here know or can recommend a technical writer? |
| 04:15:18 | nsh: | what kind of technicals? |
| 04:16:58 | maaku: | wizardly bitcoin proposals and such |
| 04:17:49 | maaku: | someone who can grok the kinds of things discussed here relatively quickly and then write both documentation and stuff for public consumption |
| 04:23:41 | kanzure: | maaku: eric hunting would be pretty great for that |
| 04:27:51 | maaku: | kanzure: this one? https://www.linkedin.com/pub/eric-hunting/1a/61/9b2 |
| 04:29:55 | kanzure: | that profile is quite betraying to him... i should bug him about that. |
| 04:30:19 | maaku: | thanks for the reference I'll pass it along. if you have a better profile that would help |
| 04:36:25 | PRab__: | PRab__ is now known as PRab |
| 05:47:33 | sipa: | amiller: tss, hiw dare you misremember the date of 'the future' |
| 05:47:37 | sipa: | *how |
| 05:50:47 | amiller: | :o |
| 06:08:28 | phantomcircuit: | petertodd, im sure this has been answered before, but.... can you use the contracthash stuff to embed the stealth address parameters in the signature? |
| 06:08:53 | phantomcircuit: | oh nvm |
| 06:09:01 | phantomcircuit: | that's got out of band reqs also |
| 06:09:03 | phantomcircuit: | ignore me |
| 06:09:39 | siraj__: | siraj__ has left #bitcoin-wizards |
| 06:51:56 | lclc_bnc: | lclc_bnc is now known as lclc |
| 06:53:30 | justanotheruser: | justanotheruser is now known as bareenannenbruke |
| 08:20:48 | lclc: | lclc is now known as lclc_bnc |
| 08:21:16 | petertodd: | Ok, I think I came with the best name ever for anti-replay/anti-doublespend single-use-seals: Lazy Commitments. |
| 08:21:38 | petertodd: | Basically, like a normal commitment you commit to a value in advance. However because you haven't actually figured out what the value is yet, you do it lazily. |
| 08:24:03 | nsh: | heh |
| 08:24:52 | nsh: | how do you commit to an un{known|evaluated} value? |
| 08:25:07 | petertodd: | A binary tree of lazy commitments naturally leads to a Lazy Set Commitment: you commit to a set, and when you figure out what should actually be in the set you gradually populate branches of the tree. |
| 08:25:18 | petertodd: | nsh: with bitcoin! (or trust) |
| 08:25:23 | petertodd: | nsh: your homework: figure out how |
| 08:26:30 | nsh: | hrm |
| 08:32:09 | petertodd: | @encthenet came up with a good one: "Schrödinger's commitment scheme: you commit to a value, but you don't know what it is still the big reveal." |
| 08:34:46 | petertodd: | and... that's actually what PayPub/Darkleaks does! the commitment is to use use the blockchain as a random beacon, and you don't know what the value will be until later! |
| 08:37:03 | nsh: | wait |
| 08:37:07 | nsh: | this solves timelock |
| 08:37:12 | petertodd: | ? |
| 08:37:43 | nsh: | timelock encryption. if can encrypt content so that it can only be decrypted with certain coin-spends |
| 08:37:56 | nsh: | then you can do that to m_timelock'd inputs and solve timelock encryption |
| 08:38:05 | nsh: | or am i missing things |
| 08:38:41 | phantomcircuit: | nsh, timelock stuff is mostly not useful for these things because they're expensive to validate that there isn't a solution |
| 08:39:01 | petertodd: | lolol! the problem is your Schrödinger commitment scheme needs to have the operation to derive a pubkey now from the secret key to be revealed later - blockchain as random beacon doesn't support that operation |
| 08:39:12 | nsh: | 'Files are split into segments and encrypted. These segments are unlocked only when the leaker reveals the key by claiming his Bitcoins.' from darkleaks coverage |
| 08:39:45 | nsh: | probably reading too much into that |
| 08:41:36 | nsh: | well, it should try harder :) |
| 08:42:30 | petertodd: | nsh: ah, but see, there's a step where you commit to revealing part of the leak in advance, and that part is determiend by what the blockchain hash will be some time in the future |
| 08:43:04 | nsh: | oh, hmm |
| 08:44:10 | nsh: | ah, i get it |
| 08:44:21 | nsh: | that's clever |
| 08:45:00 | nsh: | devilish even :) |
| 08:49:05 | nsh: | should be able to use this to bootstrap a pretty interesting class of interactive games too |
| 08:49:11 | nsh: | and protocols |
| 08:50:39 | petertodd: | for sure |
| 08:58:23 | lclc_bnc: | lclc_bnc is now known as lclc |
| 09:05:18 | cameron.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 | cameron.freenode.net: | Users on #bitcoin-wizards: andy-logbot btcdrak SDCDev CoinMuncher Mably rusty hashtag_ hashtag ielo oujh orik p15_ justanotheruser hktud0 Starduster devrandom d1ggy kinlo paveljanik TheSeven koeppelmann PRab copumpkin moa linelevel cornusammonis Cory Dr-G2 fanquake alawson adam3us1 Emcy delll_ Adlai droark nuke1989 shesek jessepollak ahmed_ Luke-Jr luny arubi flower Graet ryan-c s1w Eliel veox amiller warptangent indolering huseby tromp K1773R GAit elevation TD-Linux |
| 09:05:18 | cameron.freenode.net: | Users on #bitcoin-wizards: Logicwax LarsLarsen go1111111 airbreather iddo lechuga_ prodatalab Pan0ram1x midnightmagic leakypat jgarzik maaku waxwing mariorz antgreen CryptOprah sdaftuar_ Apocalyptic tromp_ jaekwon coryfields Xzibit17 platinuum artifexd epscy_ Muis kumavis dasource bosma guruvan c0rw1n cluckj spinza Anduck binaryatrocity bedeho brad__ gmaxwell burcin dansmith_btc paperbot dc17523be3 sipa melvster grandmaster fenn espes__ dgenr8 PaulCapestany jbenet |
| 09:05:18 | cameron.freenode.net: | Users on #bitcoin-wizards: Oizopower mappum harrow Visheate a5m0 sneak crescendo Taek eric livegnik asoltys_ pigeons catlasshrugged kanzure heath JonTitor ajweiss smooth BananaLotus petertodd bbrittain Keefe cfields jaromil Fistful_of_Coins jcorgan optimator gribble warren dardasaba fluffypony bobke_ earlz sl01 phantomcircuit Iriez nickler wumpus BrainOverfl0w isis gwillen roasbeef stonecoldpat phedny so wizkid057 hguux__ otoburb lclc qwopqwop Meeh gnusha_ gavinandresen |
| 09:05:18 | cameron.freenode.net: | Users on #bitcoin-wizards: cryptowest morcos MRL-Relay null_radix Krellan azariah berndj HM2 btc___ catcow NikolaiToryzin helo andytoshi throughnothing Adrian_G @ChanServ brand0 BlueMatt yrashk PFate cursive michagogo Alanius wiz davout Hunger- [d__d] NeatBasis tripleslash mr_burdell bliljerk101 DoctorBTC nsh nanotube weex_ d9b4bef9 deego lnovy MoALTz forrestv yoleaux comboy Zouppen SubCreative hollandais |
| 09:31:43 | gmaxwell: | nsh: yea, 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. |
| 09:32:13 | nsh: | hmm, perhaps |
| 09:33:19 | gmaxwell: | I'd talked before in here a while back on doing the same trick with images (sampling over pixels) to construct very low res versions.... it might work better for that. |
| 09:41:20 | petertodd: | gmaxwell: oh damn, why didn't I already think of that images trick? |
| 09:41:28 | petertodd: | gmaxwell: could do the same thing with audio too I bet |
| 09:42:51 | petertodd: | gmaxwell: a_d fo_ t_at m__ter w__h te__ doc___n_s li__ b__ks __d _epor__ |
| 09:43:03 | petertodd: | gmaxwell: (maybe not that last one) |
| 09:44:06 | petertodd: | you know, the class of information where sampling doesn't risk "giving it all away" is actually most strongly the obvious one: artistic works |
| 09:48:33 | nsh: | maybe you can apply a holographic transformation to a file so that any revealed segment attests to the well-distributedness of the original information throughout the whole |
| 09:48:49 | nsh: | that seems more dubious after articulation :/ |
| 09:49:53 | gmaxwell: | petertodd: there is a long description of the image version in here a while back (including where I pointed out that you can use signal processing from compressed sensing to construct a good image from a random sample) |
| 09:49:59 | gmaxwell: | maybe a year or so ago? |
| 09:51:16 | nsh: | actually, it's not so dubious. you can oversample the bits of the original and then do fourier transform |
| 09:51:21 | petertodd: | gmaxwell: yeah, pretty obvious idea in hind sight |
| 09:51:27 | nsh: | but whether or not that could be faked is more open |
| 09:52:06 | nsh: | oh, something vaguely like this exists even: http://en.wikipedia.org/wiki/Holographic_algorithm |
| 09:52:11 | gmaxwell: | nsh: you can always fake it, alas, e.g. the 'original' may be low resolution in reality. |
| 09:52:17 | nsh: | * nsh nods |
| 09:52:50 | nsh: | perhaps you can commit to the total 'sum resolution' separately somehow |
| 09:52:55 | petertodd: | gmaxwell: make the sampling be a combination of randomly distributed points, and a randomly chosen chunk |
| 09:53:38 | petertodd: | gmaxwell: or really, the density of points randomly sampled should itself be random over the picture |
| 09:54:35 | gmaxwell: | random alone achieves that, but the problem is that it can be very hard to tell if it wasn't crapped up just by downsampling and then adding noise based on the lower res image. |
| 09:54:36 | nsh: | hrmm |
| 09:54:55 | nsh: | that seems like an improvement |
| 09:55:20 | petertodd: | gmaxwell: right, but if you have some of the image being high density points, or 100% reveal, that noise will be revealed |
| 09:55:52 | petertodd: | gmaxwell: equally, if every additinal bit of data revealed incrementally reveales more detail, at least the revenue stops when the fraud is revealed |
| 09:56:00 | nsh: | i think you can bound the difference in quality against likelihood of detection |
| 09:56:18 | petertodd: | nsh: probably |
| 10:12:21 | nsh: | -- |
| 10:12:22 | nsh: | The idea of timestamping information is actually centuries old. For example, when Robert Hooke discovered Hooke's law in 1660, he did not want to publish it yet, but wanted to be able to claim priority. So he published the anagram ceiiinosssttuv and later published the translation ut tensio sic vis (Latin for "as is the extension, so is the force"). Similarly, Galileo first published his discovery of the phases of Venus in the anagram form. |
| 10:12:25 | nsh: | -- http://en.wikipedia.org/wiki/Trusted_timestamping |
| 10:12:26 | nsh: | (TIL) |
| 10:14:29 | Zouppen: | cool |
| 10:16:34 | Zouppen: | that quote needs citation |
| 10:19:17 | nsh: | ( http://gadyasblog.blogspot.co.uk/2009/10/ceiiinosssttuv-hookes-law-more-commonly.html // http://www.aps.org/publications/apsnews/200811/backpage.cfm ) |
| 10:25:50 | lclc: | lclc is now known as lclc_bnc |
| 13:46:26 | lclc_bnc: | lclc_bnc is now known as lclc |
| 14:01:31 | Adlai: | mappum: how (in)sane would it be to run mercury in a blockchain against itself as a decentralized coinswap market? |
| 14:12:24 | Adlai: | https://gist.github.com/adlai/976d308efdb2e886ecb9 'revisions' link includes the orignial text by gmaxwell |
| 14:12:26 | lclc: | lclc is now known as lclc_bnc |
| 14:14:10 | Adlai: | * Adlai takes https://gist.github.com/adlai/976d308efdb2e886ecb9#file-coinswap-txt-L24 to suggest that Alice should be the participant who cares more about anonymity, whereas Bob should be incentivized for the risk of being deanonymized |
| 17:08:50 | buttsniff: | buttsniff is now known as grubles |
| 17:13:57 | anthony: | anthony is now known as Guest75489 |
| 18:07:34 | embicoin_: | embicoin_ is now known as embicoin |
| 18:09:25 | mappum: | Adlai: why create another blockchain? bitcoin should work just fine |
| 18:09:29 | mappum: | i hadn't looked closely at coinswap before, it seems to basically be an enhanced version of atomic swaps to make the transactions not associated with each other |
| 18:40:12 | siraj_: | http://blog.onename.com/blockstore-bitcoin/ interesting |
| 18:50:47 | elevation: | elevation is now known as Guest638 |
| 19:08:00 | kanzure: | wrong |
| 19:08:48 | kanzure: | for anyone to think that's interesting they would have to be unaware of literally all of the prior work |
| 19:17:44 | mappum: | kanzure: what prior work are you thinking of, permacoin? |
| 19:19:14 | kanzure: | the page seems to be down at the moment, but this was the "store the hash of a dht in the blockchain" idea again, right? |
| 19:20:56 | mappum: | yes, and done in a counterparty-like way (fake transactions embedded in OP_RETURNs on bitcoin) |
| 19:21:45 | fluffypony: | eugh. |
| 19:27:56 | siraj_: | right |
| 19:28:22 | siraj_: | here's a better link https://github.com/openname/blockstore |
| 19:28:46 | instagibbs: | don't know the prior work, but I'm also unsure of what it's supposed to solve? Checkins of DHTs? |
| 19:29:21 | siraj_: | decentralized authorization of data ownership |
| 19:29:42 | siraj_: | and access |
| 19:30:20 | instagibbs: | who publishes the DHT? Onename? |
| 19:30:26 | instagibbs: | like, sticking it in a block |
| 19:30:49 | siraj_: | they say each node of their client is a DHT node (its built in) |
| 19:31:14 | siraj_: | im not sure how they are incentivizing them. no tit-for-tat mechanism like bittorrent or monetary incentive like filecoin |
| 19:31:16 | mappum: | that part doesn't seem like it needs to be coupled to the blockchain, they should really be separate systems |
| 19:31:18 | instagibbs: | but the anchor being published on the blockchain must be put there by someone... perhaps this is off topic |
| 19:36:50 | maaku: | there is absolutely no reason to include any information in the block chain for this purpose. NONE. |
| 19:37:39 | instagibbs: | At this point in my bitcoin 'career', if a project doesn't explicitly numerate why it needs the blockchain up front, my eyes glaze over |
| 19:38:00 | siraj_: | Is there another way to authorize ownership of your data in a decentralized way in a DHT? |
| 19:38:12 | mappum: | they should just be using namecoin, the extra features they try to put in are unrelated |
| 19:40:30 | siraj_: | namecoin lets you authenticate but it doesn't let you authorize yourself to access your data. for example, in a decentralized social network namecoin would let you verify you are unique, but if the network is using a DHT to store data, all data would be global read write unless there was a way to authorize ownership. the blockchain provides decentralized consensus on data ownership because only you own your private key. i've yet to see |
| 19:40:35 | siraj_: | something else that does that as securely. |
| 19:40:56 | kanzure: | "authorize ownership" is meaningless nonsense |
| 19:41:03 | gmaxwell: | that does what? |
| 19:42:46 | kanzure: | i thought everyone and their mom has done "publishing a hash in a transaction" by now? i'm a little confused why i would have to invoke permacoin or whatever. |
| 19:43:35 | GAit: | TEE (Trusted Execution Environment) with directIO on screen on Android, demo by Ledger on GreenBits https://www.youtube.com/watch?v=Ugd_irhBnto |
| 19:44:23 | instagibbs: | GAit: +1, excited to see these finally roll out |
| 19:47:05 | GAit: | instagibbs: same here, even with NFC it is a bit painful to use a hardware wallet with your mobile. With USB it is outright a mission. |
| 19:56:05 | siraj_: | @kanzure assume i have a social network on a DHT where users don't have to self-host their data. a user publishes an image to the DHT and it returns a hash. i only want myself to be able to access this image. This is where i see the utility of something like blockstore. I'm not sure how else only i can have access to said image in the DHT. |
| 19:58:23 | mappum: | siraj_: if you're letting other people store it, it's already considered public data. you could encrypt the image and let people store that, then only you can access the image |
| 19:59:01 | siraj_: | but if the apps source code is open source, anyone could easily decrypt it |
| 19:59:57 | mappum: | no, only you store the encryption keys |
| 20:00:56 | gmaxwell: | siraj_: I think you're confusing some basic concepts. Public key cryptography, which lets a third party encrypt a message so that only you can decrypt it, is widely used and existed long before Bitcoin. It accomplishes the goal you're describing. |
| 20:01:23 | siraj_: | ok thx guys bbl crypto study time |
| 20:07:00 | stonecoldpat: | good example of why i love bitcoin, it is a good excuse to introduce people to crypto (who may not necessarily have been introduced to it previously). or at least introduce people to the concept of public/private keys. (y) |
| 20:27:19 | hightorque: | hightorque is now known as shea256 |
| 20:33:26 | Adlai: | mappum: there would only be a single blockchain involved. by "in a blockchain against itself" i mean: "the utxos given and received live in the same blockchain; an additional protocol (coinswap) is used which lets the buyer obtain a utxo unlinkable to the one traded away by the merely-blockchain-observing public" |
| 20:34:20 | Adlai: | a crude way of saying this is "hey, atomic cross-chain swapping looks rather similar to CoinSwap, i wonder if we couldn't reuse code built around the former to facilitate the latter too" |
| 20:36:58 | mappum: | Adlai: ah, i interpreted that incorrectly. yes, they are very similar and coinswap can even happen on separate chains, so you would be killing 2 birds with 1 stone. but i wouldn't feel confident implementing coinswap unless there was a good decentralized solution for order matching (otherwise the central service can log who swapped) |
| 20:38:06 | amiller: | stonecoldpat, it used to be that if you wanted to show someone crypto, all you could do is send signed encrypted email message |
| 20:38:38 | amiller: | but it's really not fun at all.... checking a signature is super boring all you can do is look at it and mumble to yourself "yes i trust this" "no i do not trust this" |
| 20:38:45 | amiller: | or you send a pointless encrypted message |
| 20:38:47 | mappum: | Adlai: someday though, thanks for bringing coinswap to my attention. |
| 20:38:51 | gmaxwell: | mappum: hm? you don't need order matching, you need one sided registration of interest then other things can be party to party. |
| 20:39:27 | mappum: | gmaxwell: you do when you're doing the swap for trading instead of just for anonymity |
| 20:39:58 | gmaxwell: | okay, that one does need more extensive matching. |
| 20:41:27 | woah: | mappum https://www.youtube.com/watch?v=oSnYmMHp-o8 |
| 20:41:39 | woah: | perhaps something like this could be adapted for order matching |
| 20:42:14 | woah: | one of my favorite things from ccc this year |
| 20:43:12 | woah: | https://events.ccc.de/congress/2014/Fahrplan/system/attachments/2535/original/dp5-31c3.pdf |
| 20:44:34 | mappum: | woah: interesting, i'll have to give that a closer look sometime. i'm staying away from trying to do decentralized order matching for now because there are a lot of factors at play (traders might want to attack other traders by e.g. sending them fake orders) so it would be hard to get right |
| 20:46:14 | kanzure: | .title https://www.youtube.com/watch?v=oSnYmMHp-o8 |
| 20:46:15 | yoleaux: | DP5: PIR for Privacy-preserving Presence - YouTube |
| 20:48:25 | Adlai: | isn't "one sided registration of interest" enough? the would-be Bobs of a blockchain just need some way to inform would-be Alices of their openness to perform swaps, which iiuc is just the pair (utxo for sale, private contact channel); decentralized order matching results from it being impossible to spend an already spent transaction, so an 'expired' Bob-side listing is detectable by being missing |
| 20:48:26 | Adlai: | from the utxo set |
| 20:49:26 | Adlai: | * Adlai needs to study mercury, and the PIR concept linked by woah |
| 20:50:12 | Adlai: | still speaking a little (lot) outside my depth, trying to make sure that there's a viable idea at the other end of this thought train |
| 20:51:02 | mappum: | Adlai: right, coinswap can work fine without centralized matching, i was thinking of using coinswaps in atomic-swap market trades where you do need centralized matching. but for now that's not the best since the order-matching service has records of who swapped with who |
| 20:51:43 | mappum: | that could be viable though if the order matching could be decentralized |
| 20:51:53 | orperelman: | Mappum - how about semi-decentralised? |
| 20:52:54 | mappum: | orperelman: how would that work? |
| 20:53:24 | Adlai: | a centralized service which knows the set of all would-be Bobs ("coinswap offers"?) and how often PIRs are performed ("alice inquiries"?), but doesn't help or interfere with what the recipiets of the information do with it |
| 20:54:38 | mappum: | Adlai: right, that works if you only care about doing the coinswap for anonymity |
| 20:54:48 | Adlai: | a superset of all potential coinswap participants in a blockchain can be determined by any passive observer, and i'm not convinced the operator of such a centralized server knows anything appreciably more than that set precisely (ie, not a superset) |
| 20:55:30 | Adlai: | well yes, that's the direction i'm taking this: the joinmarket team are working towards coinjoin markets, and coinswap is looking lonely over there in the corner |
| 20:57:36 | Adlai: | rudimentaly DoS-mitigation is achieved by breaking step 6 in half, so Alice always pays a network fee; Bob only broadcasts after seeing confirmations on TX0; think "proof-of-burn", but useful |
| 20:58:59 | Adlai: | "useful" since the fee is a) going to mining fees, not being destroyed b) enabling progression to the protocol stage if both participants are honest |
| 20:59:09 | Adlai: | to the *next* protocol stage |
| 20:59:29 | Adlai: | * Adlai is talking about https://gist.github.com/adlai/976d308efdb2e886ecb9#file-coinswap-txt-L16 |
| 21:00:35 | mappum: | hasn't that been updated to have another party (Carol)? |
| 21:00:47 | Adlai: | no, it's been simplified to remove her. |
| 21:01:00 | Adlai: | https://gist.github.com/adlai/976d308efdb2e886ecb9/revisions |
| 21:01:29 | mappum: | oh, i see. so it still works as long as the coins aren't associated with each other |
| 21:02:03 | gmaxwell: | Really, you can look at coinswap as not a thing in and of itself, but a combination of two things: An atomic swap, and novation contract compression. The NCC provides perfect privacy as a necessary side effect of the compression; if details of the contract were leaked, then you obviously didn't compress it enough. :) |
| 21:02:46 | kanzure: | wait a sec i'm on to you |
| 21:03:02 | kanzure: | :) |
| 21:03:47 | gmaxwell: | In theory the NCC should be a general construct that you could apply to _any_ enumerated-party contract to keep the contract out of the blockchain. |
| 21:06:35 | Adlai: | did you just make up the NCC concept? "my normal approach is useless here"... there are few enough resources online about "novation", let alone NCC |
| 21:07:02 | Adlai: | s/just//, i guess "is it hitherto unpublished, from google's perspective" |
| 21:08:01 | mappum: | i just made the same google searches :P |
| 21:09:05 | Adlai: | * Adlai talks less, reads more |
| 21:10:23 | andytoshi: | (reading scrollback) o.O did somebody suggest using a blockchain as an encryption scheme? i think that's a new one.. |
| 21:11:23 | Adlai: | mappum: http://cacr.uwaterloo.ca/techreports/2014/cacr2014-10.pdf is a little less content-free than woah's dp5-31c3.pdf (linked from within those slides) |
| 21:11:25 | Adlai: | .title |
| 21:11:27 | yoleaux: | Adlai: Sorry, that doesn't appear to be an HTML page. |
| 21:11:38 | kanzure: | womp womp |
| 21:11:50 | kanzure: | although i would be interested in figuring out how to extract titles from pdfs. it seems to be one of those Difficult Problems. |
| 21:11:55 | Adlai: | http://tripbot.tripsit.me/flashy/orange/PATCHES%2520WELCOME |
| 21:11:58 | kanzure: | (formatting detection etc) |
| 21:12:21 | Adlai: | oh dear that's broken, oops >_> |
| 21:13:36 | gmaxwell: | andytoshi: not that uncommon to see people try to apply 'bitcoin/blockchains' where they really want asymetric crypto; no different than the old 'DHT' in place of 'distributed system'. |
| 21:14:27 | kanzure: | for april this year you guys should re-publish ralph merkle's paper and see if anyone notices that this "revolutionary cryptosystem" was previously known |
| 21:17:17 | Adlai: | make sure to cite recent work ("A generalization of the data integrity scheme used by certain cryptosystems, such as Bitcoin") |
| 21:17:19 | gmaxwell: | kanzure: by you guys you mean Nicolas van Saberhagen the second? |
| 21:17:37 | andytoshi: | hmm, i should highlight on that.. |
| 21:19:20 | andytoshi: | (everyone should) |
| 21:20:13 | Adlai: | * Adlai is not spartacus (yet) |
| 21:22:40 | Adlai: | although an interesting question for somebody at my stage in the crypto quest is "you wake up in late 2008, knowing what you do today; can you beat satoshi to the press?" |
| 21:23:21 | gmaxwell: | I've been a part of some communities that had collective troll accounts. E.g. some account where people share the credentials, as kind of an open secret. |
| 21:27:38 | gmaxwell: | kanzure: with respect to the earlier thing with the DHT network; whats _interesting_ there is that someone actually went and built it. |
| 21:28:27 | gmaxwell: | I haven't looked at the design, may well be crap and all... but I think it's very useful for something like that to exist; even if it just serves the purpose of shunting off misplaced things that think they want to shove data in the blockchain. |
| 21:29:08 | kanzure: | yeah, i suppose i was focusing more on the hash portion |
| 21:29:25 | kanzure: | i don't really have anything against DHT networks existing and doing things |
| 21:29:48 | kanzure: | whoops by "hash portion" i meant the one they place into the blockchain |
| 21:30:30 | gmaxwell: | If its well built and serves that purpose I'll gladly run a large node of it, at a loss, just to help discourage crap from going into the chain. Indeed, the hash portion is, meh. At least the stuff we'd talked about before used UTXO for rate limiting, not transactions, so you didn't have to transact. Alternatively, a sign to contract would at least make it more efficient to do and it could run |
| 21:30:36 | gmaxwell: | as a side effect of existing txn with no marginal cost. |
| 21:31:35 | gmaxwell: | the motivation for using utxo is so that no transactions are required per DHT operation. |
| 21:54:36 | bramc: | A few people from this channel may or may not be coming to meet me in a minute |
| 21:54:47 | kanzure: | if you stream it i will type it |
| 21:57:16 | gmaxwell: | bramc: I'm in the lobby in the south building. No one else is here yet. I'll let you know when other people show up. |
| 21:57:47 | bramc: | gmaxwell, Cool I'm upstairs on the 6th floor |
| 21:58:12 | gmaxwell: | K. I'll hang out here for people to show for a bit. |
| 22:01:43 | sipa: | which tower? |
| 22:01:50 | sipa: | bramc: we'll be there in a few minutes |
| 22:02:12 | gmaxwell: | sipa: south, as I mentioned specifically for your benefit. :) |
| 22:02:37 | zooko: | Huh, I wonder if bramc's new project is exploring side-chainy options. |
| 22:03:05 | kanzure: | nah they are ging to brawl about proof-of-work |
| 22:04:36 | kanzure: | so much for that stream |
| 22:06:39 | Adlai: | zooko: https://botbot.me/freenode/bitcoin-wizards/2015-02-14/?msg=31966591&page=1 |
| 22:08:32 | Adlai: | as i understand DMMSs, they make most sense when both blockchains use similar (if not identical) PoW algorithms. changing one chain's algorithm would require implementing both verification algorithms in both chains |
| 22:22:39 | zooko: | Adlai: thanks. |
| 23:08:02 | andytoshi: | Adlai: "DMMS" simply refers to the cryptographic property required of hash signatures.. |
| 23:08:41 | andytoshi: | ...what you mean is, "when using a hash signature as a DMMS in one chain of work done on another", it makes most sense for both blockchains to use similar (or identical) PoW algorithms |
| 23:09:03 | Adlai: | * Adlai passes the thanks to andytoshi |
| 23:09:05 | andytoshi: | and yes, if you wanted to sidechain a scrypt chain with Bitcoin, say, you'd need an "adaptor" sidechain which understood both PoW |
| 23:09:13 | nsh: | hrm |
| 23:09:27 | nsh: | so you can bridge PoW like dominoes tiles? |
| 23:09:36 | nsh: | *PoW algorithms |
| 23:09:55 | andytoshi: | nsh: yeah, you'd be moving your coin from Bitcoin to the adaptor chain to the target chain |
| 23:09:55 | nsh: | interesting... |
| 23:10:03 | andytoshi: | and to move back, you'd undo in the same order |
| 23:10:21 | nsh: | what's the transaction overhead for a chain of atomic swaps of length two like that? |
| 23:10:38 | andytoshi: | well, for atomic swaps you'd not need any adaptor chains |
| 23:10:43 | nsh: | oh, hm |
| 23:10:54 | nsh: | i thought all chains were coupled by atomic swaps... |
| 23:10:58 | andytoshi: | because they don't use a DMMS, they use 2-of-2 sigs |
| 23:11:17 | nsh: | hmm |
| 23:11:51 | Adlai: | using atomic swaps, two 2of2 in each chain. using lock/unlock proofs... more than this, depending how large a DMMS is needed for each stage in each chain |
| 23:11:53 | andytoshi: | nsh: "atomic swap" refers to a coinswap-like protocol and requires a counterparty on the chain that you're moving to; the alternative is to actually move the coin by the sidechain peg, which doesn't require a counterparty but does require a DMMS |
| 23:12:08 | nsh: | ah, right |
| 23:12:18 | nsh: | i was conflating atomic swaps with two-way pegs |
| 23:12:28 | andytoshi: | they are totally distinct; the peg would likely only be used by market makers who are moving a lot of coins, since they're slow and big |
| 23:12:36 | nsh: | * nsh nods |
| 23:12:46 | Adlai: | "market takers" would accept swap offers from makers |
| 23:13:58 | andytoshi: | Adlai: sure, but both parties would likely be big players who are somehow making money off of the overhead, with the goal of having a supply of coins on each chain .... as long as there is such a supply, ordinary people would use coinswaps |
| 23:14:44 | Adlai: | "market taker" = ordinary people using coinswaps. i don't think we're in disagreement here, maybe just some confusion about terminology. |
| 23:15:03 | andytoshi: | oh :) yes |
| 23:15:43 | Adlai: | in this context, market = atomic swap market. i guess you could talk about there being a market for mining lock/unlock proofs, but that's another story |
| 23:31:03 | nsh: | fgodel |
| 23:38:29 | rusty: | nsh: nice find re:timestamping. Thanks! |
| 23:38:41 | nsh: | np :) |
| 23:51:57 | anthony: | anthony is now known as Guest85694 |