--- Log opened Fri Sep 04 00:00:00 2015
00:00 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
00:01 -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds]
00:02 -!- ebfull [~ebfull@73.34.119.0] has quit [Ping timeout: 244 seconds]
00:04 -!- 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:06 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Quit: WeeChat 1.3]
00:06 -!- gill3s [~gill3s@unaffiliated/gill3s] has joined #bitcoin-wizards
00:07 -!- deego [~user@unaffiliated/deego] has joined #bitcoin-wizards
00:11 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Ping timeout: 250 seconds]
00:16 -!- ebfull [~ebfull@73.34.119.0] has joined #bitcoin-wizards
00:20 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
00:21 -!- 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:28 -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards
00:35 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
01:06 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-wizards
01:11 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
01:13 -!- spinza [~spin@197.89.184.38] has quit [Excess Flood]
01:20 -!- spinza [~spin@197.89.184.38] has joined #bitcoin-wizards
01:33 -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Ping timeout: 250 seconds]
01:35 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-wizards
01:37 -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.]
01:50 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards
01:59 -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Ping timeout: 255 seconds]
02:01 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds]
02:01 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-wizards
02:08 -!- nullbyte [~NSA@193.138.219.233] has quit [Ping timeout: 265 seconds]
02:16 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
02:17 -!- metamarc [~cypher@unaffiliated/agorist000] has joined #bitcoin-wizards
02:18 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards
02:25 -!- 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:26 -!- gmaxwell is now known as Guest36270
02:33 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards
02:38 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards
02:41 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 240 seconds]
02:45 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 268 seconds]
03:00 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-shdkzlaqgecziert] has quit [Quit: Connection closed for inactivity]
03:06 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards
03:14 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 244 seconds]
03:16 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards
03:23 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 272 seconds]
03:27 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards
03:58 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has joined #bitcoin-wizards
04:09 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte]
04:17 -!- harding [~harding@mail.dtrt.org] has joined #bitcoin-wizards
04:35 -!- King_Rex [~King_Rex@53.sub-70-193-64.myvzw.com] has joined #bitcoin-wizards
04:38 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards
04:38 -!- warptangent [~warptan@unaffiliated/warptangent] has quit [Remote host closed the connection]
04:47 -!- warptangent [~warptan@unaffiliated/warptangent] has joined #bitcoin-wizards
04:48 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer]
04:49 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards
05:02 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards
05:18 -!- 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:21 -!- 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:39 -!- adam3us [~Adium@62-2-191-242.static.cablecom.ch] has joined #bitcoin-wizards
05:42 -!- MrHodl [~fuc@185.22.183.202] has joined #bitcoin-wizards
05:50 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Quit: Leaving]
05:52 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards
05:54 -!- davispuh [~quassel@212.93.100.199] has joined #bitcoin-wizards
05:56 -!- binaryFate [~jeremie@joule.ulb.ac.be] has joined #bitcoin-wizards
06:00 -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards
06:06 -!- damethos [~damethos@unaffiliated/damethos] has quit [Remote host closed the connection]
06:15 -!- kang_ [67efe9d5@gateway/web/freenode/ip.103.239.233.213] has joined #bitcoin-wizards
06:17 -!- c0rw|zZz is now known as c0rw1n
06:17 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-wizards
06:20 -!- 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:22 -!- 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:26 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
06:29 -!- hazirafel [~ufoinc@31.154.91.221] has joined #bitcoin-wizards
06:31 -!- MrHodl [~fuc@185.22.183.202] has quit []
06:34 -!- 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:38 -!- 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:39 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards
06:41 -!- GGuyZ [~GGuyZ@dhcp-18-189-28-106.dyn.mit.edu] has joined #bitcoin-wizards
06:44 -!- frankenmint [~frankenmi@71-222-57-192.ptld.qwest.net] has joined #bitcoin-wizards
06:52 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards
07:10 -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards
07:11 -!- eudoxia [~eudoxia@r167-57-55-201.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards
07:14 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
07:18 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has left #bitcoin-wizards []
07:25 -!- chris13243 [~chris@107.25.161.212] has joined #bitcoin-wizards
07:27 -!- NLNico_ [~NLNico@unaffiliated/nlnico] has joined #bitcoin-wizards
07:27 -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Read error: Connection reset by peer]
07:34 -!- chris13243 [~chris@107.25.161.212] has quit [Ping timeout: 264 seconds]
07:43 -!- 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:51 -!- GGuyZ [~GGuyZ@dhcp-18-189-28-106.dyn.mit.edu] has quit [Quit: GGuyZ]
07:56 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
07:56 -!- chris13243 [~chris@108.121.115.250] has joined #bitcoin-wizards
07:57 -!- NLNico_ [~NLNico@unaffiliated/nlnico] has quit [Ping timeout: 240 seconds]
07:58 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-wizards
08:01 -!- NLNico_ [~NLNico@unaffiliated/nlnico] has joined #bitcoin-wizards
08:03 -!- nwilcox [~nwilcox@74-95-207-205-SFBA.hfc.comcastbusiness.net] has joined #bitcoin-wizards
08:05 -!- shen_noe [~shen_noe@104.156.228.141] has quit [Quit: Leaving]
08:13 -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards
08:14 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
08:18 -!- NLNico_ [~NLNico@unaffiliated/nlnico] has quit [Ping timeout: 252 seconds]
08:24 -!- chris13243 [~chris@108.121.115.250] has quit [Ping timeout: 244 seconds]
08:26 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds]
08:27 -!- 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:28 -!- 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:29 -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Remote host closed the connection]
08:30 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Quit: WeeChat 1.4-dev]
08:48 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards
08:50 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-wizards
08:54 -!- nwilcox [~nwilcox@74-95-207-205-SFBA.hfc.comcastbusiness.net] has quit [Ping timeout: 268 seconds]
09:00 -!- 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:01 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-wizards
09:02 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Client Quit]
09:03 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-wizards
09:03 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Client Quit]
09:05 -!- 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:07 -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards
09:08 -!- nullbyte [~NSA@198.203.28.43] has quit [Ping timeout: 264 seconds]
09:12 -!- hazirafel [~ufoinc@31.154.91.221] has joined #bitcoin-wizards
09:24 -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has quit [Remote host closed the connection]
09:28 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
09:29 -!- hazirafel [~ufoinc@31.154.91.221] has quit [Read error: Connection reset by peer]
09:36 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards
09:40 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
09:44 -!- gill3s [~gill3s@unaffiliated/gill3s] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
09:46 -!- 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:48 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 268 seconds]
09:52 -!- nullbyte [~NSA@198.203.28.43] has joined #bitcoin-wizards
09:55 -!- 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:57 -!- adam3us [~Adium@62-2-191-242.static.cablecom.ch] has joined #bitcoin-wizards
09:59 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds]
10:00 -!- 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:01 < kanzure> https://bytecoin.org/static/files/docs/aggregate-addresses.pdf
10:06 -!- ginah [~nahnah@50.248.81.66] has quit [Remote host closed the connection]
10:08 < 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:09 < 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:10 -!- 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:12 -!- 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:13 -!- 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:14 < 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:15 < fluffypony> dEBRUYNE: no we did something different
10:16 < fluffypony> we have a third component, a short payment ID, that is optional and encrypted
10:16 < fluffypony> (well, optionally encrypted)
10:17 < 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:18 < 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:19 < 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:20 < 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:21 < 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:22 < jack-jack> I'm sorry, joined I joined in the middle of the chat
10:22 < fluffypony> jack-jack: you're forgiven
10:23 < 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:24 < 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:25 < 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:26 < 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:27 < 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:28 < 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:29 < 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:30 < 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:32 < fluffypony> ah
10:33 < 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:34 < 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:35 < 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:36 < 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:37 -!- 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:38 < 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:39 < 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:40 < 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:41 < jack-jack> finally, R is random
10:43 < 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:45 -!- c0rw1n is now known as greenbat
10:47 < 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:48 < 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:49 -!- 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:50 < jack-jack> yep, oversimplified
10:51 < 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:54 < 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:55 < gmaxwell> If you're revising the paper, feel free to thank me for commentary.
10:56 < 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:58 -!- 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:59 -!- greenbat is now known as c0rw1n
10:59 -!- davispuh [~quassel@212.93.100.199] has joined #bitcoin-wizards
11:01 -!- 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:03 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
11:04 -!- 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:05 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 264 seconds]
11:07 < 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:08 < 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:09 < 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:10 < 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:13 < 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:14 < 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:15 < 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:16 < phantomcircuit> ha
11:16 < petertodd> tromp_: huh, never seen hawk before
11:17 -!- 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:18 < 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:22 -!- 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:25 -!- 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:26 -!- nullbyte [NSA@gateway/vpn/mullvad/x-bhaoenjwhxyghjgn] has joined #bitcoin-wizards
11:30 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards
11:31 < 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:32 -!- 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:33 < 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:34 < 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:35 < 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:36 < 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:37 < 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:38 < 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:39 < gmaxwell> Fortuneately moxie has seperate load/store and no other instruction has access to anything but registers.
11:41 -!- shen_noe [~shen_noe@104.156.228.141] has quit [Quit: Leaving]
11:42 < 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:43 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards
11:44 < 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:45 < 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:46 -!- 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:47 -!- 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:48 < 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:49 < 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:50 < 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:51 < 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:52 -!- 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:53 < 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:54 < Eliel> gmaxwell: well, that's only necessary for scripts with unusually high upper bounds.
11:55 < 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:56 < 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:58 < 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:59 < gmaxwell> CodeShark: cost can be easily and reliably measured by tracing.
12:00 < 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:01 < gmaxwell> in all cases the upper bound on computation must still be fairly low... though computation could be broken up as PT suggests.
12:02 < 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:03 < 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:04 < 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:05 < 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:06 < 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:07 -!- 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:08 < kanzure> jgarzik: thanks
12:08 -!- erasmospunk [~erasmospu@179.43.156.162] has joined #bitcoin-wizards
12:09 -!- blackwraith [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
12:10 -!- Guest89 [~textual@c-73-15-187-144.hsd1.ca.comcast.net] has joined #bitcoin-wizards
12:11 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 260 seconds]
12:12 < CodeShark> if the computation can be broken up and smaller pieces verified and paid for individually it could work
12:14 < 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:16 < 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:17 < CodeShark> it's for a presentation, gmaxwell
12:17 < CodeShark> although perhaps it will end up becoming a publication
12:18 -!- adam3us [~Adium@178.197.232.114] has quit [Quit: Leaving.]
12:20 < 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:21 < CodeShark> so do you have a list?
12:21 < kanzure> yes... one sec.
12:23 -!- 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:24 < 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:26 < 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:27 < 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:28 < 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:29 < 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:30 < 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:31 < 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:32 -!- hsmiths [uid95325@gateway/web/irccloud.com/x-xtwdoiglfenniqep] has joined #bitcoin-wizards
12:41 < 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:42 < CodeShark> sure. and mine is on validation costs and incentives. ditto :)
12:43 < 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:45 -!- digitalmagus [~digitalma@unaffiliated/digitalmagus] has quit [Ping timeout: 246 seconds]
12:49 -!- chris13243 [~chris@68.27.186.20] has joined #bitcoin-wizards
12:51 -!- Guest89 [~textual@c-73-15-187-144.hsd1.ca.comcast.net] has joined #bitcoin-wizards
12:56 -!- adam3us [~Adium@178.197.232.153] has joined #bitcoin-wizards
13:02 -!- chris13243 [~chris@68.27.186.20] has quit [Ping timeout: 252 seconds]
13:03 < ghtdak> iset
13:08 -!- Hunger-- [hunger@proactivesec.com] has quit [Ping timeout: 264 seconds]
13:09 -!- tromp__ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards
13:09 -!- hazirafel [~ufoinc@31.154.91.221] has joined #bitcoin-wizards
13:10 -!- tripleslash [~\\\@unaffiliated/imsaguy] has joined #bitcoin-wizards
13:12 -!- 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:13 -!- 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:14 -!- otoburb_ [~otoburb@unaffiliated/otoburb] has quit [Client Quit]
13:16 -!- kang_ [67efe9d5@gateway/web/freenode/ip.103.239.233.213] has joined #bitcoin-wizards
13:18 -!- zooko [~user@c-73-14-172-248.hsd1.co.comcast.net] has joined #bitcoin-wizards
13:24 < 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:25 < kanzure> you can use multisig pools for receiving cheap utxos on the blockchain in that circumstance
13:26 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards
13:27 < 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:28 -!- adam3us [~Adium@178.197.232.153] has quit [Quit: Leaving.]
13:29 < 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:30 < 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:31 < 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:32 -!- adam3us [~Adium@178.197.236.137] has joined #bitcoin-wizards
13:33 < kanzure> (although you don't have to immediately exit into utxos anyway)
13:34 -!- 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:35 < gmaxwell> the software impl is perfectly reasonable though.
13:36 -!- 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:37 < 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:38 < 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:39 < 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:40 < kanzure> well, the lightning network nodes might be miners
13:41 -!- 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:42 < 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:43 -!- otoburb [~otoburb@unaffiliated/otoburb] has joined #bitcoin-wizards
13:44 -!- adam3us [~Adium@178.197.236.52] has joined #bitcoin-wizards
13:45 -!- 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:46 -!- 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:47 < 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:48 < 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:49 < 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:50 < 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:51 < 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:52 -!- 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:53 < 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:54 < 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:55 < 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:56 < 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:57 < 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:58 < 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:59 < 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]
14:00 < 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:01 < 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:02 -!- 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:03 -!- 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:04 < 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:05 < 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:06 -!- 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:07 -!- 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:08 -!- 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:09 < 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:10 < 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:11 -!- erasmospunk [~erasmospu@mi-18-24-58.service.infuturo.it] has joined #bitcoin-wizards
14:12 < 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:13 < 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:14 < CodeShark> well, decentralization doesn't have to mean flood networks
14:14 < gmaxwell> nice timing re ISPs comment and #bitcoin
14:15 < 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:16 -!- 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:17 < 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:18 < 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:19 -!- 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:20 < 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:22 < 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:23 < 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:24 < 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:25 < 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:26 < 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:27 < 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:28 < 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:29 < 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:30 < 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:31 < 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:32 < 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:33 < CodeShark> ad-hoc mesh networks :)
14:33 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards
14:34 < 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:35 < gmaxwell> otherwise you have no oppturnity to get other people to rebalance your channels.
14:36 < 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:37 < 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:38 < Taek> you have to put a transaction on the blockchain for every link you establish
14:39 < gmaxwell> Taek: it doesn't mean greater setup costs.
14:40 < 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:41 < 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:42 < 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:43 -!- 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:44 < 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:45 < 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:46 < 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:47 -!- 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:49 < 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:50 < 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:51 < 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:52 < 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:53 -!- 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:55 < 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:56 < 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:57 < gmaxwell> But yea, it's impressive the gains you can get.
14:58 -!- hazirafel [~ufoinc@31.154.91.221] has quit [Ping timeout: 246 seconds]
14:59 < 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/
15:00 -!- 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:01 -!- RoboTeddy [~roboteddy@c-67-188-40-9.hsd1.ca.comcast.net] has quit []
15:02 < 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:03 < kanzure> for that one there's http://diyhpl.us/~bryan/papers2/brain-emulation-roadmap-report.pdf
15:05 < 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:06 < 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:07 < phantomcircuit> something something cubic blocks
15:07 -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Quit: Ex-Chat]
15:08 < kanzure> er, then what is merkle tree construction actually limited towards?
15:09 < 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:10 < 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:11 < 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:12 < 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:13 < 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:14 -!- 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:15 < gmaxwell> it's really just N*2 hashes total for efficient software I promise.
15:15 < phantomcircuit> yeah i can see why now
15:16 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has quit [Remote host closed the connection]
15:18 -!- erasmospunk [~erasmospu@81.17.20.66] has quit [Ping timeout: 264 seconds]
15:19 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Remote host closed the connection]
15:28 -!- instagibbs_ [6c1fd228@gateway/web/freenode/ip.108.31.210.40] has quit [Quit: Page closed]
15:29 -!- zooko [~user@c-73-14-172-248.hsd1.co.comcast.net] has quit [Ping timeout: 246 seconds]
15:31 -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has quit [Read error: Connection reset by peer]
15:46 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
15:54 < 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
16:06 -!- 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:10 -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has quit [Ping timeout: 256 seconds]
16:11 < 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:12 -!- kyuupichan [~Neil@ae051180.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-wizards
16:13 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 244 seconds]
16:21 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 244 seconds]
16:24 -!- MrHodl [~fuc@185.22.183.196] has joined #bitcoin-wizards
16:24 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_]
16:28 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
16:28 -!- MrHodl [~fuc@185.22.183.196] has quit [Ping timeout: 250 seconds]
16:32 -!- 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:34 -!- chris13243 [~chris@72-57-94-244.pools.spcsdns.net] has joined #bitcoin-wizards
16:37 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ]
16:39 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards
16:40 -!- snthsnth [~snthsnth@98.207.208.241] has joined #bitcoin-wizards
16:45 -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has quit [Ping timeout: 244 seconds]
16:48 -!- 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:49 -!- GAit [~GAit@2.230.161.158] has joined #bitcoin-wizards
16:54 -!- Guest89 [~textual@c-73-15-187-144.hsd1.ca.comcast.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
17:02 -!- 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:03 -!- nullbyte [NSA@gateway/vpn/mullvad/x-suntigubcdbwjacp] has quit [Ping timeout: 264 seconds]
17:04 -!- sausage_factory [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
17:05 -!- blackwraith [~priidu@unaffiliated/priidu] has quit [Ping timeout: 240 seconds]
17:06 < 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:08 < gmaxwell> I think I saw a presentation with a Schrödinger CRC.
17:09 -!- 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:10 < kanzure> the nasa system fault tolerance stuff slide deck?
17:11 -!- 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:12 < 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:13 < 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:14 < 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:24 < 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:25 < gmaxwell> sounds great, just give me 4x overhead to play with. :P
17:26 < 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:27 < 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:28 < gmaxwell> plus if someone tries to attack you, you can throw battery acid at them. What could go wrong?
17:29 < gmaxwell> you can get old x61 laptops for almost free, though usually not with working batteries.
17:30 < midnightmagic> rolled a 1, critical fumble, arggghhh
17:31 < jgarzik> rofl I have way too many burner desktops
17:32 < kanzure> i would be far far more interested in capturing whatever malware people try to release
17:34 < 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:35 < kanzure> you can make jgarzik do it
17:35 < midnightmagic> "Installation of Bitcoin requires a kernel module to be loaded at boot-time.."
17:41 < 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:42 < gmaxwell> Luke-Jr: I thought you did!
17:43 < 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:44 < Luke-Jr> oh, that exists. but I almost never use it.
17:44 < kanzure> ok
17:45 < 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:46 -!- 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:47 < 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:48 < phantomcircuit> gmaxwell, i brought a burner laptop/cellphone to defcon
17:49 < phantomcircuit> didn't have a burner sim though
17:49 < phantomcircuit> possibly there's malware on it
17:51 < gmaxwell> I am continually frustrated that no machine learning software flaw detector exists.
17:52 < ryan-c> I reuse my burner sim between DEFCONs
17:53 < ryan-c> (and i have a burner phone)
17:56 < ryan-c> I'm pretty sure malware on SIM is possible.
17:58 < 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
18:00 < 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:01 < 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:02 -!- 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:03 < 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:05 < ryan-c> Luke-Jr: I become a fan of "laptop is a thin client and browser" model.
18:06 < 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:07 < 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:08 < 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:09 < 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:10 < 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:11 < 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:12 < 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:13 < 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:14 < 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:15 < 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:16 < 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:17 < kanzure> eh cursor prediction is easy
18:17 < kanzure> it's a seventh or eighth sense
18:18 < gmaxwell> ryan-c: this is what counting and ctrl-<arrows> is for. :)
18:19 < 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:20 < 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:22 -!- chris13243 [~chris@70-0-141-35.pools.spcsdns.net] has quit [Ping timeout: 255 seconds]
18:33 -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards
18:35 -!- 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:36 -!- 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:38 -!- ASTP001 [~ASTP001@50-78-139-77-static.hfc.comcastbusiness.net] has quit [Ping timeout: 264 seconds]
18:39 -!- Dr-G2 [~Dr-G@xd9bf77f1.dyn.telefonica.de] has quit [Ping timeout: 272 seconds]
18:47 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
18:50 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wswgyjzrlpvyjnfo] has quit [Quit: Connection closed for inactivity]
19:24 -!- chris13243 [~chris@72.62.203.163] has joined #bitcoin-wizards
19:25 -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards
19:28 -!- snthsnth [~snthsnth@98.207.208.241] has quit [Ping timeout: 272 seconds]
19:38 -!- ajweiss [~adam@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Quit: leaving]
19:39 -!- sausage_factory [~priidu@unaffiliated/priidu] has quit [Ping timeout: 240 seconds]
19:47 -!- davispuh [~quassel@212.93.100.199] has quit [Read error: Connection reset by peer]
19:53 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
19:55 -!- chris13243 [~chris@72.62.203.163] has quit [Ping timeout: 256 seconds]
20:00 -!- fkhan [weechat@gateway/vpn/mullvad/x-ilhuivpqrqyspunz] has quit [Ping timeout: 246 seconds]
20:01 -!- MrHodl [~fuc@185.22.183.203] has quit []
20:11 -!- 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:13 -!- [7] [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services]
20:13 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
20:16 -!- hazirafel [~ufoinc@31.154.91.221] has joined #bitcoin-wizards
20:21 -!- adam3us [~Adium@62-2-191-242.static.cablecom.ch] has quit [Quit: Leaving.]
20:24 -!- 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:25 -!- robbak [~robbak@unaffiliated/robbak] has quit [Quit: Konversation terminated!]
20:28 -!- superobserver [~superobse@unaffiliated/superobserver] has joined #bitcoin-wizards
20:31 -!- hazirafel [~ufoinc@31.154.91.221] has quit [Ping timeout: 264 seconds]
20:36 -!- p15 [~p15@10.248.234.209.client.dyn.strong-ap1.bringover.net] has joined #bitcoin-wizards
20:38 -!- kang_ [67efe917@gateway/web/freenode/ip.103.239.233.23] has joined #bitcoin-wizards
20:43 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 260 seconds]
20:45 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ]
20:47 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards
20:49 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards
20:50 -!- 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:51 -!- adam3us [~Adium@178.197.225.106] has joined #bitcoin-wizards
20:52 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-cayslxusigmlowsd] has quit [Quit: Connection closed for inactivity]
20:53 -!- adam3us [~Adium@178.197.225.106] has quit [Client Quit]
20:55 -!- adam3us [~Adium@178.197.225.106] has joined #bitcoin-wizards
20:56 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 265 seconds]
21:08 -!- adam3us [~Adium@178.197.225.106] has quit [Quit: Leaving.]
21:17 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
21:27 -!- 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:29 -!- 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:40 -!- 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:41 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards
21:47 -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ]
22:03 -!- p15 [~p15@10.248.234.209.client.dyn.strong-ap1.bringover.net] has quit [Ping timeout: 268 seconds]
22:06 -!- adam3us [~Adium@178.197.224.143] has joined #bitcoin-wizards
22:07 -!- adam3us [~Adium@178.197.224.143] has quit [Client Quit]
22:21 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds]
22:48 -!- Hunger-- [hunger@proactivesec.com] has joined #bitcoin-wizards
22:50 -!- fkhan [~weechat@unaffiliated/loteriety] has quit [Ping timeout: 244 seconds]
22:52 -!- 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]
23:00 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds]
23:06 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Ping timeout: 265 seconds]
23:07 -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards
23:10 -!- dhaK is now known as dhafk
23:21 -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Read error: Connection reset by peer]
23:21 -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards
23:23 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam]
23:25 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
23:26 -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards
23:38 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
23:39 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam]
23:40 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
23:47 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
23:48 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam]
23:49 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
23:52 -!- Hunger-- [hunger@proactivesec.com] has joined #bitcoin-wizards
--- Log closed Sat Sep 05 00:00:01 2015