--- Log opened Thu Sep 15 00:00:54 2016
00:08 -!- 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:09 -!- lmatteis [uid3300@gateway/web/irccloud.com/x-fpiwfuhqariyqfxs] has joined #bitcoin-wizards
00:10 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-itusvovcfdzicgvj] has joined #bitcoin-wizards
00:15 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-mpgyffmrauxeavgv] has joined #bitcoin-wizards
00:16 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-mpgyffmrauxeavgv] has quit [Client Quit]
00:17 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-upchjwuqyoijfnjx] has joined #bitcoin-wizards
00:19 -!- 1JTAA9IUE [~hashtagg_@cpe-174-97-254-80.ma.res.rr.com] has quit [Ping timeout: 250 seconds]
00:20 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
00:22 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
00:24 -!- cdecker [~cdecker@184.68.38.206] has joined #bitcoin-wizards
00:39 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
00:42 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 265 seconds]
00:55 -!- bildramer1 [~bildramer@2001:0:5ef5:79fd:492:1e20:a237:51b5] has quit [Ping timeout: 248 seconds]
00:57 -!- bildramer [~bildramer@p5DC8AE4A.dip0.t-ipconnect.de] has joined #bitcoin-wizards
01:03 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
01:10 -!- cdecker [~cdecker@184.68.38.206] has quit [Ping timeout: 240 seconds]
01:34 -!- nanasho [~nanashi@host-188-174-248-58.customer.m-online.net] has joined #bitcoin-wizards
01:34 < nanasho> Hello mates
01:48 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-wizards
01:55 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 240 seconds]
01:55 -!- gielbier [~gielbier@unaffiliated/gielbier] has joined #bitcoin-wizards
02:07 -!- skang404 [~skang404@27.6.192.89] has joined #bitcoin-wizards
02:14 -!- skang404 [~skang404@27.6.192.89] has quit [Ping timeout: 265 seconds]
02:41 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-wizards
03:04 -!- skang404 [~skang404@223.176.171.112] has joined #bitcoin-wizards
03:08 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards
03:11 -!- skang404 [~skang404@223.176.171.112] has quit [Ping timeout: 240 seconds]
03:13 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Quit: laurentmt]
03:20 -!- edvorg [~edvorg@14.169.89.229] has joined #bitcoin-wizards
03:26 -!- Emcy_ [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards
03:33 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds]
03:53 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
03:57 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards
03:58 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit]
04:15 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 265 seconds]
04:26 -!- hashtag [~hashtagg_@cpe-174-97-254-80.ma.res.rr.com] has joined #bitcoin-wizards
04:30 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
04:32 -!- skang404 [~skang404@223.176.171.112] has joined #bitcoin-wizards
04:40 -!- skang404 [~skang404@223.176.171.112] has quit [Ping timeout: 265 seconds]
04:45 -!- skang404 [~skang404@27.6.192.89] has joined #bitcoin-wizards
04:53 -!- skang404 [~skang404@27.6.192.89] has quit [Ping timeout: 260 seconds]
05:05 -!- skang404 [~skang404@27.6.192.89] has joined #bitcoin-wizards
05:09 -!- Guest29379 is now known as starsoccer
05:11 -!- 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:12 -!- 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:21 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards
05:21 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit]
05:24 -!- Cloudflare [~Cloudflar@unaffiliated/cloudflare] has quit [Quit: Bye]
05:24 -!- mryandao [~mryandaoI@unaffiliated/mryandao] has quit [Quit: do not disturb. look busy...]
05:26 -!- mryandao [~mryandaoI@45.32.191.82] has joined #bitcoin-wizards
05:26 -!- Cloudflare [~Cloudflar@unaffiliated/cloudflare] has joined #bitcoin-wizards
05:31 -!- pro [~pro@unaffiliated/pro] has joined #bitcoin-wizards
05:32 -!- skang404 [~skang404@27.6.192.89] has joined #bitcoin-wizards
05:35 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
05:39 -!- skang404 [~skang404@27.6.192.89] has quit [Ping timeout: 265 seconds]
05:39 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
05:45 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
05:49 -!- 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:50 -!- mryandao [~mryandaoI@45.32.191.82] has joined #bitcoin-wizards
05:51 -!- 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:53 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Ping timeout: 265 seconds]
05:54 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
06:06 -!- nikivi [~nikivi@wlan-200025.nbw.tue.nl] has joined #bitcoin-wizards
06:19 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
06:21 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Remote host closed the connection]
06:24 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
06:28 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Read error: Connection reset by peer]
06:32 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-wizards
06:38 -!- Noldorin_ [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
06:41 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 244 seconds]
06:42 -!- e_0 [~e0@cs10-dhcp10.bu.edu] has quit [Ping timeout: 240 seconds]
06:43 -!- nikivi [~nikivi@wlan-200025.nbw.tue.nl] has quit [Quit: irc]
06:43 -!- Noldorin_ [~noldorin@unaffiliated/noldorin] has quit [Ping timeout: 248 seconds]
06:47 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards
06:47 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit]
06:49 -!- nikivi [~nikivi@wlan-200025.nbw.tue.nl] has joined #bitcoin-wizards
06:49 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards
06:55 -!- cjd [~user@2c0f:f930:2:12::] has quit [Ping timeout: 248 seconds]
07:11 -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards
07:12 -!- nikivi [~nikivi@wlan-200025.nbw.tue.nl] has quit [Quit: irc]
07:22 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards
07:23 -!- edvorg [~edvorg@14.169.89.229] has quit [Ping timeout: 250 seconds]
07:27 -!- cjd [~user@2c0f:f930:2:12::] has joined #bitcoin-wizards
07:27 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Quit: laurentmt]
07:44 < kinlo> ±.
07:46 -!- nanasho [~nanashi@host-188-174-248-58.customer.m-online.net] has quit [Remote host closed the connection]
07:51 -!- Starduster [~guest@unaffiliated/starduster] has joined #bitcoin-wizards
08:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
08:14 -!- e4xit_ [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-wizards
08:16 -!- 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:17 -!- 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:25 < 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:36 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards
08:37 < bsm117532> Cool.  amiller was working on something similar with "proofs of proofs of work"
08:41 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit]
08:45 -!- MoALTz [~no@78-11-247-26.static.ip.netia.com.pl] has joined #bitcoin-wizards
08:49 -!- Noldorin_ [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
08:52 -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has quit [Ping timeout: 265 seconds]
08:55 -!- Emcy_ [~MC@unaffiliated/mc1984] has quit [Read error: Connection reset by peer]
08:55 -!- Noldorin_ [~noldorin@unaffiliated/noldorin] has quit [Ping timeout: 265 seconds]
09:06 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards
09:06 -!- mountaingoat [~mountaing@gateway/vpn/privateinternetaccess/mountaingoat] has joined #bitcoin-wizards
09:08 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit]
09:16 < amiller> the author of this post isn't aware of http://fc16.ifca.ai/bitcoin/papers/KLS16.pdf which solves that problem
09:17 < bsm117532> You should make that comment on his blog. ;-)
09:29 -!- Emcy [~MC@213.107.7.236] has joined #bitcoin-wizards
09:30 -!- Emcy [~MC@213.107.7.236] has quit [Changing host]
09:30 -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards
09:31 < kanzure> "The bumpy road towards iPhone 5c NAND mirroring" http://arxiv.org/abs/1609.04327
09:33 < kabaum> Thanks. I'm looking at the paper right now.
09:33 < kabaum> Thanks kanzure for pointing me here
09:33 < kanzure> yep...
09:38 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has joined #bitcoin-wizards
09:40 -!- laurentmt [~Thunderbi@80.215.234.166] has joined #bitcoin-wizards
09:40 -!- laurentmt [~Thunderbi@80.215.234.166] has quit [Client Quit]
09:43 < kabaum> I mean the http://fc16.ifca.ai/bitcoin/papers/KLS16.pd paper. Just to avoid misunderstanding.
09:47 -!- Noldorin_ [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
09:51 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services]
09:51 -!- [7] [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
09:56 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
09:57 -!- Noldorin_ is now known as Noldorin
10:01 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 276 seconds]
10:03 < 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:04 < 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:05 < andytoshi> but there are a lot of straggling non-skip blocks near the end
10:08 < 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:14 < 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:20 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 250 seconds]
10:24 < 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:26 -!- echonaut1 [~echonaut@46.101.192.134] has quit [Remote host closed the connection]
10:27 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-wizards
10:37 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Ping timeout: 265 seconds]
10:42 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
10:56 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-wizards
11:11 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
11:26 -!- Sleepnbum [Sleepnbum@72.67.47.196] has joined #bitcoin-wizards
11:41 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
11:59 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds]
12:00 -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-wizards
12:00 < andytoshi> maaku: ah, i am not
12:01 < 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:08 -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 240 seconds]
12:10 -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-wizards
12:25 < maaku> optimal solutions involve dynamic programming, which is not crazy complex, but not something I'd want in consensus code either
12:26 < 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:27 < 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:32 -!- 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:33 < 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:39 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam]
12:45 -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 276 seconds]
12:49 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
12:52 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
12:54 < 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:55 < 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:57 -!- MoALTz [~no@78-11-247-26.static.ip.netia.com.pl] has quit [Quit: Leaving]
12:58 < 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:59 < maaku> bsm117532: have you looked at monotone?
12:59 < bsm117532> The RCS software?
13:04 < 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:05 < 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:06 < 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:07 < 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:08 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
13:11 < 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:12 < 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:13 < petertodd> e.g. does your scheme need a timestamp proof? an anti-replay mechanism? a proof-of-publication?
13:14 < maaku> bsm117532: yes, http://monotone.ca/
13:17 < 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:18 < 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:19 < petertodd> bsm117532: what, specifically, is this preventing from happening?
13:19 < sipa> bsm117532: i generally dislike hacking bitcoin keys into reusable identities
13:20 < 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:21 < sipa> and it creates incentives to break fungibility for solving a problem that it wasn't intended to solve
13:22 < 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:23 < 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:24 < 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:25 < 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:26 < 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:27 < 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:28 < 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:29 < 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:30 < 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:31  * bsm117532 looks at the number of P2SH addresses...as evidence that old features will likely never be able to be soft-forked out...
13:32 < 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:33 < 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:34 < 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:35 < 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:37 < 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:38 < 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:39 < 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:40 < 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:41 < sipa> you can just reveal the key through whatever channel you'd use to reveal the txid
13:42 < petertodd> bsm117532: you should read this: https://github.com/petertodd/ID2020DesignWorkshop/blob/6918aa3cae5c2fc75c94c9c4e19121ca52446606/topics-and-advance-readings/DexPredicatesForSmarterSigs.md
13:43 < 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:45 < katu> re: fungibility, miners can incentivize it. by demanding much higher fees for inputs with reused address.
13:47 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-wizards
13:57 < 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:58 < 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!)
14:06 -!- Tenhi_ [~tenhi@static.177.80.201.138.clients.your-server.de] has joined #bitcoin-wizards
14:10 < sipa> bsm117532: you want revocability and protection on the link with identity
14:11 < sipa> on the blockchain itself is only a key
14:11 < sipa> it can be anyone's
14:16 -!- Tenhi_ [~tenhi@static.177.80.201.138.clients.your-server.de] has quit [K-Lined]
14:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 244 seconds]
14:44 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
14:45 -!- 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:46 -!- 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:47 -!- 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:48 -!- _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:50 -!- 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:51 -!- Lightsword [~Lightswor@107.170.253.193] has joined #bitcoin-wizards
14:52 -!- 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:53 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-wizards
14:54 -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-wizards
14:55 -!- 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:56 -!- wpalczynski [sid55851@gateway/web/irccloud.com/x-rhlrallynindltyu] has joined #bitcoin-wizards
14:57 -!- kumavis [sid13576@gateway/web/irccloud.com/x-mtiveusourzqyjvr] has joined #bitcoin-wizards
15:01 -!- baffo32 [baffo32@gateway/shell/layerbnc/x-xeeyszsxgjeqphkd] has joined #bitcoin-wizards
15:09 -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 260 seconds]
15:10 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
15:14 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds]
15:23 -!- jnewbery [~jnewbery@67.251.193.154] has joined #bitcoin-wizards
15:28 -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-wizards
15:30 -!- jnewbery [~jnewbery@67.251.193.154] has quit []
15:31 < 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:32 < bsm117532> Bitcoin transactions can indicate revocation.
15:33 < 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:35 < 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:58 < 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?
16:02 < 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:03 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
16:12 -!- JHistone [~JHistone@cpc104808-sgyl39-2-0-cust135.18-2.cable.virginm.net] has quit [Quit: Leaving]
16:13 < 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:14 < 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:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
16:19 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]
16:21 -!- Sleepnbum [Sleepnbum@72.67.47.196] has quit [Ping timeout: 244 seconds]
16:23 < 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:25 < 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:33 -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving]
16:35 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam]
16:37 -!- adiabat [~adiabat@159.203.193.74] has quit [Remote host closed the connection]
16:50 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds]
16:52 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 244 seconds]
16:54 -!- superkuh [~superkuh@unaffiliated/superkuh] has quit [Ping timeout: 265 seconds]
16:55 -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 244 seconds]
17:02 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
17:03 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
17:07 < 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:08 -!- superkuh_ is now known as superkuh
17:22 -!- AaronvanW [~ewout@185pc230.sshunet.nl] has quit [Read error: Connection reset by peer]
17:26 -!- neha [~narula@tbilisi.csail.mit.edu] has quit [Remote host closed the connection]
17:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
17:37 -!- cdecker [~cdecker@184.68.47.6] has joined #bitcoin-wizards
17:43 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 264 seconds]
17:55 -!- harrymm [~wayne@104.222.140.120] has quit [Remote host closed the connection]
17:56 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wmccdywsmlpiopbp] has quit [Quit: Connection closed for inactivity]
17:58 -!- harrymm [~wayne@104.222.140.128] has joined #bitcoin-wizards
17:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
18:08 -!- bsm117532- [~AndChat70@rrcs-50-74-107-234.nyc.biz.rr.com] has joined #bitcoin-wizards
18:10 < 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:11 < sipa> you can just ask them to sign a message again
18:11 < sipa> then you also know the key is still valid
18:14 -!- mountaingoat [~mountaing@gateway/vpn/privateinternetaccess/mountaingoat] has quit [Ping timeout: 265 seconds]
18:15 < sipa> also, the presense of a utxo does not mean they didn't lose the key
18:17 -!- bsm117532- [~AndChat70@rrcs-50-74-107-234.nyc.biz.rr.com] has quit [Ping timeout: 272 seconds]
18:20 < kanzure> and the lack of presence of utxo too
18:30 -!- 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:31 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
18:32 -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has joined #bitcoin-wizards
18:36 -!- superkuh [~superkuh@unaffiliated/superkuh] has quit [Ping timeout: 264 seconds]
18:37 < 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:38 < bsm1175321> I think it's impossible to prove your key hasn't been copied...
18:48 -!- superkuh [~superkuh@unaffiliated/superkuh] has joined #bitcoin-wizards
18:58 < sipa> i still don't understand what the blockchain offers here
18:59 < 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
19:00 < sipa> you don't know it is not copied, but the other party hurts itself only by doing so
19:01 < sipa> but you do know it's live
19:06 < 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:07 -!- 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:08 < 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:09 < 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:10 < 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:11 < 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:12 < 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:13 < 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:14 < 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:15 < 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:16 < bsm1175321> Any financial system in which the counterparty can't be reliably identified is unusable.
19:16 < bsm1175321> We need both.
19:17 < bsm1175321> And proof-of-work is the best way to secure both.
19:20 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 244 seconds]
19:21 -!- cdecker [~cdecker@184.68.47.6] has quit [Ping timeout: 244 seconds]
19:32 -!- aem [AEM@gateway/shell/elitebnc/x-ledhrzcewhohrera] has quit [Remote host closed the connection]
19:36 -!- AEM [AEM@gateway/shell/elitebnc/x-eqpxnamdgnopxpzr] has joined #bitcoin-wizards
19:38 -!- AEM is now known as aem
19:44 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
19:51 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:53 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards
20:18 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]
20:19 -!- pro [~pro@unaffiliated/pro] has quit [Quit: Leaving]
20:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
20:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 248 seconds]
20:37 -!- jron [~okok@ec2-54-161-129-226.compute-1.amazonaws.com] has quit [Ping timeout: 244 seconds]
20:41 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam]
20:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
20:50 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
21:00 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
21:18 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 250 seconds]
21:47 < qpm> tx:<Jeremy_Rand> bsm1175321: FYI Namecoin has been exploring the possibility of naming PGP key fingerprints (or similar public key material)
21:48 < bsm1175321> Jeremy_Rand see also blockstack and onename on that topic.
21:49 < 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:50 < 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:51 < 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:52 < 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:53 < 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:54 < 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:55 < 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:56 < 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:57 < 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:58 < 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:59 < 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?
22:00 < 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:01 < 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:02 < 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:03 < 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:04 < 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:05 < 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:07 < 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:09 < 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:11 < 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:12 < 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:14 < sipa> i'm not sure
22:15 < 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:16 < sipa> a sidechain also has no more security than its fees/... whatever pay miners
22:19 < 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:20 < 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:21 < qpm> tx:<Jeremy_Rand> Yeah, that is indeed quite low :(
22:22 < 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:23 < 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:24 < qpm> tx:<Jeremy_Rand> Even so, I agree with you that fees and security are problematic with a low number of users.
22:25 < 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:26 < sipa> but you can't prunr
22:26 < sipa> block size is only one side of scalability
22:27 < 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:28 < 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:29  * bsm1175321 continues to harp on disassociating names from identity...
22:30 < 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:31 < 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:33 < 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:34 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
22:34 < midnightmagic> :-/
22:35 < bsm1175321> Hahaaa I name the Red Cr0ss.
22:36 < qpm> * tx:Jeremy_Rand didn't know that "startup charity" was a term that was used
22:37 -!- mode/#bitcoin-wizards [+o midnightmagic] by ChanServ
22:38 -!- 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:40 < 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:41 < qpm> tx:<Jeremy_Rand> (roughly 30 BTC if my math is right)
22:44 < 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:48 < 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:49 < bsm1175321> likewise!
22:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jtmmhoetlnprdfpq] has joined #bitcoin-wizards
22:56 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has quit [Quit: Three sheets to the wind]
23:07 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
23:11 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
23:12 -!- NewLiberty [~NewLibert@172.58.40.145] has joined #bitcoin-wizards
23:28 -!- assder [d4555899@gateway/web/freenode/ip.212.85.88.153] has joined #bitcoin-wizards
23:32 < fluffypony> Jeremy_Rand: just wait till "startup charities" start ICO'ing
23:40 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-wizards
23:45 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
23:49 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Changing host]
23:49 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-wizards
--- Log closed Fri Sep 16 00:00:55 2016