| --- Log opened Fri Sep 04 00:00:00 2015 | ||
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds] | 00:00 | |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds] | 00:01 | |
| -!- ebfull [~ebfull@73.34.119.0] has quit [Ping timeout: 244 seconds] | 00:02 | |
| -!- DougieBot5000_ [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 00:04 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Killed (hobana.freenode.net (Nickname regained by services))] | 00:04 | |
| -!- DougieBot5000_ is now known as DougieBot5000 | 00:04 | |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Quit: WeeChat 1.3] | 00:06 | |
| -!- gill3s [~gill3s@unaffiliated/gill3s] has joined #bitcoin-wizards | 00:06 | |
| -!- deego [~user@unaffiliated/deego] has joined #bitcoin-wizards | 00:07 | |
| -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Ping timeout: 250 seconds] | 00:11 | |
| -!- ebfull [~ebfull@73.34.119.0] has joined #bitcoin-wizards | 00:16 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 00:20 | |
| -!- adam3us [~Adium@62-2-191-242.static.cablecom.ch] has quit [Quit: Leaving.] | 00:21 | |
| -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-wizards | 00:21 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 00:21 | |
| -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards | 00:28 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 00:35 | |
| -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-wizards | 01:06 | |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 01:11 | |
| -!- spinza [~spin@197.89.184.38] has quit [Excess Flood] | 01:13 | |
| -!- spinza [~spin@197.89.184.38] has joined #bitcoin-wizards | 01:20 | |
| -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Ping timeout: 250 seconds] | 01:33 | |
| -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-wizards | 01:35 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] | 01:37 | |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards | 01:50 | |
| -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Ping timeout: 255 seconds] | 01:59 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] | 02:01 | |
| -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-wizards | 02:01 | |
| -!- nullbyte [~NSA@193.138.219.233] has quit [Ping timeout: 265 seconds] | 02:08 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 02:16 | |
| -!- metamarc [~cypher@unaffiliated/agorist000] has joined #bitcoin-wizards | 02:17 | |
| -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards | 02:18 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 250 seconds] | 02:25 | |
| -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has quit [Ping timeout: 246 seconds] | 02:25 | |
| -!- gmaxwell [greg@mf4-xiph.osuosl.org] has joined #bitcoin-wizards | 02:25 | |
| -!- gmaxwell is now known as Guest36270 | 02:26 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 02:33 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 02:38 | |
| -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 240 seconds] | 02:41 | |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 268 seconds] | 02:45 | |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-shdkzlaqgecziert] has quit [Quit: Connection closed for inactivity] | 03:00 | |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 03:06 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 244 seconds] | 03:14 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 03:16 | |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 272 seconds] | 03:23 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 03:27 | |
| -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has joined #bitcoin-wizards | 03:58 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte] | 04:09 | |
| -!- harding [~harding@mail.dtrt.org] has joined #bitcoin-wizards | 04:17 | |
| -!- King_Rex [~King_Rex@53.sub-70-193-64.myvzw.com] has joined #bitcoin-wizards | 04:35 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 04:38 | |
| -!- warptangent [~warptan@unaffiliated/warptangent] has quit [Remote host closed the connection] | 04:38 | |
| -!- warptangent [~warptan@unaffiliated/warptangent] has joined #bitcoin-wizards | 04:47 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer] | 04:48 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 04:49 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 05:02 | |
| -!- fuc [~fuc@ool-43571e2c.dyn.optonline.net] has joined #bitcoin-wizards | 05:18 | |
| -!- fuc is now known as mrhodl | 05:18 | |
| -!- mrhodl [~fuc@ool-43571e2c.dyn.optonline.net] has quit [Client Quit] | 05:18 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] | 05:18 | |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wswgyjzrlpvyjnfo] has joined #bitcoin-wizards | 05:21 | |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 05:21 | |
| -!- adam3us [~Adium@62-2-191-242.static.cablecom.ch] has joined #bitcoin-wizards | 05:39 | |
| -!- MrHodl [~fuc@185.22.183.202] has joined #bitcoin-wizards | 05:42 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Quit: Leaving] | 05:50 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 05:52 | |
| -!- davispuh [~quassel@212.93.100.199] has joined #bitcoin-wizards | 05:54 | |
| -!- binaryFate [~jeremie@joule.ulb.ac.be] has joined #bitcoin-wizards | 05:56 | |
| -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards | 06:00 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Remote host closed the connection] | 06:06 | |
| -!- kang_ [67efe9d5@gateway/web/freenode/ip.103.239.233.213] has joined #bitcoin-wizards | 06:15 | |
| -!- c0rw|zZz is now known as c0rw1n | 06:17 | |
| -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-wizards | 06:17 | |
| -!- davispuh [~quassel@212.93.100.199] has quit [Ping timeout: 264 seconds] | 06:20 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has quit [Read error: Connection reset by peer] | 06:20 | |
| -!- Emcy [~MC@cpc3-swan1-0-0-cust996.7-3.cable.virginm.net] has joined #bitcoin-wizards | 06:22 | |
| -!- Emcy [~MC@cpc3-swan1-0-0-cust996.7-3.cable.virginm.net] has quit [Changing host] | 06:22 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards | 06:22 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 06:26 | |
| -!- hazirafel [~ufoinc@31.154.91.221] has joined #bitcoin-wizards | 06:29 | |
| -!- MrHodl [~fuc@185.22.183.202] has quit [] | 06:31 | |
| -!- rubensayshi [~ruben@91.206.81.13] has quit [Read error: Connection reset by peer] | 06:34 | |
| -!- ufoinc__ [~ufoinc@31.154.91.221] has joined #bitcoin-wizards | 06:34 | |
| -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-wizards | 06:34 | |
| -!- hazirafel [~ufoinc@31.154.91.221] has quit [Ping timeout: 252 seconds] | 06:38 | |
| -!- ufoinc__ [~ufoinc@31.154.91.221] has quit [Ping timeout: 256 seconds] | 06:38 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards | 06:39 | |
| -!- GGuyZ [~GGuyZ@dhcp-18-189-28-106.dyn.mit.edu] has joined #bitcoin-wizards | 06:41 | |
| -!- frankenmint [~frankenmi@71-222-57-192.ptld.qwest.net] has joined #bitcoin-wizards | 06:44 | |
| -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards | 06:52 | |
| -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 07:10 | |
| -!- eudoxia [~eudoxia@r167-57-55-201.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 07:11 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 07:14 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has left #bitcoin-wizards [] | 07:18 | |
| -!- chris13243 [~chris@107.25.161.212] has joined #bitcoin-wizards | 07:25 | |
| -!- NLNico_ [~NLNico@unaffiliated/nlnico] has joined #bitcoin-wizards | 07:27 | |
| -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Read error: Connection reset by peer] | 07:27 | |
| -!- chris13243 [~chris@107.25.161.212] has quit [Ping timeout: 264 seconds] | 07:34 | |
| -!- Guest36270 [greg@mf4-xiph.osuosl.org] has quit [Changing host] | 07:43 | |
| -!- Guest36270 [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-wizards | 07:43 | |
| -!- Guest36270 is now known as gmaxwell | 07:43 | |
| -!- GGuyZ [~GGuyZ@dhcp-18-189-28-106.dyn.mit.edu] has quit [Quit: GGuyZ] | 07:51 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 07:56 | |
| -!- chris13243 [~chris@108.121.115.250] has joined #bitcoin-wizards | 07:56 | |
| -!- NLNico_ [~NLNico@unaffiliated/nlnico] has quit [Ping timeout: 240 seconds] | 07:57 | |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-wizards | 07:58 | |
| -!- NLNico_ [~NLNico@unaffiliated/nlnico] has joined #bitcoin-wizards | 08:01 | |
| -!- nwilcox [~nwilcox@74-95-207-205-SFBA.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 08:03 | |
| -!- shen_noe [~shen_noe@104.156.228.141] has quit [Quit: Leaving] | 08:05 | |
| -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards | 08:13 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] | 08:14 | |
| -!- NLNico_ [~NLNico@unaffiliated/nlnico] has quit [Ping timeout: 252 seconds] | 08:18 | |
| -!- chris13243 [~chris@108.121.115.250] has quit [Ping timeout: 244 seconds] | 08:24 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] | 08:26 | |
| -!- mkarrer_ [~mkarrer@165.Red-83-55-152.dynamicIP.rima-tde.net] has joined #bitcoin-wizards | 08:27 | |
| -!- mkarrer [~mkarrer@77.Red-81-33-48.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 08:27 | |
| -!- mkarrer_ [~mkarrer@165.Red-83-55-152.dynamicIP.rima-tde.net] has quit [Remote host closed the connection] | 08:28 | |
| -!- mkarrer [~mkarrer@247.Red-83-36-8.dynamicIP.rima-tde.net] has joined #bitcoin-wizards | 08:28 | |
| -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Remote host closed the connection] | 08:29 | |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Quit: WeeChat 1.4-dev] | 08:30 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 08:48 | |
| -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-wizards | 08:50 | |
| -!- nwilcox [~nwilcox@74-95-207-205-SFBA.hfc.comcastbusiness.net] has quit [Ping timeout: 268 seconds] | 08:54 | |
| -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 09:00 | |
| -!- chris13243 [~chris@72-57-138-43.pools.spcsdns.net] has joined #bitcoin-wizards | 09:00 | |
| -!- nullbyte [~NSA@198.203.28.43] has joined #bitcoin-wizards | 09:00 | |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-wizards | 09:01 | |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Client Quit] | 09:02 | |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-wizards | 09:03 | |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Client Quit] | 09:03 | |
| -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Quit: Leaving] | 09:05 | |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-wizards | 09:05 | |
| -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has joined #bitcoin-wizards | 09:05 | |
| -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards | 09:07 | |
| -!- nullbyte [~NSA@198.203.28.43] has quit [Ping timeout: 264 seconds] | 09:08 | |
| -!- hazirafel [~ufoinc@31.154.91.221] has joined #bitcoin-wizards | 09:12 | |
| -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has quit [Remote host closed the connection] | 09:24 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 09:28 | |
| -!- hazirafel [~ufoinc@31.154.91.221] has quit [Read error: Connection reset by peer] | 09:29 | |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 09:36 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 09:40 | |
| -!- gill3s [~gill3s@unaffiliated/gill3s] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 09:44 | |
| -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 260 seconds] | 09:46 | |
| -!- chris13243 [~chris@72-57-138-43.pools.spcsdns.net] has quit [Ping timeout: 252 seconds] | 09:46 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 268 seconds] | 09:48 | |
| -!- nullbyte [~NSA@198.203.28.43] has joined #bitcoin-wizards | 09:52 | |
| -!- adam3us [~Adium@62-2-191-242.static.cablecom.ch] has quit [Read error: Connection reset by peer] | 09:55 | |
| -!- kang_ [67efe9d5@gateway/web/freenode/ip.103.239.233.213] has quit [Quit: Page closed] | 09:55 | |
| -!- adam3us [~Adium@62-2-191-242.static.cablecom.ch] has joined #bitcoin-wizards | 09:57 | |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] | 09:59 | |
| -!- firebird_ [b90c2f30@gateway/web/freenode/ip.185.12.47.48] has joined #bitcoin-wizards | 10:00 | |
| -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 10:00 | |
| firebird_ | https://bytecoin.org/blog/cryptonote-aggregate-addresses-whitepaper/ | 10:00 |
|---|---|---|
| kanzure | https://bytecoin.org/static/files/docs/aggregate-addresses.pdf | 10:01 |
| -!- ginah [~nahnah@50.248.81.66] has quit [Remote host closed the connection] | 10:06 | |
| dEBRUYNE | kanzure, firebird_: Monero already integrated that, see -> https://github.com/monero-project/bitmonero/pull/317 & subsequent -> https://github.com/monero-project/bitmonero/pull/361 | 10:08 |
| kanzure | heh using pastebin for proposals.. oh well. http://pastebin.com/bp5RKXuC | 10:09 |
| -!- afk11 [~afk11@unaffiliated/afk11] has quit [Read error: Connection reset by peer] | 10:09 | |
| -!- estem [~estem@50.248.81.66] has joined #bitcoin-wizards | 10:10 | |
| gmaxwell | firebird_: thanks, I'd be surprised if the same observation wasn't made in prior stealth address discussions in bitcoin. | 10:10 |
| -!- kmels [~kmels@186.64.110.122] has joined #bitcoin-wizards | 10:12 | |
| gmaxwell | To save people time, when scanning transactions, the transaction contains the ephemeral public key R. You'd look for your address as P = H(aR)G + B where a is your viewing secret and B is your spending pubkey. | 10:12 |
| firebird_ | I'm not sure it works the same way in Monero | 10:12 |
| gmaxwell | The paper suggests that you compute D = H(aR)G and then for each output perform a point subtraction to recover the apparent B. | 10:12 |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 10:13 | |
| gmaxwell | This lets you have many distinct spending private keys, with one scanning key. The advantage of doing so is that you don't have to do seperate ECDH work per spending private key. | 10:13 |
| gmaxwell | And the advantage of that is that if you're a webwallet you can tall customers apart. | 10:14 |
| dEBRUYNE | firebird_: Paging fluffypony to elaborate :P | 10:14 |
| fluffypony | dEBRUYNE: no we did something different | 10:15 |
| fluffypony | we have a third component, a short payment ID, that is optional and encrypted | 10:16 |
| fluffypony | (well, optionally encrypted) | 10:16 |
| gmaxwell | I think the complexity claim in the paper is bogus, It's staying it takes the complexity from Addresses * Txn to Addresses+Txn, but thats only true if you totally discount the point additions. The ECDH is probably only about (say) 20x slower than the point additions (as those adds will need a sqrt, a ge+gej, and a modular inversion), so I don't think it's reasonable to ignore them. | 10:17 |
| fluffypony | gmaxwell: agreed | 10:17 |
| gmaxwell | fluffypony: is the payment ID stuff adequate for web-ishwallets and such? | 10:18 |
| -!- jack-jack [b23fe762@gateway/web/freenode/ip.178.63.231.98] has joined #bitcoin-wizards | 10:18 | |
| fluffypony | gmaxwell: no, more for deposit-taking systems where they provide the payment ID to the payee, and then they're able to identify incoming transactions for that user | 10:18 |
| gmaxwell | Yea, so I think this is perhaps a worthwhile approach, but not amazing. :) | 10:19 |
| fluffypony | the one-viewkey-many-spendkeys idea for a webwallet is an interesting application of it | 10:19 |
| fluffypony | I don't see that they've realised that is even a possibility | 10:19 |
| gmaxwell | hahah | 10:20 |
| fluffypony | so well done gmaxwell, you've figured out a novel application of their scheme | 10:20 |
| fluffypony | that actually gives it value :-P | 10:20 |
| gmaxwell | I usually have to come up with an application for something in order to understand it. | 10:20 |
| gmaxwell | But indeed, they don't really seem to explicitly call that out. | 10:20 |
| gmaxwell | But you can give them a bit more credit, they might have been thinking it and just not communicated it really well. | 10:20 |
| fluffypony | I couldn't come up with an application for it, so I rejected it as pointless, but I was thinking in terms of a single user's wallet (in which case if you want separate "addresses" for fear of them being associated together you'd have to roll both keys) | 10:21 |
| -!- rubensayshi [~ruben@91.206.81.13] has quit [Ping timeout: 240 seconds] | 10:21 | |
| fluffypony | gmaxwell: nah, their conclusion: "Aggregate addresses is the solution that significantly improves Bytecoin transaction processing for services. This scheme is useful for all CryptoNote currencies as it drastically upgrades user experience and effectively depreciates Payment ID." | 10:21 |
| jack-jack | I'm sorry, joined I joined in the middle of the chat | 10:22 |
| fluffypony | jack-jack: you're forgiven | 10:22 |
| jack-jack | what's the novelty application that gmaxwell came up with? | 10:23 |
| gmaxwell | Okay I was slightly wrong on the above complexity is ECDH * Transactions + Sqrt,GeGej,Inv * Outputs + hashtable, OR it's ECDH * Transactions + Sqrt,GeGej,Fe * Outputs * Addresses. It is a complexity improvement over ECDH * Transactions * Addresses. | 10:23 |
| fluffypony | jack-jack: one lemon tree, but the tree doesn't know who owns individual lemons | 10:23 |
| gmaxwell | fluffypony: yea, I think its a dumb replacement for payment ID. | 10:23 |
| -!- nullbyte [~NSA@198.203.28.43] has quit [Ping timeout: 244 seconds] | 10:23 | |
| gmaxwell | It's not a complexity improvement over payment ID, but it may be a usability/security improvement of it. | 10:24 |
| fluffypony | yeah, which we achieved by first serializing the payment ID into the address, and then shortening + encrypting it | 10:24 |
| fluffypony | (because there's no difference between a 95-char address and a 150ish-char address | 10:25 |
| -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards | 10:25 | |
| jack-jack | 150 chars is more than a tweet :) | 10:26 |
| fluffypony | heh heh | 10:26 |
| fluffypony | payment IDs are optional, and you can use OpenAlias in a tweet anyway :) | 10:26 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-ageuuwqziecnlihq] has joined #bitcoin-wizards | 10:26 | |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Quit: WeeChat 1.4-dev] | 10:26 | |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-wizards | 10:26 | |
| jack-jack | and why including pid at all? | 10:27 |
| gmaxwell | oh their scheme has a privacy flaw. | 10:27 |
| kanzure | does it make sense to use pow for situations like "supernode with signing pool federated consensus has fraud proof showing fraud, network has to decide on alternative non-fraudulent signing pool, use pow to do a first-past-the-post election race for alternative signing pool for whole network to switch to"? this seems to fail for things like "oops the alternative signing pool/server supernode the network has picked doesn't actually have ... | 10:27 |
| kanzure | ... the necessary capacity". | 10:27 |
| kanzure | (this is for "graceful recovery of catastrophic consensus failures, like an evil mining cartel or evil fraudulent supernode") | 10:28 |
| gmaxwell | Yea, privacy of their scheme is busted. | 10:28 |
| -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 10:28 | |
| fluffypony | jack-jack: to identify payments without the payee having to tell you the details of the transaction | 10:29 |
| jack-jack | gmaxwell: what do you mean? | 10:29 |
| gmaxwell | Lets imagine that there addresses with keys (a, B1), (a, B2), (a, B3) which are known to you. A transaction shows up on the network with two outputs P1 and P2 and you would like to test the hypothesis that the transaction pays B1 and B2. | 10:29 |
| kanzure | oh actually i guess it would be pretty hard to pick a machine that did not have the necessary capacity- even trash laptops these days can do 20k/sec transaction verification. but someone might have put up their arduino as an alternative :-)... | 10:29 |
| -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has quit [Ping timeout: 240 seconds] | 10:29 | |
| gmaxwell | So you check if P1 - P2 == B1 - B2 and if the relation holds, the transaction pays those two addresses. This is because P1 = B1 + D and P2 = B2 + D and the D (contribution of the ephemeral part) cancels under addition. | 10:30 |
| gmaxwell | I feel stupid to have not seen that immediately. :( | 10:30 |
| gmaxwell | Look right? | 10:30 |
| fluffypony | ah | 10:32 |
| fluffypony | pity | 10:33 |
| ryan-c | jack-jack: note that twitter allows tweets to contain 140 characters - which can be more than 140 bytes total | 10:33 |
| gmaxwell | This can be fixed, if the scheme does ECDH per output instead of per transaction. Even just the Hash. E.g. H(index||aR)G changing the complexities from O(transactions) to O(outputs) | 10:34 |
| gmaxwell | I guess I'll write a short little latex formated note so people will find my cryptanalysis credible. lol. | 10:35 |
| -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 10:35 | |
| ryan-c | heh | 10:35 |
| ryan-c | it's funny how much more credible latex makes things | 10:35 |
| gmaxwell | hm. I created a directory called "crytponote.b" and it struck me how much that sounds like a virus name. :P | 10:36 |
| -!- c0rw1n [~c0rw1n@228.208-241-81.adsl-dyn.isp.belgacom.be] has quit [Read error: Connection reset by peer] | 10:36 | |
| -!- c0rw1n [~c0rw1n@228.208-241-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 10:37 | |
| jack-jack | gmaxwell: > This can be fixed, if the scheme does ECDH per output instead of per transaction. Even just the Hash. E.g. H(index||aR)G changing the complexities from O(transactions) to O(outputs) | 10:37 |
| jack-jack | gmaxwell: actually, it is the way it is implemented | 10:37 |
| jack-jack | ;) | 10:37 |
| ryan-c | gmaxwell: It looks like you're trying to write a ransomeware. Would you like help? | 10:38 |
| jack-jack | https://cryptonote.org/cns/cns006.txt | 10:38 |
| jack-jack | >> one-time public key P = H(r*A || n)*G + B | 10:38 |
| gmaxwell | jack-jack: That isn't what the paper describes. It also increases the computational complexity considerably, as it means a fixed basis multiply per output. | 10:38 |
| jack-jack | the number of output is also hashed | 10:39 |
| fluffypony | also lol @ 2012 | 10:39 |
| jack-jack | however it was omitted both in original CN whitepaper and this one | 10:39 |
| -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards | 10:39 | |
| jack-jack | gj | 10:40 |
| fluffypony | by original you mean the fake v1 that had all the bits ripped out from v2 but left footnotes in that referred to non-existent sections? | 10:40 |
| jack-jack | by original I mean the whitepaper that allowed you to have a meaningful life :) | 10:40 |
| jack-jack | but that's not the point | 10:40 |
| jack-jack | finally, R is random | 10:41 |
| jack-jack | ah, nope comment on R is irrelevant in case of 1 tx | 10:43 |
| jack-jack | R is common, but considering output number being hashed, D's will be different for different outputs | 10:43 |
| -!- c0rw1n is now known as greenbat | 10:45 | |
| jack-jack | I should agree, this whitepaper messes up the things actually implemented. Here: "First, for each transaction, the derivation is computed: D = Hs(aR)G" should be "for each output". | 10:47 |
| jack-jack | But that's not an uncommon mistake, thanks for the feedback | 10:48 |
| gmaxwell | It can't say "for each output" because there is no output specific index anywhere. | 10:48 |
| -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has quit [Ping timeout: 250 seconds] | 10:49 | |
| -!- jojva [~dev@shattrath.sceen.net] has quit [Quit: Quitte] | 10:49 | |
| jack-jack | yep, oversimplified | 10:50 |
| jack-jack | gmaxwell: >It also increases the computational complexity considerably, as it means a fixed basis multiply per output | 10:51 |
| jack-jack | that's actually what was stated: "As a result, the time it takes to process M outputs if there are N users is proportional to M + N, not M · N as with the naive approach" | 10:51 |
| jack-jack | gmaxwell: it should be as follows: "First, for each output, the derivation is computed: D = Hs(aR||n)G, where n is the index of the output in the transaction" | 10:54 |
| gmaxwell | D needs a subscript. | 10:54 |
| gmaxwell | If you're revising the paper, feel free to thank me for commentary. | 10:55 |
| gmaxwell | Dn = Hs(aR||n)G and Pn = Bn + Dn in the sender and Bn = Pn - Dn in the reciever. and lookup Bn in the hashtable. | 10:56 |
| -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards | 10:58 | |
| -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 244 seconds] | 10:58 | |
| -!- greenbat is now known as c0rw1n | 10:59 | |
| -!- davispuh [~quassel@212.93.100.199] has joined #bitcoin-wizards | 10:59 | |
| -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards | 11:01 | |
| gmaxwell | 10:30 < xiphmont> I wonder if USB superposition implies that cellphones are quantum 1/2 spin devices and, if so, can they be entangled? | 11:01 |
| gmaxwell | 10:33 < gnafu> How can they get entangled? They're wireless! | 11:01 |
| gmaxwell | 10:56 < TD-Linux> spook action at a distance | 11:01 |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 11:03 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 252 seconds] | 11:04 | |
| petertodd | what's the current status of stuff like moxie for deterministic code execution? looks like there's moxie, ethereum vm, bitcoin script, and... ? | 11:04 |
| -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 264 seconds] | 11:05 | |
| tromp_ | TinyRAM | 11:07 |
| tromp_ | see http://www.scipr-lab.org/specs.html | 11:07 |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] | 11:07 | |
| petertodd | tromp_: thanks! | 11:08 |
| -!- chris13243 [~chris@72-62-133-13.pools.spcsdns.net] has joined #bitcoin-wizards | 11:08 | |
| petertodd | "The TinyRAM architecture is a random-access machine designed to be a convenient tool for expressing the correctness of nondeterministic computations." <- _non_deterministic?! | 11:08 |
| petertodd | interesting definition they must be using | 11:09 |
| kanzure | also there's this thing https://github.com/pepper-project/tinyram | 11:09 |
| petertodd | presumably that's in relation to how the proofs hide stuff, or something :/ | 11:09 |
| -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [] | 11:09 | |
| petertodd | kanzure: thanks | 11:09 |
| kanzure | was trying to convince andytoshi to infiltrate that group to see what's up (since it's local to him) | 11:09 |
| petertodd | heh | 11:10 |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Ping timeout: 264 seconds] | 11:10 | |
| petertodd | I'm trying to figure out what's a reasonable recommendation to make to a client(s) about what direction to be going in for smartcontracts crud | 11:10 |
| kanzure | also https://github.com/scipr-lab/libsnark/blob/1767d5d9602fb8ac2ce9fa928c9dfc0d78975bf2/src/relations/ram_computations/rams/examples/ram_examples.tcc | 11:13 |
| tromp_ | so that would depend on whether they want to do zero knowledge proofs for their smart contracts | 11:13 |
| -!- shen_noe [~shen_noe@104.156.228.141] has joined #bitcoin-wizards | 11:13 | |
| petertodd | IMO zero-knowledge proofs are too early to trust, so it'd just be to have a secure VM that can't be escaped | 11:14 |
| phantomcircuit | petertodd, afaik the only solution to receive significant review is bitcoin script | 11:14 |
| phantomcircuit | fun | 11:14 |
| petertodd | phantomcircuit: heh, I can believe that | 11:14 |
| tromp_ | There's also http://oblivm.com/hawk/ which must have a vm hidden in there | 11:15 |
| petertodd | phantomcircuit: OTOH, I know of someone using the python isolation tools for this... I basically said I'd have to say in my security review that we're assuming there is no security, and they (fortunately!) agreed | 11:15 |
| phantomcircuit | ha | 11:16 |
| petertodd | tromp_: huh, never seen hawk before | 11:16 |
| -!- jack-jack [b23fe762@gateway/web/freenode/ip.178.63.231.98] has quit [Quit: Page closed] | 11:17 | |
| tromp_ | and then there's Tezos and Tauchain... | 11:17 |
| phantomcircuit | petertodd, i would assume that most sandboxing mechanisms have some kind of time limit on execution | 11:18 |
| phantomcircuit | rather than a resource counter | 11:18 |
| petertodd | phantomcircuit: yeah, I think time/space limits are the way to go for engineering simplicity | 11:18 |
| phantomcircuit | which is bad | 11:18 |
| phantomcircuit | time restrictions are bad | 11:18 |
| petertodd | phantomcircuit: ah, yeah, wallclock time is very bad | 11:18 |
| petertodd | phantomcircuit: needs to be instruction "time" | 11:18 |
| phantomcircuit | yeah | 11:18 |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 11:22 | |
| -!- GGuyZ [~GGuyZ@172.56.22.156] has joined #bitcoin-wizards | 11:22 | |
| -!- chris13243 [~chris@72-62-133-13.pools.spcsdns.net] has quit [Ping timeout: 264 seconds] | 11:25 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-ageuuwqziecnlihq] has quit [Ping timeout: 246 seconds] | 11:25 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-bhaoenjwhxyghjgn] has joined #bitcoin-wizards | 11:26 | |
| -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards | 11:30 | |
| gmaxwell | I found moxie when looking for something like tinyram. .. no code available for tinyram AFAIK, and moxie has pretty nice GCC support, and I heard LLVM/clang was in progress. | 11:31 |
| gmaxwell | phantomcircuit: non-determinstic just means that there can be non-public inputs. | 11:31 |
| -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Quit: Leaving.] | 11:32 | |
| phantomcircuit | petertodd, ^ | 11:32 |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] | 11:32 | |
| gmaxwell | E.g. you can setup a transcript where you prove F(A,b) == True for some B. Tinyram itself does nothing to help you hide B, but its setup to not gratitiously inflate the size of the public data for schemes where you can hide inputs. | 11:33 |
| petertodd | gmaxwell: makes sense | 11:33 |
| petertodd | gmaxwell: I'm thinking for practical systems, we'll find the GCC support to be pretty useful | 11:34 |
| gmaxwell | And the circuit arithemetic implementing it is especially small, given that. | 11:34 |
| gmaxwell | petertodd: Yea "no shit". | 11:34 |
| petertodd | gmaxwell: heh :) | 11:34 |
| gmaxwell | petertodd: so there is a paper on doing interactive proofs for faithful execution on x86. | 11:35 |
| petertodd | gmaxwell: oh! | 11:35 |
| gmaxwell | (because some people like pain) | 11:35 |
| petertodd | gmaxwell: how do the proofs work? | 11:36 |
| gmaxwell | e.g. where you build a hashtree over the transcript and if multiple oracles disagree you do log() queries to find the point of first disagreement then you check that step and reject the bad oracle. | 11:36 |
| -!- GGuyZ [~GGuyZ@172.56.22.156] has quit [Ping timeout: 246 seconds] | 11:36 | |
| gmaxwell | So it works so long as one oracle is honest. | 11:36 |
| petertodd | gmaxwell: right, sounds very useful | 11:36 |
| gmaxwell | as you'll eventually find the truthteller. | 11:37 |
| petertodd | gmaxwell: has anyone implemented anything like that for moxie? (how many moxie VM's are there? I think I just saw jgarzik's, and the qemu one | 11:37 |
| gmaxwell | No one has, it wouldn't be hard. the most tricky part is that you need to make the dram a hashtree. | 11:38 |
| gmaxwell | otherwise you can't compactly prove the result of a load instruction. | 11:38 |
| petertodd | gmaxwell: right, and that doens't sound hard to do (modulo speed) | 11:38 |
| gmaxwell | Fortuneately moxie has seperate load/store and no other instruction has access to anything but registers. | 11:39 |
| -!- shen_noe [~shen_noe@104.156.228.141] has quit [Quit: Leaving] | 11:41 | |
| petertodd | gmaxwell: right, sounds easy enough | 11:42 |
| petertodd | related question: how appropriate is moxie for a scriptPubKey replacement? (including for OpenPGP) Would you want to add some "system calls" for baked in sha256/ecc, etc? | 11:42 |
| -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards | 11:43 | |
| gmaxwell | It really needs crypto accelerators (thats what we'd likely call fixed function units for crypto if we were talking about some SOC)-- performing things like SHA256 directly in it has performance that probably makes it unusable without fancy jit stuff, which defeats some of the assurance purposes. | 11:44 |
| gmaxwell | (and they could easily be done safely and without compromising the assurances, I think). | 11:44 |
| petertodd | makes sense; has anyone done any prototypes of that? | 11:44 |
| gmaxwell | I have non-released stuff fussing around with it. Still unsure of the best way to handle it. I'm not sure if anyone has actually played with that. | 11:45 |
| gmaxwell | The prerhaps bigger issue as a scriptpubkey replacement is that the code is not very succinct. | 11:45 |
| -!- c0rw1n [~c0rw1n@228.208-241-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 244 seconds] | 11:46 | |
| gmaxwell | It's less compact than x86, generally, and no comparison to Script for in-domain things. | 11:46 |
| -!- firebird_ [b90c2f30@gateway/web/freenode/ip.185.12.47.48] has quit [Quit: Page closed] | 11:46 | |
| gmaxwell | e.g. see pieter's key tree stuff where the hashtree stuff is 6 bytes per level (and would be 8 bytes total, if Script had FOR/NEXT like HP RPN does) | 11:46 |
| -!- adam3us [~Adium@62-2-191-242.static.cablecom.ch] has quit [Quit: Leaving.] | 11:47 | |
| petertodd | yeah, already opcodes are at least 16bits for instance | 11:47 |
| gmaxwell | you obviously also need a setup to provide it access to useful data from the enclosing enviroment. | 11:47 |
| petertodd | basically some kind of well-defined memmapping - might be nice to adopt a standard function call style for that | 11:48 |
| gmaxwell | they also just do a lot less. which is good and even essential when targeting it with a C compiler. :) | 11:48 |
| petertodd | yup | 11:48 |
| Eliel | would it really need baked in opcodes? If you can define functions by hash of the function code, only one transaction ever needs to include the function itself and then implementations can then implement optimized versions of specific hashes for often used functions. | 11:48 |
| gmaxwell | Eliel: No, because the computational burden of an operation must be normative in a consensus system. | 11:48 |
| gmaxwell | E.g. a side effect of any function is updating the cycle counter, so... | 11:49 |
| petertodd | Eliel: that's an approach too, but needs a well-defined function call scheme, and as gmaxwell says, has consensus issues | 11:49 |
| gmaxwell | Eliel: what I was actually doing though, in my setup was handling the accelerators using function calls though. Because that made it easier to use standard moxie toolchain. | 11:49 |
| petertodd | gmaxwell: as though the function was calling memory that didn't actually exist? | 11:50 |
| gmaxwell | petertodd: yea, just in my accelerated version I intercepted the jump and switched to the replacement. | 11:50 |
| gmaxwell | but otherwise a native version could be used in a dumb machine (e.g. so gdb works) though the execution wasn't exactly identical. | 11:51 |
| -!- chmod755 [~chmod755@unaffiliated/chmod755] has joined #bitcoin-wizards | 11:51 | |
| -!- c0rw1n [~c0rw1n@228.208-241-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 11:51 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] | 11:52 | |
| Eliel | also, for estimating the computational burden for a script. I think I'd approach it by requiring the script to specify an upper limit for itself, that could then be used for determining the transaction fee. You'd incentivize correct upper bounds by automatically failing the script if it violates it's own defined upper bound. | 11:52 |
| gmaxwell | in any case what I'd planned on accelerating was memcmp/memcmp/bzero/etc. along with hash functions, and ecc (for a couple high performance curves). I looked into pulling in all of GMP but it seemed like to much work to make certantly safe. | 11:53 |
| petertodd | gmaxwell: sounds like a decent way to handle it would be to basically pretend that part of memory existed, but for some reason couldn't be accessed by the actual code, and for debugging actually load that memory with code implementing the real thing | 11:53 |
| gmaxwell | Eliel: yep, absolutely-- discussed here before. Though you need to also ban peers that give you failing scripts (if you weren't already thinking that) | 11:53 |
| petertodd | gmaxwell: all sounds reasonable | 11:53 |
| Eliel | gmaxwell: well, that's only necessary for scripts with unusually high upper bounds. | 11:54 |
| CodeShark | unless we have conditional branching, is there ever a case where computational cost cannot be reasonably estimated simply by parsing? | 11:55 |
| petertodd | gmaxwell: one thing with smartcontract crud is you may have a situation where you want to basically be able to "call" another chunk of user-written code in a deterministic way, and have it either do the calculation fo rreal, or just return a cached answer | 11:55 |
| petertodd | gmaxwell: e.g. so you could split up some massive computation like... verify every transaction in a huge chain | 11:55 |
| kanzure | petertodd: there has been talk about embedding moxiebox interpreter called by opcode.. | 11:55 |
| gmaxwell | CodeShark: nice unless there. technically we only need a grammer where computational cost is trivial to determine, but compiling general code to such systems is hard. | 11:56 |
| -!- adam3us [~Adium@178.197.228.122] has joined #bitcoin-wizards | 11:56 | |
| petertodd | the programming model in that case becomes nice and simple to the end user, whre they're just calling functions with names like VerifyTransaction() | 11:56 |
| CodeShark | in particular, looping on conditionals complicates cost evaluation...or makes it impossible to do so | 11:58 |
| petertodd | CodeShark: well, IMO cost though actual instructions executed is way simpler; our track record of doing otherwise is poor... | 11:58 |
| gmaxwell | CodeShark: cost can be easily and reliably measured by tracing. | 11:59 |
| gmaxwell | and you can abort at the limit. | 12:00 |
| gmaxwell | Basically the input is cost,script and yes, someone can send you an incorrect cost, but no less than they can just send you a correct cost but a script that is unsuccessful. | 12:00 |
| gmaxwell | in all cases the upper bound on computation must still be fairly low... though computation could be broken up as PT suggests. | 12:01 |
| gmaxwell | Normally you'd hide the computation from the network using the coinswap transformation. | 12:02 |
| kanzure | "just use a merklized abstract syntax tree to hide the actual computation, and tell everyone they better behave or else" doesn't work? | 12:02 |
| gmaxwell | (or the fancier bonded versions suggested by Ed Felten and his students) | 12:03 |
| gmaxwell | kanzure: sure but the threat has to be credible. | 12:03 |
| gmaxwell | You can't hide the computation when the network can't actually process it, or the threat is a dead letter. | 12:03 |
| -!- adam3us [~Adium@178.197.228.122] has quit [Quit: Leaving.] | 12:03 | |
| kanzure | excessive computation causes all outputs to go to fees? :-) | 12:04 |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 12:04 | |
| kanzure | but yes i see your point | 12:04 |
| gmaxwell | kanzure: then I make an invalid spend of your coins that also does excessive computations. | 12:05 |
| gmaxwell | MOAR COINS FOR THE MINE GODS. | 12:05 |
| jgarzik | kanzure, fyi had no bandwidth for review - looks like gud stuf | 12:06 |
| -!- mkarrer [~mkarrer@247.Red-83-36-8.dynamicIP.rima-tde.net] has quit [] | 12:06 | |
| -!- adam3us [~Adium@178.197.232.114] has joined #bitcoin-wizards | 12:07 | |
| -!- mkarrer [~mkarrer@247.Red-83-36-8.dynamicIP.rima-tde.net] has joined #bitcoin-wizards | 12:07 | |
| kanzure | jgarzik: thanks | 12:08 |
| -!- erasmospunk [~erasmospu@179.43.156.162] has joined #bitcoin-wizards | 12:08 | |
| -!- blackwraith [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 12:09 | |
| -!- Guest89 [~textual@c-73-15-187-144.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 12:10 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 260 seconds] | 12:11 | |
| CodeShark | if the computation can be broken up and smaller pieces verified and paid for individually it could work | 12:12 |
| gmaxwell | well for defined party contracts you can teach the network to perform the interactive protocol I gave above. | 12:14 |
| gmaxwell | and you bond performance. | 12:14 |
| gmaxwell | (by gave I mean cited) | 12:14 |
| gmaxwell | (and by cited I mean mentioned vaguely without giving enough information for you to actually find it) | 12:14 |
| CodeShark | lol | 12:14 |
| gmaxwell | (though I did say enough that you likely don't need the paper) | 12:14 |
| -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has quit [Remote host closed the connection] | 12:14 | |
| CodeShark | speaking of which, I'm putting together a list of commitment structure proposals (UTXO commitments, fraud proofs, etc..) for Montreal. If anyone here would like to have their work included, please PM me | 12:16 |
| gmaxwell | CodeShark: make sure you check with the archivist. | 12:16 |
| CodeShark | it's for a presentation, gmaxwell | 12:17 |
| CodeShark | although perhaps it will end up becoming a publication | 12:17 |
| -!- adam3us [~Adium@178.197.232.114] has quit [Quit: Leaving.] | 12:18 | |
| kanzure | CodeShark: he means "make sure you ask kanzure for all the links about those things" | 12:20 |
| CodeShark | oh...ok :) | 12:20 |
| kanzure | CodeShark: asking people for links to their work is unfortunately never going to work | 12:20 |
| CodeShark | so do you have a list? | 12:21 |
| kanzure | yes... one sec. | 12:21 |
| -!- Guest89 [~textual@c-73-15-187-144.hsd1.ca.comcast.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 12:23 | |
| kanzure | CodeShark: http://diyhpl.us/~bryan/irc/bitcoin/utxo-commitments-or-fraud-proofs.stdout.txt | 12:23 |
| -!- CohibAA [~CohibAA@unaffiliated/cohibaa] has joined #bitcoin-wizards | 12:23 | |
| CodeShark | wonderful, thank you very much :) | 12:24 |
| kanzure | if you would like me to run a query with another tag please let me know | 12:24 |
| -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has joined #bitcoin-wizards | 12:24 | |
| kanzure | as for fraud proofs i think this is the best link out of the bunch, at least for describing the necessary types of fraud proofs https://bitcointalk.org/index.php?topic=1103281.msg11743498#msg11743498 | 12:26 |
| CodeShark | right, I had seen that one before - but admittedly I don | 12:27 |
| CodeShark | I don't spend much time on bitcointalk | 12:27 |
| CodeShark | so many of the others I haven't fully read through | 12:27 |
| -!- eudoxia_ [~eudoxia@r167-57-96-88.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 12:27 | |
| kanzure | also i double checked and it seems i have some non-github content about proofchains over here: http://0bin.net/paste/vLDRrhx-ALufTR94#DmA7QRjxtKebJ66MJfbQTrVYPUKC1khfdpWT8pdbZpJ | 12:28 |
| kanzure | (single-use seals) | 12:28 |
| gmaxwell | There is fraud proof discussion I had quite early in bitcoin-dev and on the mailing list I think... back before I realized that the bitcoin whitepaper mentioned them in the SPV section. | 12:29 |
| CodeShark | heh | 12:29 |
| petertodd | kanzure: thanks, but that should be on github :) | 12:29 |
| gmaxwell | Obviously there is that little table on that wiki page from me. | 12:29 |
| kanzure | https://github.com/proofchains/python-proofchains | 12:30 |
| kanzure | petertodd: right, right.. | 12:30 |
| petertodd | kanzure: https://github.com/proofchains/python-proofchains/blob/master/proofchains/core/uniquebits/singleuseseal.py | 12:30 |
| -!- eudoxia_ [~eudoxia@r167-57-96-88.dialup.adsl.anteldata.net.uy] has quit [Client Quit] | 12:30 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 12:30 | |
| kanzure | petertodd: it is hard keeping 4000 links straight | 12:31 |
| -!- eudoxia [~eudoxia@r167-57-55-201.dialup.adsl.anteldata.net.uy] has quit [Ping timeout: 240 seconds] | 12:31 | |
| -!- hsmiths [uid95325@gateway/web/irccloud.com/x-xtwdoiglfenniqep] has joined #bitcoin-wizards | 12:32 | |
| CodeShark | glad someone's doing this crucial task, kanzure :) | 12:41 |
| CodeShark | much appreciated - we really do need it | 12:41 |
| kanzure | CodeShark: my presentation is a review of all scalability proposals that have been made since 2009. if you have things that you think are in danger of being missed, please send them my way... | 12:41 |
| CodeShark | sure. and mine is on validation costs and incentives. ditto :) | 12:42 |
| kanzure | validation costs hmm. | 12:43 |
| -!- eudoxia [~eudoxia@167.57.96.88] has joined #bitcoin-wizards | 12:43 | |
| kanzure | maybe: https://bitcointalk.org/index.php?topic=206303.0 https://bitcointalk.org/index.php?topic=277471.0 https://bitcointalk.org/index.php?topic=1100305.0 https://bitcointalk.org/index.php?topic=21995.0 | 12:43 |
| -!- digitalmagus [~digitalma@unaffiliated/digitalmagus] has quit [Ping timeout: 246 seconds] | 12:45 | |
| -!- chris13243 [~chris@68.27.186.20] has joined #bitcoin-wizards | 12:49 | |
| -!- Guest89 [~textual@c-73-15-187-144.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 12:51 | |
| -!- adam3us [~Adium@178.197.232.153] has joined #bitcoin-wizards | 12:56 | |
| -!- chris13243 [~chris@68.27.186.20] has quit [Ping timeout: 252 seconds] | 13:02 | |
| ghtdak | iset | 13:03 |
| -!- Hunger-- [hunger@proactivesec.com] has quit [Ping timeout: 264 seconds] | 13:08 | |
| -!- tromp__ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 13:09 | |
| -!- hazirafel [~ufoinc@31.154.91.221] has joined #bitcoin-wizards | 13:09 | |
| -!- tripleslash [~\\\@unaffiliated/imsaguy] has joined #bitcoin-wizards | 13:10 | |
| -!- gwollon [~gwillen@li450-236.members.linode.com] has joined #bitcoin-wizards | 13:12 | |
| -!- zxzzt_ [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-wizards | 13:12 | |
| -!- petertod1 [~pete@ec2-52-5-185-120.compute-1.amazonaws.com] has joined #bitcoin-wizards | 13:12 | |
| -!- otoburb_ [~otoburb@unaffiliated/otoburb] has joined #bitcoin-wizards | 13:12 | |
| -!- [\\\] [~\\\@unaffiliated/imsaguy] has quit [Ping timeout: 244 seconds] | 13:12 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 244 seconds] | 13:12 | |
| -!- Iriez [wario@distribution.xbins.org] has quit [Ping timeout: 244 seconds] | 13:12 | |
| -!- SDCDev [~quassel@unaffiliated/sdcdev] has quit [Read error: Connection reset by peer] | 13:12 | |
| -!- JayDugger1 [~jwdugger@108.19.186.58] has quit [Ping timeout: 244 seconds] | 13:12 | |
| -!- epscy [~epscy@176.126.241.239] has quit [Ping timeout: 244 seconds] | 13:12 | |
| -!- gwillen [~gwillen@unaffiliated/gwillen] has quit [Ping timeout: 244 seconds] | 13:12 | |
| -!- Meeh [~meeeeeeh@meeh.sigterm.no] has quit [Ping timeout: 244 seconds] | 13:12 | |
| -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 244 seconds] | 13:12 | |
| -!- helo [~helo@unaffiliated/helo] has quit [Ping timeout: 244 seconds] | 13:12 | |
| -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Ping timeout: 244 seconds] | 13:12 | |
| -!- petertodd [~pete@ec2-52-5-185-120.compute-1.amazonaws.com] has quit [Ping timeout: 244 seconds] | 13:12 | |
| -!- otoburb [~otoburb@unaffiliated/otoburb] has quit [Ping timeout: 244 seconds] | 13:12 | |
| -!- helo [~helo@69.60.98.175] has joined #bitcoin-wizards | 13:12 | |
| -!- helo [~helo@69.60.98.175] has quit [Changing host] | 13:12 | |
| -!- helo [~helo@unaffiliated/helo] has joined #bitcoin-wizards | 13:12 | |
| -!- Iriez [wario@distribution.xbins.org] has joined #bitcoin-wizards | 13:13 | |
| -!- JayDugger [~jwdugger@108.19.186.58] has joined #bitcoin-wizards | 13:13 | |
| -!- maraoz [~maraoz@c-73-15-187-144.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 13:13 | |
| -!- jcorgan [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has joined #bitcoin-wizards | 13:13 | |
| -!- jcorgan [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has quit [Changing host] | 13:13 | |
| -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-wizards | 13:13 | |
| -!- Meeh [~meeeeeeh@meeh.sigterm.no] has joined #bitcoin-wizards | 13:13 | |
| -!- SDCDev [~quassel@unaffiliated/sdcdev] has joined #bitcoin-wizards | 13:13 | |
| -!- epscy [~epscy@176.126.241.239] has joined #bitcoin-wizards | 13:13 | |
| -!- otoburb_ [~otoburb@unaffiliated/otoburb] has quit [Client Quit] | 13:14 | |
| -!- kang_ [67efe9d5@gateway/web/freenode/ip.103.239.233.213] has joined #bitcoin-wizards | 13:16 | |
| -!- zooko [~user@c-73-14-172-248.hsd1.co.comcast.net] has joined #bitcoin-wizards | 13:18 | |
| Taek | kanzure, all: has there been any discussion on what happens if we discover that bitcoin will not scale beyond a certain point | 13:24 |
| -!- chris13243 [~chris@70-7-83-124.pools.spcsdns.net] has joined #bitcoin-wizards | 13:24 | |
| Taek | even the lightning network is not going to scale to 7 billion humans on 1mb blocks | 13:24 |
| Taek | assuming that 1mb is indeed a hard limit, and that lightning is the best we can do off-chain, what happens? | 13:24 |
| kanzure | you can use multisig pools for receiving cheap utxos on the blockchain in that circumstance | 13:25 |
| -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards | 13:26 | |
| Taek | meaning multiple people sharing each utxo? Sounds trust-required | 13:27 |
| kanzure | i think you could make multisig "pools" more trustless | 13:27 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-bhaoenjwhxyghjgn] has quit [Ping timeout: 250 seconds] | 13:27 | |
| -!- adam3us [~Adium@178.197.232.153] has quit [Quit: Leaving.] | 13:28 | |
| kanzure | there might be a legitimate reason to think that the only transactions that should get committed are breach-remedy transactions, heh | 13:29 |
| -!- nullbyte [~NSA@198.203.28.43] has joined #bitcoin-wizards | 13:29 | |
| kanzure | anyway, if you really need to have extra data, you could always do the extension block idea, or auxiliary blocks plugged in via transactions that specify their existence or something, or sidechains that are either chains themselves with normal verification constraints or federated pools (which is almost very similar to "hrrr multisig pools") with signed blocks or signed ledgers.. | 13:30 |
| kanzure | multi-chain lightning network nodes let users respond to fee pressures to select other types of utxos they are okay with receiving http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010909.html | 13:31 |
| -!- adam3us [~Adium@178.197.236.137] has joined #bitcoin-wizards | 13:32 | |
| kanzure | (although you don't have to immediately exit into utxos anyway) | 13:33 |
| -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has joined #bitcoin-wizards | 13:34 | |
| TD-Linux | moxie looks pretty awesome. though it seems clearly targeted toward hw implementation vs a software one | 13:34 |
| gmaxwell | the software impl is perfectly reasonable though. | 13:35 |
| -!- adam3us [~Adium@178.197.236.137] has quit [Quit: Leaving.] | 13:36 | |
| kanzure | Taek: some people are not going to understand bitcoin, no matter how amazing our software is, and persuading them to use bitcoin anyway without understanding safety implications might be unethical. so it's possible that not everyone is going to use bitcoin... | 13:36 |
| phantomcircuit | Taek, lightning (aka hash locked bidirectional micro payment channels configured into a network) are almost certainly not the best that we can do | 13:37 |
| TD-Linux | for an interpreter, yes. but I imagine that bitcoin wouldn't want to integrate a JIT... | 13:37 |
| kanzure | Taek: also in general it causes lots of angry users when they were told about certain features that turn out to be oops not true | 13:37 |
| kanzure | phantomcircuit: go on | 13:37 |
| phantomcircuit | kanzure, you already mentioned the obvious, probabilistic payments | 13:37 |
| kanzure | Taek: for example, advertising bitcoin as anonymous is *dangerous* to user safety and is *actively harmful* | 13:37 |
| phantomcircuit | for something like starbucks that receives a few million payments per day a 100,000x probability is reasonable | 13:38 |
| kanzure | yes i have not completely internalized those proposals yet | 13:38 |
| kanzure | https://bitcointalk.org/index.php?topic=62558.0 | 13:38 |
| kanzure | http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-May/002564.html | 13:38 |
| gmaxwell | TD-Linux: yea no, fair enough. When I say the software is good I mean its a switch statement that almost fits on your screen. | 13:38 |
| gmaxwell | TD-Linux: not that its fast or easy to make fast, I agree. | 13:38 |
| phantomcircuit | more so though there is good reason to believe that the payment channels in a lightning like setup can be rebalanced, thus allowing for channels to remain open indefinitely | 13:39 |
| kanzure | right | 13:39 |
| kanzure | phantomcircuit: has anyone looked at whether probabilistic payments + lightning or other payment channels works? | 13:39 |
| phantomcircuit | there is the obvious question there about how you keep bitcoin mining secure in such a scenario though | 13:39 |
| -!- nullbyte [~NSA@198.203.28.43] has quit [Ping timeout: 272 seconds] | 13:39 | |
| phantomcircuit | kanzure, i've not seen any discussion about combining the two approaches no | 13:39 |
| kanzure | well, the lightning network nodes might be miners | 13:40 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-suntigubcdbwjacp] has joined #bitcoin-wizards | 13:41 | |
| phantomcircuit | kanzure, indeed they should be but unfortunately the current market indicates that those who should be miners dont seem to be | 13:41 |
| phantomcircuit | for example all of the exchanges should be mining even if only at 0.1-1% of the network levels | 13:42 |
| kanzure | is there a good link that i can use about this | 13:42 |
| phantomcircuit | (at 1% of the network you get to select the transactions in approximately 1 block every day) | 13:42 |
| -!- otoburb [~otoburb@unaffiliated/otoburb] has joined #bitcoin-wizards | 13:43 | |
| -!- adam3us [~Adium@178.197.236.52] has joined #bitcoin-wizards | 13:44 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 13:45 | |
| Taek | phantomcircuit: if starbucks is receiving payments at 100,000x, doesn't that mean that some people are going to get slammed with a $XXX,XXX bill for their coffee cup? | 13:45 |
| -!- adam3us [~Adium@178.197.236.52] has quit [Client Quit] | 13:46 | |
| kanzure | "I doubt many want to risk paying much more than 100 times more than they bargained for." | 13:46 |
| phantomcircuit | Taek, they pool their money before hand | 13:47 |
| Taek | "So, to make that work, there would need to be a way for Alice to put that 1 BTC on hold for Bob's benefit, albeit only temporarily. This way, Alice can't swipe the coin out from under Bob, but on the other hand, Bob doesn't get to keep control of the coin if he doesn't receive a winning share after a certain amount of time." -> also seems like a hard problem | 13:47 |
| phantomcircuit | it's like the lottery | 13:47 |
| phantomcircuit | actually the mechanism would probably be the same as with micropayment channels | 13:48 |
| phantomcircuit | so potentially it's made irrelevant by them | 13:48 |
| Taek | yeah I've always assumed that probabilistic payments were approx. inferior to payment channels | 13:48 |
| gmaxwell | they make a different tradeoff. | 13:49 |
| gmaxwell | I expect they could be combined too, but maybe not much reason to do that. | 13:49 |
| Taek | what is the benefit to using probabilistic payments? | 13:50 |
| gmaxwell | When people start talking about micropayments-- true micropayments, like sub usd cent in value-- probablistic payments are probably most interesting. | 13:50 |
| phantomcircuit | gmaxwell, you'd need to combine funds into a single multisig with a mechanism to recover funds if someone disappears | 13:50 |
| phantomcircuit | which i suspect basically ends up looking like a super cumbersome micropayment channel | 13:50 |
| gmaxwell | phantomcircuit: nah, I posted PP schemes that I think work and give all interesting properties, including doublespend detection. | 13:51 |
| gmaxwell | I even had you add opcodes to elements-alpha to make them implementable! | 13:51 |
| gmaxwell | (thats why I wanted verifying signature data on the stack) | 13:51 |
| -!- kang_ [67efe9d5@gateway/web/freenode/ip.103.239.233.213] has quit [Quit: Page closed] | 13:52 | |
| phantomcircuit | gmaxwell, yeah i know, but if you're doing very high odds you want to pool the risk with other users | 13:52 |
| phantomcircuit | 100x is probably the highest that a single person is going to want to go | 13:52 |
| gmaxwell | Because you can prevent PP doublespend by having a bonded coin that can be redeemed/destroyed on presentation of a proof of two signatures with another key. | 13:52 |
| phantomcircuit | 100x is obviously still very useful | 13:52 |
| gmaxwell | phantomcircuit: depends on the fee level. | 13:53 |
| phantomcircuit | well and i guess if it's sub cent payments it can be much higher | 13:53 |
| phantomcircuit | 1000x on a 0.001 payment would be fine | 13:53 |
| gmaxwell | right. In any case, it's speculative if really tiny payments make _social_ sense, but I think we have the technology to make them reasonably efficient. | 13:54 |
| Taek | if you make the majority of your daily purchases using PP, it would seem reasonable to have a pool set aside of several thousand dollars to draw from. | 13:54 |
| gmaxwell | bigger hurdle is that many people really dislike payments with variance, on both the sending and recieving side. | 13:55 |
| phantomcircuit | gmaxwell, btw even with dbcache=4 the bottleneck on this rpi2 seems to be merkle tree root calculations | 13:55 |
| phantomcircuit | fScriptChecks = false and cpu saturated | 13:55 |
| gmaxwell | phantomcircuit: so leveldb wastes a ton of cpu on lookups, dunno why. | 13:56 |
| gmaxwell | so that might also be a factor for you. | 13:56 |
| phantomcircuit | gmaxwell, oh right, it's because it's bisecting the table files | 13:56 |
| Taek | re: tradeoffs, with PP you could pay any address, but with payment channels you don't have that flexibility | 13:56 |
| phantomcircuit | the table files are sorted and lookups within them are done by bisecting the file | 13:56 |
| phantomcircuit | and it's walking the journal file for each lookup which is O(n) (but hopefully with a small n most of the time) | 13:57 |
| gmaxwell | taek: networked channels mostly makes that a non-issue. | 13:58 |
| gmaxwell | Taek: the parties just need channels up to _someone_ and you do path finding and make a series of pairwise trades. | 13:58 |
| phantomcircuit | indeed the current designs call for onion routed payments to be the default | 13:59 |
| gmaxwell | like the original ripple system, but trading an asset rather than a debt so payment is guarenteed. :) | 13:59 |
| phantomcircuit | it's expected that the cost per payment will be so low that 5x increase for strong privacy will be a no brainer | 13:59 |
| Taek | gmaxwell: true, but that comes with implementation overhead, and if each pairwise trade is charging some sort of fee, you deal with fee overhead as well | 13:59 |
| -!- CohibAA [~CohibAA@unaffiliated/cohibaa] has quit [Remote host closed the connection] | 13:59 | |
| kanzure | payment routing includes things like finding fee-optimal paths | 14:00 |
| -!- zooko [~user@c-73-14-172-248.hsd1.co.comcast.net] has quit [Ping timeout: 264 seconds] | 14:00 | |
| phantomcircuit | Taek, people keep brining this up and suggesting it will make the network centralized, but it's expected the the cost will be so low that it wont have any effect | 14:00 |
| gmaxwell | Taek: illogical thinking, or actually if you think through there is a highly unethical argument burried in there; let me explain. | 14:00 |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 14:00 | |
| phantomcircuit | for example i intend to setup a hub as soon as it's possible and charge nothing | 14:00 |
| phantomcircuit | (not with lots of funds available of course, but still) | 14:00 |
| kanzure | re: the importance of paying to addresses, i don't think addresses are useful. they will die eventually... | 14:01 |
| gmaxwell | Taek: Lets imagine a transaction directly hits the bitcoin network. Then every node in the world and all future ones through history are _forced_ to transfer and process it if they want to participate. The total cost is considerable, though much of it is an externality. | 14:01 |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 255 seconds] | 14:01 | |
| -!- Guest89 [~textual@c-73-15-187-144.hsd1.ca.comcast.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 14:02 | |
| gmaxwell | Taek: now for the channel case, the similar per node costs are involved, but only for a few nodes, the total cost is much lower, and participation is voluntary. | 14:02 |
| Taek | kanzure: I don't understand 'they will die eventually...' ? | 14:02 |
| CodeShark | the term "bitcoin address" is a somewhat unfortunate misnomer...the parallel with, say, email (which is already used and understood by many) just isn't really there | 14:02 |
| gmaxwell | Taek: also, --- least cost routing network, so almost perfect competition... and fees would often be negative, due to channel rebalancing. | 14:02 |
| kanzure | Taek: bitcoin addresses are really just one particular standard for contracts; there's no reason to keep using those. | 14:02 |
| -!- xabbix [~xabbix@unaffiliated/xabbix] has quit [Ping timeout: 240 seconds] | 14:03 | |
| -!- RoboTedd_ [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 14:03 | |
| gmaxwell | So the comparison about 'but won't participants in my payment want fees?' is saying "I don't want to pay the true price for processing my transaction in a highly efficient market, but I'd rather externalize a thousands of fold cost on other parties that have no real choice except to not run a bitcoin node at all" | 14:04 |
| -!- tromp [~tromp@rtc35-217.rentec.com] has joined #bitcoin-wizards | 14:04 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] | 14:04 | |
| gmaxwell | and keep in mind, there is no reason to assume the bitcoin transactions themselves will be free, the validation costs get externalized, but POW security costs are not. | 14:05 |
| -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 252 seconds] | 14:05 | |
| -!- kyuupichan [~Neil@ae051180.dynamic.ppp.asahi-net.or.jp] has quit [Ping timeout: 244 seconds] | 14:06 | |
| -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-wizards | 14:06 | |
| Taek | gmaxwell: from a purely utilitarian perspective, the cost of using networked channels is (setup + routing fees)*# of payments | 14:06 |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Read error: Connection reset by peer] | 14:06 | |
| Taek | in a PP setup, the cost is (txn fee)*(# of payments)*(probability of payment) | 14:06 |
| -!- chris13243 [~chris@70-7-83-124.pools.spcsdns.net] has quit [Ping timeout: 264 seconds] | 14:07 | |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards | 14:07 | |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Client Quit] | 14:07 | |
| -!- zooko [~user@73.14.172.248] has joined #bitcoin-wizards | 14:07 | |
| CodeShark | the cost of routing transactions for a relatively tiny percentage of all transactions taking place is also relatively tiny compared to the cost of focing everyone in the world to have to validate each transaction | 14:07 |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards | 14:07 | |
| Taek | wrt the ethical problem, I'm not really sure how to answer that. I usually assume (perhaps incorreclty) that at some point the blockchain will be constantly 100% full | 14:07 |
| gmaxwell | Taek: no, setup + routing*payments. | 14:07 |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds] | 14:07 | |
| Taek | oh right | 14:07 |
| -!- erasmospunk [~erasmospu@179.43.156.162] has quit [Ping timeout: 244 seconds] | 14:08 | |
| -!- Logicwax [~Logicwax@c-76-126-174-152.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds] | 14:08 | |
| -!- tromp_ [~tromp@rtc35-217.rentec.com] has quit [Ping timeout: 250 seconds] | 14:08 | |
| phantomcircuit | Taek, i keep saying "is expected to be" but really the cost of payment routing will be virtually zero | 14:08 |
| gmaxwell | but setup can be disregarded, assuming its widely used, everyone will have channels setup already. And PP assumes a linear utility for money, ... you want your paycheck via a PP? :P | 14:08 |
| CodeShark | we already pay for routing via ISPs | 14:09 |
| CodeShark | imagine if someone were insisting the Internet should be a flood network instead :p | 14:09 |
| kanzure | comparisons to internet architecture are not useful; internet is terrible architecture. | 14:09 |
| Taek | CodeShark: I don't think that's a valid comparison. You can't exactly do 'probabilistic packets' | 14:09 |
| kanzure | (i'm just upset about someone using an argument about "peering agreements" on me.. bleh.) | 14:10 |
| CodeShark | the point isn't to tout the merits of current Internet architecture, kanzure - but to point out how much worse it could be | 14:10 |
| -!- jeremyrubin [~jeremyrub@biohazard-cafe.mit.edu] has quit [Ping timeout: 268 seconds] | 14:10 | |
| -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 14:10 | |
| -!- erasmospunk [~erasmospu@mi-18-24-58.service.infuturo.it] has joined #bitcoin-wizards | 14:11 | |
| CodeShark | as much as I dislike the centralized nature of ISPs and resource allocation, I'd rather pay my ISP than have to wade through every single message everyone everywhere on the Internet broadcasts | 14:12 |
| Taek | you'd still have to get the messages from an ISP? | 14:13 |
| CodeShark | no, you could just use shortwave radio or something :p | 14:13 |
| fluffypony | CodeShark: someone told me on Reddit a few days ago that in "5-7 years everything will be decentralised" | 14:13 |
| fluffypony | all I could think about is message-passing everyone's stupid media downloads | 14:13 |
| CodeShark | well, decentralization doesn't have to mean flood networks | 14:14 |
| gmaxwell | nice timing re ISPs comment and #bitcoin | 14:14 |
| CodeShark | I'm thinking more of an ad-hoc mesh network where routing services can be provided by anyone | 14:15 |
| -!- erasmospunk [~erasmospu@mi-18-24-58.service.infuturo.it] has quit [Ping timeout: 246 seconds] | 14:15 | |
| -!- adam3us [~Adium@62-2-191-242.static.cablecom.ch] has joined #bitcoin-wizards | 14:16 | |
| CodeShark | you could still do stupid media downloads...but it won't be free (although it might very well be cheaper than current ISPs) | 14:16 |
| Taek | I have a hard time thinking about fair-cost models for a payment routing network, but it does seem to me like 'free' routing would be dangerous for the router | 14:17 |
| -!- xabbix [~xabbix@unaffiliated/xabbix] has joined #bitcoin-wizards | 14:17 | |
| gmaxwell | CodeShark: usually transfer stunts like that very much do not work. Last mile bandwidth is enomrously more expensive (in physical terms) than datacenter bandwidth. | 14:17 |
| Taek | if there's a lot of traffic going a particular direction on the network, you could have all of your channels drained in that direction | 14:17 |
| Taek | and then you need to somehow find a way to rebalance | 14:17 |
| gmaxwell | Taek: no need for 'the router' | 14:17 |
| gmaxwell | Taek: you rebalance by offering negative fees to move in the other direction. | 14:17 |
| Taek | right, but you can only afford negative fees if you were charging positive fees in the first place | 14:18 |
| gmaxwell | (or zero fees if you're not that desperate) | 14:18 |
| gmaxwell | Taek: what no! | 14:18 |
| Taek | ok what did I miss? | 14:18 |
| -!- chris13243 [~chris@107.25.80.127] has joined #bitcoin-wizards | 14:19 | |
| kanzure | your negative fees can be subsidized upstream | 14:19 |
| gmaxwell | Taek: there is a channel from me to you, and I've paid you all the coins in it, so all the coins are on your side now. Later someone wants to route through me to reach codeshark, they could come via andytoshi to me, but I'd rather move some of the taek-gmaxwell channel back to me, so I offer negative fees that way, even though I never connected any fees before. | 14:19 |
| gmaxwell | (and it's totally reasonable for me to do this, since rebalancing the channel saves me fees in the future-- e.g. the fees I'd have closing and establising a new channel) | 14:20 |
| gmaxwell | s/connected/collected/ | 14:20 |
| Taek | I still having trouble visualizing a whole network doing this, but I think that only makes sense in a limited scope. | 14:22 |
| -!- erasmospunk [~erasmospu@81.17.20.66] has joined #bitcoin-wizards | 14:22 | |
| -!- zooko [~user@73.14.172.248] has quit [Ping timeout: 272 seconds] | 14:22 | |
| Taek | Let's we have a network where everyone is connected to K and nobody else | 14:22 |
| Taek | and for whatever reason, today a bunch of payments are going to G, so K's channel to G gets drained | 14:23 |
| -!- Emcy [~MC@unaffiliated/mc1984] has quit [Ping timeout: 260 seconds] | 14:23 | |
| Taek | K knows that in the future he's going to need to make more payments to G, so now he needs to re-fill that channel | 14:24 |
| Taek | unless there are more random processes that help reset it, the channel is stuck without some form of encouragement | 14:25 |
| gmaxwell | Yes, indeed, though thats an uninteresting and degenerate topology. | 14:25 |
| Taek | hmm. | 14:25 |
| Taek | perhaps so. Was just trying to create something easier to reason about | 14:25 |
| kanzure | the point is that negative fees are a form of fee competition so that your negative fees are selected over competing alternatives | 14:25 |
| gmaxwell | what you said so far is true, but it's a problem with the topology. If you imagine several stars, e.g. K1,K2,K3 and each user is connected to two of them.. then you can start seeing how things work. | 14:26 |
| gmaxwell | (though even stars are kind of degenerate at all, but that topo is enough to see all the behaviors I'm talking about) | 14:27 |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 14:27 | |
| Taek | do you mind explaining further? | 14:27 |
| CodeShark | you're basically rewarding people for replenishing your channel | 14:27 |
| CodeShark | so you don't have to renegotiate one | 14:27 |
| gmaxwell | now when K1->G ends up all on G's side, zero or negative fees going the order way creates a reason for someone on K3 paying someone on K1 to use the K3->G->K1->X route. | 14:28 |
| CodeShark | you offer a route that, while not necessarily the most efficient, helps replenish your channel | 14:28 |
| CodeShark | and rewarding people for using it | 14:28 |
| Taek | CodeShark: I understand that, but the only reason your channel is depleted in the first place is that *other people* were using it. | 14:28 |
| Taek | *presumably for free | 14:28 |
| CodeShark | ? | 14:29 |
| CodeShark | why would you presume that? | 14:29 |
| gmaxwell | Taek: no-- your software would charge fees for transactions that moved channels in ways they don't like, and pay fees for transactions that move channels in ways they like. | 14:29 |
| -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has quit [Quit: Leaving...] | 14:29 | |
| Taek | gmaxwell: oh. Somehow I thought we were assuming that fees were going to be 0 to move money around. | 14:30 |
| kanzure | fees can be zero for as long as you have a positive balance on the channel | 14:30 |
| -!- chris13243 [~chris@107.25.80.127] has quit [Ping timeout: 244 seconds] | 14:30 | |
| gmaxwell | Taek: for any given transaction they may be-- if you can find a route whos rebalance you can help. | 14:30 |
| Taek | gmaxwell: certainly, though I would expect on-average you'd wind up paying relatively small fees, and in proportion to the volume of money | 14:31 |
| gmaxwell | Basically you can imagine it like this, there is a cost to reset channels. channel fees should amortize that cost fairly across all the users that exploit the channel. | 14:31 |
| Taek | yeah that makes sense | 14:32 |
| gmaxwell | thats why you have to think of a more complex topology than a hub/spoke or you can't see those effects and there is little to no shared amoritization. | 14:32 |
| CodeShark | ad-hoc mesh networks :) | 14:33 |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 14:33 | |
| CodeShark | a "hub" is just a regular node that offers routing services | 14:34 |
| -!- Guest89 [~textual@c-73-15-187-144.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 14:34 | |
| gmaxwell | because you'd like to minimize your costs every participant should be a 'hub'. | 14:34 |
| gmaxwell | otherwise you have no oppturnity to get other people to rebalance your channels. | 14:35 |
| kanzure | also every lightning network node should randomly start up new channels with very small balances with random other nodes, and then increase the channel balance over time once the node has proven trustworthy | 14:36 |
| kanzure | because random network growth has many privacy advantages and other effects | 14:36 |
| CodeShark | yes, resistant to partitioning | 14:36 |
| CodeShark | as well | 14:36 |
| Taek | being a hub means greater setup costs, and if the average participant has more connections it means the overall network is more expensive (in terms of block space) | 14:37 |
| -!- Guest89 [~textual@c-73-15-187-144.hsd1.ca.comcast.net] has quit [Client Quit] | 14:37 | |
| CodeShark | we want to avoid having, say, two huge cliques linked only by a single link :) | 14:37 |
| -!- zooko [~user@c-73-14-172-248.hsd1.co.comcast.net] has joined #bitcoin-wizards | 14:37 | |
| Taek | of course, that makes that link very powerful | 14:37 |
| kanzure | Taek: hubness setup costs are what? | 14:37 |
| Taek | you have to put a transaction on the blockchain for every link you establish | 14:38 |
| gmaxwell | Taek: it doesn't mean greater setup costs. | 14:39 |
| gmaxwell | consider, _eventually_ your channel will deplete. And you must setup again. Now if you do _no_ rebalancing, two channels will take twice as long to deplete as one (assuming equal value and uniform usage). | 14:40 |
| Taek | I wish I understood without needing it to be spoon-fed to me lol | 14:40 |
| gmaxwell | But having two up at one means you can prolong your channels by rebalancing. | 14:40 |
| CodeShark | the cost of the anchor transaction can be negotiated between the two parties | 14:40 |
| CodeShark | and might have something to do with risk metrics | 14:40 |
| gmaxwell | and indeed, someone else can pay that setup cost if doing so helps their rebalancing. | 14:40 |
| Taek | gmaxwell: I see. You'd want to optimize for the total number of channels that get created over time, which includes channels that need to be refreshed. | 14:41 |
| gmaxwell | Yup. | 14:41 |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] | 14:41 | |
| gmaxwell | and rebalancing can have a huge effect, increasing the lifetime manyfold. | 14:42 |
| -!- instagibbs_ [6c1fd228@gateway/web/freenode/ip.108.31.210.40] has joined #bitcoin-wizards | 14:42 | |
| -!- jeremyrubin [~jeremyrub@biohazard-cafe.mit.edu] has joined #bitcoin-wizards | 14:42 | |
| -!- RoboTedd_ [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Remote host closed the connection] | 14:43 | |
| -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] | 14:43 | |
| Taek | Ok. I'm now trying to reason about the fundamental limitations of such a system. Let's assume that there exists some magic configuration which guarantees perfect rebalancing at 3 connections per participant | 14:44 |
| Luke-Jr | gmaxwell: why would my channel deplete? O.o | 14:44 |
| Luke-Jr | as long as I'm paid more than I spend, I wouldn't expect that. | 14:44 |
| Taek | The network grow linearly over time limited by the blockchain size | 14:45 |
| Taek | You'd still need to refresh channels any time that someone had a change in their total network | 14:45 |
| Taek | *networth | 14:45 |
| gmaxwell | Luke-Jr: 'deplete' means unbalance. | 14:45 |
| Luke-Jr | ok | 14:45 |
| instagibbs_ | Taek: or open another channel, no? | 14:45 |
| CodeShark | wouldn't it be possible for multiple parties to negotiate opening up a clique with a single anchor transaction? | 14:46 |
| * Luke-Jr will need to go over Rusty's latest stuff to learn the new terms :p | 14:46 | |
| gmaxwell | Luke-Jr: Channels obey conservation of coins. A 10 BTC channel always has 10 BTC into it, but it's 'depleted' when the 10 BTC is all owned by one side or the other. | 14:46 |
| gmaxwell | well I dunno if rusty used depleted, thats how I think of it. :P | 14:46 |
| Taek | instagibbs_: yeah, same idea. You need another transaction to represent that your gains/losses have reached the limits of your channels | 14:46 |
| instagibbs_ | This is all really fascinating. | 14:46 |
| -!- erasmospunk [~erasmospu@81.17.20.66] has quit [Ping timeout: 265 seconds] | 14:47 | |
| Taek | So then when there is networth fluidity on the network, it prevents new people from joining | 14:47 |
| instagibbs_ | But another channel seems superior most times, since again, your open channels are + value | 14:47 |
| Taek | also interesting to think that the human population grows exponentially (or device population, if devices start doing their own blockchain things_ | 14:47 |
| gmaxwell | allow me to introduce you to the friendly but stern logistic function. | 14:49 |
| gmaxwell | Human population doesn't grow exponentially. :P | 14:49 |
| Taek | instagibbs_: Yeah seems like there's no reason to completely close a channel ever. | 14:49 |
| gmaxwell | at least not the population on earth! | 14:50 |
| -!- erasmospunk [~erasmospu@81.17.20.66] has joined #bitcoin-wizards | 14:50 | |
| instagibbs_ | Taek: well under attack scenario you need to close out more. more $$$ to settle | 14:50 |
| instagibbs_ | other than that it's hard to imagine | 14:50 |
| -!- Logicwax [~Logicwax@c-76-126-174-152.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 14:50 | |
| Taek | gmaxwell: historically it grew exponentially no? You are just pointing out that there is a physical limit to the # of humans that fit on the planet? | 14:51 |
| gmaxwell | Right. | 14:51 |
| gmaxwell | (and we're actually within spitting distance of current best esimates of it! at least in exponential growth terms) | 14:51 |
| CodeShark | we could easily stick the entire world's population into the grand canyon...but most would probably starve pretty quickly | 14:52 |
| gmaxwell | yes, this was assuming people staying alive. :P | 14:52 |
| gmaxwell | not turning them into some kind of bizarre meat-moon. | 14:52 |
| -!- chris13243 [~chris@70-7-16-143.pools.spcsdns.net] has joined #bitcoin-wizards | 14:53 | |
| -!- chris13243 [~chris@70-7-16-143.pools.spcsdns.net] has quit [Read error: Connection reset by peer] | 14:53 | |
| -!- Guest89 [~textual@c-73-15-187-144.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 14:53 | |
| Taek | interesting | 14:55 |
| zooko | ☺ | 14:55 |
| Taek | Assuming that the human population stops at 10 billion, and that the average lifespan is 100 years | 14:55 |
| Taek | and that there's approx. no net flow of networth | 14:55 |
| Taek | and that each human needs exactly 2 channels to keep their channels alive indefinitely | 14:56 |
| Taek | you end up at 6 tps | 14:56 |
| instagibbs_ | That's the kind of napkin math we need. | 14:56 |
| instagibbs_ | ;) | 14:56 |
| -!- RoboTeddy [~roboteddy@c-67-188-40-9.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 14:56 | |
| Taek | That's why I'm here :) | 14:56 |
| gmaxwell | you're going to need more dimensions to make that cow any more spherical. | 14:56 |
| gmaxwell | But yea, it's impressive the gains you can get. | 14:57 |
| -!- hazirafel [~ufoinc@31.154.91.221] has quit [Ping timeout: 246 seconds] | 14:58 | |
| gmaxwell | I can get you something like 11 tps in 1mb with a soft fork, incidentally. just by changing to BLS signatures. (not saying that 1mb is a reasonable limit in such a world... but it's amusing) | 14:59 |
| kanzure | meat-moon isn't as difficult as it may sound | 14:59 |
| kanzure | http://www.islandone.org/MMSG/aasm/ | 14:59 |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 15:00 | |
| -!- frankenmint [~frankenmi@71-222-57-192.ptld.qwest.net] has quit [Remote host closed the connection] | 15:00 | |
| -!- erasmospunk [~erasmospu@81.17.20.66] has quit [Ping timeout: 246 seconds] | 15:00 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-9.hsd1.ca.comcast.net] has quit [] | 15:01 | |
| kanzure | also you can just compress people down and run them on clouds anyway | 15:02 |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 15:02 | |
| fluffypony | I like that idea | 15:02 |
| kanzure | for that one there's http://diyhpl.us/~bryan/papers2/brain-emulation-roadmap-report.pdf | 15:03 |
| kanzure | strangely, those two documents share some authors despite being written 30 years apart | 15:05 |
| -!- erasmospunk [~erasmospu@81.17.20.66] has joined #bitcoin-wizards | 15:05 | |
| kanzure | "the other stuff that ralph merkle is up to" | 15:06 |
| phantomcircuit | gmaxwell, i've had people argue that my assertion that IBD scales O(n^2) with O(n) block increase is false because there is a limit to the size of block you can construct due to merkle tree construction being O(n log n) | 15:06 |
| phantomcircuit | which is just comical as fuck | 15:06 |
| phantomcircuit | something something cubic blocks | 15:07 |
| -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Quit: Ex-Chat] | 15:07 | |
| kanzure | er, then what is merkle tree construction actually limited towards? | 15:08 |
| gmaxwell | phantomcircuit: you can show them pieter's code, it happily builds trees that are 2^26 in size and such. of course the tree doesn't get any wider if your transactions just get fat instead of numerous. | 15:09 |
| gmaxwell | kanzure: in pieter's new code the MT construction uses log2(entries) memory and takes time roughly equal to sha2d-ing the data twice. | 15:10 |
| kanzure | cool | 15:10 |
| gmaxwell | so you could build a tree over all the atoms in the universe with a ordinary desktop, no problem, if were patient enough to hash the universe twice. | 15:10 |
| phantomcircuit | kanzure, it is actually O(n log n) but i've written code that does 300k append operations per second in O(log n) space so realistically the O(n log n) limit is like | 15:10 |
| phantomcircuit | huge | 15:10 |
| kanzure | for the record i am not patient enough to hash the universe twice | 15:11 |
| gmaxwell | phantomcircuit: it's not n log n. it's n*2. | 15:11 |
| gmaxwell | efficient MT contruction is linear time. | 15:11 |
| phantomcircuit | gmaxwell, each append is O(log n) but for the current n value, oopsies | 15:12 |
| kanzure | i wonder if we should have someone do a "here's some common scaling laws and graphs of common curves to consider when we complain about scaling" | 15:12 |
| kanzure | "this part of the graph is where all lobsters on the planet can have 2 transactions per millenia" | 15:13 |
| kanzure | er, *do a presentation about | 15:13 |
| -!- eudoxia [~eudoxia@167.57.96.88] has quit [Quit: Leaving] | 15:13 | |
| -!- chris13243 [~chris@70.7.149.11] has joined #bitcoin-wizards | 15:14 | |
| gmaxwell | phantomcircuit: not so. You defer work and ripple up. | 15:14 |
| phantomcircuit | hmm yeah | 15:14 |
| phantomcircuit | it's log n worst case | 15:14 |
| phantomcircuit | O(1) best case | 15:14 |
| phantomcircuit | yeah you're right | 15:14 |
| gmaxwell | it's really just N*2 hashes total for efficient software I promise. | 15:15 |
| phantomcircuit | yeah i can see why now | 15:15 |
| -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has quit [Remote host closed the connection] | 15:16 | |
| -!- erasmospunk [~erasmospu@81.17.20.66] has quit [Ping timeout: 264 seconds] | 15:18 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Remote host closed the connection] | 15:19 | |
| -!- instagibbs_ [6c1fd228@gateway/web/freenode/ip.108.31.210.40] has quit [Quit: Page closed] | 15:28 | |
| -!- zooko [~user@c-73-14-172-248.hsd1.co.comcast.net] has quit [Ping timeout: 246 seconds] | 15:29 | |
| -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has quit [Read error: Connection reset by peer] | 15:31 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 15:46 | |
| gmaxwell | Hey, maybe a bit of fun mindless work-- Pieter recently posted sage code that does mechnical verification of the group law in libsecp256k1, https://github.com/sipa/secp256k1/commit/914bef100c15139c53a42486a6cdf56f48e534d9 but what it doesn't do is verify that what the library actually implements (in https://github.com/bitcoin/secp256k1/blob/master/src/group_impl.h ) are actually the same. So I' | 15:54 |
| -!- chris13243 [~chris@70.7.149.11] has quit [Read error: Connection reset by peer] | 15:54 | |
| gmaxwell | m offering a 5 BTC bounty for the first discovered substantive (e.g. invalidates the integrity of the proof) difference due to a transcription error between the implementations of secp256k1_gej_* and their sage replicas. | 15:54 |
| -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards | 15:54 | |
| -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving] | 16:06 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards | 16:06 | |
| -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-wizards | 16:06 | |
| -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has quit [Ping timeout: 256 seconds] | 16:10 | |
| gmaxwell | (also knowing you tried and failed would earn you my debt, if anyone does so you can register your failure by ACKing https://github.com/bitcoin/secp256k1/pull/302 ) | 16:11 |
| -!- kyuupichan [~Neil@ae051180.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-wizards | 16:12 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 244 seconds] | 16:13 | |
| -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 244 seconds] | 16:21 | |
| -!- MrHodl [~fuc@185.22.183.196] has joined #bitcoin-wizards | 16:24 | |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] | 16:24 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 16:28 | |
| -!- MrHodl [~fuc@185.22.183.196] has quit [Ping timeout: 250 seconds] | 16:28 | |
| -!- tucenaber [~tucenaber@o144.231.lokis.net.pl] has joined #bitcoin-wizards | 16:32 | |
| -!- tucenaber [~tucenaber@o144.231.lokis.net.pl] has quit [Changing host] | 16:32 | |
| -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has joined #bitcoin-wizards | 16:32 | |
| -!- chris13243 [~chris@72-57-94-244.pools.spcsdns.net] has joined #bitcoin-wizards | 16:34 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] | 16:37 | |
| -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards | 16:39 | |
| -!- snthsnth [~snthsnth@98.207.208.241] has joined #bitcoin-wizards | 16:40 | |
| -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has quit [Ping timeout: 244 seconds] | 16:45 | |
| -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has joined #bitcoin-wizards | 16:48 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer] | 16:48 | |
| -!- GAit [~GAit@2.230.161.158] has joined #bitcoin-wizards | 16:49 | |
| -!- Guest89 [~textual@c-73-15-187-144.hsd1.ca.comcast.net] has quit [Quit: Textual IRC Client: www.textualapp.com] | 16:54 | |
| -!- GAit [~GAit@2.230.161.158] has quit [Quit: Leaving.] | 17:02 | |
| -!- dhaK [dhaK@2a02:1610:1:1003:20c:29ff:fe3e:4633] has joined #bitcoin-wizards | 17:02 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-suntigubcdbwjacp] has quit [Ping timeout: 264 seconds] | 17:03 | |
| -!- sausage_factory [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 17:04 | |
| -!- blackwraith [~priidu@unaffiliated/priidu] has quit [Ping timeout: 240 seconds] | 17:05 | |
| kanzure | "While error detecting codes, such as CRCs, are better than cryptographic techniques, neither provide adequate coverage for active electronics in safety-critical systems. This is illustrated by the Schrödinger CRC scenario where a CRC-protected message with a single Byzantine faulty bit presents different data to different observers and each observer sees a valid CRC.[3][4]" ouch | 17:06 |
| gmaxwell | I think I saw a presentation with a Schrödinger CRC. | 17:08 |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 17:09 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Client Quit] | 17:09 | |
| kanzure | the nasa system fault tolerance stuff slide deck? | 17:10 |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] | 17:11 | |
| -!- chris13243 [~chris@72-57-94-244.pools.spcsdns.net] has quit [Ping timeout: 250 seconds] | 17:11 | |
| midnightmagic | I've had a storage bitflip on an ECC-ram machine | 17:12 |
| gmaxwell | I don't agree with the WP article, FWIW. | 17:12 |
| gmaxwell | I've seen some really awesome errors with CRC protected systems that wouldn't be possible with a digital signature. Though obviously performance usually avoids it. | 17:13 |
| gmaxwell | An example was a part that was transparently replacing the CRC on messages that came in, without verifying the inbound CRC. | 17:13 |
| gmaxwell | So it always turned detectable corruption into undetectable corruption. And the fact that it could calculate a CRC at all was totally undocumented, just some side effect of hardwired seralizer logic. | 17:14 |
| gmaxwell | had the system been using a MAC the design just wouldn't have worked. | 17:14 |
| midnightmagic | Michael Wolfe, the guy who's one of the primary designers of the portland group compiler suite, insisted to me personally and in front of a classroom of about 80 people that the reason they didn't bother supporting ATI hardware even by 2013-ish was because ATI hardware at the time didn't have ecc ram onboard and so it would deliver unreliable results. (some models actually did have ecc by th | 17:24 |
| midnightmagic | en.) This was directly refuted as a valid reason by at least 15 other academics I spoke with including team leads and head scientists, and during about half of all the paper presentations at the conference, who all uniformly said all their algorithms and software are designed with highly unreliable computing elements *specifically in mind.* I've always wondered what it would mean to rebuild | 17:24 |
| midnightmagic | consumer-level software like bitcoin with local reliable computing, and whether this could help us more-accurately detect faulty hardware (beyond just voting schemes, but actual self-testing autonomous, isolated agents running within an internally redundant machine.) | 17:24 |
| gmaxwell | sounds great, just give me 4x overhead to play with. :P | 17:25 |
| midnightmagic | :-) I've got a machine here you can monkey around on if you want. | 17:26 |
| jgarzik | with Scaling Bitcoin being a concentration of devs, I wonder if it would be a good idea to adopt DEFCON best practices and bring a burner laptop and burner phone, leaving the primaries at home | 17:26 |
| gmaxwell | We do internally redundant computation for some things in bitcoin core. :) | 17:26 |
| gmaxwell | jgarzik: Luke-Jr did this for bitcoin2013 and I believe I heard someone mentioning doing it for scaling bitcoin. | 17:26 |
| Taek | jgarzik: I had a dream last night where all 5 people with commit access were murdered | 17:27 |
| gmaxwell | perhaps I'll do that as well. I have a whole stack of burner laptops. :) | 17:27 |
| gmaxwell | hm but they don't have batteries. | 17:27 |
| midnightmagic | I have burner desktops! And car batteries! | 17:27 |
| gmaxwell | plus if someone tries to attack you, you can throw battery acid at them. What could go wrong? | 17:28 |
| gmaxwell | you can get old x61 laptops for almost free, though usually not with working batteries. | 17:29 |
| midnightmagic | rolled a 1, critical fumble, arggghhh | 17:30 |
| jgarzik | rofl I have way too many burner desktops | 17:31 |
| kanzure | i would be far far more interested in capturing whatever malware people try to release | 17:32 |
| phantomcircuit | midnightmagic, iirc lots of people have realized that their automated bug reporting stuff should include a hardware testing suite | 17:34 |
| phantomcircuit | apparently reduces the volume of bug reports significantly | 17:34 |
| phantomcircuit | it would be nice if there was a kernel level memory tester that ran in the background slowly | 17:34 |
| * phantomcircuit looks around for rusty | 17:34 | |
| kanzure | you can make jgarzik do it | 17:35 |
| midnightmagic | "Installation of Bitcoin requires a kernel module to be loaded at boot-time.." | 17:35 |
| Luke-Jr | gmaxwell: I did? O.o | 17:41 |
| kanzure | gmaxwell: re: that wikipedia article about byzantine generals' problems, | 17:41 |
| kanzure | seems that iang wrote up some reasonable criticism here http://financialcryptography.com/mt/archives/001522.html | 17:41 |
| kanzure | not sure if that was the origin of "dynamic membership set" stuff | 17:41 |
| gmaxwell | Luke-Jr: I thought you did! | 17:42 |
| Luke-Jr | gmaxwell: I just never trust mobile stuff period. | 17:43 |
| gmaxwell | kanzure: no, other way around. | 17:43 |
| Luke-Jr | my laptop is essentially no more than a SSH+VNC thinclient | 17:43 |
| gmaxwell | Luke-Jr: I thought you had a seperate new netbook. | 17:43 |
| Luke-Jr | oh, that exists. but I almost never use it. | 17:44 |
| kanzure | ok | 17:44 |
| Luke-Jr | I guess maybe my usage patterns makes them somewhat effectively "burner", but I've never really considered them that way because I have nothing more permanent in that form factor | 17:45 |
| Luke-Jr | although the last year, I've found VNC is a pain due to my DSL upload :/ | 17:45 |
| kanzure | we should plant someone with really obvious malware and then have a game to find the plant | 17:45 |
| -!- kmels [~kmels@186.64.110.122] has quit [Ping timeout: 246 seconds] | 17:46 | |
| kanzure | (no we shouldn't) | 17:46 |
| -!- chris13243 [~chris@70-0-141-35.pools.spcsdns.net] has joined #bitcoin-wizards | 17:46 | |
| gmaxwell | Andytoshi recently believed his laptop was stolen and it had been left suspended, unlocked with all his credentials available. Don't let this happen to you. | 17:47 |
| phantomcircuit | gmaxwell, i brought a burner laptop/cellphone to defcon | 17:48 |
| phantomcircuit | didn't have a burner sim though | 17:49 |
| phantomcircuit | possibly there's malware on it | 17:49 |
| gmaxwell | I am continually frustrated that no machine learning software flaw detector exists. | 17:51 |
| ryan-c | I reuse my burner sim between DEFCONs | 17:52 |
| ryan-c | (and i have a burner phone) | 17:53 |
| ryan-c | I'm pretty sure malware on SIM is possible. | 17:56 |
| phantomcircuit | ryan-c, it definitely is but iirc you need to have the keys for the sim to load anything onto them | 17:58 |
| ryan-c | kanzure: A few years ago some guys were spamming the CTF network with wireshark dissector 0-days - that was fun, especially once people started replaying them. | 17:58 |
| phantomcircuit | but being defcon probably someone there has stolen those | 17:58 |
| ryan-c | tbh, if i were the sort of person to drop 0days at a conference i'd go for blackhat or better yet rsa | 18:00 |
| phantomcircuit | ryan-c, blackhat you might actually get in trouble for it | 18:00 |
| ryan-c | phantomcircuit: yes, true | 18:00 |
| phantomcircuit | rsa they'd call the fbi | 18:00 |
| phantomcircuit | ... over from the other table | 18:00 |
| ryan-c | also true | 18:01 |
| ryan-c | depends on goals | 18:01 |
| ryan-c | goals at defcon are much more likely to be merely trolling | 18:01 |
| -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 246 seconds] | 18:02 | |
| ryan-c | but yeah, at defcon someone exploiting phones even if caught probably would at worst have their toys and badge taken away by goons | 18:02 |
| ryan-c | exploiting people on the wifi would probably be considered "amusing" (donno if anyone was there for it, but this was pretty funny https://web.archive.org/web/20130116161913/http://www.evilscheme.org/defcon) | 18:03 |
| ryan-c | Luke-Jr: I become a fan of "laptop is a thin client and browser" model. | 18:05 |
| ryan-c | do you use mosh? | 18:06 |
| gmaxwell | mosh <3 | 18:06 |
| gmaxwell | if you do not use mosh, stop what you are doing and install. | 18:06 |
| ryan-c | haha | 18:07 |
| ryan-c | so true | 18:07 |
| Luke-Jr | I think I installed mosh, but never use it | 18:07 |
| bsm117532 | +1 on mosh | 18:07 |
| gmaxwell | ryan-c: well I used a special protocol called airhook for many years, which got many of the advantages of mosh. But it was finniky and I couldn't suggest it easily to other people. | 18:07 |
| ryan-c | before mosh, i did hacky shit with airhook http://airhook.ofb.net/ | 18:07 |
| Luke-Jr | roaming sounds like a bad feature in this case :P | 18:07 |
| ryan-c | hahah | 18:07 |
| gmaxwell | 0_o | 18:07 |
| gmaxwell | ryan-c: if you ever still use it, it has a realloc misuse bug I've been carrying patches for years for.. :) | 18:08 |
| kanzure | telepaths are the worst | 18:08 |
| -!- maraoz [~maraoz@c-73-15-187-144.hsd1.ca.comcast.net] has quit [Quit: Leaving] | 18:08 | |
| ryan-c | gmaxwell: I do not still use it. Is that why it very occasionally corrupted ssh packets? | 18:08 |
| gmaxwell | ryan-c: yes, likely! | 18:08 |
| ryan-c | iirc that would cause my ssh sessions to die once every couple of weeks | 18:09 |
| Luke-Jr | my SSH connections die fairly often over T-Mobile :/ | 18:09 |
| ryan-c | oh, google authenticator for pam is pretty great too | 18:09 |
| ryan-c | Luke-Jr: mosh will fix that for you | 18:09 |
| gmaxwell | lots of cell networks corrupt ssh and ssh doesn't tolerate.. mosh does. | 18:09 |
| gmaxwell | and mosh is usable across a 1 second ping with 30% packet loss. | 18:10 |
| gmaxwell | (so was airhook) | 18:10 |
| kanzure | what about temporary sim card resellers in the area? | 18:10 |
| ryan-c | i use mosh on tmobile during my bart commute pretty much every day | 18:10 |
| Luke-Jr | kanzure: let me know if you find any | 18:10 |
| kanzure | uh thanks | 18:10 |
| Luke-Jr | :P | 18:10 |
| kanzure | oh. | 18:10 |
| ryan-c | mosh (and airhook) also handle "network went away for several days" | 18:10 |
| Luke-Jr | I prefer if my SSH connection dies if I might have disappeared.. | 18:11 |
| ryan-c | and "ip address of client changed" | 18:11 |
| gmaxwell | ryan-c: so talking with friends, we were thinking that my phone was somehow amazingly better because I said it worked fine the whole caltrain trip from SF to southbay. | 18:11 |
| gmaxwell | ryan-c: and then later I realized it's because I'm using mosh and terminal apps and they're trying to use webapps. | 18:11 |
| ryan-c | gmaxwell: lol | 18:12 |
| gmaxwell | And yes, webapps just do not work with 1 second ping times and 30% packet loss. :) | 18:12 |
| kanzure | what does mosh really have over ssh + tmux | 18:12 |
| Luke-Jr | kanzure: what gmaxwell just said? :P | 18:12 |
| * kanzure looks at https://mosh.mit.edu/ | 18:12 | |
| ryan-c | kanzure: predictive local echo | 18:12 |
| kanzure | ssh + tmux handles that situation just fine | 18:12 |
| Luke-Jr | kanzure: no | 18:12 |
| kanzure | does for me? | 18:12 |
| ryan-c | kanzure: tolerates 90% packet loss | 18:12 |
| kanzure | haven't measured packet loss though | 18:13 |
| Luke-Jr | kanzure: SSH gets really bad if there's significant packet loss | 18:13 |
| Luke-Jr | since it's TCPO | 18:13 |
| -!- MrHodl [~fuc@185.22.183.203] has joined #bitcoin-wizards | 18:13 | |
| Luke-Jr | TCP* | 18:13 |
| ryan-c | kanzure: basically it compensates for all the terribleness of cell networks | 18:13 |
| kanzure | this is an appealing feature "Mosh doesn't fill up network buffers, so Control-C always works to halt a runaway process." but tmux sorta breaks this anyway | 18:13 |
| gmaxwell | I think the predictive local echo is ... kinda boring. | 18:14 |
| gmaxwell | kanzure: mosh works across crappy connections where TCP is barely usable. Including ones that are OK but randomly go out like when you're in transportation or at a conference. | 18:14 |
| ryan-c | gmaxwell: I really like it hiding the latency. | 18:14 |
| Luke-Jr | I wish someone did a network transparency layer for Qt with mosh-like semantics :P | 18:15 |
| gmaxwell | I don't look at what I'm typing in any case. Actually what I like about it is that it lets me see the latency by changing the color of the text as its acknoweldged. | 18:15 |
| ryan-c | color? | 18:15 |
| ryan-c | it does underlines for me | 18:15 |
| kanzure | reading what you write directly violates "don't repeat yourself", it's good to have principles | 18:15 |
| gmaxwell | Luke-Jr: any modern X11 stuff is hardly usable remotely. :( so sad. but it's all blasting pixmaps in really inefficient ways across the wire. | 18:15 |
| Luke-Jr | gmaxwell: that's why I want the network layer inside Qt: send text and widget types | 18:16 |
| gmaxwell | ryan-c: or that, I'm on a low latency connection right now so I can't see it. | 18:16 |
| ryan-c | gmaxwell: I am a heavy command line user and often am editing command pipelines, so it telling me where the cursor is going to be is helpful | 18:16 |
| kanzure | eh cursor prediction is easy | 18:17 |
| kanzure | it's a seventh or eighth sense | 18:17 |
| gmaxwell | ryan-c: this is what counting and ctrl-<arrows> is for. :) | 18:18 |
| ryan-c | gmaxwell: probably | 18:19 |
| ryan-c | i'm pretty sure you're the only other person i've talked to who's used airhook | 18:19 |
| gmaxwell | well, there are several production systems out there that I created that use it. | 18:20 |
| gmaxwell | Including a fax <> sat gateway thing with lots of oil rigs that use it. | 18:20 |
| ryan-c | i gotta take off, meeting some friends for dinner | 18:20 |
| gmaxwell | but yea, I'm not sure I've ever encountered someone I didn't introduct to it that knew about it. | 18:20 |
| ryan-c | oh, yeah, it'd be fantastic for satellite comms | 18:20 |
| gmaxwell | I've been using it since like ... CDPD days. | 18:20 |
| -!- chris13243 [~chris@70-0-141-35.pools.spcsdns.net] has quit [Ping timeout: 255 seconds] | 18:22 | |
| -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 18:33 | |
| -!- Dr-G [~Dr-G@x4d08d145.dyn.telefonica.de] has joined #bitcoin-wizards | 18:35 | |
| -!- Dr-G [~Dr-G@x4d08d145.dyn.telefonica.de] has quit [Changing host] | 18:35 | |
| -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards | 18:35 | |
| -!- King_Rex [~King_Rex@53.sub-70-193-64.myvzw.com] has quit [Remote host closed the connection] | 18:36 | |
| -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] | 18:36 | |
| -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has quit [Ping timeout: 264 seconds] | 18:38 | |
| -!- Dr-G2 [~Dr-G@xd9bf77f1.dyn.telefonica.de] has quit [Ping timeout: 272 seconds] | 18:39 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 18:47 | |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wswgyjzrlpvyjnfo] has quit [Quit: Connection closed for inactivity] | 18:50 | |
| -!- chris13243 [~chris@72.62.203.163] has joined #bitcoin-wizards | 19:24 | |
| -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards | 19:25 | |
| -!- snthsnth [~snthsnth@98.207.208.241] has quit [Ping timeout: 272 seconds] | 19:28 | |
| -!- ajweiss [~adam@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Quit: leaving] | 19:38 | |
| -!- sausage_factory [~priidu@unaffiliated/priidu] has quit [Ping timeout: 240 seconds] | 19:39 | |
| -!- davispuh [~quassel@212.93.100.199] has quit [Read error: Connection reset by peer] | 19:47 | |
| -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] | 19:53 | |
| -!- chris13243 [~chris@72.62.203.163] has quit [Ping timeout: 256 seconds] | 19:55 | |
| -!- fkhan [weechat@gateway/vpn/mullvad/x-ilhuivpqrqyspunz] has quit [Ping timeout: 246 seconds] | 20:00 | |
| -!- MrHodl [~fuc@185.22.183.203] has quit [] | 20:01 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] | 20:11 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 20:11 | |
| -!- [7] [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services] | 20:13 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 20:13 | |
| -!- hazirafel [~ufoinc@31.154.91.221] has joined #bitcoin-wizards | 20:16 | |
| -!- adam3us [~Adium@62-2-191-242.static.cablecom.ch] has quit [Quit: Leaving.] | 20:21 | |
| -!- fkhan [~weechat@193.138.219.233] has joined #bitcoin-wizards | 20:24 | |
| -!- fkhan [~weechat@193.138.219.233] has quit [Changing host] | 20:24 | |
| -!- fkhan [~weechat@unaffiliated/loteriety] has joined #bitcoin-wizards | 20:24 | |
| -!- superobserver [~superobse@unaffiliated/superobserver] has quit [Ping timeout: 246 seconds] | 20:24 | |
| -!- robbak [~robbak@unaffiliated/robbak] has quit [Quit: Konversation terminated!] | 20:25 | |
| -!- superobserver [~superobse@unaffiliated/superobserver] has joined #bitcoin-wizards | 20:28 | |
| -!- hazirafel [~ufoinc@31.154.91.221] has quit [Ping timeout: 264 seconds] | 20:31 | |
| -!- p15 [~p15@10.248.234.209.client.dyn.strong-ap1.bringover.net] has joined #bitcoin-wizards | 20:36 | |
| -!- kang_ [67efe917@gateway/web/freenode/ip.103.239.233.23] has joined #bitcoin-wizards | 20:38 | |
| -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 260 seconds] | 20:43 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] | 20:45 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 20:47 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 20:49 | |
| -!- chris13243 [~chris@99.204.125.165] has joined #bitcoin-wizards | 20:50 | |
| -!- chris13243 [~chris@99.204.125.165] has quit [Read error: Connection reset by peer] | 20:50 | |
| -!- adam3us [~Adium@178.197.225.106] has joined #bitcoin-wizards | 20:51 | |
| -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-cayslxusigmlowsd] has quit [Quit: Connection closed for inactivity] | 20:52 | |
| -!- adam3us [~Adium@178.197.225.106] has quit [Client Quit] | 20:53 | |
| -!- adam3us [~Adium@178.197.225.106] has joined #bitcoin-wizards | 20:55 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 265 seconds] | 20:56 | |
| -!- adam3us [~Adium@178.197.225.106] has quit [Quit: Leaving.] | 21:08 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 21:17 | |
| -!- GGuyZ_ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 21:27 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Read error: Connection reset by peer] | 21:27 | |
| -!- GGuyZ_ is now known as GGuyZ | 21:27 | |
| -!- GGuyZ_ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 21:29 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Read error: Connection reset by peer] | 21:29 | |
| -!- GGuyZ_ is now known as GGuyZ | 21:29 | |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 21:40 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Read error: Connection reset by peer] | 21:40 | |
| -!- frankenmint [~frankenmi@71-222-57-192.ptld.qwest.net] has joined #bitcoin-wizards | 21:40 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 21:41 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] | 21:47 | |
| -!- p15 [~p15@10.248.234.209.client.dyn.strong-ap1.bringover.net] has quit [Ping timeout: 268 seconds] | 22:03 | |
| -!- adam3us [~Adium@178.197.224.143] has joined #bitcoin-wizards | 22:06 | |
| -!- adam3us [~Adium@178.197.224.143] has quit [Client Quit] | 22:07 | |
| -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds] | 22:21 | |
| -!- Hunger-- [hunger@proactivesec.com] has joined #bitcoin-wizards | 22:48 | |
| -!- fkhan [~weechat@unaffiliated/loteriety] has quit [Ping timeout: 244 seconds] | 22:50 | |
| -!- p15 [~p15@209.234.248.5] has joined #bitcoin-wizards | 22:52 | |
| -!- fkhan [weechat@unaffiliated/loteriety] has joined #bitcoin-wizards | 22:52 | |
| -!- fkhan [weechat@unaffiliated/loteriety] has quit [Changing host] | 22:52 | |
| -!- fkhan [weechat@gateway/vpn/mullvad/x-ubnnpslidjquurvz] has joined #bitcoin-wizards | 22:52 | |
| -!- Hunger-- [hunger@proactivesec.com] has quit [Ping timeout: 240 seconds] | 22:52 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] | 23:00 | |
| -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Ping timeout: 265 seconds] | 23:06 | |
| -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards | 23:07 | |
| -!- dhaK is now known as dhafk | 23:10 | |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Read error: Connection reset by peer] | 23:21 | |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards | 23:21 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 23:23 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 23:25 | |
| -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards | 23:26 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 23:38 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 23:39 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 23:40 | |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 23:47 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 23:48 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 23:49 | |
| -!- Hunger-- [hunger@proactivesec.com] has joined #bitcoin-wizards | 23:52 | |
| --- Log closed Sat Sep 05 00:00:01 2015 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!