| --- Log opened Thu Sep 15 00:00:54 2016 | ||
| -!- lmatteis [uid3300@gateway/web/irccloud.com/x-fqsggbchikpviuem] has quit [Read error: Connection reset by peer] | 00:08 | |
| -!- jl2012 [uid133844@gateway/web/irccloud.com/x-jcmiqzzflvizwaoe] has quit [Ping timeout: 265 seconds] | 00:08 | |
| -!- lmatteis [uid3300@gateway/web/irccloud.com/x-fpiwfuhqariyqfxs] has joined #bitcoin-wizards | 00:09 | |
| -!- jl2012 [uid133844@gateway/web/irccloud.com/x-itusvovcfdzicgvj] has joined #bitcoin-wizards | 00:10 | |
| -!- btcdrak [uid165369@gateway/web/irccloud.com/x-mpgyffmrauxeavgv] has joined #bitcoin-wizards | 00:15 | |
| -!- btcdrak [uid165369@gateway/web/irccloud.com/x-mpgyffmrauxeavgv] has quit [Client Quit] | 00:16 | |
| -!- btcdrak [uid165369@gateway/web/irccloud.com/x-upchjwuqyoijfnjx] has joined #bitcoin-wizards | 00:17 | |
| -!- 1JTAA9IUE [~hashtagg_@cpe-174-97-254-80.ma.res.rr.com] has quit [Ping timeout: 250 seconds] | 00:19 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 00:20 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 00:22 | |
| -!- cdecker [~cdecker@184.68.38.206] has joined #bitcoin-wizards | 00:24 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] | 00:39 | |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 265 seconds] | 00:42 | |
| -!- bildramer1 [~bildramer@2001:0:5ef5:79fd:492:1e20:a237:51b5] has quit [Ping timeout: 248 seconds] | 00:55 | |
| -!- bildramer [~bildramer@p5DC8AE4A.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 00:57 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 01:03 | |
| -!- cdecker [~cdecker@184.68.38.206] has quit [Ping timeout: 240 seconds] | 01:10 | |
| -!- nanasho [~nanashi@host-188-174-248-58.customer.m-online.net] has joined #bitcoin-wizards | 01:34 | |
| nanasho | Hello mates | 01:34 |
|---|---|---|
| -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-wizards | 01:48 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 240 seconds] | 01:55 | |
| -!- gielbier [~gielbier@unaffiliated/gielbier] has joined #bitcoin-wizards | 01:55 | |
| -!- skang404 [~skang404@27.6.192.89] has joined #bitcoin-wizards | 02:07 | |
| -!- skang404 [~skang404@27.6.192.89] has quit [Ping timeout: 265 seconds] | 02:14 | |
| -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-wizards | 02:41 | |
| -!- skang404 [~skang404@223.176.171.112] has joined #bitcoin-wizards | 03:04 | |
| -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards | 03:08 | |
| -!- skang404 [~skang404@223.176.171.112] has quit [Ping timeout: 240 seconds] | 03:11 | |
| -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Quit: laurentmt] | 03:13 | |
| -!- edvorg [~edvorg@14.169.89.229] has joined #bitcoin-wizards | 03:20 | |
| -!- Emcy_ [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards | 03:26 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds] | 03:33 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 03:53 | |
| -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards | 03:57 | |
| -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit] | 03:58 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 265 seconds] | 04:15 | |
| -!- hashtag [~hashtagg_@cpe-174-97-254-80.ma.res.rr.com] has joined #bitcoin-wizards | 04:26 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] | 04:30 | |
| -!- skang404 [~skang404@223.176.171.112] has joined #bitcoin-wizards | 04:32 | |
| -!- skang404 [~skang404@223.176.171.112] has quit [Ping timeout: 265 seconds] | 04:40 | |
| -!- skang404 [~skang404@27.6.192.89] has joined #bitcoin-wizards | 04:45 | |
| -!- skang404 [~skang404@27.6.192.89] has quit [Ping timeout: 260 seconds] | 04:53 | |
| -!- skang404 [~skang404@27.6.192.89] has joined #bitcoin-wizards | 05:05 | |
| -!- Guest29379 is now known as starsoccer | 05:09 | |
| -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-wizards | 05:11 | |
| -!- skang404 [~skang404@27.6.192.89] has quit [Ping timeout: 244 seconds] | 05:11 | |
| -!- paveljanik [~paveljani@79.98.72.216] has joined #bitcoin-wizards | 05:12 | |
| -!- paveljanik [~paveljani@79.98.72.216] has quit [Changing host] | 05:12 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards | 05:12 | |
| -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards | 05:21 | |
| -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit] | 05:21 | |
| -!- Cloudflare [~Cloudflar@unaffiliated/cloudflare] has quit [Quit: Bye] | 05:24 | |
| -!- mryandao [~mryandaoI@unaffiliated/mryandao] has quit [Quit: do not disturb. look busy...] | 05:24 | |
| -!- mryandao [~mryandaoI@45.32.191.82] has joined #bitcoin-wizards | 05:26 | |
| -!- Cloudflare [~Cloudflar@unaffiliated/cloudflare] has joined #bitcoin-wizards | 05:26 | |
| -!- pro [~pro@unaffiliated/pro] has joined #bitcoin-wizards | 05:31 | |
| -!- skang404 [~skang404@27.6.192.89] has joined #bitcoin-wizards | 05:32 | |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards | 05:35 | |
| -!- skang404 [~skang404@27.6.192.89] has quit [Ping timeout: 265 seconds] | 05:39 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 05:39 | |
| -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards | 05:45 | |
| -!- mryandao [~mryandaoI@45.32.191.82] has quit [Quit: do not disturb. look busy...] | 05:49 | |
| -!- Cloudflare [~Cloudflar@unaffiliated/cloudflare] has quit [Quit: Bye] | 05:49 | |
| -!- mryandao [~mryandaoI@45.32.191.82] has joined #bitcoin-wizards | 05:50 | |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] | 05:51 | |
| -!- Cloudflare [~Cloudflar@unaffiliated/cloudflare] has joined #bitcoin-wizards | 05:51 | |
| -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Ping timeout: 265 seconds] | 05:53 | |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards | 05:54 | |
| -!- nikivi [~nikivi@wlan-200025.nbw.tue.nl] has joined #bitcoin-wizards | 06:06 | |
| -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards | 06:19 | |
| -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Remote host closed the connection] | 06:21 | |
| -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards | 06:24 | |
| -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Read error: Connection reset by peer] | 06:28 | |
| -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-wizards | 06:32 | |
| -!- Noldorin_ [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards | 06:38 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 244 seconds] | 06:41 | |
| -!- e_0 [~e0@cs10-dhcp10.bu.edu] has quit [Ping timeout: 240 seconds] | 06:42 | |
| -!- nikivi [~nikivi@wlan-200025.nbw.tue.nl] has quit [Quit: irc] | 06:43 | |
| -!- Noldorin_ [~noldorin@unaffiliated/noldorin] has quit [Ping timeout: 248 seconds] | 06:43 | |
| -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards | 06:47 | |
| -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit] | 06:47 | |
| -!- nikivi [~nikivi@wlan-200025.nbw.tue.nl] has joined #bitcoin-wizards | 06:49 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards | 06:49 | |
| -!- cjd [~user@2c0f:f930:2:12::] has quit [Ping timeout: 248 seconds] | 06:55 | |
| -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards | 07:11 | |
| -!- nikivi [~nikivi@wlan-200025.nbw.tue.nl] has quit [Quit: irc] | 07:12 | |
| -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards | 07:22 | |
| -!- edvorg [~edvorg@14.169.89.229] has quit [Ping timeout: 250 seconds] | 07:23 | |
| -!- cjd [~user@2c0f:f930:2:12::] has joined #bitcoin-wizards | 07:27 | |
| -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Quit: laurentmt] | 07:27 | |
| kinlo | ±. | 07:44 |
| -!- nanasho [~nanashi@host-188-174-248-58.customer.m-online.net] has quit [Remote host closed the connection] | 07:46 | |
| -!- Starduster [~guest@unaffiliated/starduster] has joined #bitcoin-wizards | 07:51 | |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] | 08:02 | |
| -!- e4xit_ [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-wizards | 08:14 | |
| -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has quit [Ping timeout: 255 seconds] | 08:16 | |
| -!- e4xit_ is now known as e4xit | 08:16 | |
| -!- Kelticfox [Kelticfox@freenode/corporate-sponsor/privateinternetaccess.com/kelticfox] has joined #bitcoin-wizards | 08:17 | |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards | 08:17 | |
| kanzure | "compact spv proofs" http://popeller.io/index.php/2016/09/15/compact-spv-proofs/ | 08:25 |
| -!- Kelticfox [Kelticfox@freenode/corporate-sponsor/privateinternetaccess.com/kelticfox] has left #bitcoin-wizards [] | 08:25 | |
| -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards | 08:36 | |
| bsm117532 | Cool. amiller was working on something similar with "proofs of proofs of work" | 08:37 |
| -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit] | 08:41 | |
| -!- MoALTz [~no@78-11-247-26.static.ip.netia.com.pl] has joined #bitcoin-wizards | 08:45 | |
| -!- Noldorin_ [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards | 08:49 | |
| -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has quit [Ping timeout: 265 seconds] | 08:52 | |
| -!- Emcy_ [~MC@unaffiliated/mc1984] has quit [Read error: Connection reset by peer] | 08:55 | |
| -!- Noldorin_ [~noldorin@unaffiliated/noldorin] has quit [Ping timeout: 265 seconds] | 08:55 | |
| -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards | 09:06 | |
| -!- mountaingoat [~mountaing@gateway/vpn/privateinternetaccess/mountaingoat] has joined #bitcoin-wizards | 09:06 | |
| -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit] | 09:08 | |
| amiller | the author of this post isn't aware of http://fc16.ifca.ai/bitcoin/papers/KLS16.pdf which solves that problem | 09:16 |
| bsm117532 | You should make that comment on his blog. ;-) | 09:17 |
| -!- Emcy [~MC@213.107.7.236] has joined #bitcoin-wizards | 09:29 | |
| -!- Emcy [~MC@213.107.7.236] has quit [Changing host] | 09:30 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards | 09:30 | |
| kanzure | "The bumpy road towards iPhone 5c NAND mirroring" http://arxiv.org/abs/1609.04327 | 09:31 |
| kabaum | Thanks. I'm looking at the paper right now. | 09:33 |
| kabaum | Thanks kanzure for pointing me here | 09:33 |
| kanzure | yep... | 09:33 |
| -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has joined #bitcoin-wizards | 09:38 | |
| -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards | 09:40 | |
| -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit] | 09:40 | |
| kabaum | I mean the http://fc16.ifca.ai/bitcoin/papers/KLS16.pd paper. Just to avoid misunderstanding. | 09:43 |
| -!- Noldorin_ [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards | 09:47 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services] | 09:51 | |
| -!- [7] [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 09:51 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 09:56 | |
| -!- Noldorin_ is now known as Noldorin | 09:57 | |
| -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 276 seconds] | 10:01 | |
| andytoshi | note that while the sidechains whitepaper claims "1024 blocks becomes expected 10" (and by extension 420k blocks becomes 19), in my simulations, 420k blocks usually compresses to ~300 blocks (with huge variance) | 10:03 |
| andytoshi | i don't have a good idea of why this is the case, the compressed chain does have the expected log-sized "1, 200k, 300k, 350k, 375k, ..." shape | 10:04 |
| -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] | 10:04 | |
| andytoshi | but there are a lot of straggling non-skip blocks near the end | 10:05 |
| andytoshi | so i think there is something wrong with the expected-length argument in the sidechains paper (though it appears the asymptotics are correct) | 10:08 |
| bsm117532 | The number of blocks having hash values less than a certain value is an "order statistic": https://en.wikipedia.org/wiki/Order_statistic | 10:14 |
| bsm117532 | The probability distribution therof is a Beta distribution. | 10:14 |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 250 seconds] | 10:20 | |
| maaku | andytoshi are you using an optimal path finding algorithm? | 10:24 |
| maaku | I would expect that the optimal paths do not take maximal jumps | 10:24 |
| -!- echonaut1 [~echonaut@46.101.192.134] has quit [Remote host closed the connection] | 10:26 | |
| -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-wizards | 10:27 | |
| -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Ping timeout: 265 seconds] | 10:37 | |
| -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards | 10:42 | |
| -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-wizards | 10:56 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 11:11 | |
| -!- Sleepnbum [Sleepnbum@72.67.47.196] has joined #bitcoin-wizards | 11:26 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 11:41 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] | 11:59 | |
| -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-wizards | 12:00 | |
| andytoshi | maaku: ah, i am not | 12:00 |
| andytoshi | for mimblewimble i think i can't because i need a consensus-defined skiplist where old links don't change based on new blocks .. but i think even in my earlier 2waypeg sims i was using pretty dumb pathfinding schemes | 12:01 |
| -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 240 seconds] | 12:08 | |
| -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-wizards | 12:10 | |
| maaku | optimal solutions involve dynamic programming, which is not crazy complex, but not something I'd want in consensus code either | 12:25 |
| maaku | but there might be an incremental algorithm which is better than a greedy path to genesis | 12:26 |
| maaku | in fact I thought that's what you were going to do? | 12:26 |
| andytoshi | maybe. i'm not convinced because i don't want the validity of old blocks (i.e. what backlinks must exist) to be changeable by new blocks | 12:26 |
| maaku | if you have a current best path, and you find a new block and use that to only skip back to blocks on the current best path, that's NOT the same as a greedy algorithm | 12:27 |
| andytoshi | oh! you're right | 12:27 |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 12:32 | |
| andytoshi | so i have simulation code that does this, it is giving me the high-variance-but-usually-around-300 results | 12:32 |
| andytoshi | interestingly this is the same as what a remember getting from a greedy algo.. | 12:33 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 12:33 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 12:39 | |
| -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 276 seconds] | 12:45 | |
| -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards | 12:49 | |
| -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] | 12:52 | |
| petertodd | so I wrote a module for OpenTimestamps that timestamps files within git trees in a privacy preserving way: https://github.com/opentimestamps/python-opentimestamps/blob/master/opentimestamps/core/git.py | 12:54 |
| petertodd | I'm interested in feedback/peer review! | 12:55 |
| petertodd | it's used by the opentimestamps client: https://github.com/opentimestamps/opentimestamps-client | 12:55 |
| petertodd | which I blogged about earlier today: https://petertodd.org/2016/opentimestamps-announcement | 12:55 |
| -!- MoALTz [~no@78-11-247-26.static.ip.netia.com.pl] has quit [Quit: Leaving] | 12:57 | |
| bsm117532 | That' | 12:58 |
| bsm117532 | That's awesome. Now we just need to sign our commits using keys exposed on the blockchain. | 12:58 |
| bsm117532 | I really want a git integration that signs with secp256k1 keys... | 12:58 |
| maaku | bsm117532: have you looked at monotone? | 12:59 |
| bsm117532 | The RCS software? | 12:59 |
| petertodd | bsm117532: so long as by "exposed" you don't mean your secret keys :P | 13:04 |
| bsm117532 | A developer can indicate a key he's going to use to sign a commit by indicating a spent txid. | 13:04 |
| petertodd | bsm117532: IIRC GnuPG is added secp256k1 support, so that'll likely be possible | 13:05 |
| petertodd | bsm117532: well, so what exactly are you trying to prove there? | 13:05 |
| sipa | petertodd: woah! | 13:05 |
| bsm117532 | I'm saying that bitcoin can prove the integrity of bitcoin core by having developers sign code (in addition to your timestamps) -- and those keys should be on the blockchain instead of some flawed CA or web of trust. | 13:06 |
| sipa | you're confusing things | 13:06 |
| petertodd | sipa: note that there's actually *two* ways of signing git commits in OTS - the thing I posted above re-hashes entire trees, which allows you to extract a timestamp for a single file without (hopefully!) revealing anything about other files in the repo, or the directory structure | 13:06 |
| petertodd | bsm117532: yeah, just putting keys on a blockchain doesn't by itself prove much | 13:06 |
| sipa | bsm117532: the blockchain here is a transport mechanism, a simple (and highly inefficient) replacement for http | 13:07 |
| sipa | bsm117532: the keys are at the level of a web of trust | 13:07 |
| petertodd | sipa: I build the rehashing support because I wanted to be able to apply it to my personal git repos for mail, company records, etc. | 13:07 |
| bsm117532 | I know that's how it works now. | 13:07 |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 13:08 | |
| bsm117532 | petertodd: One can indicate a txid, and arrange to maintain control of the first output of subsequent transactions, even in the face of key loss events. | 13:11 |
| kanzure | what? so you lose one key but not the other? | 13:12 |
| kanzure | "what is trust root" | 13:12 |
| bsm117532 | The trust root is Bitcoin itself and it's PoW. | 13:12 |
| petertodd | bsm117532: rather than talking about txids - an implementation detail - you should talk about what kinds of proofs you think the system is giving you | 13:12 |
| petertodd | e.g. does your scheme need a timestamp proof? an anti-replay mechanism? a proof-of-publication? | 13:13 |
| maaku | bsm117532: yes, http://monotone.ca/ | 13:14 |
| bsm117532 | petertodd: The system gives me proofs that I haven't chosen to revoke my (code signing) key in the last ~10 minutes. | 13:17 |
| -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-wizards | 13:17 | |
| petertodd | bsm117532: that's a design goal, not an explicit statement about what exact type of proofs will do that :) | 13:18 |
| bsm117532 | petertodd: The blocks are the proofs. I don't see what you're getting at... | 13:18 |
| petertodd | bsm117532: a block is a block - what *type* of proof is it exactly? | 13:18 |
| petertodd | bsm117532: what, specifically, is this preventing from happening? | 13:19 |
| sipa | bsm117532: i generally dislike hacking bitcoin keys into reusable identities | 13:19 |
| bsm117532 | It's preventing compromised keys from signing code via stealing root CA keys, or brute forcing collisions in a web of trust. | 13:20 |
| bsm117532 | sipa: Why? Because bitcoin was supposed to be more fungible than it actually is? | 13:20 |
| sipa | bsm117532: because it's a problem that needs fixing outside of bitcoin | 13:20 |
| sipa | and it creates incentives to break fungibility for solving a problem that it wasn't intended to solve | 13:21 |
| bsm117532 | sipa: fungibility is already irretrievably broken, regardless of intention. :-( | 13:22 |
| sipa | i disagree. it's not a boolea | 13:22 |
| sipa | it took years, but wallets these days are actually no longer continuously reusing keys | 13:22 |
| -!- JHistone [~JHistone@cpc104808-sgyl39-2-0-cust135.18-2.cable.virginm.net] has joined #bitcoin-wizards | 13:22 | |
| bsm117532 | I have a hard time seeing how bitcoin could evolve to true fungibility. I think Zcash/Mimblewimble/BLS stuff will come along, with true fungibility. | 13:23 |
| sipa | if bitcoin's fungibility is irretrievably broken, then you should convince everyone here to abandon it | 13:23 |
| bsm117532 | Or repurpose it ;-) | 13:23 |
| bsm117532 | But if you have ideas to recover fungibility, I'd love to hear... | 13:24 |
| sipa | again, it's not a boolean | 13:24 |
| sipa | so if you phrase it as "improve" rather than "recover", i'm willing to discuss that | 13:24 |
| bsm117532 | Sure | 13:24 |
| bsm117532 | Could bitcoin evolve to block-level signature aggregation? I have a hard time seeing that. | 13:25 |
| -!- vega4 [~JBouncer@static.88-198-5-245.clients.your-server.de] has quit [Read error: Connection reset by peer] | 13:25 | |
| sipa | i believe that's totally viable | 13:26 |
| sipa | i have more difficulty how it could adopt CT or MW | 13:26 |
| kanzure | that's one of the advantages of segwit upgrades | 13:26 |
| sipa | *seeing | 13:26 |
| sipa | but signature aggregation, sure | 13:26 |
| bsm117532 | EErrr what I really mean there is block-level coinjoin, as seems to be possible with MW | 13:27 |
| sipa | OWAS does that | 13:27 |
| sipa | and i believe OWAS is softforkable, but it may be nontrivial | 13:27 |
| kanzure | i think signature aggregation can be done with restricting behavior on anyonecanspends | 13:27 |
| kanzure | (through a soft-fork, i mean...) | 13:28 |
| sipa | i mean... everything is softforkable in the sense of "we define an extra part of block size (like segwit), and you can move coins there with a special anyonecanspend, and then move them back... but in that new region totally different consensus rules apply" | 13:28 |
| bsm117532 | But as long as soft fork is the name of the game, the original, less-fungible txns will be present, and can be used to indicate keys that sign code. | 13:28 |
| sipa | you can softfork out the original tx type at some point :) | 13:29 |
| kanzure | bsm117532: over a very long timeframe i would expect to see various transaction types to become unsupported over time, as long as alternatives are supported | 13:29 |
| bsm117532 | Bitcoin, seen as a keyserver is far superior to a CA or web of trust. Maybe there should be a different blockchain for it... | 13:29 |
| sipa | bsm117532: i completely disagree with that | 13:30 |
| sipa | you'd lose the economic incentive to secure the chain without transactions that support the exchange rate of the security-providing subsidy value | 13:30 |
| * bsm117532 looks at the number of P2SH addresses...as evidence that old features will likely never be able to be soft-forked out... | 13:31 | |
| bsm117532 | sipa: I agree completely with your last statement. But that brings us back to doing it on top of bitcoin itself... | 13:32 |
| sipa | yes, i don't think there is another choice | 13:32 |
| sipa | so if you really believe that the fungibility issue is irrepairably broken, we should abandon bitcoin, and build something better | 13:33 |
| sipa | but i don't think that is the case | 13:33 |
| bsm117532 | sipa: Well imagine huge coinjoins existing alongside old few in/out P2PKH txns. I think we can have it both ways. | 13:34 |
| sipa | and we need a lot more time to research better technology, experiment with it, and then investigate whether it could be brough to bitcoin in some form, rather than needing to start over | 13:34 |
| sipa | not giving up prematurely | 13:34 |
| sipa | so if you'd like to see bitcoin as just a keyserver or an anchor, i think you're missing the point that its security depends on it being usable as a transactable currency | 13:35 |
| bsm117532 | Not "just" a keyserver, but "also": since it contains an internal keyserver, essentially, why not use it to sign itself and ensure its own code integrity? | 13:37 |
| sipa | i disagree that it contains a keyserver | 13:38 |
| petertodd | sipa: +1 | 13:38 |
| bsm117532 | every spent txid reveals pubkeys. That's the sense that it's a keyserver. | 13:38 |
| sipa | it can't provide that function without reducing fungibility, making its security story even harder to argue for | 13:38 |
| petertodd | bsm117532: by that argument, testnet is a publishing platform for 80's musicians... | 13:39 |
| bsm117532 | It can provide that functionality now, and until its fungibility is upgraded to make it impossible. | 13:39 |
| sipa | bsm117532: those txids are not associated with an identity | 13:39 |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 13:39 | |
| bsm117532 | All I have to do is indicate which txid... | 13:39 |
| -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 276 seconds] | 13:39 | |
| bsm117532 | and it becomes associated | 13:39 |
| sipa | no, it does not prove your identityu | 13:40 |
| -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 265 seconds] | 13:40 | |
| petertodd | sipa: and even if it did, you don't need a blockchain for that | 13:40 |
| sipa | petertodd: +1 | 13:40 |
| sipa | you can just reveal the key through whatever channel you'd use to reveal the txid | 13:41 |
| petertodd | bsm117532: you should read this: https://github.com/petertodd/ID2020DesignWorkshop/blob/6918aa3cae5c2fc75c94c9c4e19121ca52446606/topics-and-advance-readings/DexPredicatesForSmarterSigs.md | 13:42 |
| petertodd | bsm117532: I put a lot of thought a few months ago into how to use this tech for identity, and what I actually came up with out of that was it's remarkable how narrow the use-cases are for Bitcoin - timestamping is one of the few examples where Bitcoin clearly helps | 13:43 |
| petertodd | (hence why I (re)wrote opentimestamps!) | 13:43 |
| katu | re: fungibility, miners can incentivize it. by demanding much higher fees for inputs with reused address. | 13:45 |
| -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-wizards | 13:47 | |
| bsm117532 | sipa: sure you can just reveal keys...but if I reveal a txid, I also have a built-in revocation and replacement mechanism that is protected by PoW. | 13:57 |
| bsm117532 | vs. having your CRL endpoint DDoS'ed (or pgpkeys.mit.edu) | 13:57 |
| bsm117532 | petertodd: timestamping, and key control. (BTW sorry for hijacking the conversation, your code is cool and I'll look at it in more detail!) | 13:58 |
| -!- Tenhi_ [~tenhi@static.177.80.201.138.clients.your-server.de] has joined #bitcoin-wizards | 14:06 | |
| sipa | bsm117532: you want revocability and protection on the link with identity | 14:10 |
| sipa | on the blockchain itself is only a key | 14:11 |
| sipa | it can be anyone's | 14:11 |
| -!- Tenhi_ [~tenhi@static.177.80.201.138.clients.your-server.de] has quit [K-Lined] | 14:16 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 244 seconds] | 14:25 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 14:44 | |
| -!- mappum [sid43795@gateway/web/irccloud.com/x-aylckcjxvpzvmyjs] has quit [Ping timeout: 250 seconds] | 14:45 | |
| -!- _whitelogger [~whitelogg@uruz.whitequark.org] has quit [Ping timeout: 250 seconds] | 14:45 | |
| -!- rodarmor [rodarmor@2600:3c01::f03c:91ff:fe61:6c68] has quit [Ping timeout: 250 seconds] | 14:45 | |
| -!- kumavis [sid13576@gateway/web/irccloud.com/x-bzzhnddussctxflo] has quit [Ping timeout: 250 seconds] | 14:45 | |
| -!- CryptoAi [sid28532@gateway/web/irccloud.com/x-ktpobrkpfhscyuqp] has quit [Ping timeout: 250 seconds] | 14:45 | |
| -!- nicolagreco [sid157154@gateway/web/irccloud.com/x-hngrrlaftnyyfhuc] has quit [Ping timeout: 250 seconds] | 14:45 | |
| -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has quit [Ping timeout: 250 seconds] | 14:46 | |
| -!- baffo32 [baffo32@gateway/shell/layerbnc/x-mbaveuhxukufuoek] has quit [Ping timeout: 250 seconds] | 14:46 | |
| -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Ping timeout: 250 seconds] | 14:46 | |
| -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has quit [Ping timeout: 250 seconds] | 14:46 | |
| -!- sipa [~pw@unaffiliated/sipa1024] has quit [Ping timeout: 250 seconds] | 14:46 | |
| -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:8419:4777:d81c:45e] has quit [Ping timeout: 250 seconds] | 14:47 | |
| -!- wpalczynski [sid55851@gateway/web/irccloud.com/x-nqsxqiinvzyggsqs] has quit [Ping timeout: 250 seconds] | 14:47 | |
| -!- helo [~helo@unaffiliated/helo] has quit [Ping timeout: 250 seconds] | 14:47 | |
| -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has quit [Ping timeout: 250 seconds] | 14:47 | |
| -!- gigq [~gigq@2602:302:d14c:51a0:3ac9:86ff:fe0e:683d] has quit [Ping timeout: 250 seconds] | 14:47 | |
| -!- PaulCape_ [~PaulCapes@2604:5500:17:2ea:e1e8:378f:29b1:e12d] has joined #bitcoin-wizards | 14:47 | |
| -!- _whitelogger [~whitelogg@uruz.whitequark.org] has joined #bitcoin-wizards | 14:48 | |
| -!- gigq [~gigq@2602:302:d14c:51a0:3ac9:86ff:fe0e:683d] has joined #bitcoin-wizards | 14:48 | |
| -!- sipa [~pw@2a02:348:86:3011::1] has joined #bitcoin-wizards | 14:48 | |
| -!- helo [~helo@unaffiliated/helo] has joined #bitcoin-wizards | 14:48 | |
| -!- mappum [sid43795@gateway/web/irccloud.com/x-ofdiarglswxvevsu] has joined #bitcoin-wizards | 14:50 | |
| -!- CryptoAi [sid28532@gateway/web/irccloud.com/x-iipsnqwlnbvkyslb] has joined #bitcoin-wizards | 14:50 | |
| -!- Lightsword [~Lightswor@107.170.253.193] has joined #bitcoin-wizards | 14:51 | |
| -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #bitcoin-wizards | 14:52 | |
| -!- rodarmor [rodarmor@2600:3c01::f03c:91ff:fe61:6c68] has joined #bitcoin-wizards | 14:52 | |
| -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has joined #bitcoin-wizards | 14:52 | |
| -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-wizards | 14:53 | |
| -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-wizards | 14:54 | |
| -!- aalex [~aalex@64.187.177.58] has quit [Quit: Connection reset by beer] | 14:55 | |
| -!- nicolagreco [uid157154@gateway/web/irccloud.com/x-wdejribvllugjhko] has joined #bitcoin-wizards | 14:55 | |
| -!- wpalczynski [sid55851@gateway/web/irccloud.com/x-rhlrallynindltyu] has joined #bitcoin-wizards | 14:56 | |
| -!- kumavis [sid13576@gateway/web/irccloud.com/x-mtiveusourzqyjvr] has joined #bitcoin-wizards | 14:57 | |
| -!- baffo32 [baffo32@gateway/shell/layerbnc/x-xeeyszsxgjeqphkd] has joined #bitcoin-wizards | 15:01 | |
| -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 260 seconds] | 15:09 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 15:10 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds] | 15:14 | |
| -!- jnewbery [~jnewbery@67.251.193.154] has joined #bitcoin-wizards | 15:23 | |
| -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-wizards | 15:28 | |
| -!- jnewbery [~jnewbery@67.251.193.154] has quit [] | 15:30 | |
| bsm117532 | sipa: If I point you to a txid I control, it's not going to be "anyone's" -- It's going to be mine. | 15:31 |
| bsm117532 | Bitcoin transactions can indicate revocation. | 15:32 |
| bsm117532 | I'm going to control the first output, in a chain of transactions. By following successive spends in the chain, an observer to whom I've given the starting txid can track my revocations, as well as pick up a new key that I intend to use. | 15:33 |
| bsm117532 | This is a "self-sovereign" identity. If you're familiar with uPort on Ethereum, essentially I've figured out how to do it in top of Bitcoin by maintaining control of the first output in a chain of txns. | 15:35 |
| midnightmagic | petertodd: to ensure directory information except maximum depth isn't leaked, could one consider the filepath or directory path itself merklized into a balanced tree. it could be selectively revealed then right? | 15:58 |
| midnightmagic | or maybe you could mask out selective or randomly-size portions of the paths and consider the filepath as a single string not split on component boundaries.. | 16:02 |
| midnightmagic | hrm | 16:02 |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds] | 16:03 | |
| -!- JHistone [~JHistone@cpc104808-sgyl39-2-0-cust135.18-2.cable.virginm.net] has quit [Quit: Leaving] | 16:12 | |
| bsm117532 | petertodd: Very interesting (smart signatures). I've outlined how to deploy a self-sovereign identity on Bitcoin, but there one is revealing a script that evaluated to true to spend the txn, and repurposing that script for a different use. For simple scripts there's a logical extension (e.g. multi-sig). | 16:13 |
| bsm117532 | You're saying one could deploy an entirely different "script" that lets an observer validate an off-chain interaction (e.g. code signing, or auth event). | 16:14 |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards | 16:18 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer] | 16:19 | |
| -!- Sleepnbum [Sleepnbum@72.67.47.196] has quit [Ping timeout: 244 seconds] | 16:21 | |
| bsm117532 | petertodd: Why do you say that use cases are "narrow"? Deploying your Dex scripts, and replacing them with new ones seems like a perfect use. Knowing that a Dex script is still valid comes down to knowing that a particular UTXO is unspent. (so, UTXO set commitments are immensely helpful) | 16:23 |
| -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 16:23 | |
| bsm117532 | Timestamps from the blockchain bound a region of time when a particular key was valid (or Dex script could have been used to sign code). So historical signatures can be verified. | 16:25 |
| -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving] | 16:33 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 16:35 | |
| -!- adiabat [~adiabat@159.203.193.74] has quit [Remote host closed the connection] | 16:37 | |
| -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds] | 16:50 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 244 seconds] | 16:52 | |
| -!- superkuh [~superkuh@unaffiliated/superkuh] has quit [Ping timeout: 265 seconds] | 16:54 | |
| -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 244 seconds] | 16:55 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 17:02 | |
| -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards | 17:03 | |
| sipa | bsm117532: you can claim that a transaction is yours (and you can prove so by signing a message with the key), but that is no different than me sending you the key without any transaction, and signing a message with it. the only thing yhe blockchain does is prove that that key existed at a certain point in time, not whom it belongs to. and for the timestamping use case, we have better solutions that put them in a merkle tree instead of telling... | 17:07 |
| -!- superkuh_ [~superkuh@unaffiliated/superkuh] has joined #bitcoin-wizards | 17:07 | |
| sipa | the whole world about it. | 17:07 |
| -!- superkuh_ is now known as superkuh | 17:08 | |
| -!- AaronvanW [~ewout@185pc230.sshunet.nl] has quit [Read error: Connection reset by peer] | 17:22 | |
| -!- neha [~narula@tbilisi.csail.mit.edu] has quit [Remote host closed the connection] | 17:26 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 17:31 | |
| -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-wizards | 17:37 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 264 seconds] | 17:43 | |
| -!- harrymm [~wayne@104.222.140.120] has quit [Remote host closed the connection] | 17:55 | |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wmccdywsmlpiopbp] has quit [Quit: Connection closed for inactivity] | 17:56 | |
| -!- harrymm [~wayne@104.222.140.128] has joined #bitcoin-wizards | 17:58 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 17:58 | |
| -!- bsm117532- [~AndChat70@rrcs-50-74-107-234.nyc.biz.rr.com] has joined #bitcoin-wizards | 18:08 | |
| bsm117532- | sipa: It is different because the transaction mechanism can provide key revocation and replacement. What you want to know is whether a given key is still valid, which corresponds to asking whether a given UTXO is unspent. If you hide key data in a Merkle tree, an observer couldn't see your revocation. | 18:10 |
| sipa | you can just ask them to sign a message again | 18:11 |
| sipa | then you also know the key is still valid | 18:11 |
| -!- mountaingoat [~mountaing@gateway/vpn/privateinternetaccess/mountaingoat] has quit [Ping timeout: 265 seconds] | 18:14 | |
| sipa | also, the presense of a utxo does not mean they didn't lose the key | 18:15 |
| -!- bsm117532- [~AndChat70@rrcs-50-74-107-234.nyc.biz.rr.com] has quit [Ping timeout: 272 seconds] | 18:17 | |
| kanzure | and the lack of presence of utxo too | 18:20 |
| -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Quit: Textual IRC Client: www.textualapp.com] | 18:30 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has quit [Ping timeout: 244 seconds] | 18:30 | |
| -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards | 18:31 | |
| -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has joined #bitcoin-wizards | 18:32 | |
| -!- superkuh [~superkuh@unaffiliated/superkuh] has quit [Ping timeout: 264 seconds] | 18:36 | |
| bsm1175321 | An attacker can also "sign a message again". That does not prove the key is still valid. A balance at a UTXO is sitting at a *different* address than the hash of the pubkey previously revealed. One can separate the revocation mechanism from normal key use. (e.g. an offline key or pre-signed transaction) | 18:37 |
| -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Ping timeout: 240 seconds] | 18:37 | |
| bsm1175321 | I think it's impossible to prove your key hasn't been copied... | 18:38 |
| -!- superkuh [~superkuh@unaffiliated/superkuh] has joined #bitcoin-wizards | 18:48 | |
| sipa | i still don't understand what the blockchain offers here | 18:58 |
| sipa | you are already talking to the other party to know what the txid is | 18:59 |
| sipa | just ask then what their key is directly at that point | 18:59 |
| sipa | you don't know it is not copied, but the other party hurts itself only by doing so | 19:00 |
| sipa | but you do know it's live | 19:01 |
| bsm1175321 | The blockchain offers fast, timestamped, irrevocable *revocations*, and continuity with the new key, once established. Both the old and new key are known to be controlled by the same entity. *Without* a separate secure line of communication to that entity through the entire key loss process. | 19:06 |
| -!- kekroment [~kekroment@cultofkek.com] has quit [Ping timeout: 265 seconds] | 19:07 | |
| sipa | you need a secure line of communication anyway to establish identity of the key | 19:07 |
| bsm1175321 | But you only need a secure line of communication once, not in perpetuity. | 19:08 |
| bsm1175321 | Your model assumes a perpetual secure line of communication. If we had that a lot of things would be easier... | 19:08 |
| sipa | no, just once, to establish an identity key | 19:08 |
| bsm1175321 | And the revocation, and the new key. | 19:09 |
| sipa | afterwards you sign/encrypt using that key | 19:09 |
| -!- N0S4A2 [~weechat@24.35.69.143] has joined #bitcoin-wizards | 19:09 | |
| bsm1175321 | The attacker has that key now. What next? | 19:09 |
| sipa | you're eaten by a grue | 19:09 |
| bsm1175321 | hahaaa | 19:09 |
| sipa | you can't solve that problem | 19:09 |
| bsm1175321 | I can. Using UTXOs on a blockchain. | 19:10 |
| sipa | if i lose my key, i can't spend that utxo | 19:10 |
| sipa | you're using the blockchain as a publishing mechanism for revocation certificates | 19:10 |
| sipa | i guess that works | 19:11 |
| sipa | it's a use for proof of publication | 19:11 |
| bsm1175321 | The key you lost corresponds to an *already* *spent* UTXO. The next spend comes from a *different* key, held in a different location. | 19:11 |
| sipa | but it only works if you don't lose the key | 19:11 |
| bsm1175321 | You can lose the key. | 19:11 |
| sipa | i don't understand | 19:11 |
| bsm1175321 | People will lose keys. I assume it. | 19:11 |
| bsm1175321 | I'm making a chain of transactions, using the most recently *spent* transaction (which reveals a pubkey) for authentication/code signing. | 19:12 |
| sipa | ok, so there is a stronger key held more securely that can sign revocations | 19:12 |
| sipa | what if you lose that one? | 19:12 |
| bsm1175321 | Ok so you can do that, but you still have a problem of publishing the revocations. | 19:13 |
| sipa | agree | 19:13 |
| bsm1175321 | CRL's generally exist at a HTTP endpoint that an attacker can DDoS. | 19:13 |
| sipa | i disagree that a blockchain is the best solution for it | 19:13 |
| sipa | but i agree it's a use case for a block chain | 19:13 |
| * bsm1175321 lets sipa think on it. | 19:13 | |
| bsm1175321 | I think it's a *perfect* use case for a non-fungible blockchain. (but, let's improve fungibility too) | 19:14 |
| sipa | any use for proof of publication is vulnerable to censorship | 19:14 |
| sipa | and a non-fungible blockchain (in extresis) won't have valuable tokens, which means it can't provide security | 19:15 |
| sipa | *extremis | 19:15 |
| bsm1175321 | Any financial system in which the counterparty can't be reliably identified is unusable. | 19:16 |
| bsm1175321 | We need both. | 19:16 |
| bsm1175321 | And proof-of-work is the best way to secure both. | 19:17 |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 244 seconds] | 19:20 | |
| -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 244 seconds] | 19:21 | |
| -!- aem [AEM@gateway/shell/elitebnc/x-ledhrzcewhohrera] has quit [Remote host closed the connection] | 19:32 | |
| -!- AEM [AEM@gateway/shell/elitebnc/x-eqpxnamdgnopxpzr] has joined #bitcoin-wizards | 19:36 | |
| -!- AEM is now known as aem | 19:38 | |
| -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 19:44 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] | 19:51 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards | 19:53 | |
| -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds] | 20:18 | |
| -!- pro [~pro@unaffiliated/pro] has quit [Quit: Leaving] | 20:19 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 20:26 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 248 seconds] | 20:33 | |
| -!- jron [~okok@ec2-54-161-129-226.compute-1.amazonaws.com] has quit [Ping timeout: 244 seconds] | 20:37 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 20:41 | |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] | 20:43 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 20:50 | |
| -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards | 21:00 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 250 seconds] | 21:18 | |
| qpm | tx:<Jeremy_Rand> bsm1175321: FYI Namecoin has been exploring the possibility of naming PGP key fingerprints (or similar public key material) | 21:47 |
| bsm1175321 | Jeremy_Rand see also blockstack and onename on that topic. | 21:48 |
| qpm | tx:<Jeremy_Rand> bsm1175321: Yes, I'm aware of Blockstack. Their work is, in my opinion, not particularly useful, because (among other things) their transaction validity isn't backed by PoW. | 21:49 |
| bsm1175321 | I have no interest in naming. Naming creates a market for things which can be remembered, transcribed through meat-space, and chiseled onto stone tablets. A txid (or pubkey) is a perfect identifier, though not memorable. But who cares? I have software for that. | 21:50 |
| qpm | tx:<Jeremy_Rand> It's trivially easy to construct a transaction that looks just like a Blockstack transaction (it's a Bitcoin tx that has an OP_RETURN script), and there's no way to prove that my transaction is invalid without inspecting the entire Bitcoin chain | 21:51 |
| bsm1175321 | I agree, and that's why my proposal (above) does not rely on OP_RETURN. | 21:51 |
| bsm1175321 | There's a new security model here not only for fungible assets, but for non-fungible identities, and light clients can use it by tracking block headers (with the addition of UTXO set commitments) | 21:52 |
| qpm | tx:<Jeremy_Rand> bsm1175321: Namecoin's utility for things like this, IMO, is that you can have one key that owns the Namecoin name, and that key can sign new transactions that authorize new PGP keys or revoke existing ones | 21:53 |
| qpm | tx:<Jeremy_Rand> The ability to have a human meaningful name for that identity is cool too of course | 21:53 |
| bsm1175321 | I'm punting on the human readable part. There's a lot of utility to be found by abandoning it. I have software for that. Once that punt is accepted, Bitcoin as it stands is a powerful alternative. | 21:54 |
| qpm | tx:<Jeremy_Rand> Although gmaxwell's concerns about it being easy to construct near-colliding human-meaningful names are valid, and dealing with them is nontrivial | 21:54 |
| bsm1175321 | That's easy to solve: stop transcribing identities through your head-meat. It's not as good at it as my software. | 21:55 |
| othe | human readability just introduces namesquatting | 21:55 |
| bsm1175321 | Let markets develop elsewhere. It doesn't belong in the protocol. | 21:55 |
| qpm | tx:<Jeremy_Rand> bsm1175321: well, if you don't have human-readable names, that does decrease usability for some use cases. I agree totally that getting rid of human-readable names does result in more confidence in the system from a cryptographic standpoint. | 21:56 |
| othe | the sites who use that identity should deal with it themselves, mapping a pubkey to a username is no big deal | 21:56 |
| bsm1175321 | Jeremy_Rand: put a directory server that translates long identifiers into human-readable names somewhere. Put it in software. Don't make me fuck with it. | 21:56 |
| qpm | tx:<Jeremy_Rand> othe: last I heard about 50% of ICANN names are squatted. That's a significant number, but that also means that 50% of the names are nonsquatted, which isn't incredibly bad. | 21:57 |
| bsm1175321 | That's (at least) a 50% probability that I'll mis-identify a counterparty in a transaction/interaction. We can do better. | 21:58 |
| qpm | tx:<Jeremy_Rand> bsm1175321: well, then you've got a trusted party in the directory server, right? Or are you proposing a different way of doing the mapping? | 21:58 |
| bsm1175321 | Software identifies the counterparty, not my head-meat. Not the name mapping. Name-mapping is only for visual display and convenience, not authentication/authorization. | 21:59 |
| qpm | tx:<Jeremy_Rand> bsm1175321: I don't follow how you're inferring the risk of fraud from the fraction of squatted names | 21:59 |
| bsm1175321 | Wait, did I seriously just buy something from amaz0n.com? | 21:59 |
| qpm | tx:<Jeremy_Rand> Have you ever mistyped amaz0n.com into your web browser? | 22:00 |
| bsm1175321 | Or was it amazondot.com? Or ama2on.com? Fuck if my head-meat and font interpreter can tell. | 22:00 |
| bsm1175321 | I clicked on an ad, as many unawares users do... | 22:00 |
| othe | i mistyped ebay 2 minutes ago, entered ebaz as i am in nyc on a non german keyboard...happens all the time for me. | 22:00 |
| qpm | tx:<Jeremy_Rand> othe: interesting. That said, I don't think it's accurate to infer 50% chance of fraud based on 50% squatted names as bsm1175321 suggested | 22:01 |
| bsm1175321 | It even had a valid certificate from some craptacular authority in bazquuxistan. It was green in my browser bar. I didn't question it. | 22:01 |
| othe | qpm, if u have something like global unique human readable names... theres like 1mio people called adam smith prolly...it just wont work, every service provider has to do the mapping himself | 22:02 |
| bsm1175321 | Jeremy_Rand doesn't matter, it's way too high. Computers will NEVER tell you that all 32-bytes of A equal all 32-bytes of B unless they actually do. Let software do the hard work of deciding that A (seller) = B (payment account) | 22:02 |
| sipa | qpm: i don't understand the interest in namecoin | 22:02 |
| sipa | it's a very interesting problem, but a completely backwards solution | 22:02 |
| qpm | tx:<Jeremy_Rand> sipa: may I ask what you consider completely backwards? | 22:03 |
| sipa | either it functions as a currency, and nobody will use it for name registration | 22:03 |
| sipa | or it functions as a nameservice, and its currency aspect will fail to protect against dos | 22:04 |
| sipa | there is no reason why the price for registration needs to be tied to the exchange rate | 22:04 |
| qpm | tx:<Jeremy_Rand> sipa: I'm not an economist, but if a nameservice blockchain has tokens that are worth 1 registration, then those tokens end up with an exchange rate roughly equivalent to the market value of being able to register a name | 22:05 |
| qpm | tx:<Jeremy_Rand> am I incorrect? | 22:05 |
| sipa | yes, and there is no reason why that is tied to the capacity of the system | 22:05 |
| sipa | you have two parameters, the security of the system and the cost of registration | 22:07 |
| sipa | in namecoin they are both defined by the exchange rate | 22:07 |
| qpm | tx:<Jeremy_Rand> btw, I definitely agree that it's unpleasant to have a naming system that has an exchange rate that isn't pegged to some price that's meaningful to humans (i.e. the price of NMC is relatively volatile) | 22:07 |
| qpm | tx:<Jeremy_Rand> sipa: if we consider a hypothetical Namecoin-like chain where name renewals require paying $10 USD per year to miners, and we assume a significant number of names (say, a small TLD's level), my guess is that that would confer a fairly large amount of security in terms of miner fees. But I haven't chugged those numbers lately. | 22:09 |
| bsm1175321 | By separating naming from authentication/authorization, the naming becomes purely a UI/UX feature. I really don't care how many other assholes claim to be amaz0n.com, my software will never get it wrong after the first time I visit the real amazon.com. My eyeballs will. | 22:11 |
| qpm | tx:<Jeremy_Rand> sipa: I'm curious if you would consider the problems you're describing to be improvable by using a Namecoin-like system that's a pegged sidechain using BTC to register names? | 22:12 |
| sipa | i'm not sure | 22:14 |
| bsm1175321 | FWIW I'm unconvinced that the naming component needs PoW protection. The only reason namecoin thinks it needs protection is that names are actually being used, today, for *authentication*. Which, is a dumb thing to do, really. | 22:15 |
| sipa | i feel there is a fundamental problem between payinfg for security and exchange rates | 22:15 |
| sipa | a sidechain also has no more security than its fees/... whatever pay miners | 22:16 |
| qpm | tx:<Jeremy_Rand> hmm, so I just did some math, if you assume 10 million names in the system and $10 per year renewal, then you end up with 10,000,000 * 10 / 365 / 24 / 6 = 1902 USD in fees per block | 22:19 |
| qpm | tx:<Jeremy_Rand> that's not a lot of fees, unfortunately (compared to Bitcoin's chain, at least) | 22:19 |
| sipa | that means that for 20000$ i can probably have the chain reorged if i don't like that my competitor got a name instead of me | 22:20 |
| qpm | tx:<Jeremy_Rand> Yeah, that is indeed quite low :( | 22:21 |
| bsm1175321 | There are many, many more financial participants than registered DNS names, and all of them don't want to end up paying the wrong person. | 22:22 |
| qpm | tx:<Jeremy_Rand> sipa: on the other hand, 10 million names might be a fairly low estimate depending on what use cases we're talking. DNS has about 100 million users (plus 100 million squatted names), but if we consider identities, it's a lot more. There are far more Internet users than websites. | 22:23 |
| qpm | tx:<Jeremy_Rand> Even so, I agree with you that fees and security are problematic with a low number of users. | 22:24 |
| sipa | and with a high number of users, you get scalability problems | 22:25 |
| sipa | namecoin scales even worse than bitcoin as you need go keep spent records | 22:25 |
| qpm | tx:<Jeremy_Rand> sipa: right, so based on back of napkin calculations I did a while back, if you had about 100 million names, you would end up with a block size of circa 3 to 4 MB | 22:25 |
| sipa | but you can't prunr | 22:26 |
| sipa | block size is only one side of scalability | 22:26 |
| qpm | tx:<Jeremy_Rand> sipa: I think it's possible to only keep the hashes of name values in permanent storage. You could keep the expansions of the hashes in a separate data structure (sort of like SegWit), and nodes could throw out that data structure after a couple years since it's not consensus-critical | 22:27 |
| sipa | utxo set size, block chain size, ... may much more easily become dominant for a namecoin like system | 22:27 |
| sipa | maybe | 22:27 |
| sipa | but what if a miner wants a name for themselves? | 22:28 |
| -!- cdecker [~cdecker@184.68.38.206] has joined #bitcoin-wizards | 22:28 | |
| sipa | they can censor attempts to register or renew that name | 22:28 |
| qpm | tx:<Jeremy_Rand> sipa: in terms of UTXO set size, Aaron Swartz's Nakanames proposal (which basically described something like Namecoin) included an estimate of the UTXO set size, it was around 16 GB for the DNS use case I believe | 22:28 |
| * bsm1175321 continues to harp on disassociating names from identity... | 22:29 | |
| qpm | tx:<Jeremy_Rand> sipa: how is that fundamentally different from a Bitcoin miner attempting to censor transactions from UTXO's they don't like? In a naming system they could force it to expire rather than having to attack it forever, | 22:30 |
| qpm | tx:<Jeremy_Rand> but it's still difficult | 22:30 |
| sipa | qpm: bitcoin addresses are not identities | 22:30 |
| sipa | and you can't censor what you don't understand what it's for | 22:31 |
| qpm | tx:<Jeremy_Rand> sipa: Are you referring to the expected reward for pulling off such an attack, or are you saying something else? | 22:31 |
| -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] | 22:31 | |
| sipa | no, miners just don't know what to censor | 22:31 |
| qpm | tx:<Jeremy_Rand> sipa: ah. Right, to do the attack for Bitcoin you would need to know what UTXO's to target | 22:31 |
| sipa | assuming decent fungibility | 22:31 |
| qpm | tx:<Jeremy_Rand> sipa: my assumption is that in Bitcoin, even if miners did know what to censor, it would be difficult to actually perform the censorship, based on the difficulty of getting a majority of hashrate to attack the system. If that assumption is wrong, then Bitcoin is likely to have trouble too at some point. | 22:33 |
| -!- mintmoney [~whosed2@c-71-225-146-175.hsd1.pa.comcast.net] has joined #bitcoin-wizards | 22:33 | |
| mintmoney | Hi everyone! We have built a google survey regarding a startup charity's name selection! We could use all the feedback that we can get & it's only 3 questions, so please take 1 minute: https://goo.gl/forms/tgUGKxdlKXUTHlLd2 | 22:33 |
| -!- MoALTz [~no@78-11-247-26.static.ip.netia.com.pl] has joined #bitcoin-wizards | 22:33 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 22:34 | |
| midnightmagic | :-/ | 22:34 |
| bsm1175321 | Hahaaa I name the Red Cr0ss. | 22:35 |
| qpm | * tx:Jeremy_Rand didn't know that "startup charity" was a term that was used | 22:36 |
| -!- mode/#bitcoin-wizards [+o midnightmagic] by ChanServ | 22:37 | |
| -!- mode/#bitcoin-wizards [+b *!*@c-71-225-146-175.hsd1.pa.comcast.net] by midnightmagic | 22:38 | |
| -!- mintmoney was kicked from #bitcoin-wizards by midnightmagic [reasons] | 22:38 | |
| -!- mode/#bitcoin-wizards [-o midnightmagic] by midnightmagic | 22:38 | |
| bsm1175321 | Awwww, that troll was making my point for me... | 22:38 |
| qpm | tx:<Jeremy_Rand> So if you assume 100 million names (which is conceivable if identities are the use case, since there's billions of people in the world), you wind up with (I think) more miner fees per block than the current Bitcoin block subsidy | 22:40 |
| qpm | tx:<Jeremy_Rand> (roughly 30 BTC if my math is right) | 22:41 |
| bsm1175321 | Identity needs to be tied to assets, in a very deep way. Because my attempt to transfer 30M USD needs to be tied to my counterparty risk, which is, coincidentally... 30M USD. | 22:44 |
| qpm | tx:<Jeremy_Rand> sipa / bsm1175321: anyway thanks for the chat -- excellent points. Gotta get some sleep now, I'd love to talk more about this sometime. | 22:48 |
| bsm1175321 | likewise! | 22:49 |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jtmmhoetlnprdfpq] has joined #bitcoin-wizards | 22:54 | |
| -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has quit [Quit: Three sheets to the wind] | 22:56 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 23:07 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] | 23:11 | |
| -!- NewLiberty [~NewLibert@172.58.40.145] has joined #bitcoin-wizards | 23:12 | |
| -!- assder [d4555899@gateway/web/freenode/ip.212.85.88.153] has joined #bitcoin-wizards | 23:28 | |
| fluffypony | Jeremy_Rand: just wait till "startup charities" start ICO'ing | 23:32 |
| -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-wizards | 23:40 | |
| -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 23:45 | |
| -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Changing host] | 23:49 | |
| -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-wizards | 23:49 | |
| --- Log closed Fri Sep 16 00:00:55 2016 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!