--- Log opened Tue Jul 05 00:00:48 2016 | ||
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 00:02 | |
-!- cypher__ [~cypher@97-85-41-80.dhcp.bycy.mi.charter.com] has joined #bitcoin-wizards | 00:03 | |
-!- agorist000 [~cypher@unaffiliated/agorist000] has quit [Ping timeout: 246 seconds] | 00:06 | |
-!- warren [~warren@fedora/wombat/warren] has quit [Ping timeout: 240 seconds] | 00:16 | |
-!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 252 seconds] | 00:16 | |
-!- jessepollak [~jessepoll@104.131.138.130] has quit [Ping timeout: 240 seconds] | 00:17 | |
-!- LeMiner [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 252 seconds] | 00:17 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards | 00:19 | |
-!- Lightsword [~Lightswor@107.170.253.193] has quit [Ping timeout: 276 seconds] | 00:19 | |
-!- warren [~warren@fedora/wombat/warren] has joined #bitcoin-wizards | 00:21 | |
-!- jessepollak [~jessepoll@104.131.138.130] has joined #bitcoin-wizards | 00:22 | |
-!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has joined #bitcoin-wizards | 00:24 | |
-!- afk11 [~afk11@109.255.154.81] has joined #bitcoin-wizards | 00:25 | |
-!- afk11 [~afk11@109.255.154.81] has quit [Changing host] | 00:25 | |
-!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-wizards | 00:25 | |
-!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Changing host] | 00:26 | |
-!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-wizards | 00:26 | |
-!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-wizards | 00:28 | |
-!- murch [~murch@p4FE3A827.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 00:34 | |
-!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards | 00:46 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] | 01:02 | |
-!- edvorg [~edvorg@14.186.80.50] has joined #bitcoin-wizards | 01:09 | |
-!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-wizards | 01:18 | |
-!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 01:18 | |
-!- xsdfdfsa [~x@unaffiliated/sdfgsdfg] has joined #bitcoin-wizards | 01:19 | |
-!- rubensayshi [~ruben@82.201.93.169] has quit [Ping timeout: 260 seconds] | 01:38 | |
-!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-wizards | 01:40 | |
-!- JackH [~Jack@79-73-186-51.dynamic.dsl.as9105.com] has joined #bitcoin-wizards | 01:41 | |
-!- jannes [~jannes@178.132.211.90] has joined #bitcoin-wizards | 02:30 | |
-!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards | 02:40 | |
-!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] | 02:41 | |
-!- rubensayshi [~ruben@82.201.93.169] has quit [Ping timeout: 258 seconds] | 02:46 | |
-!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-wizards | 02:46 | |
-!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: gabridome_] | 03:01 | |
-!- Ylbam [uid99779@gateway/web/irccloud.com/x-zggashcsarwrdhur] has joined #bitcoin-wizards | 03:02 | |
-!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards | 03:06 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards | 03:07 | |
-!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards | 03:07 | |
-!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] | 03:14 | |
-!- Lysanders [~Lysanders@unaffiliated/lysanders] has joined #bitcoin-wizards | 03:29 | |
-!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards | 03:29 | |
-!- edvorg [~edvorg@14.186.80.50] has quit [Remote host closed the connection] | 03:32 | |
-!- Lysander1 [~Lysanders@unaffiliated/lysanders] has quit [Ping timeout: 246 seconds] | 03:32 | |
-!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 03:35 | |
-!- edvorg [~edvorg@14.186.80.50] has joined #bitcoin-wizards | 03:40 | |
-!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer] | 03:41 | |
-!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 03:44 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds] | 03:47 | |
-!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] | 03:50 | |
-!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: gabridome_] | 04:08 | |
-!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 252 seconds] | 04:10 | |
-!- blozo [~blozo@ppp121-44-178-241.lns20.syd7.internode.on.net] has joined #bitcoin-wizards | 04:15 | |
-!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] | 04:26 | |
-!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-wizards | 04:34 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 04:34 | |
-!- Noice_ [~Noice__@2001:1900:2104:2::86] has quit [Quit: Leaving] | 04:38 | |
-!- Noice [~Noice__@2001:1900:2104:2::86] has joined #bitcoin-wizards | 04:38 | |
-!- xsdfdfsa [~x@unaffiliated/sdfgsdfg] has quit [Remote host closed the connection] | 04:44 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] | 04:54 | |
-!- pro [~pro@unaffiliated/pro] has joined #bitcoin-wizards | 05:05 | |
-!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards | 05:05 | |
-!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: gabridome_] | 05:22 | |
-!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards | 05:44 | |
-!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] | 05:56 | |
-!- blozo [~blozo@ppp121-44-178-241.lns20.syd7.internode.on.net] has quit [Remote host closed the connection] | 06:13 | |
-!- ruby32 [~ruby32@184-207-5-121.pools.spcsdns.net] has joined #bitcoin-wizards | 06:17 | |
-!- Samdney [~Samdney@nat-wlan2.rrze.uni-erlangen.de] has joined #bitcoin-wizards | 06:19 | |
-!- ruby32d [~ruby32@184.248.11.122] has joined #bitcoin-wizards | 06:23 | |
-!- ruby32 [~ruby32@184-207-5-121.pools.spcsdns.net] has quit [Ping timeout: 240 seconds] | 06:25 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] | 06:25 | |
-!- ruby32d [~ruby32@184.248.11.122] has quit [Ping timeout: 252 seconds] | 06:51 | |
-!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards | 07:03 | |
-!- ruby32 [~ruby32@38.121.165.30] has joined #bitcoin-wizards | 07:04 | |
-!- gammastorm [~thorsten@p2003006D6E1ECE00B1895B4B7F2B7177.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 07:07 | |
gammastorm | my next sat solver is out.... wanna see it ? | 07:09 |
---|---|---|
-!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards | 07:09 | |
-!- c0rw1n_ [~c0rw1n@116.47-244-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 264 seconds] | 07:10 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 07:10 | |
-!- c0rw1n [~c0rw1n@116.47-244-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 240 seconds] | 07:11 | |
Chris_Stewart_5 | gammastorm: What are you using a sat solver for in Bitcoin? | 07:13 |
gammastorm | Chris_Stewart_5, a good sat solver makes bitcoins obsolete, as far as I understand it | 07:13 |
gammastorm | Chris_Stewart_5, are bitcoins prime numbers ? | 07:14 |
Chris_Stewart_5 | gammastorm: No, bitcoin just uses elliptic curve crypto | 07:15 |
gammastorm | Chris_Stewart_5, then a good sat solver can crack this encryption | 07:16 |
-!- Samdney [~Samdney@nat-wlan2.rrze.uni-erlangen.de] has left #bitcoin-wizards ["Verlassend"] | 07:16 | |
murch | gammastorm: You got me curious. Why would that be the case? | 07:17 |
gammastorm | normally for encryption, you have a function computing an output from an input, where when you have the output only, you will never know the input | 07:18 |
gammastorm | murch, right ? | 07:18 |
murch | Yes | 07:19 |
gammastorm | murch, but SAT solvers CAN compute the input from the outpu give the encryption algorithm as known | 07:20 |
gammastorm | murch, but SAT solvers CAN compute the input from the output, given the encryption algorithm as known | 07:20 |
murch | gammastorm: That may be so, but is it more efficient than just bruteforcing? | 07:20 |
gammastorm | muchyeah it is | 07:21 |
murch | Why? | 07:21 |
gammastorm | murch, are you a low level coder and good with theory ? | 07:21 |
gammastorm | murch, SAT Solvers do not bruteforce, they compute | 07:22 |
nsh | we probably don't need to hear about it until you factor a 1024 bit modulus with your SAT solver, gammastorm :) | 07:22 |
nsh | you can assume at that point someone will be interested | 07:22 |
murch | gammastorm: I think you have a wrong understanding of the properties of the cryptographic function in use. | 07:22 |
gammastorm | murch, maybe yes | 07:23 |
murch | A SAT solver is a program that checks whether a large number of predicates can be satisfied at the same time. | 07:24 |
gammastorm | murch, yes, and solve eliptic functions can be transformed into this problem | 07:24 |
murch | I don't think I am well versed enough in elliptic curve cryptography to completely allay that but I'd expect that partial solutions don't give you any benefit whatsoever, so I'd be very surprised if you could use a SAT solver to extract the private key from a public key. – If I understand correctly that this is what you're trying to do. | 07:27 |
-!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-wizards | 07:29 | |
Chris_Stewart_5 | I don't know much about SAT solvers, but don't they essentially prove that a there exists a key k s.t. public key p was derived from k? | 07:30 |
-!- oneeman [~oneeman@ip77-154-15-186.ct.co.cr] has joined #bitcoin-wizards | 07:30 | |
Chris_Stewart_5 | or that they prove there exists a contradiction to your assumptions? | 07:32 |
nsh | you can convert a[n ECC] discrete logarithm problem into conjunctive normal form and then solve it by constraint satisfaction | 07:32 |
nsh | for 120 bits of security, it's about 10 * 120^2 disjuncts | 07:32 |
nsh | which is hard work | 07:33 |
murch | Does that also apply to ECDSA? | 07:33 |
nsh | i would assume so, but i don't know how it would affect the complexity of the CNF representation | 07:34 |
nsh | some discussion here: https://arxiv.org/pdf/0907.1755.pdf | 07:34 |
murch | Yeah, I had found that also. | 07:34 |
nsh | not much discussion of reductions of DLP to other problem varieties that i can find. would have expected more | 07:35 |
-!- superkuh [~superkuh@unaffiliated/superkuh] has quit [Ping timeout: 272 seconds] | 07:36 | |
murch | It does seem to depend on ciphers though, and I'm not versed enough to say whether it translates to extracting one key from the other or from a signature | 07:37 |
-!- superkuh [~superkuh@unaffiliated/superkuh] has joined #bitcoin-wizards | 07:37 | |
nsh | also: http://courses.cs.washington.edu/courses/cse573/04au/Project/mini1/TheS&Ateam/SATeamFinalPaper.pdf | 07:38 |
nsh | (for RSA / prime factorization) | 07:39 |
fluffypony | someone already did the Bitcoin SAT solver thing years ago | 07:40 |
fluffypony | https://github.com/capiman/sha256-sat-bitcoin | 07:40 |
nsh | (though that's a SHA PoW solver rather than ECDLP solver) | 07:41 |
fluffypony | yesh | 07:41 |
fluffypony | https://ellipticnews.wordpress.com/2016/03/31/ecdlp-can-be-solved-in-24-th-root-time/ | 07:42 |
murch | I might be dense, but I don't get why phrasing the key relation as a set of predicate would reduce the workload to evaluate all the predicates. | 07:42 |
nsh | it probably doesn't. but SAT solvers only solve SAT problems... | 07:42 |
murch | well, it's been shown that you can translate the 21 known NP hard problems into one another, so you'd probably be able to apply any of the algorithms to all the problems. I'm just not sure that it provides a significant complexity reduction in this case. | 07:44 |
murch | fluffypony: that was an April fool's day hoax. | 07:45 |
fluffypony | awwww | 07:45 |
fluffypony | pity | 07:45 |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 258 seconds] | 07:50 | |
nsh | (there is a relation between integral points on elliptic curves and sphere packing, but it's unlikely to give such magical delights) | 07:54 |
-!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards | 07:54 | |
-!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards | 07:56 | |
-!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] | 07:57 | |
helo | i'm here for the magical delights | 08:00 |
-!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards | 08:00 | |
murch | I'd settle for some Turkish delights | 08:00 |
nsh | that's how the queen of narnia gets you... | 08:02 |
murch | nsh: I think I may be out of her typical prey pattern due to my age. :p | 08:05 |
* nsh smiles | 08:06 | |
-!- gammastorm [~thorsten@p2003006D6E1ECE00B1895B4B7F2B7177.dip0.t-ipconnect.de] has quit [Quit: Leaving] | 08:07 | |
-!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] | 08:11 | |
-!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-wizards | 08:15 | |
-!- rubensayshi [~ruben@82.201.93.169] has quit [Quit: Leaving] | 08:20 | |
-!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-wizards | 08:21 | |
-!- rubensayshi [~ruben@82.201.93.169] has quit [Remote host closed the connection] | 08:22 | |
-!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] | 08:23 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 08:27 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards | 08:36 | |
-!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards | 08:36 | |
-!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has quit [Ping timeout: 264 seconds] | 09:09 | |
-!- Tenhi [~tenhi@static-ip-69-64-50-196.inaddr.ip-pool.com] has quit [Ping timeout: 250 seconds] | 09:10 | |
-!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards | 09:15 | |
-!- zooko [~user@c-71-229-205-98.hsd1.co.comcast.net] has joined #bitcoin-wizards | 09:17 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] | 09:18 | |
-!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has joined #bitcoin-wizards | 09:21 | |
-!- Tenhi [~tenhi@static.177.80.201.138.clients.your-server.de] has joined #bitcoin-wizards | 09:23 | |
-!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #bitcoin-wizards | 09:24 | |
-!- blozo [~blozo@ppp121-44-178-241.lns20.syd7.internode.on.net] has joined #bitcoin-wizards | 09:29 | |
-!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: gabridome_] | 09:33 | |
-!- Tenhi [~tenhi@static.177.80.201.138.clients.your-server.de] has quit [K-Lined] | 09:34 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards | 09:35 | |
-!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-wizards | 10:03 | |
-!- zooko [~user@c-71-229-205-98.hsd1.co.comcast.net] has quit [Ping timeout: 258 seconds] | 10:19 | |
-!- c0rw1n [~c0rw1n@116.47-244-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 10:28 | |
-!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] | 10:35 | |
-!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] | 10:44 | |
-!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards | 10:52 | |
-!- c0rw1n_ [~c0rw1n@116.47-244-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 11:02 | |
-!- MaxSan_ [~one@46.19.137.116] has joined #bitcoin-wizards | 11:11 | |
-!- mkarrer [~mkarrer@48.red-83-47-111.dynamicip.rima-tde.net] has quit [] | 11:19 | |
-!- mkarrer [~mkarrer@48.red-83-47-111.dynamicip.rima-tde.net] has joined #bitcoin-wizards | 11:20 | |
-!- mkarrer [~mkarrer@48.red-83-47-111.dynamicip.rima-tde.net] has quit [Client Quit] | 11:21 | |
-!- CubicEarth [~cubiceart@2600:100f:b023:4432:8869:d16e:fae4:bfb7] has joined #bitcoin-wizards | 11:23 | |
-!- CubicEarth [~cubiceart@2600:100f:b023:4432:8869:d16e:fae4:bfb7] has quit [Remote host closed the connection] | 11:23 | |
-!- mkarrer [~mkarrer@48.red-83-47-111.dynamicip.rima-tde.net] has joined #bitcoin-wizards | 11:25 | |
-!- licnep [uid4387@gateway/web/irccloud.com/x-zovonqpvygdphzpa] has quit [Quit: Connection closed for inactivity] | 11:27 | |
-!- wizkid057 [~wk@unaffiliated/wizkid057] has quit [Read error: Connection reset by peer] | 11:34 | |
-!- wizkid057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards | 11:39 | |
-!- akoko [~u@77-46-245-49.dynamic.isp.telekom.rs] has left #bitcoin-wizards ["Leaving"] | 11:51 | |
-!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 11:51 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 258 seconds] | 11:58 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] | 12:09 | |
-!- go1111111 [~go1111111@104.200.154.19] has quit [Quit: Leaving] | 12:13 | |
-!- NewLiberty [~NewLibert@107-142-8-22.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards | 12:24 | |
-!- c0rw1n [~c0rw1n@116.47-244-81.adsl-dyn.isp.belgacom.be] has quit [Read error: Connection reset by peer] | 12:41 | |
-!- c0rw1n- [~c0rw1n@116.47-244-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 12:41 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards | 12:42 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Client Quit] | 12:43 | |
-!- blackwraith [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 12:59 | |
-!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 246 seconds] | 13:01 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards | 13:01 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 13:25 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] | 13:43 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards | 14:02 | |
-!- Starduster_ is now known as Starduster | 14:04 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Client Quit] | 14:05 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] | 14:11 | |
-!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] | 14:11 | |
-!- c0rw1n- [~c0rw1n@116.47-244-81.adsl-dyn.isp.belgacom.be] has quit [Read error: Connection reset by peer] | 14:20 | |
-!- c0rw1n- [~c0rw1n@116.47-244-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 14:23 | |
-!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards | 14:28 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 14:30 | |
-!- MaxSan_ [~one@46.19.137.116] has quit [Quit: Leaving.] | 14:38 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards | 14:41 | |
-!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards | 14:49 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] | 14:53 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds] | 15:07 | |
-!- BTCDoubler [~grubles@p3037-ipbf909aobadori.miyagi.ocn.ne.jp] has joined #bitcoin-wizards | 15:16 | |
BTCDoubler | [OPEN] BTC doubler service. Send me your BTC and get TWICE back. PM me to begin. 100% vouched and legit. Guaranteed. | 15:16 |
fluffypony | BTCDoubler: go away | 15:20 |
BTCDoubler | eat a dick | 15:20 |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards | 15:20 | |
-!- mode/#bitcoin-wizards [+o midnightmagic] by ChanServ | 15:23 | |
-!- BTCDoubler was kicked from #bitcoin-wizards by midnightmagic [BTCDoubler] | 15:23 | |
-!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds] | 15:23 | |
-!- BTCDoubler [~grubles@p3037-ipbf909aobadori.miyagi.ocn.ne.jp] has joined #bitcoin-wizards | 15:23 | |
BTCDoubler | [OPEN] BTC doubler service. Send me your BTC and get TWICE back. PM me to begin. 100% vouched and legit. Guaranteed. | 15:23 |
-!- ruby32 [~ruby32@38.121.165.30] has quit [Remote host closed the connection] | 15:23 | |
fluffypony | ah, I see self-correcting is not in BTCDoubler's nature. | 15:23 |
BTCDoubler | [OPEN] BTC doubler service. Send me your BTC and get TWICE back. PM me to begin. 100% vouched and legit. Guaranteed.. | 15:24 |
BTCDoubler | [OPEN] BTC doubler service. Send me your BTC and get TWICE back. PM me to begin. 100% vouched and legit. Guaranteed... | 15:24 |
fluffypony | midnightmagic ^^ | 15:24 |
qpm | tx:<Jeremy_Rand> someone please kickban this idiot | 15:24 |
BTCDoubler | [OPEN] BTC doubler service. Send me your BTC and get TWICE back. PM me to begin. 100% vouched and legit. Guaranteed.... | 15:24 |
-!- BTCDoubler was kicked from #bitcoin-wizards by midnightmagic [BTCDoubler] | 15:24 | |
@midnightmagic | yep sorry | 15:24 |
-!- r0ach [~r0ach@107-217-214-192.lightspeed.jcvlfl.sbcglobal.net] has quit [] | 15:26 | |
-!- jpans [~james@188.25.105.239] has joined #bitcoin-wizards | 15:27 | |
jpans | [OPEN] BTC doubler service. Send me your BTC and get TWICE back. PM me to begin. 100% vouched and legit. Guaranteed. | 15:27 |
jpans | [OPEN] BTC doubler service. Send me your BTC and get TWICE back. PM me to begin. 100% vouched and legit. Guaranteed.. | 15:27 |
qpm | tx:<Jeremy_Rand> I see our scammer has more than one IRC account | 15:28 |
jpans | [OPEN] BTC doubler service. Send me your BTC and get TWICE back. PM me to begin. 100% vouched and legit. Guaranteed... | 15:28 |
jpans | [OPEN] BTC doubler service. Send me your BTC and get TWICE back. PM me to begin. 100% vouched and legit. Guaranteed.... | 15:28 |
-!- MaxSan_ [~one@www17.redstation.co.uk] has joined #bitcoin-wizards | 15:29 | |
-!- jpans was kicked from #bitcoin-wizards by midnightmagic [jpans] | 15:35 | |
-!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 15:36 | |
-!- ruby32 [~ruby32@184-207-8-206.pools.spcsdns.net] has joined #bitcoin-wizards | 15:41 | |
-!- igotcompetence [~igotcompe@113.sub-70-211-18.myvzw.com] has joined #bitcoin-wizards | 15:53 | |
-!- zooko [~user@c-73-217-96-13.hsd1.co.comcast.net] has joined #bitcoin-wizards | 15:57 | |
-!- ruby32d [~ruby32@184-207-0-250.pools.spcsdns.net] has joined #bitcoin-wizards | 16:02 | |
-!- ruby32 [~ruby32@184-207-8-206.pools.spcsdns.net] has quit [Read error: Connection reset by peer] | 16:02 | |
-!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] | 16:07 | |
-!- gabridome_ [~gabridome@213.215.206.11] has joined #bitcoin-wizards | 16:16 | |
-!- gabridome_ [~gabridome@213.215.206.11] has quit [Client Quit] | 16:20 | |
-!- MaxSan_ [~one@www17.redstation.co.uk] has quit [Ping timeout: 240 seconds] | 16:20 | |
-!- murch [~murch@p4FE3A827.dip0.t-ipconnect.de] has quit [Quit: Leaving.] | 16:20 | |
-!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 244 seconds] | 16:23 | |
-!- NewLiberty_ [~NewLibert@107-142-8-22.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards | 16:27 | |
-!- NewLiberty [~NewLibert@107-142-8-22.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 246 seconds] | 16:27 | |
-!- ruby32d [~ruby32@184-207-0-250.pools.spcsdns.net] has quit [Read error: Connection reset by peer] | 16:28 | |
-!- zooko [~user@c-73-217-96-13.hsd1.co.comcast.net] has quit [Ping timeout: 246 seconds] | 16:33 | |
-!- MaxSan_ [~one@78.129.153.58] has joined #bitcoin-wizards | 16:38 | |
-!- igotcompetence [~igotcompe@113.sub-70-211-18.myvzw.com] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 16:38 | |
-!- wizkid057 [~wk@unaffiliated/wizkid057] has quit [Read error: Connection reset by peer] | 16:43 | |
-!- binaryFate [~binaryFat@2607:ff48:aa81:800::a15f:1] has quit [Ping timeout: 272 seconds] | 16:47 | |
-!- wizkid057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards | 16:47 | |
-!- c0rw1n- [~c0rw1n@116.47-244-81.adsl-dyn.isp.belgacom.be] has quit [Quit: Konversation terminated!] | 16:56 | |
-!- c0rw1n- [~c0rw1n@116.47-244-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 16:56 | |
-!- MaxSan_ [~one@78.129.153.58] has quit [Ping timeout: 240 seconds] | 17:11 | |
-!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] | 17:18 | |
-!- igotcompetence [~igotcompe@192.80.7.74] has joined #bitcoin-wizards | 17:22 | |
-!- igotcompetence [~igotcompe@192.80.7.74] has quit [Max SendQ exceeded] | 17:22 | |
-!- igotcompetence [~igotcompe@192.80.7.74] has joined #bitcoin-wizards | 17:23 | |
-!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer] | 17:25 | |
-!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards | 17:26 | |
-!- MaxSan_ [~one@84.39.116.180] has joined #bitcoin-wizards | 17:30 | |
-!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 17:35 | |
-!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards | 17:39 | |
-!- hashtagg [~hashtagg_@cpe-174-97-254-80.ma.res.rr.com] has joined #bitcoin-wizards | 17:50 | |
-!- hashtag [~hashtag@cpe-174-97-254-80.ma.res.rr.com] has joined #bitcoin-wizards | 17:51 | |
-!- hashtagg_ [~hashtag@cpe-174-97-254-80.ma.res.rr.com] has quit [Ping timeout: 246 seconds] | 17:53 | |
-!- hashtag_ [~hashtagg_@cpe-174-97-254-80.ma.res.rr.com] has quit [Ping timeout: 240 seconds] | 17:53 | |
-!- Ylbam [uid99779@gateway/web/irccloud.com/x-zggashcsarwrdhur] has quit [Quit: Connection closed for inactivity] | 17:55 | |
-!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 17:57 | |
-!- igotcompetence [~igotcompe@192.80.7.74] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 18:11 | |
-!- N0S4A2 [~weechat@216-243-38-141.users.condointernet.net] has quit [Quit: WeeChat 1.5] | 18:17 | |
-!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-wizards | 18:18 | |
-!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] | 18:30 | |
-!- MaxSan_ [~one@84.39.116.180] has quit [Ping timeout: 264 seconds] | 18:30 | |
-!- tromp [~tromp@ool-944bc34f.dyn.optonline.net] has joined #bitcoin-wizards | 18:31 | |
-!- JackH [~Jack@79-73-186-51.dynamic.dsl.as9105.com] has quit [Ping timeout: 272 seconds] | 18:36 | |
-!- Nightwolf [~Nightwolf@unaffiliated/nightwolf] has quit [Read error: Connection reset by peer] | 18:36 | |
-!- Nightwolf [~Nightwolf@hg-nachhaltigkeit.de] has joined #bitcoin-wizards | 18:38 | |
-!- Nightwolf [~Nightwolf@hg-nachhaltigkeit.de] has quit [Changing host] | 18:38 | |
-!- Nightwolf [~Nightwolf@unaffiliated/nightwolf] has joined #bitcoin-wizards | 18:38 | |
-!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has quit [Ping timeout: 276 seconds] | 18:41 | |
-!- btcbilly [~ident@cpe-76-180-226-52.buffalo.res.rr.com] has joined #bitcoin-wizards | 18:43 | |
btcbilly | IMPORTANT ANNOUNCEMENT! BTC growing service is now open. PM me to begin. Send me BTC and get MUCH MORE back right away. 100% honest & legit. | 18:43 |
qpm | tx:<Jeremy_Rand> today must be Scam Spam Tuesday. | 18:44 |
btcbilly | IMPORTANT ANNOUNCEMENT! BTC growing service is now open. PM me to begin. Send me BTC and get MUCH MORE back right away. 100% honest & legit! | 18:45 |
qpm | tx:<Jeremy_Rand> midnightmagic: ^ | 18:45 |
btcbilly | you stapupoid qpm | 18:45 |
-!- mkarrer [~mkarrer@48.red-83-47-111.dynamicip.rima-tde.net] has quit [] | 18:45 | |
qpm | * tx:Jeremy_Rand waits for someone to kickban the dude | 18:46 |
btcbilly | IMPORTANT ANNOUNCEMENT! BTC growing service is now open. PM me to begin. Send me BTC and get MUCH MORE back right away. 100% honest & legit!! | 18:46 |
bsm117532 | You can tell it's real by the "100% honest & legit!!". I put that at the end of all my emails too. | 18:47 |
btcbilly | you stupid fool | 18:47 |
qpm | * tx:Jeremy_Rand wonders why anyone would be dumb enough to believe this scam | 18:48 |
btcbilly | IMPORTANT ANNOUNCEMENT! BTC growing service is now open. PM me to begin. Send me BTC and get MUCH MORE back right away. 100% honest & legit!! | 18:48 |
-!- tromp [~tromp@ool-944bc34f.dyn.optonline.net] has quit [Remote host closed the connection] | 18:48 | |
pigeons | i was just thinking i bet he was the only one ever dumb enough and thats why he's trying it to steal his money back from someone else | 18:49 |
qpm | tx:<Jeremy_Rand> Since I'm using a relay I can't easily see who's an op here; can someone please tag an op so that the kickban hammer can be applied? | 18:49 |
btcbilly | IMPORTANT ANNOUNCEMENT! BTC growing service is now open. PM me to begin. Send me BTC and get MUCH MORE back right away. 100% honest & legit. | 18:49 |
bsm117532 | There's always a bigger douchebag. The only winning algorithm is not to play. | 18:49 |
btcbilly | IMPORTANT ANNOUNCEMENT! BTC growing service is now open. PM me to begin. Send me BTC and get MUCH MORE back right away. 100% honest & legit. | 18:49 |
pigeons | maybe get him klined he' all over the place | 18:49 |
bsm117532 | Also, banning identical repeat messages is a good idea. | 18:50 |
* midnightmagic fiddles.. | 18:50 | |
pigeons | i'm sure freenode continues to just love bitcoin | 18:50 |
-!- btcbilly was kicked from #bitcoin-wizards by midnightmagic [btcbilly] | 18:50 | |
bsm117532 | Sorry to bother you midnightmagic, but thanks. | 18:51 |
-!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards | 18:52 | |
@midnightmagic | 'sokay. Dude's harassing piles of #bitcoin-* channels, not just here. | 18:53 |
@midnightmagic | It's completely fine to ping me repeatedly and often if someone is being abusive. | 18:53 |
bsm117532 | Thanks again | 18:53 |
qpm | * tx:Jeremy_Rand was about to ban him from #namecoin since he hit there too, but midnightmagic beat me to it | 18:53 |
bsm117532 | So since I'm here... no one commented over the weekend about my braids ideas. I'm more and more thinking that UTXO set commitments *require* a braid (multiple parent) structure, because of the time required to create/validate a UTXO set commitment. One must be able to both validate and mine at the same time. | 18:55 |
bsm117532 | Not to mention bringing bitcoin back to its claimed 51% security guarantee... | 18:56 |
qpm | tx:<Jeremy_Rand> That reminds me, since I'm here as well. Is this a reasonable channel to ask about technical obstacles involving UTXO set commitments, or is that best done somewhere else? | 18:58 |
bsm117532 | qpm tx jeremy_rand please do ask here, it's relevant and important. | 18:59 |
qpm | tx:<Jeremy_Rand> Ok. So Namecoin would like to add commitments to the UNO set (unspent name output set), which seems to have strong technical overlap with doing so for the UTXO set. | 18:59 |
-!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has quit [Quit: Leaving.] | 19:00 | |
bsm117532 | Interesting...do you have a link? | 19:00 |
amiller_ | that's neat Jeremy_Rand | 19:00 |
amiller_ | i think it's a good idea | 19:00 |
-!- pro [~pro@unaffiliated/pro] has quit [Quit: Leaving] | 19:00 | |
bsm117532 | The big problem with UTXO commitments is adding a slow validation procedure in the critical path. (What does a miner do with his mining equipment while he's validating the UNO) | 19:00 |
amiller_ | there are also some ideas where you are basically responsible for your own update | 19:01 |
qpm | tx:<Jeremy_Rand> Given that there's strong technical overlap, my first instinct is that it makes sense for the overlapping parts to be merged into Bitcoin, and then have Namecoin maintain a patchset on it for stuff that's specific to us | 19:01 |
amiller_ | especially if it doesn't have to be modified unless you take some action | 19:01 |
qpm | tx:<Jeremy_Rand> So my question is basically, what technical obstacles have been solved in Bitcoin's world for this, and what obstacles are still outstanding? | 19:01 |
bsm117532 | amiller_: can you elaborate on "responsible for your own update" -- what does that mean? | 19:01 |
-!- JamesLove [~jtseng@ip149-71-211-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards | 19:02 | |
amiller_ | there are still some debates on which high level approach to use | 19:02 |
amiller_ | bsm117532, this "responsible for your own update" this is an idea from the merkle mountain range files of petertodd | 19:02 |
amiller_ | the idea is that miners can file your transaction output into a tree of txo's, and *then forget about it* | 19:02 |
amiller_ | if you can't remember the merkle tree branch needed to prove your existence, then you can't spend your coin | 19:03 |
qpm | tx:<Jeremy_Rand> bsm117532: there's a GitHub branch of Namecoin that has some code already written, but it's proof of concept and would be likely to be rewritten. I can dig up a link if you're curious | 19:03 |
kanzure | https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md | 19:03 |
kanzure | https://github.com/proofchains/python-proofmarshal/blob/master/proofmarshal/mmr.py | 19:03 |
amiller_ | kanzure is there even a canonical discussion about this txo commitment stuff | 19:03 |
amiller_ | maybe this https://petertodd.org/2016/delayed-txo-commitments | 19:03 |
kanzure | https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html | 19:04 |
bsm117532 | amiller_: "forgetting about it" seems incompatible with maintaining the global ledger net balance. Does that mean your transaction is effectively reversed and funds return to the previous UTXO, if you aren't online and capable of producing a proof? | 19:04 |
amiller_ | bsm117532, no, in this sense it isn't any different thn if you send yourself some coins and delete your private key | 19:04 |
amiller_ | the reason to use a merkle mountain range is so that your merkle branch is *stable* | 19:05 |
qpm | tx:<Jeremy_Rand> This is the Namecoin branch if it matters: https://github.com/domob1812/namecore/tree/uno-trie -- main interesting thing is that it's a trie (which makes sense since it's indexed by name) | 19:05 |
amiller_ | that's fine, is there a maximum length of the trie? | 19:06 |
-!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] | 19:06 | |
amiller_ | ethereum uses a nice one-size-fits-all data structure, it's not perfect but it's a nice way of committing to a default choice and sticking to it | 19:06 |
amiller_ | it's a trie where you hash the keys being stored | 19:06 |
-!- JamesLove [~jtseng@ip149-71-211-87.adsl2.static.versatel.nl] has quit [Quit: Ex-Chat] | 19:06 | |
amiller_ | so it's 256-bits | 19:06 |
qpm | tx:<Jeremy_Rand> Well, Namecoin names are limited to 255 characters, so I guess that would be the max length | 19:07 |
bsm117532 | jeremy_rand a trie is an optimization for semantic names. :-/ | 19:07 |
qpm | tx:<Jeremy_Rand> it's an intended design goal that you could retrieve a subtrie which corresponds to a name prefix | 19:07 |
qpm | tx:<Jeremy_Rand> bsm117532: not sure I follow? | 19:08 |
bsm117532 | Let's back away from semantically meaningful names and assume names are randomly allocated. Does a trie provide any improvement for data which is uniformly distributed (like hash outputs -- txids)? | 19:09 |
-!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer] | 19:09 | |
bsm117532 | (I think the answer is "no") | 19:09 |
amiller_ | it's not the perfect choice but it's an easy default | 19:09 |
-!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 19:09 | |
qpm | tx:<Jeremy_Rand> None that I can think of off-hand. Namecoin names are meaningful, e.g a name with the prefix "d/" is a domain name. So it makes sense for Namecoin's case, I think. | 19:09 |
qpm | tx:<Jeremy_Rand> It also means that a UTXO commitment scheme probably has different requirements from an UNO commitment scheme | 19:10 |
bsm117532 | So, jeremy_rand, I'd say that your mapping of human-meaning into the address space is flawed. A better compression function is needed. | 19:10 |
bsm117532 | I don't know why I should devote bits to a flawed compression function. | 19:11 |
qpm | tx:<Jeremy_Rand> bsm117532: feel free to elaborate, I guess I still don't follow | 19:11 |
amiller_ | Jeremy_rand: what's the status of the proof of concept, is it usable or what? is there a readme for this feature | 19:12 |
bsm117532 | Errr....so a trie is a data structure that is only relevant for "common prefixes". e.g. in English a 'c' is more likely to be followed by 'ie' as in 'science' and never 'sceince'. | 19:12 |
bsm117532 | This is an artifact of a poor encoding into the available bits. Applying a hash function to the input will result in a better distribution of storage. | 19:13 |
bsm117532 | The trie is an artifact of cheap memory costs relative to computation costs, in other words... | 19:14 |
qpm | tx:<Jeremy_Rand> amiller_: Daniel Kraft wrote it about a year ago to get feedback, it's not usable in its current state last I checked. IIRC it constructs the trie structure but doesn't enforce any consensus rules for it right now | 19:14 |
bsm117532 | The blockchain is MUCH more sensitive to storage costs. | 19:14 |
qpm | tx:<Jeremy_Rand> and the trie structure is definitely open to revision (or complete reworking) | 19:14 |
amiller_ | jeremy_rand: in my opinion waiting for it to get merged into bitcoin before you can try it in namecoin seems like a bad project timeline plan! | 19:15 |
bsm117532 | jeremy_rand I'm also working on a similar idea, and security is dependent on getting UTXO set commitments, FWIW. | 19:15 |
amiller_ | we've talked about how to softfork sneak it into coinbase transactions | 19:16 |
bsm117532 | But, hash the names first (I don't care how). Don't make nodes store your uncompressed data. | 19:16 |
qpm | tx:<Jeremy_Rand> amiller_: heh, that's one thing I was wondering. I gather that it's turned out to be quite difficult for Bitcoin. Which makes me wonder whether we're unaware of some challenges that Bitcoin is trying to solve that we possibly don't even know need solving :) | 19:17 |
bsm117532 | My comment at the beginning of this thread was that UTXO set commitments are very time consuming to validate: log(n) hashes per insertion/deletion, and a block contains thousands of transactions. So inserting them causes miners to face a Sophie's choice: what to do with your mining equipment while you're checking the UTXO set commitment. | 19:17 |
pigeons | also talk to maaku who has spent quite some time on the issue | 19:17 |
amiller_ | oh yeah | 19:17 |
bsm117532 | This has caused others to attempt to super-optimize the UTXO set commitment algorithm, but no algorithm will ever be "zero time". | 19:17 |
bsm117532 | And we need it to be zero time, so that a miner can mine and validate at the same time. | 19:18 |
bsm117532 | I've been working on an alternate approach ("braids") which allows blocks to have multiple parents, so that one can mine and validate at the same time. | 19:18 |
qpm | tx:<Jeremy_Rand> Yeah. So on one hand Namecoin has much smaller block in practice (since a naming system inherently has lower tx volume than a financial system). Meaning that the overhead may be less trouble for us. | 19:18 |
rusty2 | bsm117532: I thought that was the reason behind proposals for a delayed UTXO set (ie. this is the UTXO set 100 blocks ago), so you could precalc? | 19:19 |
amiller_ | maakus' nice site about this is down :( http://utxo.tumblr.com/ | 19:19 |
qpm | tx:<Jeremy_Rand> But yes, I don't think we've directly considered the latency impact on block validation | 19:19 |
amiller_ | i dont see an arxiv of it | 19:19 |
bsm117532 | jeremy_rand I think if namecoin was as successful as DNS, it would face the same problem. Assuming block validation has zero time cost is the underlying error... | 19:19 |
qpm | tx:<Jeremy_Rand> So that is definitely something that we need to think about carefully | 19:19 |
amiller_ | kanzure, i wonder if you have an idea if that's preserved anywhere? | 19:19 |
bsm117532 | rusty2: That's great if I want to be wrong by an hour. | 19:20 |
-!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] | 19:20 | |
-!- tromp [~tromp@ool-944bc34f.dyn.optonline.net] has joined #bitcoin-wizards | 19:20 | |
kanzure | amiller_: nope | 19:20 |
rusty2 | bsm117532: no, you just need the last 100 blocks to calc the real UTXO set though. | 19:20 |
amiller_ | maybe i have completely the wrong page and i'm google searching bad | 19:20 |
-!- rusty2 is now known as rusty | 19:20 | |
kanzure | amiller_: https://github.com/bitcoin/bitcoin/pull/3977 | 19:21 |
qpm | tx:<Jeremy_Rand> bsm117532: based on back of napkin calculations that might or might not be valid, worldwide adoption of Namecoin would be around 4 MB average blocksize, I'm guessing Bitcoin would be a lot more (not counting off-chain transactions). But I could be wrong on that one. | 19:21 |
qpm | tx:<Jeremy_Rand> rusty2: honestly a delayed UNO set is probably fine for Namecoin | 19:22 |
bsm117532 | rusty I'm interested in *immediately* knowing if anyone has broadcast a valid transaction. I don't care if it's mined, but bitcoin's mining/security model is long-term important. Therefore I dislike delayed commitments. | 19:22 |
qpm | tx:<Jeremy_Rand> unless I'm missing some attacks | 19:22 |
bsm117532 | jeremy_rand how do you arrive at a 4MB number, given that bitcoin is shackled at 1MB? | 19:22 |
rusty | bsm117532: then you need to know that last 100 blocks. That shouldn't be a problem, should it? | 19:23 |
qpm | tx:<Jeremy_Rand> The use case for Namecoin is making sure that you're not being fed a TLS fingerprint for a domain that's been revoked a long time ago. | 19:23 |
qpm | tx:<Jeremy_Rand> Meaning that UNO commitments from a few hours ago are presumably still very useful | 19:23 |
bsm117532 | rusty: I'm interested in the "light client" model, which is dependent on "proof of absence" from the UTXO set. This can only be achieved with UTXO set commitments, assuming "light clients" have the block headers, which include the UTXO set commitment. | 19:24 |
qpm | tx:<Jeremy_Rand> bsm117532: IIRC, I took the number of ICANN domains, and considered the size of a typical Namecoin name tx and the expiration period of Namecoin names, and assumed that 10% of names would need to revoke keys more often than that | 19:24 |
qpm | tx:<Jeremy_Rand> so obviously it's a very inaccurate calculation | 19:25 |
bsm117532 | jeremy_rand I see...interesting. Still a relevant order of magnitude. | 19:25 |
qpm | tx:<Jeremy_Rand> still, I suspect that a naming system has lower tx volume than a financial system | 19:25 |
rusty | bsm117532: yeah, then you want each block to contain a UTXO changeset. Now you need "prove predecessor was in UTXO 100 blocks ago" + 100 x proof-not-in-utxo-changeset. | 19:26 |
rusty | bsm117532: vary 100 to taste, of course. | 19:27 |
bsm117532 | rusty The model I have in my head is one of header-distribution combined with "prove this tx is still unspent in the most recent block I know about". | 19:28 |
qpm | tx:<Jeremy_Rand> so given that Namecoin is probably fine with a delay of 12 blocks or so (maybe longer) for the commitments, what obstacles are likely to exist? It sounds like validation latency doesn't really matter in our model, whereas in bsm117532's threat model it's a big deal | 19:28 |
rusty | bsm117532: ... and this would give it to you. | 19:28 |
rusty | bsm117532: plus, it's fairly simple. | 19:29 |
bsm117532 | rusty: 100 blocks introduces a timescale which allows me to attack. By induction, the required timescale to prevent the attack is infinite. | 19:29 |
bsm117532 | PoS coins make the same mistake. | 19:29 |
rusty | bsm117532? Please describe the attack. | 19:30 |
rusty | bsm117532: If I prove that it was in the UTXO set 100 blocks ago, and not in any UTXO delta in every block since then, what is the attack? | 19:30 |
bsm117532 | rusty: Create a chain longer than the "bonding time" (100 blocks) -- the chains are indistinguishable. | 19:30 |
rusty | bsm117532: err... fake blocks can lie to light clients. That's always true... | 19:31 |
bsm117532 | A node can only lie to a light client if it can prove the block hash (PoW) is related to his unspent commitment, in a provable manner. | 19:32 |
bsm117532 | ...makes it extremely expensive to lie, in a provable manner. | 19:32 |
bsm117532 | Because you have to produce an alternate set of block headers... | 19:33 |
rusty | bsm117532: We've obviously not communicating well. If attacker can create a valid PoW chain of 100 blocks, UTXO set validity is not your core issue. | 19:33 |
rusty | bsm117532: I'm not sue what you're missing. Each block would commit to "full utxo set 100 blocks ago" and "change in utxo set cause by this block". | 19:34 |
bsm117532 | rusty: The argument that moving the problem back 100 blocks doesn't fundamentally change anything. A 51% attacker can still attack, it just takes 100 blocks. It just changes the timescale of the attack, but doesn't remove the attack. | 19:34 |
bsm117532 | I'm interested in *timely* UTXO proofs, and 100 block proofs are really not terribly useful. | 19:35 |
rusty | bsm117532: <sigh> The reason for 100 blocks is simply to allow precalculation for miners. It doesn't change any other properties. | 19:35 |
-!- blackwraith [~priidu@unaffiliated/priidu] has quit [Ping timeout: 246 seconds] | 19:35 | |
bsm117532 | rusty: It's a wrong solution to the wrong problem. The problem is that miners can't both mine and validate at the same time (because...orphans). Introducing extra computation in the validation is therefore abhorrent. | 19:36 |
bsm117532 | If I'm dependent on proof-of-absence I'm now dependent on 6x proof-of-absence commitment time. | 19:37 |
rusty | bsm117532: no, adding trivial computation to validation is not a problem. And this is pretty trivial. | 19:38 |
bsm117532 | rusty: The argument is that UTXO set commitments are not trivial to compute, and that's the problem. (I still want to see benchmarks on this, BTW, I have not done any myself) | 19:38 |
qpm | tx:<Jeremy_Rand> Maybe I'm confused, but isn't checking whether a root hash matches a root hash you calculated 100 blocks ago relatively easy? Or am I misjudging what the task is? | 19:39 |
bsm117532 | Making a merkle root out of a 1GB dataset is not "trivial"... | 19:39 |
rusty | Yes, exactly qpm: tx:<Jeremy_Rand>. | 19:39 |
-!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 19:40 | |
qpm | tx:<Jeremy_Rand> Ok, so given that a trie seems to make sense in Namecoin's case, and that Namecoin is totally fine with a delayed commitment, how much overlap is there between Namecoin's use case and that of Bitcoin? | 19:41 |
qpm | tx:<Jeremy_Rand> (unless there are problems with a trie in Namecoin's case that I don't see?) | 19:42 |
qpm | tx:<Jeremy_Rand> btw, Daniel Kraft's thread documenting the Namecoin branch is at https://forum.namecoin.org/viewtopic.php?f=5&t=2239 | 19:43 |
bsm117532 | jeremy_rand: I'm very interested in the answer, because I want to push on the same issue, and I've seen zero action on Bitcoin's side in incorporating UTXO set commitments. I'm willing to write code/PR's and shepherd it through the process. But I see having multiple parents as critical to any plan inserting extra validation time...validation time is lost profit or lost capacity, one way or the other. | 19:45 |
amiller_ | Jeremy_Rand, that's cool, it looks like maybe the only thing left to do is make an SPV client for it also? | 19:47 |
amiller_ | and that it is all in memory as opposed to partially in leveldb or something | 19:47 |
amiller_ | it might be inconvenient to put hash structures in leveldb, at least the obvious way | 19:47 |
-!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-wizards | 19:48 | |
qpm | tx:<Jeremy_Rand> amiller_: I've got SPV working for Namecoin as of about a month ago (via BitcoinJ), Namecoin support was merged to libdohj yesterday. So if Namecoin does adopt Daniel's branch, probably would be doable to add that to the SPV codebase | 19:49 |
-!- hashtag [~hashtag@cpe-174-97-254-80.ma.res.rr.com] has quit [Ping timeout: 276 seconds] | 19:50 | |
bsm117532 | We're O(1) away from deadly scalability problems, doesn't matter where you put the data structure at this point... another route is needed. | 19:50 |
amiller_ | bsm117532, if you missed it by 2 inches in the other direction, it wouldn't have been close at all | 19:50 |
qpm | tx:<Jeremy_Rand> amiller_: I'm just hesitant to introduce changes to Namecoin that aren't part of Bitcoin. Which is why I'm trying to evaluate how much overlap there is between Bitcoin's and Namecoin's respective needs here | 19:52 |
amiller_ | bitcoin you have very little tolerance for bloat because it's under billions of dollars of heavy use and super high stakes, i think that's a good explanation for why the bar is high but and not enough appropriate resources have been allocated towards it | 19:53 |
qpm | tx:<Jeremy_Rand> amiller_: Yeah. Makes sense. Would you suggest that Namecoin do our own thing for now, and then maybe adopt a Bitcoin solution in the future if one materializes and it's applicable? | 19:57 |
amiller_ | yup, that's my suggestion! | 19:58 |
qpm | tx:<Jeremy_Rand> amiller_: cool. Your opinion has high value, so I'll probably advocate that. :) | 19:59 |
qpm | tx:<Jeremy_Rand> amiller_: if we do it as a softfork, how would we then remove it in favor of a future Bitcoin solution if we needed to? That would be a hardfork if not planned carefully | 19:59 |
qpm | tx:<Jeremy_Rand> Best solution that comes to mind is to make the initial softfork expire after a year or so if not renewed by another softfork | 20:00 |
qpm | tx:<Jeremy_Rand> But maybe there's a way I'm not thinking of? | 20:00 |
amiller_ | similarly i doubt whether worrying about soft-fork vs hard-fork is as important for namecoin until it's got more critical use and upgradeable users | 20:01 |
qpm | tx:<Jeremy_Rand> amiller_: Fair point, I suppose | 20:02 |
amiller_ | that's interesting to think about, i have no idea how soft fork / hard fork interacts between bitcoin and merge mined coins that track it | 20:03 |
amiller_ | you could soft fork to kill off the merge mine coin | 20:03 |
qpm | tx:<Jeremy_Rand> amiller_: Bitcoin's VersionBits actually breaks merge mined coins; Namecoin is planning to hardfork to fix that | 20:04 |
qpm | tx:<Jeremy_Rand> specifically bit 0x100 indicates to Namecoin that a block is merge-mined, and a parent block isn't allowed to be merge-mined under Namecoin's rules | 20:04 |
qpm | tx:<Jeremy_Rand> so if Bitcoin miners try to mine a VersionBits softfork using bit 0x100, they also can't merge-mine | 20:05 |
amiller_ | too bad for namecoin i guess | 20:07 |
qpm | tx:<Jeremy_Rand> IMO it was unwise for Namecoin to abuse the version field for that purpose. But I wasn't around when that spec was written, so not like I have much right to complain | 20:07 |
qpm | tx:<Jeremy_Rand> anyway yeah, Namecoin's hardfork is coded and is being tested now. It'll be mildly unpleasant to deploy it, but as you say there aren't a lot of users at the moment, so probably not a huge deal compared to what Bitcoin would have to do to hardfork. | 20:08 |
amiller_ | i don't see any clear way you could plan ahead for bitcoin to soft fork a new feature, such that you can soft fork it now, and later only need to soft fork to swap over to bitcoin's | 20:10 |
-!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has joined #bitcoin-wizards | 20:10 | |
qpm | tx:<Jeremy_Rand> True | 20:10 |
amiller_ | let me know if you think of something better | 20:11 |
qpm | tx:<Jeremy_Rand> will do :) | 20:11 |
-!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] | 20:28 | |
bsm117532 | jeremy_rand: I know of no serious proposal to add UTXO set commitments to bitcoin, much to my chagrin. I will add one soon if one does not appear. Namecoin has an opportunity to lead here. but please don't make us deal with your trie, just hash the shit first and use buckets. | 20:29 |
bsm117532 | jeremy_rand also, proposals using OP_RETURN will be met with resistance. Put the commitments in a pruneable part of the dataset. | 20:30 |
-!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards | 20:30 | |
-!- a5m0_ is now known as a5m0 | 20:31 | |
bsm117532 | FWIW I would be happy to see more development on namecoin. It's a good idea and has been dormant for far too long. | 20:33 |
-!- tromp [~tromp@ool-944bc34f.dyn.optonline.net] has quit [Remote host closed the connection] | 20:42 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 20:43 | |
-!- gabridome_ [~gabridome@213.215.206.11] has joined #bitcoin-wizards | 20:44 | |
-!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has joined #bitcoin-wizards | 21:06 | |
-!- r0ach [~r0ach@107-217-214-192.lightspeed.jcvlfl.sbcglobal.net] has joined #bitcoin-wizards | 21:06 | |
-!- gabridome_ [~gabridome@213.215.206.11] has quit [Quit: gabridome_] | 21:08 | |
-!- MaxSan_ [~one@109.202.107.15] has joined #bitcoin-wizards | 21:09 | |
-!- Burrito [~Burrito@unaffiliated/burrito] has quit [Ping timeout: 250 seconds] | 21:15 | |
-!- MaxSan_ [~one@109.202.107.15] has quit [Ping timeout: 264 seconds] | 21:35 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] | 21:38 | |
-!- alferz [~alferz@unaffiliated/alfer] has quit [Ping timeout: 240 seconds] | 21:38 | |
-!- PeterR [488fe7f6@gateway/web/freenode/ip.72.143.231.246] has joined #bitcoin-wizards | 21:39 | |
PeterR | bsm117532: @awemany from bitco.in is also very interested in UTXO commitments (and has another interesting idea called UTXO "coalescing"). | 21:39 |
PeterR | What I'd personally love for Bitcoin Unlimited (BU) is a scheme to allow new BU nodes to startup without downloading the blockchain--just the UTXO set and a bit of historical data. | 21:39 |
PeterR | A committment scheme that was initially based on trust but defined a path to transition to a trustless scheme once the majority of the hash power was onboard would be ideal IMO. The non-trustless committments would demonstrate the usefulness of concept, thereby motivating miners to adopt and transition to the trustless scheme. | 21:40 |
-!- tromp [~tromp@ool-944bc34f.dyn.optonline.net] has joined #bitcoin-wizards | 21:43 | |
-!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services] | 21:45 | |
-!- [7] [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 21:45 | |
-!- alferz [~alferz@46.166.188.232] has joined #bitcoin-wizards | 21:45 | |
-!- alferz [~alferz@46.166.188.232] has quit [Changing host] | 21:46 | |
-!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards | 21:46 | |
-!- tromp [~tromp@ool-944bc34f.dyn.optonline.net] has quit [Ping timeout: 244 seconds] | 21:47 | |
-!- PeterR [488fe7f6@gateway/web/freenode/ip.72.143.231.246] has quit [Quit: Page closed] | 21:50 | |
-!- oneeman [~oneeman@ip77-154-15-186.ct.co.cr] has quit [Quit: Leaving] | 21:51 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 22:13 | |
-!- alferz [~alferz@unaffiliated/alfer] has quit [Ping timeout: 240 seconds] | 22:27 | |
-!- dingus [~grubles@unaffiliated/grubles] has joined #bitcoin-wizards | 22:28 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 252 seconds] | 22:28 | |
-!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards | 22:33 | |
-!- alferz [~alferz@unaffiliated/alfer] has quit [Ping timeout: 240 seconds] | 22:37 | |
-!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards | 22:43 | |
-!- zooko [~user@2601:281:8000:8387:38fc:7037:e9cb:2de0] has joined #bitcoin-wizards | 22:52 | |
-!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has quit [Ping timeout: 252 seconds] | 22:56 | |
-!- zooko [~user@2601:281:8000:8387:38fc:7037:e9cb:2de0] has quit [Ping timeout: 250 seconds] | 23:10 | |
-!- Ylbam [uid99779@gateway/web/irccloud.com/x-agmwsdszuiegfmzx] has joined #bitcoin-wizards | 23:15 | |
-!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] | 23:26 | |
-!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards | 23:28 | |
-!- tromp [~tromp@ool-944bc34f.dyn.optonline.net] has joined #bitcoin-wizards | 23:44 | |
-!- tromp [~tromp@ool-944bc34f.dyn.optonline.net] has quit [Ping timeout: 264 seconds] | 23:48 | |
-!- murch [~murch@p4FE39CD5.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 23:50 | |
-!- blozo [~blozo@ppp121-44-178-241.lns20.syd7.internode.on.net] has quit [] | 23:53 | |
maaku | bsm117532: why 100? just have the commitment be to the penultimate block | 23:56 |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 23:56 | |
maaku | the utxo commitment structure I designed took on the order of a million or so hashes to update, which is reasonable. that's about 1s of validation time | 23:57 |
maaku | what is unreasonable is it also took a million database updates to store | 23:57 |
maaku | but that problem mostly goes away if the update is to the penultimate block | 23:59 |
--- Log closed Wed Jul 06 00:00:49 2016 |
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!