--- Log opened Tue Jul 05 00:00:48 2016 00:02 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 00:03 -!- cypher__ [~cypher@97-85-41-80.dhcp.bycy.mi.charter.com] has joined #bitcoin-wizards 00:06 -!- agorist000 [~cypher@unaffiliated/agorist000] has quit [Ping timeout: 246 seconds] 00:16 -!- warren [~warren@fedora/wombat/warren] has quit [Ping timeout: 240 seconds] 00:16 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 252 seconds] 00:17 -!- 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:19 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards 00:19 -!- Lightsword [~Lightswor@107.170.253.193] has quit [Ping timeout: 276 seconds] 00:21 -!- warren [~warren@fedora/wombat/warren] has joined #bitcoin-wizards 00:22 -!- jessepollak [~jessepoll@104.131.138.130] has joined #bitcoin-wizards 00:24 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has joined #bitcoin-wizards 00:25 -!- 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:26 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Changing host] 00:26 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-wizards 00:28 -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-wizards 00:34 -!- murch [~murch@p4FE3A827.dip0.t-ipconnect.de] has joined #bitcoin-wizards 00:46 -!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards 01:02 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] 01:09 -!- edvorg [~edvorg@14.186.80.50] has joined #bitcoin-wizards 01:18 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-wizards 01:18 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards 01:19 -!- xsdfdfsa [~x@unaffiliated/sdfgsdfg] has joined #bitcoin-wizards 01:38 -!- rubensayshi [~ruben@82.201.93.169] has quit [Ping timeout: 260 seconds] 01:40 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-wizards 01:41 -!- JackH [~Jack@79-73-186-51.dynamic.dsl.as9105.com] has joined #bitcoin-wizards 02:30 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-wizards 02:40 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards 02:41 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 02:46 -!- rubensayshi [~ruben@82.201.93.169] has quit [Ping timeout: 258 seconds] 02:46 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-wizards 03:01 -!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: gabridome_] 03:02 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zggashcsarwrdhur] has joined #bitcoin-wizards 03:06 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards 03:07 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards 03:07 -!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards 03:14 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 03:29 -!- Lysanders [~Lysanders@unaffiliated/lysanders] has joined #bitcoin-wizards 03:29 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards 03:32 -!- 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:35 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 03:40 -!- edvorg [~edvorg@14.186.80.50] has joined #bitcoin-wizards 03:41 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer] 03:44 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 03:47 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds] 03:50 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 04:08 -!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: gabridome_] 04:10 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 252 seconds] 04:15 -!- blozo [~blozo@ppp121-44-178-241.lns20.syd7.internode.on.net] has joined #bitcoin-wizards 04:26 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 04:34 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-wizards 04:34 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 04:38 -!- 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:44 -!- xsdfdfsa [~x@unaffiliated/sdfgsdfg] has quit [Remote host closed the connection] 04:54 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] 05:05 -!- pro [~pro@unaffiliated/pro] has joined #bitcoin-wizards 05:05 -!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards 05:22 -!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: gabridome_] 05:44 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 05:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 06:13 -!- blozo [~blozo@ppp121-44-178-241.lns20.syd7.internode.on.net] has quit [Remote host closed the connection] 06:17 -!- ruby32 [~ruby32@184-207-5-121.pools.spcsdns.net] has joined #bitcoin-wizards 06:19 -!- Samdney [~Samdney@nat-wlan2.rrze.uni-erlangen.de] has joined #bitcoin-wizards 06:23 -!- ruby32d [~ruby32@184.248.11.122] has joined #bitcoin-wizards 06:25 -!- 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:51 -!- ruby32d [~ruby32@184.248.11.122] has quit [Ping timeout: 252 seconds] 07:03 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 07:04 -!- ruby32 [~ruby32@38.121.165.30] has joined #bitcoin-wizards 07:07 -!- gammastorm [~thorsten@p2003006D6E1ECE00B1895B4B7F2B7177.dip0.t-ipconnect.de] has joined #bitcoin-wizards 07:09 < gammastorm> my next sat solver is out.... wanna see it ? 07:09 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards 07:10 -!- 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:11 -!- c0rw1n [~c0rw1n@116.47-244-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 240 seconds] 07:13 < 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:14 < gammastorm> Chris_Stewart_5, are bitcoins prime numbers ? 07:15 < Chris_Stewart_5> gammastorm: No, bitcoin just uses elliptic curve crypto 07:16 < 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:17 < murch> gammastorm: You got me curious. Why would that be the case? 07:18 < 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:19 < murch> Yes 07:20 < 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:21 < gammastorm> muchyeah it is 07:21 < murch> Why? 07:21 < gammastorm> murch, are you a low level coder and good with theory ? 07:22 < 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:23 < gammastorm> murch, maybe yes 07:24 < 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:27 < 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:29 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-wizards 07:30 < 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:32 < 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:33 < nsh> which is hard work 07:33 < murch> Does that also apply to ECDSA? 07:34 < 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:35 < nsh> not much discussion of reductions of DLP to other problem varieties that i can find. would have expected more 07:36 -!- superkuh [~superkuh@unaffiliated/superkuh] has quit [Ping timeout: 272 seconds] 07:37 < 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:38 < nsh> also: http://courses.cs.washington.edu/courses/cse573/04au/Project/mini1/TheS&Ateam/SATeamFinalPaper.pdf 07:39 < nsh> (for RSA / prime factorization) 07:40 < fluffypony> someone already did the Bitcoin SAT solver thing years ago 07:40 < fluffypony> https://github.com/capiman/sha256-sat-bitcoin 07:41 < nsh> (though that's a SHA PoW solver rather than ECDLP solver) 07:41 < fluffypony> yesh 07:42 < 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:44 < 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:45 < murch> fluffypony: that was an April fool's day hoax. 07:45 < fluffypony> awwww 07:45 < fluffypony> pity 07:50 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 258 seconds] 07:54 < 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:56 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards 07:57 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 08:00 < 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:02 < nsh> that's how the queen of narnia gets you... 08:05 < murch> nsh: I think I may be out of her typical prey pattern due to my age. :p 08:06 * nsh smiles 08:07 -!- gammastorm [~thorsten@p2003006D6E1ECE00B1895B4B7F2B7177.dip0.t-ipconnect.de] has quit [Quit: Leaving] 08:11 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 08:15 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-wizards 08:20 -!- rubensayshi [~ruben@82.201.93.169] has quit [Quit: Leaving] 08:21 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-wizards 08:22 -!- rubensayshi [~ruben@82.201.93.169] has quit [Remote host closed the connection] 08:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 08:27 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 08:36 -!- 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 09:09 -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has quit [Ping timeout: 264 seconds] 09:10 -!- Tenhi [~tenhi@static-ip-69-64-50-196.inaddr.ip-pool.com] has quit [Ping timeout: 250 seconds] 09:15 -!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards 09:17 -!- zooko [~user@c-71-229-205-98.hsd1.co.comcast.net] has joined #bitcoin-wizards 09:18 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] 09:21 -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has joined #bitcoin-wizards 09:23 -!- Tenhi [~tenhi@static.177.80.201.138.clients.your-server.de] has joined #bitcoin-wizards 09:24 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #bitcoin-wizards 09:29 -!- blozo [~blozo@ppp121-44-178-241.lns20.syd7.internode.on.net] has joined #bitcoin-wizards 09:33 -!- gabridome_ [~gabridome@2-228-102-98.ip191.fastwebnet.it] has quit [Quit: gabridome_] 09:34 -!- Tenhi [~tenhi@static.177.80.201.138.clients.your-server.de] has quit [K-Lined] 09:35 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards 10:03 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-wizards 10:19 -!- zooko [~user@c-71-229-205-98.hsd1.co.comcast.net] has quit [Ping timeout: 258 seconds] 10:28 -!- c0rw1n [~c0rw1n@116.47-244-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards 10:35 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 10:44 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] 10:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 11:02 -!- c0rw1n_ [~c0rw1n@116.47-244-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards 11:11 -!- MaxSan_ [~one@46.19.137.116] has joined #bitcoin-wizards 11:19 -!- mkarrer [~mkarrer@48.red-83-47-111.dynamicip.rima-tde.net] has quit [] 11:20 -!- mkarrer [~mkarrer@48.red-83-47-111.dynamicip.rima-tde.net] has joined #bitcoin-wizards 11:21 -!- mkarrer [~mkarrer@48.red-83-47-111.dynamicip.rima-tde.net] has quit [Client Quit] 11:23 -!- 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:25 -!- mkarrer [~mkarrer@48.red-83-47-111.dynamicip.rima-tde.net] has joined #bitcoin-wizards 11:27 -!- licnep [uid4387@gateway/web/irccloud.com/x-zovonqpvygdphzpa] has quit [Quit: Connection closed for inactivity] 11:34 -!- wizkid057 [~wk@unaffiliated/wizkid057] has quit [Read error: Connection reset by peer] 11:39 -!- wizkid057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards 11:51 -!- 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:58 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 258 seconds] 12:09 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] 12:13 -!- go1111111 [~go1111111@104.200.154.19] has quit [Quit: Leaving] 12:24 -!- NewLiberty [~NewLibert@107-142-8-22.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards 12:41 -!- 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:42 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards 12:43 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Client Quit] 12:59 -!- blackwraith [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 13:01 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 246 seconds] 13:01 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards 13:25 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 13:43 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] 14:02 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards 14:04 -!- Starduster_ is now known as Starduster 14:05 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Client Quit] 14:11 -!- 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:20 -!- c0rw1n- [~c0rw1n@116.47-244-81.adsl-dyn.isp.belgacom.be] has quit [Read error: Connection reset by peer] 14:23 -!- c0rw1n- [~c0rw1n@116.47-244-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards 14:28 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 14:30 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 14:38 -!- MaxSan_ [~one@46.19.137.116] has quit [Quit: Leaving.] 14:41 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards 14:49 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards 14:53 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] 15:07 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds] 15:16 -!- 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:20 < fluffypony> BTCDoubler: go away 15:20 < BTCDoubler> eat a dick 15:20 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards 15:23 -!- 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: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> [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: 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:26 -!- r0ach [~r0ach@107-217-214-192.lightspeed.jcvlfl.sbcglobal.net] has quit [] 15:27 -!- 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:28 < qpm> tx: 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:29 -!- MaxSan_ [~one@www17.redstation.co.uk] has joined #bitcoin-wizards 15:35 -!- jpans was kicked from #bitcoin-wizards by midnightmagic [jpans] 15:36 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards 15:41 -!- ruby32 [~ruby32@184-207-8-206.pools.spcsdns.net] has joined #bitcoin-wizards 15:53 -!- igotcompetence [~igotcompe@113.sub-70-211-18.myvzw.com] has joined #bitcoin-wizards 15:57 -!- zooko [~user@c-73-217-96-13.hsd1.co.comcast.net] has joined #bitcoin-wizards 16:02 -!- 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:07 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] 16:16 -!- gabridome_ [~gabridome@213.215.206.11] has joined #bitcoin-wizards 16:20 -!- 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:23 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 244 seconds] 16:27 -!- 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:28 -!- ruby32d [~ruby32@184-207-0-250.pools.spcsdns.net] has quit [Read error: Connection reset by peer] 16:33 -!- zooko [~user@c-73-217-96-13.hsd1.co.comcast.net] has quit [Ping timeout: 246 seconds] 16:38 -!- 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:43 -!- wizkid057 [~wk@unaffiliated/wizkid057] has quit [Read error: Connection reset by peer] 16:47 -!- 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:56 -!- 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 17:11 -!- MaxSan_ [~one@78.129.153.58] has quit [Ping timeout: 240 seconds] 17:18 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 17:22 -!- igotcompetence [~igotcompe@192.80.7.74] has joined #bitcoin-wizards 17:22 -!- igotcompetence [~igotcompe@192.80.7.74] has quit [Max SendQ exceeded] 17:23 -!- igotcompetence [~igotcompe@192.80.7.74] has joined #bitcoin-wizards 17:25 -!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer] 17:26 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards 17:30 -!- MaxSan_ [~one@84.39.116.180] has joined #bitcoin-wizards 17:35 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 17:39 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 17:50 -!- hashtagg [~hashtagg_@cpe-174-97-254-80.ma.res.rr.com] has joined #bitcoin-wizards 17:51 -!- hashtag [~hashtag@cpe-174-97-254-80.ma.res.rr.com] has joined #bitcoin-wizards 17:53 -!- 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:55 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zggashcsarwrdhur] has quit [Quit: Connection closed for inactivity] 17:57 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 18:11 -!- igotcompetence [~igotcompe@192.80.7.74] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 18:17 -!- N0S4A2 [~weechat@216-243-38-141.users.condointernet.net] has quit [Quit: WeeChat 1.5] 18:18 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-wizards 18:30 -!- 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:31 -!- tromp [~tromp@ool-944bc34f.dyn.optonline.net] has joined #bitcoin-wizards 18:36 -!- 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:38 -!- 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:41 -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has quit [Ping timeout: 276 seconds] 18:43 -!- 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:44 < qpm> tx: today must be Scam Spam Tuesday. 18:45 < 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: midnightmagic: ^ 18:45 < btcbilly> you stapupoid qpm 18:45 -!- mkarrer [~mkarrer@48.red-83-47-111.dynamicip.rima-tde.net] has quit [] 18:46 < 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:47 < 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:48 < 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:49 < 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: 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:50 < 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:51 < bsm117532> Sorry to bother you midnightmagic, but thanks. 18:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 18:53 <@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:55 < 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:56 < bsm117532> Not to mention bringing bitcoin back to its claimed 51% security guarantee... 18:58 < qpm> tx: 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:59 < bsm117532> qpm tx jeremy_rand please do ask here, it's relevant and important. 18:59 < qpm> tx: 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. 19:00 -!- 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:01 < amiller_> there are also some ideas where you are basically responsible for your own update 19:01 < qpm> tx: 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: 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:02 -!- 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:03 < 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: 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:04 < 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:05 < amiller_> the reason to use a merkle mountain range is so that your merkle branch is *stable* 19:05 < qpm> tx: 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:06 < 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:07 < qpm> tx: 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: it's an intended design goal that you could retrieve a subtrie which corresponds to a name prefix 19:08 < qpm> tx: bsm117532: not sure I follow? 19:09 < 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: 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:10 < qpm> tx: 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:11 < bsm117532> I don't know why I should devote bits to a flawed compression function. 19:11 < qpm> tx: bsm117532: feel free to elaborate, I guess I still don't follow 19:12 < 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:13 < 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:14 < bsm117532> The trie is an artifact of cheap memory costs relative to computation costs, in other words... 19:14 < qpm> tx: 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: and the trie structure is definitely open to revision (or complete reworking) 19:15 < 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:16 < 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:17 < qpm> tx: 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:18 < 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: 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:19 < 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: 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: 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:20 < 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:21 < kanzure> amiller_: https://github.com/bitcoin/bitcoin/pull/3977 19:21 < qpm> tx: 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:22 < qpm> tx: 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: 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:23 < rusty> bsm117532: then you need to know that last 100 blocks. That shouldn't be a problem, should it? 19:23 < qpm> tx: 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: Meaning that UNO commitments from a few hours ago are presumably still very useful 19:24 < 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: 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:25 < qpm> tx: 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: still, I suspect that a naming system has lower tx volume than a financial system 19:26 < 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:27 < rusty> bsm117532: vary 100 to taste, of course. 19:28 < 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: 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:29 < 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:30 < 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:31 < rusty> bsm117532: err... fake blocks can lie to light clients. That's always true... 19:32 < 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:33 < 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:34 < 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:35 < bsm117532> I'm interested in *timely* UTXO proofs, and 100 block proofs are really not terribly useful. 19:35 < rusty> bsm117532: 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:36 < 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:37 < bsm117532> If I'm dependent on proof-of-absence I'm now dependent on 6x proof-of-absence commitment time. 19:38 < 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:39 < qpm> tx: 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:. 19:40 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 19:41 < qpm> tx: 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:42 < qpm> tx: (unless there are problems with a trie in Namecoin's case that I don't see?) 19:43 < qpm> tx: btw, Daniel Kraft's thread documenting the Namecoin branch is at https://forum.namecoin.org/viewtopic.php?f=5&t=2239 19:45 < 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:47 < 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:48 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-wizards 19:49 < qpm> tx: 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:50 -!- 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:52 < qpm> tx: 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:53 < 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:57 < qpm> tx: 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:58 < amiller_> yup, that's my suggestion! 19:59 < qpm> tx: amiller_: cool. Your opinion has high value, so I'll probably advocate that. :) 19:59 < qpm> tx: 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 20:00 < qpm> tx: 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: But maybe there's a way I'm not thinking of? 20:01 < 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:02 < qpm> tx: amiller_: Fair point, I suppose 20:03 < 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:04 < qpm> tx: amiller_: Bitcoin's VersionBits actually breaks merge mined coins; Namecoin is planning to hardfork to fix that 20:04 < qpm> tx: 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:05 < qpm> tx: so if Bitcoin miners try to mine a VersionBits softfork using bit 0x100, they also can't merge-mine 20:07 < amiller_> too bad for namecoin i guess 20:07 < qpm> tx: 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:08 < qpm> tx: 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:10 < 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: True 20:11 < amiller_> let me know if you think of something better 20:11 < qpm> tx: will do :) 20:28 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 20:29 < 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:30 < 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:31 -!- a5m0_ is now known as a5m0 20:33 < 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:42 -!- tromp [~tromp@ool-944bc34f.dyn.optonline.net] has quit [Remote host closed the connection] 20:43 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 20:44 -!- gabridome_ [~gabridome@213.215.206.11] has joined #bitcoin-wizards 21:06 -!- 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:08 -!- gabridome_ [~gabridome@213.215.206.11] has quit [Quit: gabridome_] 21:09 -!- MaxSan_ [~one@109.202.107.15] has joined #bitcoin-wizards 21:15 -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Ping timeout: 250 seconds] 21:35 -!- MaxSan_ [~one@109.202.107.15] has quit [Ping timeout: 264 seconds] 21:38 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 21:38 -!- alferz [~alferz@unaffiliated/alfer] has quit [Ping timeout: 240 seconds] 21:39 -!- 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:40 < 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:43 -!- tromp [~tromp@ool-944bc34f.dyn.optonline.net] has joined #bitcoin-wizards 21:45 -!- 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:46 -!- alferz [~alferz@46.166.188.232] has quit [Changing host] 21:46 -!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards 21:47 -!- tromp [~tromp@ool-944bc34f.dyn.optonline.net] has quit [Ping timeout: 244 seconds] 21:50 -!- PeterR [488fe7f6@gateway/web/freenode/ip.72.143.231.246] has quit [Quit: Page closed] 21:51 -!- oneeman [~oneeman@ip77-154-15-186.ct.co.cr] has quit [Quit: Leaving] 22:13 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 22:27 -!- alferz [~alferz@unaffiliated/alfer] has quit [Ping timeout: 240 seconds] 22:28 -!- dingus [~grubles@unaffiliated/grubles] has joined #bitcoin-wizards 22:28 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 252 seconds] 22:33 -!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards 22:37 -!- alferz [~alferz@unaffiliated/alfer] has quit [Ping timeout: 240 seconds] 22:43 -!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards 22:52 -!- zooko [~user@2601:281:8000:8387:38fc:7037:e9cb:2de0] has joined #bitcoin-wizards 22:56 -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has quit [Ping timeout: 252 seconds] 23:10 -!- zooko [~user@2601:281:8000:8387:38fc:7037:e9cb:2de0] has quit [Ping timeout: 250 seconds] 23:15 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-agmwsdszuiegfmzx] has joined #bitcoin-wizards 23:26 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 23:28 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards 23:44 -!- tromp [~tromp@ool-944bc34f.dyn.optonline.net] has joined #bitcoin-wizards 23:48 -!- tromp [~tromp@ool-944bc34f.dyn.optonline.net] has quit [Ping timeout: 264 seconds] 23:50 -!- murch [~murch@p4FE39CD5.dip0.t-ipconnect.de] has joined #bitcoin-wizards 23:53 -!- blozo [~blozo@ppp121-44-178-241.lns20.syd7.internode.on.net] has quit [] 23:56 < maaku> bsm117532: why 100? just have the commitment be to the penultimate block 23:56 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 23:57 < 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:59 < maaku> but that problem mostly goes away if the update is to the penultimate block --- Log closed Wed Jul 06 00:00:49 2016