| --- Log opened Sat Sep 05 00:00:01 2015 | ||
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 00:01 | |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 00:21 | |
| -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has quit [Ping timeout: 246 seconds] | 00:24 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 00:51 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 246 seconds] | 00:59 | |
| -!- AlphaTech [AlphaTech@unaffiliated/alphatech] has joined #bitcoin-wizards | 01:03 | |
| wumpus | Luke-Jr: xpra does a pretty good job as a better network transparency layer for X, and sessions are re-attachable too | 01:05 |
|---|---|---|
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nyydjfoklttsjwvt] has joined #bitcoin-wizards | 01:07 | |
| -!- p15 [~p15@209.234.248.5] has quit [Max SendQ exceeded] | 01:14 | |
| -!- Mably [~Mably@unaffiliated/mably] has joined #bitcoin-wizards | 01:16 | |
| -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 01:17 | |
| -!- p15 [~p15@209.234.248.8] has joined #bitcoin-wizards | 01:17 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 01:17 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 255 seconds] | 01:23 | |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds] | 01:29 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 01:29 | |
| -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Read error: Connection reset by peer] | 01:37 | |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 01:40 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 01:46 | |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 252 seconds] | 02:03 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 244 seconds] | 02:13 | |
| -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has joined #bitcoin-wizards | 02:15 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds] | 02:16 | |
| heretolearn | mosh has issues with scrolling .. otherwise its nice | 02:25 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 02:42 | |
| -!- binaryFate [~jeremie@joule.ulb.ac.be] has quit [Quit: Konversation terminated!] | 02:53 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 265 seconds] | 02:55 | |
| -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has joined #bitcoin-wizards | 03:01 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 03:14 | |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] | 03:14 | |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards | 03:30 | |
| -!- gielbier [~giel@a149043.upc-a.chello.nl] has quit [Read error: Connection reset by peer] | 03:32 | |
| -!- gielbier [~giel@a149043.upc-a.chello.nl] has joined #bitcoin-wizards | 03:32 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 03:42 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Read error: Connection reset by peer] | 03:44 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 03:45 | |
| -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has quit [Ping timeout: 250 seconds] | 03:46 | |
| -!- GGuyZ_ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 03:50 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Ping timeout: 260 seconds] | 03:52 | |
| -!- GGuyZ_ is now known as GGuyZ | 03:52 | |
| -!- PRab_ [~chatzilla@2601:40a:8000:8f9b:49d8:b6f:46db:e64d] has joined #bitcoin-wizards | 04:08 | |
| -!- kaptah [kaptah@hilla.kapsi.fi] has quit [Ping timeout: 246 seconds] | 04:09 | |
| -!- kaptah [kaptah@hilla.kapsi.fi] has joined #bitcoin-wizards | 04:09 | |
| -!- PRab [~chatzilla@2601:40a:8000:8f9b:99a5:26ec:a97e:cce5] has quit [Ping timeout: 244 seconds] | 04:11 | |
| -!- PRab_ is now known as PRab | 04:11 | |
| -!- p15 [~p15@209.234.248.8] has quit [Ping timeout: 255 seconds] | 04:11 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Ping timeout: 244 seconds] | 04:18 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 04:21 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 04:28 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Quit: Leaving] | 04:35 | |
| -!- kang_ [67efe917@gateway/web/freenode/ip.103.239.233.23] has quit [Ping timeout: 246 seconds] | 04:45 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 250 seconds] | 04:48 | |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Quit: WeeChat 1.4-dev] | 04:49 | |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-wizards | 04:49 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 04:54 | |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 04:54 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection] | 04:59 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 05:01 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] | 05:08 | |
| -!- AaronvanW [~ewout@178pc208.sshunet.nl] has joined #bitcoin-wizards | 05:12 | |
| -!- AaronvanW [~ewout@178pc208.sshunet.nl] has quit [Changing host] | 05:12 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 05:12 | |
| -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards | 05:14 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has quit [Ping timeout: 264 seconds] | 05:26 | |
| -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards | 05:33 | |
| -!- trippysalmon [~rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has joined #bitcoin-wizards | 05:35 | |
| -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] | 05:36 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] | 05:40 | |
| -!- trippysalmon [~rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has quit [Read error: Connection reset by peer] | 05:43 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #bitcoin-wizards [] | 05:49 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 05:54 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0386.uvt.nl] has joined #bitcoin-wizards | 05:55 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0386.uvt.nl] has quit [Client Quit] | 06:00 | |
| -!- eudoxia [~eudoxia@r167-56-99-88.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 06:03 | |
| -!- blackwraith [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 06:06 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 250 seconds] | 06:06 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0386.uvt.nl] has joined #bitcoin-wizards | 06:20 | |
| -!- kang_ [67efe936@gateway/web/freenode/ip.103.239.233.54] has joined #bitcoin-wizards | 06:21 | |
| kanzure | .title http://samvartaka.github.io/backdoors/2015/09/03/rsa-curve25519-backdoor/ | 06:23 |
| yoleaux | Detecting an asymmetric Curve25519 backdoor in RSA key generation algorithms - samvartaka | 06:23 |
| -!- dEBRUYNE [~dEBRUYNE@vp0386.uvt.nl] has quit [Quit: Leaving] | 06:29 | |
| nsh | -- | 06:31 |
| nsh | While it does guarantee confidentiality it does not, however, guarantee indistinguishability and as such can be discovered by a third party with blackbox access to a key generation algorithm suspected to be backdoored in this fashion. The reason why it does not guarantee indistinguishability (noted as well by De Gregorio) is because the ephemeral Curve25519 public key embedded in the public modulus of the backdoored RSA public key can be distinguished fr | 06:31 |
| nsh | om a uniform random string. As noted elsewhere Curve25519 points can be distinguished from uniform random strings by virtue of the fact that they lie on the curve. Given a Curve25519 public key, which consists of the 256-bit x-coordinate of an (x,y) point on the curve, the probability that it is an x-coordinate corresponding to a valid curve-point is 1 while for a uniform random string this probability is 0.5. This thus allows for a distinguishing attack | 06:31 |
| nsh | on part of a third party collecting n public keys generated by a blackbox key generation algorithm. | 06:31 |
| nsh | -- i'm pretty sure you could overcome this with some kind of blinding | 06:31 |
| nsh | or using djb-ish point-repre uniformisation technique | 06:31 |
| nsh | .t https://www.imperialviolet.org/2013/12/25/elligator.html | 06:32 |
| yoleaux | nsh: Sorry, I don't know a timezone by that name. | 06:32 |
| nsh | .title https://www.imperialviolet.org/2013/12/25/elligator.html | 06:32 |
| yoleaux | ImperialViolet - Implementing Elligator for Curve25519 | 06:32 |
| nsh | there we go | 06:32 |
| nsh | sneakiness reestablished | 06:33 |
| -!- dEBRUYNE [~dEBRUYNE@vp0386.uvt.nl] has joined #bitcoin-wizards | 06:35 | |
| -!- blackwraith [~priidu@unaffiliated/priidu] has quit [Ping timeout: 272 seconds] | 06:36 | |
| -!- dEBRUYNE [~dEBRUYNE@vp0386.uvt.nl] has quit [Client Quit] | 06:36 | |
| -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-wizards | 06:37 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards | 06:40 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] | 06:42 | |
| -!- eudoxia [~eudoxia@r167-56-99-88.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] | 06:59 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 07:02 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] | 07:02 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 07:05 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 07:15 | |
| -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 07:32 | |
| -!- Giszmo [~leo@pc-185-201-214-201.cm.vtr.net] has joined #bitcoin-wizards | 07:33 | |
| -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-pocaeshsqhpwydxp] has joined #bitcoin-wizards | 07:37 | |
| -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined #bitcoin-wizards | 07:46 | |
| -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has quit [Ping timeout: 252 seconds] | 07:51 | |
| kang_ | Why is a two-way peg better than atomic swap? | 07:53 |
| Taek | kang_: with an atomic swap you have 2 different currencies | 07:54 |
| Taek | with a two-way peg, it's the same currency on both blockchains | 07:54 |
| kang_ | That is because you are imagining atomic swap which is usually 2-party with side-peg which is done by an individual | 07:56 |
| kang_ | Try drawing both on paper, except the origin of coins, they both look same | 07:56 |
| Taek | the origin of coins is what makes a two-way peg interesting | 07:59 |
| Taek | after you've set up the two way peg, most transfers are typically going to be atomic swaps: atomic swaps are a lot cheaper to perform | 07:59 |
| Taek | but a two way peg grants you a new power: you can move coins either direction between blockchains | 07:59 |
| Taek | and so if you ever need a net flow in a direction, you can use a 2wp to achieve that | 08:00 |
| kang_ | Yes, theoretically I get that. But practically for a merchant accepting coins on a sidechain, swapped or pegged coins make no difference because they won't do so for miners either to retain their value. Wouldn't a btc bearing sidechain require equal subsidy for the coins to esentially be equally secure? | 08:04 |
| Taek | depends on how the sidechain is set up, but generally speaking the btc on the sidechain are only as secure as the hashpower protecting the sidechain | 08:07 |
| Taek | merge mining helps mitigate the security risk to some degree | 08:07 |
| -!- frankenmint [~frankenmi@71-222-57-192.ptld.qwest.net] has quit [] | 08:07 | |
| kanzure | "retain their value" well i think there's various weird arbitrage things you can do if for whatever reason the market seems to disagree about the physical equivalency | 08:10 |
| kang_ | Case 1: Sidechain has less network hashrate -> my coins are not secure, so i won't peg to it. Case 2: Sidechain has equal hashrate to btc -> sidechain scavenges btc's hashrate which is overall not less secure 'only if' that sidechain is 'exclusive' to btc | 08:10 |
| kanzure | "i won't peg to it" what does this mean? you can't just wish the peg didn't exist. | 08:10 |
| kang_ | No I mean I won't use it | 08:10 |
| kanzure | you should not be forced to use anything | 08:11 |
| Taek | The only reason you'd use it in the first place is if it did something that you couldn't already do on the Bitcoin blockchain, e.g. Confidential Transactions | 08:11 |
| kang_ | I meant since it is a less secure chain, I'd better off using something with hasrate in between the two, like say litecoin | 08:12 |
| Taek | you might be willing to accept the decreased security for the increased functionality | 08:12 |
| kang_ | Taek: I was considering the scalability use case | 08:12 |
| kang_ | Devs can see the scalability functionality but to a user, they won't compromise security for a good cause | 08:13 |
| Taek | "I'd better off using... say litecoin" -> yes but then you aren't using the Bitcoin currency | 08:13 |
| Taek | which means you are making a different set of tradeoffs | 08:14 |
| kanzure | Taek: no there are other reasons, such as lower or different fees | 08:14 |
| -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 256 seconds] | 08:14 | |
| kanzure | kang_: i suspect that fee pressure might encourage users to choose different utxos on different chains http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010909.html | 08:14 |
| kang_ | Taek: I think I am not able to explain, please bear. BTC has hashrate x, sidechain has y (y<x), so rather than using y, I'd use some z where (x>z>y) even if that means exchainging my coins cause it is no difference to value I am holding | 08:15 |
| -!- zooko [~user@c-73-14-172-248.hsd1.co.comcast.net] has joined #bitcoin-wizards | 08:16 | |
| Taek | "no there are other reasons, such as lower or different fees" this is just semantics, but if you are using a sidechain for lower fees, it means that the bitcoin blockchain can't do transactions at the desired fee | 08:16 |
| -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards | 08:17 | |
| kanzure | Taek: i was just commenting on "The only reason is... couldn't already do on the ... " phrase. | 08:17 |
| kang_ | kanzure: So we are saying people would prefer less fees over less security? | 08:18 |
| kanzure | chains/ledgers with lower fees will probably have less security (although this is not guaranteed) | 08:18 |
| Taek | kang_: some people will make that tradeoff, others won't | 08:19 |
| -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards | 08:19 | |
| kanzure | i think you meant to ask "people would prefer less fees over more security?" | 08:19 |
| kang_ | yes, sorry | 08:19 |
| kanzure | you could have also meant "people would prefer less fees even if it meant a lower-security consensus history?" | 08:20 |
| kang_ | Taek: what happens if most won't? Then sidechains would fail as a scalability solution? Or any scalability offered is good. | 08:21 |
| kanzure | well, first, most fees are cleverly hidden from most users- by putting the fees on the merchants instead | 08:21 |
| kanzure | but that's a pull system, not a push. dunno how the same trick works in a push system- maybe child-pays-for-parent-counts, but i sorta doubt it. | 08:22 |
| kang_ | That only changes the question to "would most merchants prefer cheaper transactions over secure ones?" | 08:22 |
| kanzure | it's not really about transactions- it's about the cost of utxos once you want to create utxos | 08:24 |
| kanzure | because channels can be kept open almost indefinitely | 08:24 |
| kang_ | Channels between? Addresses? IPs? Idefinitely open channels only make sense in case of recurring payment requirements like say sandglass type flowing microtransactions | 08:26 |
| kanzure | "recurring payment requirements" sounds a lot like sending and receiving payments | 08:26 |
| kang_ | General trade is not repetitive. In real life I seldom deal with a person twice. | 08:27 |
| kanzure | kang_: are you familiar with the lightning network? the proposal is a multi-hop hub-and-spoke network where you only need at least one channel connected to the broader network to do insta-payments to anyone on the network. | 08:28 |
| kanzure | (using payment channels) | 08:28 |
| kang_ | Yes, but doesn't that require the network to be between something? Some unique identifier? | 08:29 |
| kanzure | i don't understand | 08:30 |
| kang_ | Any network, to retain its topology would need a track of its members, no? If I understand correctly payment channels are between bitcoin addresses. If so, I am saying that I seldom pay someone that might be connected to my payment channel history | 08:32 |
| kanzure | payment channels use many different bitcoin addresses during their operation | 08:33 |
| kanzure | for an elaborate on-the-ground walkthrough of how payment channels work, see https://github.com/ElementsProject/lightning/blob/master/test-cli/scripts/test.sh | 08:34 |
| kanzure | also https://lightning.network/lightning-network-paper.pdf | 08:34 |
| kang_ | Basically, every payment I make would always need a new hub everytime if it is a disconnected set of the network & that defeats the scalability | 08:35 |
| kanzure | payment channels can be used for multiple payments | 08:35 |
| kang_ | I understand LN but haven't memorised the technical terms so am unclear. Sorry, I'll read and come back. | 08:36 |
| kanzure | cool | 08:36 |
| nsh | i understand nothing | 08:41 |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 08:49 | |
| kanzure | nsh: trying to impress the monks? | 08:50 |
| * nsh smiles | 08:50 | |
| -!- Mably [~Mably@unaffiliated/mably] has quit [Read error: Connection reset by peer] | 09:13 | |
| -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards | 09:21 | |
| -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards | 09:23 | |
| -!- adam3us [~Adium@88-105-23-239.dynamic.dsl.as9105.com] has joined #bitcoin-wizards | 09:37 | |
| -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] | 09:37 | |
| -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards | 09:42 | |
| -!- adam3us [~Adium@88-105-23-239.dynamic.dsl.as9105.com] has quit [Quit: Leaving.] | 09:45 | |
| -!- davispuh [~quassel@212.93.100.199] has joined #bitcoin-wizards | 09:55 | |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 09:59 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte] | 10:03 | |
| -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 252 seconds] | 10:09 | |
| -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has joined #bitcoin-wizards | 10:13 | |
| -!- AnoAnon [~AnoAnon@197.39.230.138] has joined #bitcoin-wizards | 10:13 | |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards | 10:14 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 10:15 | |
| -!- AnoAnon [~AnoAnon@197.39.230.138] has quit [Read error: Connection reset by peer] | 10:18 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds] | 10:33 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 10:38 | |
| -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 252 seconds] | 10:40 | |
| kang_ | So I revised LN and have the statement from the paper which I have a problem with, "By chaining together multiple micropayment channels, it is possible to create a network of transaction paths" | 10:41 |
| CodeShark | what's your issue with it? | 10:42 |
| kang_ | If Alice needs to send coins to Dave, are we sure she would be able to find a path through a channel between Bob & Carol such that Alice->Bob->Carol->Dave | 10:42 |
| kang_ | I say that it would not always be able to find a path through the network of hubs | 10:43 |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [Remote host closed the connection] | 10:43 | |
| kang_ | Is there any data that proves a pth would always exist? | 10:44 |
| CodeShark | that depends on the routing protocol and the way channels are initally set up - which is not specified in the paper | 10:44 |
| CodeShark | consider how bitcoin always finds paths between two nodes - but instead of a flood network, it's a routable protocol. nodes can create small channels with random peers as part of their initial setup | 10:45 |
| CodeShark | it's certainly not a trivial problem - but I think the LN paper focuses more on the consensus layer | 10:46 |
| kang_ | Drawing a similarity with the network that is the internet, we are always able to find paths between ip addresses because of how ISP act as hubs for routing. For nodes to do the same 1. they would have to be somewhat permanent 2. Require extra work hence would need an incentive 3. Even then mostly would require a new last-mile channel setup | 10:48 |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 10:49 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] | 10:50 | |
| CodeShark | yes, all good points | 10:50 |
| CodeShark | there is an incentive, though | 10:50 |
| CodeShark | 3. seems trickiest | 10:51 |
| kang_ | Yes, 1 and 2 are problems but seem solvable. My real problem is 3 | 10:51 |
| kang_ | yes, that | 10:51 |
| CodeShark | how can someone who has no coins join the network? | 10:51 |
| -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-pocaeshsqhpwydxp] has quit [Quit: Connection closed for inactivity] | 10:52 | |
| CodeShark | there's always risk in taking on any unknown new node | 10:52 |
| CodeShark | so new nodes might expect to pay most of the anchor transaction fees | 10:52 |
| CodeShark | but they are also in the worst position to actually pay that | 10:52 |
| kang_ | Exactly such a someone is the last-mile that would need to setup a new channel with someone in the network, thereby defeating the cause | 10:53 |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 10:53 | |
| -!- hazirafel [~ufoinc@31.154.91.221] has joined #bitcoin-wizards | 10:54 | |
| CodeShark | heh - we might need extraprotocol creditors :p | 10:55 |
| -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has quit [Remote host closed the connection] | 10:55 | |
| kang_ | Sorry, didn't get you | 10:56 |
| -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-wizards | 10:57 | |
| CodeShark | I mean, it might be necessary to do risk assessment outside the protocol and front the newcomers something so they can join the network | 10:57 |
| kanzure | yes there was discussion about fronting utxos for lightning network onboarding | 10:58 |
| kanzure | i believe it was discussed in here between myself and rusty but maybe some other user | 10:58 |
| -!- blackwraith [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 10:59 | |
| kang_ | Since i always use new addresses, (and almost always pay to a fresh address) it would always require setting up new last mile channels, hence of no-use | 11:00 |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 250 seconds] | 11:00 | |
| kang_ | Infact, if both are new, rather 2 channels are required, which is actually worse | 11:01 |
| kanzure | i don't think that the protocol requires address reuse | 11:02 |
| kanzure | additionally, the final payments- however they hit the network- are not necessarily going to be using your utxos anyway. if you are worried about intermediate identification when doing payment routing, then use onion routing. | 11:03 |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards | 11:05 | |
| kang_ | Can you direct me somewhere achieving path finding and channel chain setup 'without' address reuse, please? Cause i can't imagine how it can be done | 11:05 |
| Taek | when you set up a set of payment channels,the public information is: 1. between who (at least, at the address level), and 2. which direction the money flows when the channel closes | 11:05 |
| Taek | but if you combine them with CT, you can eliminate the information revealed about how full the channel is | 11:06 |
| Taek | (sorry that was a separate thought not answering a question) | 11:06 |
| kang_ | Exactly, 'bitcoin address' is the token that identifies the nodes in an LN. If the token changes, a new channel with the existing network would be required | 11:07 |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] | 11:10 | |
| kanzure | i don't think that node identification needs to use bitcoin addresses | 11:11 |
| -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Quit: Konversation terminated!] | 11:12 | |
| -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 11:12 | |
| kang_ | In any kind of a network, there has to be some identifier identifying every node as part of it | 11:13 |
| -!- adam3us [~Adium@88-105-23-239.dynamic.dsl.as9105.com] has joined #bitcoin-wizards | 11:14 | |
| CodeShark | it would be terribly unwise to couple transaction authorization too strongly with identity | 11:18 |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [Remote host closed the connection] | 11:18 | |
| CodeShark | identity could be managed via another crypto layer | 11:19 |
| CodeShark | i.e. cryptographically generated routable addresses a la cjdns | 11:19 |
| CodeShark | the keys used to sign contracts should be an entirely separate layer | 11:20 |
| CodeShark | giving you the ability to easily rotate them, revoke them, etc... | 11:21 |
| CodeShark | without having to touch the identity layer | 11:21 |
| kang_ | Even then, for every new party, we need a new connection in the identity layer. And I always want to be a new party | 11:23 |
| -!- hazirafel [~ufoinc@31.154.91.221] has quit [Ping timeout: 264 seconds] | 11:23 | |
| CodeShark | perhaps the onramp will have to involve paying fiat - or getting paid in bitcoin | 11:24 |
| CodeShark | if someone wants to pay you in bitcoin, part of that payment could be put towards setting up a new channel | 11:25 |
| CodeShark | or if you buy bitcoin for fiat, the seller could create a new channel with you | 11:26 |
| -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] | 11:27 | |
| CodeShark | you'd probably need to set up at least two channels if you want to be able to replenish your channels | 11:28 |
| CodeShark | without closing them out | 11:28 |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards | 11:28 | |
| -!- zooko [~user@c-73-14-172-248.hsd1.co.comcast.net] has quit [Remote host closed the connection] | 11:29 | |
| CodeShark | best might be to create several channels with completely random peers as part of the initial setup | 11:29 |
| kang_ | Doesn't sound like utopian to you? | 11:29 |
| CodeShark | where I draw the line is when it becomes economically unrealistic | 11:29 |
| CodeShark | what I've said so far seems very economically realistic because the incentives are therre | 11:30 |
| CodeShark | if we have to rely purely on people doing good favors and acting altruistically, then yes, it's unrealistic | 11:30 |
| -!- zooko [~user@c-73-14-172-248.hsd1.co.comcast.net] has joined #bitcoin-wizards | 11:31 | |
| CodeShark | properly aligned incentives are key | 11:33 |
| kang_ | No even without it. For simplicity imagine there have been only 100 addresses on the blockchain yet with a LN mesh network among themselves & assume people using it stagnates. Now a new address asking for a payment needs a new connection. After a long time all the initial 100 will be replaced by n new addresses with amesh among themselves. Forever needing a new channel setup! | 11:34 |
| kang_ | Simply stating, each new address requires a new channel setup, forever! unless someone wants to reuse identity | 11:35 |
| CodeShark | first of all, "addresses on the blockchain" don't really exist | 11:35 |
| CodeShark | addresses are an application-level abstraction in bitcoin | 11:36 |
| kang_ | Yes, technically. But you get what i mean | 11:36 |
| kang_ | In the LN paper, Alice, Bob etc are addresses | 11:37 |
| CodeShark | the use of the term "address" as in "Bitcoin address" is an unfortunate misnomer that causes a lot of confusion | 11:37 |
| kang_ | replace it with public keys | 11:38 |
| CodeShark | because it really has little to do with things like IP addresses or email addresses (other than wallets making valiant efforts to equate the two when in fact they are very different) | 11:38 |
| kang_ | for simplicty | 11:38 |
| -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 244 seconds] | 11:38 | |
| kanzure | huh it's not clear to me that in the lightning paper whether alice/bob are literal p2pkh addresses- i sort of doubt it | 11:39 |
| CodeShark | most proposals I've seen don't even assume the signing keys used for contracts will ever be reused at all | 11:39 |
| CodeShark | in fact, they might only be used once | 11:39 |
| CodeShark | furthermore, they have nothing to do with message routing | 11:40 |
| kang_ | A "channel" is defined between two addresses. Can you confirm I am wrong about this? | 11:41 |
| CodeShark | where "address" in this sense means something like an IP address? | 11:42 |
| kang_ | It means the bitcoin address exactly | 11:42 |
| kanzure | hmm i guess it would be prudent to go look at what the protobuf definition of channel actually is | 11:42 |
| kanzure | here is open_channel https://github.com/ElementsProject/lightning/blob/17471d0788ba14b83a88c8ef0d4e6b5944f3ae87/lightning.proto#L47 | 11:43 |
| CodeShark | hmm...I guess in rusty's implementation, a channel is identified by a pubkey used in the anchor transaction | 11:43 |
| CodeShark | or not exactly... | 11:44 |
| -!- hazirafel [~ufoinc@31.154.91.2] has joined #bitcoin-wizards | 11:44 | |
| CodeShark | I think if we're going to associate channels with specific objects in the blockchain, they should be associated with the output of an anchor transaction | 11:45 |
| -!- hazirafel [~ufoinc@31.154.91.2] has quit [Read error: Connection reset by peer] | 11:45 | |
| -!- adam3us [~Adium@88-105-23-239.dynamic.dsl.as9105.com] has quit [Quit: Leaving.] | 11:45 | |
| CodeShark | the actual contract underlying that output is opaque to this layer | 11:46 |
| CodeShark | the way the parties are able to spend the output is an entirely separate layer | 11:47 |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 11:50 | |
| CodeShark | kang_: in the 5.9 version of the paper I don't see any mention of "address" referring to Alice and Bob | 11:52 |
| CodeShark | in fact, it recommends the use of HD keys for transaction signing | 11:53 |
| CodeShark | and as I said earlier, the paper does not specify the actual routing protocol at all | 11:53 |
| CodeShark | just the commitment structures | 11:53 |
| CodeShark | the use of the term "address" in the paper pertains to encoding of either p2pkh or p2sh | 11:55 |
| CodeShark | and the p2sh addresses typically involve pubkeys from both parties | 11:55 |
| kang_ | Yes, the paper uses the term parties | 11:57 |
| kang_ | A party could be an address, a wallet, pubkeys whichever else identifier you want to use. | 12:00 |
| kang_ | Do you understand my concern? Or have been unable to show you the problem I see, yet? | 12:01 |
| CodeShark | not really... | 12:02 |
| CodeShark | I replaced the term "address" with "party" in your "For simplicity imagine" paragraph | 12:03 |
| CodeShark | and I still am not sure I get your concern | 12:03 |
| CodeShark | are you talking about having to close and reopen channels? | 12:03 |
| kang_ | A new 'party' entering the system, requires new 'channel' to be setup. Right? | 12:04 |
| CodeShark | yes | 12:04 |
| CodeShark | at least one - preferably more :) | 12:04 |
| gmaxwell | kang_: privacy model in channels network is different (and usually much better) than bitcoin proper. As your key has primarly local significance (between you and the channel endpoint). | 12:05 |
| gmaxwell | The system rusty has been working on is onion routed. | 12:05 |
| kang_ | Privacy I understand, but not scalability | 12:05 |
| -!- hazirafel [~ufoinc@31.154.91.2] has joined #bitcoin-wizards | 12:06 | |
| gmaxwell | I think you are drowning yourself in complexity. :) First you should go understand channel-less cut through transactions: https://bitcointalk.org/index.php?topic=281848.0 | 12:07 |
| kang_ | I do understand | 12:07 |
| gmaxwell | I am doubtful that you loaded that link and read it in under 10 seconds. :) | 12:07 |
| * kanzure lowers his raised hand | 12:08 | |
| kang_ | No I read it yesterday through your reddit comment | 12:08 |
| gmaxwell | OK | 12:08 |
| -!- hazirafel [~ufoinc@31.154.91.2] has quit [Read error: Connection reset by peer] | 12:09 | |
| gmaxwell | So then I do not see the point of your objection. | 12:09 |
| kang_ | My concern is that since each new party needs new channel setups, it is optimistic to assume that each new bitcoin user would need to set this up | 12:09 |
| -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection] | 12:09 | |
| kanzure | one possible objection is somtehing like "intermediate history will never be cuttable, because outputs are never merged" or something.. | 12:10 |
| kanzure | it's a weak objection, because outputs do get merged.. intermediate history can be cut. | 12:10 |
| gmaxwell | kang_: to be a user of bitcoin at all, in any situation, requires a 'channel' of a kind in that you need to be paid bitcoin to begin with. It does not seem 'optimistic' to me to say that the same process instead can be establishing a channel. | 12:11 |
| kang_ | kanzure: About that gmaxwell wrote that he counted them earlier and there weren't many but now expects them to be significant. | 12:11 |
| CodeShark | kang_: first of all, software would take care of this initial setup automatically for new users. secondly, the main concern surrounds the cost of opening up the new channel and who will cover it | 12:11 |
| gmaxwell | kang_: that was because there were not many unconfirmed respends at all (bitcoin core won't make them except as a last resort and only of its own change). | 12:12 |
| kanzure | if payments flow in a circle in a network, you can just cut out the entire circle. | 12:12 |
| CodeShark | the main scalability optimizations are what kanzure just said...and the use of the blockchain ultimately as a last-resort settlement mechanism | 12:13 |
| gmaxwell | The word settlement confuses people. | 12:14 |
| gmaxwell | I've seen this happen over and over again. | 12:14 |
| CodeShark | the blockchain is there to protect you in the event of an uncooperative counterparty | 12:14 |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [Read error: Connection reset by peer] | 12:15 | |
| gmaxwell | A more useful mental model for the system is that the network is a trustworthy AI Judge that makes sure you complied with the contracts specified in your contracts. Now, it's possible to transact by taking every contract to the judge, but this is inefficient. | 12:15 |
| kanzure | you also don't need a literal circle; i believe cut-through is achieved when you have alice pay 1000 bobs and all 1000 bobs pay carl. you don't need to put the bobs into the blockchain if everything is working. | 12:15 |
| CodeShark | right, the blockchain is like a court | 12:15 |
| CodeShark | you don't go to court over every contract you enter | 12:15 |
| CodeShark | only the ones where there's a breach | 12:15 |
| gmaxwell | So what protocols like channels, and coinswap do is set up their contracts so that you can go to court only in the event of a dispute or only for infrequent setup/shutdown. | 12:16 |
| CodeShark | you'd much rather pry the counterparty into cooperation | 12:16 |
| -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has quit [Quit: leaving] | 12:17 | |
| CodeShark | if they continue to refuse to cooperate, then you go to the blockchain | 12:17 |
| gmaxwell | And this is a forseen use of bitcoin since day 0, which is why, for example, we have serial numbers on txins and smart contracts instead of plain digital signatures. | 12:17 |
| kang_ | Every new user needs to sign up with the court, thats the problem | 12:17 |
| -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards | 12:17 | |
| kang_ | But I get your point | 12:17 |
| kanzure | yes it's true that there's a rate limit on the number of new (confirmed) utxos that can be created | 12:17 |
| gmaxwell | kang_: Why is it a problem? Yes there is still capacity used... but then its proportional to new users rather than economic activity, and so it is enormously lower in volume. | 12:18 |
| kang_ | Because new users are indistinguishable. I prefer to appear a new user everytime | 12:19 |
| gmaxwell | (there are way to actually even prevent enrollment, as kanzure notes about circles, but thats an edge case) | 12:19 |
| kanzure | oh that prevents enrollment? | 12:20 |
| gmaxwell | kang_: Thats where I commented on privacy above. With LN privacy and fungibility is achieved a different way, using onion routing and local significance. It's looks like it will be much more effective than pseudonymous addresses. | 12:20 |
| gmaxwell | kanzure: it could, if you had an unenrolled user and can determine the funds would only move in a circle, you could avoid enrolling. | 12:21 |
| gmaxwell | (or even not in a circule, if you determine the funds would just go enrolled->unenrolled->enrolled you can just cut out the unentrolled hop) | 12:21 |
| gmaxwell | but I think it's not really an interesting case. | 12:22 |
| kanzure | i was assuming enrolled intermediates- i mean just normal use of lightning causes these intermediates to not require confirmation in the blockchain. unenrolled case prolly loses some trustless properties or something- unless you're just asking them where they want to spend their money on their behalf or something. | 12:22 |
| kanzure | yeah ok | 12:23 |
| kanzure | i think cost of channel liquidity naturally causes each node to attempt abbreviation of transaction history through net re-balancing, it would be interesting to find whether such a local search method could find optimal rebalancing (e.g. be conservative and assume at some point everything will be dumped to blockchain; in the mean time you can rebalance and try to make the dump minimally painful, but can local nodes do that, or could ... | 12:24 |
| gmaxwell | kanzure: any unentrolled party in that example is always dealing with unconfirmed txn. Like someone wants to pay you and they give you a transaction that would create a channel to do so (because you're unenrolled); but you hold onto it a bit instead (unconfirmed) and see if perhaps you're going to pay the whole value out to enrolled parties. And if so and if the penultimate hop is still online, | 12:24 |
| kanzure | ... only something with access to the full graph/payments data for the whole lightning network?) | 12:24 |
| gmaxwell | you can go cut out the enrollment. | 12:24 |
| gmaxwell | But I think this is not so interesting, I'm just being pedantic. | 12:24 |
| kang_ | LN is then a mesh network between all parties using bitcoin ever | 12:25 |
| CodeShark | gmaxwell: what's a better term to use rather than "settlement"? | 12:25 |
| kanzure | "breach remedy" | 12:26 |
| CodeShark | it's the term used both in finance and in law...but I guess breach remedy is more specific | 12:26 |
| -!- zooko [~user@c-73-14-172-248.hsd1.co.comcast.net] has quit [Ping timeout: 268 seconds] | 12:26 | |
| CodeShark | or less ambiguous, at any rate | 12:26 |
| -!- ielo [~ielo@2601:643:8001:d531:48:48d5:a078:dd39] has joined #bitcoin-wizards | 12:26 | |
| CodeShark | but it sounds awkward :p | 12:27 |
| kang_ | My original concern was this, "Case 1: Sidechain has less network hashrate -> my coins are not secure, so i won't peg to it. Case 2: Sidechain has equal hashrate to btc -> sidechain scavenges btc's hashrate which is overall not less secure 'only if' that sidechain is 'exclusive' to btc" | 12:27 |
| gmaxwell | kang_: and continuing my comment above, even with that you're still free to open many new channels... with the obvious cost of doing so, though there should be little to no need to even for good privacy/fungibility. But you could. Would people? Well in bitcoin not reusing addresses is free and reusing addresses is utterly destructive to privacy, and yet most txn are involved in address reuse. | 12:27 |
| CodeShark | "the blockchain provides well-defined breach remedy guarantees" :) | 12:27 |
| CodeShark | what about Case 3: Sidechain is merge-mined with btc :) | 12:28 |
| kanzure | hashrate is not enough to know whether a chain is "secure" | 12:28 |
| kang_ | kanzure: total history of hashrates | 12:28 |
| jtimon | kanzure any hasrate is "secure enough" if you are willing to wait enough blocks for confirmations, no? | 12:29 |
| CodeShark | gmaxwell: that is not 100% true although close - not reusing addresses involves slightly greater overhead in key management | 12:29 |
| CodeShark | and a more-than-insignificant complication in implementation | 12:30 |
| kanzure | jtimon: security is a much broader perspective; you can have insanely high hashrates, but also have a mining cartel that commits fraud... now what? | 12:30 |
| jtimon | and by any hashrate I mean any reward (subsidy + fees) | 12:30 |
| kang_ | CodeShark: Case 3 is same as 2 because merged mining means being exclusive to a blockchain | 12:30 |
| -!- ielo [~ielo@2601:643:8001:d531:48:48d5:a078:dd39] has left #bitcoin-wizards [] | 12:30 | |
| jtimon | kanzure: sure, I mean, for any definition of "secure enough" | 12:30 |
| jtimon | kanzure: the attack costs grow exponentially with the number of block confirmations, don't they? | 12:31 |
| jtimon | that's what I got from the whitepaper | 12:32 |
| kang_ | gmaxwell: My LN scalability doubts are resolved thanks. But they arose from me being redirected to LN from a doubt I asked about sidechains, mentioned above. | 12:32 |
| kanzure | jtimon: yes yes, that's all accurate, but i think kang_ is asking about something else | 12:33 |
| gmaxwell | Case 1: does that mean you stoped using bitcoin entirely the first moment the hashrate went down? :) | 12:33 |
| kanzure | "i won't peg to it"- it's not up to you; you can choose whether you want to receive utxos on that sidechain, but the peg exists independent of your decision | 12:33 |
| kang_ | gmaxwell: If it goes below say litecoin, people would definitely switch over | 12:34 |
| CodeShark | sometimes I wish we had something like BIP30 for scriptPubKeys :) | 12:34 |
| dgenr8 | kang_: so to your question of how to receive N payments without handing out the same identifier N times, you are satisfied with the answer "not that many people will see your identifier"? | 12:34 |
| kanzure | kang_: what exactly are you comparing with litecoin? | 12:34 |
| kang_ | kanzure: "BTC has hashrate x, sidechain has y (y<x), so rather than using y, I'd use some z where (x>z>y) even if that means exchainging my coins cause it is no difference to value I am holding" | 12:35 |
| gmaxwell | kang_: these things are completely incompariable. | 12:35 |
| jtimon | kang_: not necesarily if all the merchants in my neighbourhood accept btc (but not ltc) but they switch from 6 to 10 confirmations, I will probably keep using btc or eur instead of ltc | 12:36 |
| gmaxwell | Right now btc mining might even be using less power than ltc mining, and yet no one cares. | 12:36 |
| gmaxwell | (there was a period before ltc mining moved to all asics where it probably was using more power than bitcoin mining) | 12:36 |
| -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection] | 12:36 | |
| kang_ | Surprising news to me! If so my questions are settled. | 12:37 |
| jtimon | gmaxwell: the gpu-ltc times (supossedly imporssible accoring to LTC's initial announcement) | 12:37 |
| gmaxwell | lol | 12:37 |
| gmaxwell | Indeed. | 12:37 |
| kanzure | concern about hashrate should be trumped by concerns about difficulty adjustments- if there's a difficulty gap, it might take a while to trigger the difficulty adjustment sufficiently downward. | 12:38 |
| CodeShark | the irony is that the supposed strengths of scrypt over sha256 can't even be used in this context | 12:38 |
| CodeShark | so they are entirely irrelevant | 12:38 |
| kanzure | and your utxos wont be movable during that readjustment period | 12:38 |
| kanzure | well, probably wont be movable | 12:38 |
| gmaxwell | anyone know if there is a git setting to change the date format string? | 12:38 |
| kanzure | GIT_COMMIT_DATE | 12:38 |
| kang_ | dgenr8: I am satisfied with the answer that a new user recieving btc needs a transaction on the blockchain which can be replaced by a channel setup transaction instead | 12:39 |
| kanzure | oops | 12:39 |
| kanzure | GIT_COMMITTER_DATE GIT_AUTHOR_DATE | 12:39 |
| kanzure | nope i was right the first time. damn. | 12:39 |
| jcorgan | i think those can be set in the environment | 12:39 |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 12:40 | |
| kang_ | Many people would be surprised! Is this calculated somewhere? BTC power used vs LTC power consumption? | 12:40 |
| -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards | 12:40 | |
| CodeShark | you can estimate the hash rates and then grab a napkin :) | 12:40 |
| gmaxwell | kang_: I'm not aware of anywhere that does that! (and the paces that of charted BTC have done stupid stuff like assuming GPU usage long after thta was gone) | 12:40 |
| CodeShark | each scrypt hash consumes more energy than each sha256 hash - so you need to account for that factor | 12:40 |
| gmaxwell | kang_: which is part of why I was saying that no one cares. :( | 12:41 |
| jtimon | unrelated: I'm thinking about writing a chain ID BIP: am I too crazy when I say "who cares about FTC for not having their own unique genesis block, they will have to use their second block as the genesis block, no big deal" Luke-Jr seems to disagree | 12:41 |
| dgenr8 | kang_: a new channel does require a blockchain tx. otherwise the whole thing can be double spent | 12:41 |
| -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has left #bitcoin-wizards [] | 12:42 | |
| kang_ | dgenr8: Yes , but the net broadcasted count is better over time so .. | 12:42 |
| * jtimon thows the rock and hides the hand: afk | 12:42 | |
| kang_ | Is Peter Todd's calculation of >30% the counterargument to IBLT? | 12:45 |
| kang_ | Are there any other counterarguments to IBLT? | 12:46 |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards | 12:52 | |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [Ping timeout: 260 seconds] | 12:57 | |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] | 12:58 | |
| kang_ | gmaxwell: I had independently thought of transaction cut-through. You rember I asked here a few weeks ago whether there exists a non-blockchain algo to assign ownership of a private key to another party? | 12:59 |
| kang_ | I have a proposal to actually reduce the blocksize, butit could be faulty hence asking about problems with IBLT proposal | 13:00 |
| -!- nwilcox [~nwilcox@24.130.26.146] has joined #bitcoin-wizards | 13:03 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 255 seconds] | 13:14 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 13:23 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 13:25 | |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards | 13:30 | |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [Remote host closed the connection] | 13:31 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 13:35 | |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 13:37 | |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards | 13:38 | |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 255 seconds] | 13:39 | |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [Remote host closed the connection] | 13:40 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 265 seconds] | 13:40 | |
| -!- zooko [~user@2601:281:8301:e87f:c1ad:cbbb:a9a5:854e] has joined #bitcoin-wizards | 13:45 | |
| -!- zooko [~user@2601:281:8301:e87f:c1ad:cbbb:a9a5:854e] has quit [Remote host closed the connection] | 13:47 | |
| -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 264 seconds] | 13:50 | |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 13:53 | |
| -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-tdrnnewhwhlfisnc] has joined #bitcoin-wizards | 14:03 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] | 14:04 | |
| -!- GGuyZ [~GGuyZ@50.247.238.161] has joined #bitcoin-wizards | 14:09 | |
| -!- ebfull [~ebfull@73.34.119.0] has quit [Quit: cya] | 14:26 | |
| -!- ebfull [~ebfull@73.34.119.0] has joined #bitcoin-wizards | 14:26 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 14:31 | |
| -!- GGuyZ [~GGuyZ@50.247.238.161] has quit [Quit: GGuyZ] | 14:37 | |
| -!- kang_ [67efe936@gateway/web/freenode/ip.103.239.233.54] has quit [Quit: Page closed] | 14:38 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] | 14:39 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 14:41 | |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards | 14:44 | |
| -!- nwilcox [~nwilcox@24.130.26.146] has quit [Ping timeout: 255 seconds] | 14:51 | |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [Remote host closed the connection] | 14:55 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 14:55 | |
| -!- samson_ [~samson_@unaffiliated/samson-/x-7479750] has joined #bitcoin-wizards | 14:56 | |
| -!- twoone [~twoone@99-48-172-67.lightspeed.brhmmi.sbcglobal.net] has joined #bitcoin-wizards | 15:00 | |
| -!- warptangent [~warptan@unaffiliated/warptangent] has quit [Read error: Connection reset by peer] | 15:18 | |
| -!- warptangent [~warptan@unaffiliated/warptangent] has joined #bitcoin-wizards | 15:20 | |
| -!- sausage_factory [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 15:20 | |
| -!- blackwraith [~priidu@unaffiliated/priidu] has quit [Ping timeout: 250 seconds] | 15:21 | |
| -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 15:32 | |
| -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards | 15:34 | |
| -!- nwilcox_ [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 15:35 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Ping timeout: 244 seconds] | 15:35 | |
| -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] | 15:39 | |
| -!- nwilcox_ [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has quit [Quit: leaving] | 15:41 | |
| -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has quit [Quit: leaving] | 15:41 | |
| -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 15:42 | |
| -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards | 15:45 | |
| -!- maaku is now known as Guest16294 | 15:45 | |
| -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards | 15:45 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 15:48 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 15:59 | |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has joined #bitcoin-wizards | 16:05 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 16:12 | |
| -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has quit [Ping timeout: 246 seconds] | 16:15 | |
| -!- arubi [~ese168@unaffiliated/arubi] has quit [Quit: Leaving] | 16:15 | |
| -!- samson_ [~samson_@unaffiliated/samson-/x-7479750] has quit [Ping timeout: 244 seconds] | 16:20 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 16:26 | |
| -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards | 16:32 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 16:32 | |
| -!- sausage_factory [~priidu@unaffiliated/priidu] has quit [Ping timeout: 256 seconds] | 16:34 | |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 16:37 | |
| -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards | 16:42 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 244 seconds] | 16:49 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 252 seconds] | 16:51 | |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 16:55 | |
| -!- JayDugger1 [~jwdugger@108.19.186.58] has joined #bitcoin-wizards | 17:04 | |
| -!- JayDugger [~jwdugger@108.19.186.58] has quit [Ping timeout: 250 seconds] | 17:06 | |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Ping timeout: 264 seconds] | 17:25 | |
| -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards | 17:28 | |
| -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 255 seconds] | 17:30 | |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds] | 17:32 | |
| -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has quit [Quit: leaving] | 17:33 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards | 17:35 | |
| -!- roxtrongo [~roxtrongo@190-22-139-129.baf.movistar.cl] has quit [] | 17:36 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 246 seconds] | 17:40 | |
| -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has quit [Ping timeout: 260 seconds] | 17:41 | |
| -!- ne1l [~dnv@ip1f126621.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 17:43 | |
| -!- kmels [~kmels@184.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards | 17:45 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 17:48 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 260 seconds] | 18:01 | |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] | 18:03 | |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 18:03 | |
| -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds] | 18:06 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 18:14 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 244 seconds] | 18:30 | |
| -!- twoone [~twoone@99-48-172-67.lightspeed.brhmmi.sbcglobal.net] has quit [] | 18:30 | |
| -!- ne1l [~dnv@ip1f126621.dynamic.kabel-deutschland.de] has quit [Quit: Ex-Chat] | 18:35 | |
| -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Read error: Connection reset by peer] | 18:35 | |
| -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards | 18:36 | |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nyydjfoklttsjwvt] has quit [Quit: Connection closed for inactivity] | 18:40 | |
| -!- not_underground [~chatzilla@node-af9.pool-101-51.dynamic.totbb.net] has joined #bitcoin-wizards | 18:41 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] | 18:50 | |
| -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards | 18:52 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards | 19:02 | |
| -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [] | 19:05 | |
| -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined #bitcoin-wizards | 19:07 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards | 19:30 | |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] | 19:30 | |
| -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-tdrnnewhwhlfisnc] has quit [Quit: Connection closed for inactivity] | 19:42 | |
| -!- kang_ [67efe936@gateway/web/freenode/ip.103.239.233.54] has joined #bitcoin-wizards | 19:53 | |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 20:05 | |
| -!- JayDugger1 [~jwdugger@108.19.186.58] has left #bitcoin-wizards [] | 20:11 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services] | 20:12 | |
| -!- [7] [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 20:12 | |
| -!- Guest16294 [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] | 20:15 | |
| -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] | 20:24 | |
| -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards | 20:26 | |
| -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards | 20:26 | |
| -!- maaku is now known as Guest82907 | 20:27 | |
| -!- davispuh [~quassel@212.93.100.199] has quit [Read error: Connection reset by peer] | 20:41 | |
| -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has joined #bitcoin-wizards | 20:43 | |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] | 20:46 | |
| -!- snthsnth [~snthsnth@c-98-207-208-241.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 20:48 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 21:01 | |
| -!- realcr [~real@bzq-79-178-30-92.red.bezeqint.net] has quit [Quit: WeeChat 0.4.2] | 21:16 | |
| -!- GGuyZ_ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 21:20 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Ping timeout: 250 seconds] | 21:21 | |
| -!- GGuyZ_ is now known as GGuyZ | 21:21 | |
| -!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards | 21:30 | |
| -!- GGuyZ [~GGuyZ@216-15-123-91.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] | 21:39 | |
| -!- alferz [~alferz@unaffiliated/alfer] has quit [Ping timeout: 244 seconds] | 21:43 | |
| -!- Giszmo [~leo@pc-185-201-214-201.cm.vtr.net] has quit [Quit: Leaving.] | 21:43 | |
| -!- GGuyZ [~GGuyZ@216.15.123.91] has joined #bitcoin-wizards | 21:47 | |
| -!- cryptowest [~cryptowes@2604:a880:800:10::81f:3001] has quit [K-Lined] | 21:56 | |
| -!- cryptowest [~cryptowes@2604:a880:800:10::81f:3001] has joined #bitcoin-wizards | 21:57 | |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] | 22:03 | |
| -!- c0rw1n is now known as greenBat | 22:11 | |
| -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds] | 22:13 | |
| -!- greenBat is now known as c0rw1n | 22:13 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 244 seconds] | 22:14 | |
| -!- c0rw1n is now known as c0rw|zZz | 22:14 | |
| -!- drwin [~drwin@out-nat-33.jes.cz] has quit [Read error: No route to host] | 22:15 | |
| -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has quit [Quit: b_lumenkraft] | 22:15 | |
| -!- drwin [~drwin@out-nat-33.jes.cz] has joined #bitcoin-wizards | 22:16 | |
| -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 22:25 | |
| phantomcircuit | kang_, IBLT requires synchronized mempools | 22:27 |
| phantomcircuit | which is generally a bad thing | 22:27 |
| -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has joined #bitcoin-wizards | 22:37 | |
| -!- GGuyZ [~GGuyZ@216.15.123.91] has quit [Ping timeout: 272 seconds] | 22:44 | |
| -!- roxtrongo [~roxtrongo@190.22.139.129] has joined #bitcoin-wizards | 22:55 | |
| -!- go1111111 [~go1111111@104.200.154.15] has quit [Ping timeout: 265 seconds] | 22:57 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 23:00 | |
| -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has quit [Quit: b_lumenkraft] | 23:03 | |
| -!- go1111111 [~go1111111@162.244.138.37] has joined #bitcoin-wizards | 23:22 | |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 23:25 | |
| -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has joined #bitcoin-wizards | 23:30 | |
| --- Log closed Sun Sep 06 00:00:02 2015 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!