#bitcoin-wizards on 2015-09-05 — irc logs at freenode.irclog.whitequark.org

2015-06-27 08:24 wumpus changed the topic of #bitcoin-wizards to: This channel is is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja

00:05 GAit has quit [Quit: Leaving.]

00:06 dhaK has joined #bitcoin-wizards

00:06 nullbyte has quit [Ping timeout: 264 seconds]

00:08 sausage_factory has joined #bitcoin-wizards

00:09 blackwraith has quit [Ping timeout: 240 seconds]

00:10 <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

00:11 <gmaxwell> I think I saw a presentation with a Schrödinger CRC.

00:12 GAit has joined #bitcoin-wizards

00:12 GAit has quit [Client Quit]

00:13 <kanzure> the nasa system fault tolerance stuff slide deck?

00:14 AaronvanW has quit [Ping timeout: 246 seconds]

00:14 chris13243 has quit [Ping timeout: 250 seconds]

00:15 <midnightmagic> I've had a storage bitflip on an ECC-ram machine

00:16 <gmaxwell> I don't agree with the WP article, FWIW.

00:16 <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.

00:17 <gmaxwell> An example was a part that was transparently replacing the CRC on messages that came in, without verifying the inbound CRC.

00:17 <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.

00:18 <gmaxwell> had the system been using a MAC the design just wouldn't have worked.

00:27 <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

00:27 <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

00:27 <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.)

00:29 <gmaxwell> sounds great, just give me 4x overhead to play with. :P

00:29 <midnightmagic> :-) I've got a machine here you can monkey around on if you want.

00:29 <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

00:29 <gmaxwell> We do internally redundant computation for some things in bitcoin core. :)

00:30 <gmaxwell> jgarzik: Luke-Jr did this for bitcoin2013 and I believe I heard someone mentioning doing it for scaling bitcoin.

00:30 <Taek> jgarzik: I had a dream last night where all 5 people with commit access were murdered

00:30 <gmaxwell> perhaps I'll do that as well. I have a whole stack of burner laptops. :)

00:31 <gmaxwell> hm but they don't have batteries.

00:31 <midnightmagic> I have burner desktops! And car batteries!

00:31 <gmaxwell> plus if someone tries to attack you, you can throw battery acid at them. What could go wrong?

00:32 <gmaxwell> you can get old x61 laptops for almost free, though usually not with working batteries.

00:33 <midnightmagic> rolled a 1, critical fumble, arggghhh

00:34 <jgarzik> rofl I have way too many burner desktops

00:36 <kanzure> i would be far far more interested in capturing whatever malware people try to release

00:37 <phantomcircuit> midnightmagic, iirc lots of people have realized that their automated bug reporting stuff should include a hardware testing suite

00:37 <phantomcircuit> apparently reduces the volume of bug reports significantly

00:38 <phantomcircuit> it would be nice if there was a kernel level memory tester that ran in the background slowly

00:38 * phantomcircuit looks around for rusty

00:38 <kanzure> you can make jgarzik do it

00:39 <midnightmagic> "Installation of Bitcoin requires a kernel module to be loaded at boot-time.."

00:44 <Luke-Jr> gmaxwell: I did? O.o

00:44 <kanzure> gmaxwell: re: that wikipedia article about byzantine generals' problems,

00:45 <kanzure> seems that iang wrote up some reasonable criticism here http://financialcryptography.com/mt/archives/001522.html

00:45 <kanzure> not sure if that was the origin of "dynamic membership set" stuff

00:45 <gmaxwell> Luke-Jr: I thought you did!

00:46 <Luke-Jr> gmaxwell: I just never trust mobile stuff period.

00:46 <gmaxwell> kanzure: no, other way around.

00:46 <Luke-Jr> my laptop is essentially no more than a SSH+VNC thinclient

00:46 <gmaxwell> Luke-Jr: I thought you had a seperate new netbook.

00:47 <Luke-Jr> oh, that exists. but I almost never use it.

00:48 <kanzure> ok

00:48 <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

00:48 <Luke-Jr> although the last year, I've found VNC is a pain due to my DSL upload :/

00:48 <kanzure> we should plant someone with really obvious malware and then have a game to find the plant

00:49 kmels has quit [Ping timeout: 246 seconds]

00:49 <kanzure> (no we shouldn't)

00:50 chris13243 has joined #bitcoin-wizards

00:51 <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.

00:52 <phantomcircuit> gmaxwell, i brought a burner laptop/cellphone to defcon

00:52 <phantomcircuit> didn't have a burner sim though

00:52 <phantomcircuit> possibly there's malware on it

00:55 <gmaxwell> I am continually frustrated that no machine learning software flaw detector exists.

00:56 <ryan-c> I reuse my burner sim between DEFCONs

00:56 <ryan-c> (and i have a burner phone)

00:59 <ryan-c> I'm pretty sure malware on SIM is possible.

01:01 <phantomcircuit> ryan-c, it definitely is but iirc you need to have the keys for the sim to load anything onto them

01:01 <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.

01:01 <phantomcircuit> but being defcon probably someone there has stolen those

01:03 <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

01:03 <phantomcircuit> ryan-c, blackhat you might actually get in trouble for it

01:04 <ryan-c> phantomcircuit: yes, true

01:04 <phantomcircuit> rsa they'd call the fbi

01:04 <phantomcircuit> ... over from the other table

01:04 <ryan-c> also true

01:04 <ryan-c> depends on goals

01:04 <ryan-c> goals at defcon are much more likely to be merely trolling

01:05 arubi has quit [Ping timeout: 246 seconds]

01:05 <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

01:06 <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)

01:09 <ryan-c> Luke-Jr: I become a fan of "laptop is a thin client and browser" model.

01:09 <ryan-c> do you use mosh?

01:09 <gmaxwell> mosh <3

01:10 <gmaxwell> if you do not use mosh, stop what you are doing and install.

01:10 <ryan-c> haha

01:10 <ryan-c> so true

01:10 <Luke-Jr> I think I installed mosh, but never use it

01:10 <bsm117532> +1 on mosh

01:10 <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.

01:10 <ryan-c> before mosh, i did hacky shit with airhook http://airhook.ofb.net/

01:10 <Luke-Jr> roaming sounds like a bad feature in this case :P

01:10 <ryan-c> hahah

01:11 <gmaxwell> 0_o

01:11 <gmaxwell> ryan-c: if you ever still use it, it has a realloc misuse bug I've been carrying patches for years for.. :)

01:11 <kanzure> telepaths are the worst

01:11 maraoz has quit [Quit: Leaving]

01:11 <ryan-c> gmaxwell: I do not still use it. Is that why it very occasionally corrupted ssh packets?

01:12 <gmaxwell> ryan-c: yes, likely!

01:12 <ryan-c> iirc that would cause my ssh sessions to die once every couple of weeks

01:12 <Luke-Jr> my SSH connections die fairly often over T-Mobile :/

01:12 <ryan-c> oh, google authenticator for pam is pretty great too

01:13 <ryan-c> Luke-Jr: mosh will fix that for you

01:13 <gmaxwell> lots of cell networks corrupt ssh and ssh doesn't tolerate.. mosh does.

01:13 <gmaxwell> and mosh is usable across a 1 second ping with 30% packet loss.

01:13 <gmaxwell> (so was airhook)

01:13 <kanzure> what about temporary sim card resellers in the area?

01:13 <ryan-c> i use mosh on tmobile during my bart commute pretty much every day

01:13 <Luke-Jr> kanzure: let me know if you find any

01:13 <kanzure> uh thanks

01:14 <Luke-Jr> :P

01:14 <kanzure> oh.

01:14 <ryan-c> mosh (and airhook) also handle "network went away for several days"

01:14 <Luke-Jr> I prefer if my SSH connection dies if I might have disappeared..

01:14 <ryan-c> and "ip address of client changed"

01:14 <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.

01:15 <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.

01:15 <ryan-c> gmaxwell: lol

01:15 <gmaxwell> And yes, webapps just do not work with 1 second ping times and 30% packet loss. :)

01:15 <kanzure> what does mosh really have over ssh + tmux

01:15 <Luke-Jr> kanzure: what gmaxwell just said? :P

01:16 * kanzure looks at https://mosh.mit.edu/

01:16 <ryan-c> kanzure: predictive local echo

01:16 <kanzure> ssh + tmux handles that situation just fine

01:16 <Luke-Jr> kanzure: no

01:16 <kanzure> does for me?

01:16 <ryan-c> kanzure: tolerates 90% packet loss

01:16 <kanzure> haven't measured packet loss though

01:16 <Luke-Jr> kanzure: SSH gets really bad if there's significant packet loss

01:16 <Luke-Jr> since it's TCPO

01:16 mrhodl has joined #bitcoin-wizards

01:16 <Luke-Jr> TCP*

01:17 <ryan-c> kanzure: basically it compensates for all the terribleness of cell networks

01:17 <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

01:17 <gmaxwell> I think the predictive local echo is ... kinda boring.

01:17 <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.

01:17 <ryan-c> gmaxwell: I really like it hiding the latency.

01:18 <Luke-Jr> I wish someone did a network transparency layer for Qt with mosh-like semantics :P

01:18 <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.

01:18 <ryan-c> color?

01:19 <ryan-c> it does underlines for me

01:19 <kanzure> reading what you write directly violates "don't repeat yourself", it's good to have principles

01:19 <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.

01:19 <Luke-Jr> gmaxwell: that's why I want the network layer inside Qt: send text and widget types

01:19 <gmaxwell> ryan-c: or that, I'm on a low latency connection right now so I can't see it.

01:20 <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

01:20 <kanzure> eh cursor prediction is easy

01:20 <kanzure> it's a seventh or eighth sense

01:21 <gmaxwell> ryan-c: this is what counting and ctrl-<arrows> is for. :)

01:22 <ryan-c> gmaxwell: probably

01:22 <ryan-c> i'm pretty sure you're the only other person i've talked to who's used airhook

01:23 <gmaxwell> well, there are several production systems out there that I created that use it.

01:23 <gmaxwell> Including a fax <> sat gateway thing with lots of oil rigs that use it.

01:23 <ryan-c> i gotta take off, meeting some friends for dinner

01:24 <gmaxwell> but yea, I'm not sure I've ever encountered someone I didn't introduct to it that knew about it.

01:24 <ryan-c> oh, yeah, it'd be fantastic for satellite comms

01:24 <gmaxwell> I've been using it since like ... CDPD days.

01:26 chris13243 has quit [Ping timeout: 255 seconds]

01:37 ASTP001 has joined #bitcoin-wizards

01:39 Dr-G has joined #bitcoin-wizards

01:39 King_Rex has quit [Remote host closed the connection]

01:40 Yoghur114 has quit [Remote host closed the connection]

01:41 ASTP001 has quit [Ping timeout: 264 seconds]

01:42 Dr-G2 has quit [Ping timeout: 272 seconds]

01:50 Newyorkadam has joined #bitcoin-wizards

01:54 Ylbam has quit [Quit: Connection closed for inactivity]

02:27 chris13243 has joined #bitcoin-wizards

02:28 veleiro has joined #bitcoin-wizards

02:31 snthsnth has quit [Ping timeout: 272 seconds]

02:41 ajweiss has quit [Quit: leaving]

02:42 sausage_factory has quit [Ping timeout: 240 seconds]

02:51 davispuh has quit [Read error: Connection reset by peer]

02:57 belcher has quit [Quit: Leaving]

02:58 chris13243 has quit [Ping timeout: 256 seconds]

03:03 fkhan has quit [Ping timeout: 246 seconds]

03:04 mrhodl has quit []

03:14 moa has quit [Quit: Leaving.]

03:15 GGuyZ has joined #bitcoin-wizards

03:16 [7] has quit [Disconnected by services]

03:16 TheSeven has joined #bitcoin-wizards

03:20 hazirafel has joined #bitcoin-wizards

03:24 adam3us has quit [Quit: Leaving.]

03:27 fkhan has joined #bitcoin-wizards

03:28 superobserver has quit [Ping timeout: 246 seconds]

03:29 robbak has quit [Quit: Konversation terminated!]

03:31 superobserver has joined #bitcoin-wizards

03:35 hazirafel has quit [Ping timeout: 264 seconds]

03:39 p15 has joined #bitcoin-wizards

03:41 kang_ has joined #bitcoin-wizards

03:46 CodeShark has quit [Ping timeout: 260 seconds]

03:49 GGuyZ has quit [Quit: GGuyZ]

03:51 dEBRUYNE_ has joined #bitcoin-wizards

03:53 GGuyZ has joined #bitcoin-wizards

03:53 chris13243 has joined #bitcoin-wizards

03:54 chris13243 has quit [Read error: Connection reset by peer]

03:54 adam3us has joined #bitcoin-wizards

03:55 c-cex-yuriy has quit [Quit: Connection closed for inactivity]

03:57 adam3us has quit [Client Quit]

03:59 adam3us has joined #bitcoin-wizards

03:59 dEBRUYNE_ has quit [Ping timeout: 265 seconds]

04:11 adam3us has quit [Quit: Leaving.]

04:20 ThomasV has joined #bitcoin-wizards

04:31 GGuyZ_ has joined #bitcoin-wizards

04:31 GGuyZ has quit [Read error: Connection reset by peer]

04:31 GGuyZ_ is now known as GGuyZ

04:32 GGuyZ_ has joined #bitcoin-wizards

04:32 GGuyZ has quit [Read error: Connection reset by peer]

04:32 GGuyZ_ is now known as GGuyZ

04:43 bedeho has joined #bitcoin-wizards

04:43 GGuyZ has quit [Read error: Connection reset by peer]

04:44 frankenmint has joined #bitcoin-wizards

04:45 GGuyZ has joined #bitcoin-wizards

04:50 GGuyZ has quit [Quit: GGuyZ]

05:07 p15 has quit [Ping timeout: 268 seconds]

05:09 adam3us has joined #bitcoin-wizards

05:10 adam3us has quit [Client Quit]

05:25 jtimon has quit [Ping timeout: 256 seconds]

05:51 Hunger-- has joined #bitcoin-wizards

05:54 fkhan has quit [Ping timeout: 244 seconds]

05:55 p15 has joined #bitcoin-wizards

05:55 fkhan has joined #bitcoin-wizards

05:55 fkhan has quit [Changing host]

05:55 fkhan has joined #bitcoin-wizards

05:56 Hunger-- has quit [Ping timeout: 240 seconds]

06:04 ThomasV has quit [Ping timeout: 272 seconds]

06:10 veleiro has quit [Ping timeout: 265 seconds]

06:11 veleiro has joined #bitcoin-wizards

06:13 dhaK is now known as dhafk

06:24 Tiraspol has quit [Read error: Connection reset by peer]

06:24 Tiraspol has joined #bitcoin-wizards

06:26 Newyorkadam has quit [Quit: Newyorkadam]

06:29 Newyorkadam has joined #bitcoin-wizards

06:29 kmels has joined #bitcoin-wizards

06:41 ThomasV has joined #bitcoin-wizards

06:42 Newyorkadam has quit [Quit: Newyorkadam]

06:43 Newyorkadam has joined #bitcoin-wizards

06:50 priidu has joined #bitcoin-wizards

06:51 Newyorkadam has quit [Quit: Newyorkadam]

06:52 Newyorkadam has joined #bitcoin-wizards

06:56 Hunger-- has joined #bitcoin-wizards

07:04 Newyorkadam has quit [Quit: Newyorkadam]

07:25 snthsnth has joined #bitcoin-wizards

07:27 kmels has quit [Ping timeout: 246 seconds]

07:54 dEBRUYNE_ has joined #bitcoin-wizards

08:02 dEBRUYNE_ has quit [Ping timeout: 246 seconds]

08:06 AlphaTech has joined #bitcoin-wizards

08:09 <wumpus> Luke-Jr: xpra does a pretty good job as a better network transparency layer for X, and sessions are re-attachable too

08:10 Ylbam has joined #bitcoin-wizards

08:17 p15 has quit [Max SendQ exceeded]

08:20 Mably has joined #bitcoin-wizards

08:20 mjerr has joined #bitcoin-wizards

08:21 p15 has joined #bitcoin-wizards

08:21 dEBRUYNE_ has joined #bitcoin-wizards

08:26 dEBRUYNE_ has quit [Ping timeout: 255 seconds]

08:32 snthsnth has quit [Ping timeout: 264 seconds]

08:32 dEBRUYNE has joined #bitcoin-wizards

08:41 veleiro has quit [Read error: Connection reset by peer]

08:43 snthsnth has joined #bitcoin-wizards

08:49 GAit has joined #bitcoin-wizards

09:07 snthsnth has quit [Ping timeout: 252 seconds]

09:17 dEBRUYNE has quit [Ping timeout: 244 seconds]

09:18 Quanttek has joined #bitcoin-wizards

09:19 ThomasV has quit [Ping timeout: 246 seconds]

09:28 <heretolearn> mosh has issues with scrolling .. otherwise its nice

09:45 ThomasV has joined #bitcoin-wizards

09:56 binaryFate has quit [Quit: Konversation terminated!]

09:58 priidu has quit [Ping timeout: 265 seconds]

10:05 trippysalmon has joined #bitcoin-wizards

10:17 dEBRUYNE has joined #bitcoin-wizards

10:18 bedeho has quit [Ping timeout: 246 seconds]

10:34 sparetire_ has joined #bitcoin-wizards

10:35 gielbier has quit [Read error: Connection reset by peer]

10:36 gielbier has joined #bitcoin-wizards

10:45 GGuyZ has joined #bitcoin-wizards

10:48 GGuyZ has quit [Read error: Connection reset by peer]

10:48 GGuyZ has joined #bitcoin-wizards

10:49 trippysalmon has quit [Ping timeout: 250 seconds]

10:53 GGuyZ_ has joined #bitcoin-wizards

10:55 GGuyZ has quit [Ping timeout: 260 seconds]

10:55 GGuyZ_ is now known as GGuyZ

11:11 PRab_ has joined #bitcoin-wizards

11:12 kaptah has quit [Ping timeout: 246 seconds]

11:12 kaptah has joined #bitcoin-wizards

11:14 PRab has quit [Ping timeout: 244 seconds]

11:14 PRab_ is now known as PRab

11:15 p15 has quit [Ping timeout: 255 seconds]

11:21 GGuyZ has quit [Ping timeout: 244 seconds]

11:25 GGuyZ has joined #bitcoin-wizards

11:31 rusty has joined #bitcoin-wizards

11:38 dEBRUYNE has quit [Quit: Leaving]

11:48 kang_ has quit [Ping timeout: 246 seconds]

11:51 melvster has quit [Ping timeout: 250 seconds]

11:52 ghtdak has quit [Quit: WeeChat 1.4-dev]

11:52 ghtdak has joined #bitcoin-wizards

11:57 AaronvanW has joined #bitcoin-wizards

11:57 priidu has joined #bitcoin-wizards

12:03 AaronvanW has quit [Remote host closed the connection]

12:04 melvster has joined #bitcoin-wizards

12:12 GGuyZ has quit [Quit: GGuyZ]

12:15 AaronvanW has joined #bitcoin-wizards

12:17 arubi has joined #bitcoin-wizards

12:29 Emcy has quit [Ping timeout: 264 seconds]

12:36 jtimon has joined #bitcoin-wizards

12:38 trippysalmon has joined #bitcoin-wizards

12:39 mjerr has quit [Ping timeout: 260 seconds]

12:44 AaronvanW has quit [Ping timeout: 246 seconds]

12:46 trippysalmon has quit [Read error: Connection reset by peer]

12:53 rusty has left #bitcoin-wizards [#bitcoin-wizards]

12:57 Guyver2 has joined #bitcoin-wizards

12:58 dEBRUYNE has joined #bitcoin-wizards

13:03 dEBRUYNE has quit [Client Quit]

13:06 eudoxia has joined #bitcoin-wizards

13:09 blackwraith has joined #bitcoin-wizards

13:10 priidu has quit [Ping timeout: 250 seconds]

13:23 dEBRUYNE has joined #bitcoin-wizards

13:24 kang_ has joined #bitcoin-wizards

13:26 <kanzure> .title http://samvartaka.github.io/backdoors/2015/09/03/rsa-curve25519-backdoor/

13:26 <yoleaux> Detecting an asymmetric Curve25519 backdoor in RSA key generation algorithms - samvartaka

13:32 dEBRUYNE has quit [Quit: Leaving]

13:34 <nsh> --

13:34 <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

13:34 <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

13:34 <nsh> on part of a third party collecting n public keys generated by a blackbox key generation algorithm.

13:34 <nsh> -- i'm pretty sure you could overcome this with some kind of blinding

13:35 <nsh> or using djb-ish point-repre uniformisation technique

13:36 <nsh> .t https://www.imperialviolet.org/2013/12/25/elligator.html

13:36 <yoleaux> nsh: Sorry, I don't know a timezone by that name.

13:36 <nsh> .title https://www.imperialviolet.org/2013/12/25/elligator.html

13:36 <yoleaux> ImperialViolet - Implementing Elligator for Curve25519

13:36 <nsh> there we go

13:36 <nsh> sneakiness reestablished

13:38 dEBRUYNE has joined #bitcoin-wizards

13:39 blackwraith has quit [Ping timeout: 272 seconds]

13:39 dEBRUYNE has quit [Client Quit]

13:40 afk11 has joined #bitcoin-wizards

13:43 Emcy has joined #bitcoin-wizards

13:45 ThomasV has quit [Ping timeout: 272 seconds]

14:03 eudoxia has quit [Quit: Leaving]

14:05 dEBRUYNE has joined #bitcoin-wizards

14:06 GAit has quit [Quit: Leaving.]

14:08 ThomasV has joined #bitcoin-wizards

14:18 GGuyZ has joined #bitcoin-wizards

14:35 nwilcox has joined #bitcoin-wizards

14:36 Giszmo has joined #bitcoin-wizards

14:40 c-cex-yuriy has joined #bitcoin-wizards

14:49 copumpkin has joined #bitcoin-wizards

14:54 Quanttek has quit [Ping timeout: 252 seconds]

14:57 <kang_> Why is a two-way peg better than atomic swap?

14:58 <Taek> kang_: with an atomic swap you have 2 different currencies

14:58 <Taek> with a two-way peg, it's the same currency on both blockchains

14:59 <kang_> That is because you are imagining atomic swap which is usually 2-party with side-peg which is done by an individual

15:00 <kang_> Try drawing both on paper, except the origin of coins, they both look same

15:02 <Taek> the origin of coins is what makes a two-way peg interesting

15:02 <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

15:03 <Taek> but a two way peg grants you a new power: you can move coins either direction between blockchains

15:03 <Taek> and so if you ever need a net flow in a direction, you can use a 2wp to achieve that

15:08 <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?

15:10 <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

15:11 <Taek> merge mining helps mitigate the security risk to some degree

15:11 frankenmint has quit []

15:13 <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

15:13 <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

15:13 <kanzure> "i won't peg to it" what does this mean? you can't just wish the peg didn't exist.

15:14 <kang_> No I mean I won't use it

15:14 <kanzure> you should not be forced to use anything

15:15 <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

15:15 <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

15:15 <Taek> you might be willing to accept the decreased security for the increased functionality

15:15 <kang_> Taek: I was considering the scalability use case

15:16 <kang_> Devs can see the scalability functionality but to a user, they won't compromise security for a good cause

15:17 <Taek> "I'd better off using... say litecoin" -> yes but then you aren't using the Bitcoin currency

15:17 <Taek> which means you are making a different set of tradeoffs

15:17 <kanzure> Taek: no there are other reasons, such as lower or different fees

15:17 Luke-Jr has quit [Ping timeout: 256 seconds]

15:18 <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

15:19 <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

15:19 zooko has joined #bitcoin-wizards

15:19 <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

15:20 kmels has joined #bitcoin-wizards

15:20 <kanzure> Taek: i was just commenting on "The only reason is... couldn't already do on the ... " phrase.

15:21 <kang_> kanzure: So we are saying people would prefer less fees over less security?

15:22 <kanzure> chains/ledgers with lower fees will probably have less security (although this is not guaranteed)

15:22 <Taek> kang_: some people will make that tradeoff, others won't

15:22 Yoghur114 has joined #bitcoin-wizards

15:22 <kanzure> i think you meant to ask "people would prefer less fees over more security?"

15:23 <kang_> yes, sorry

15:23 <kanzure> you could have also meant "people would prefer less fees even if it meant a lower-security consensus history?"

15:24 <kang_> Taek: what happens if most won't? Then sidechains would fail as a scalability solution? Or any scalability offered is good.

15:24 <kanzure> well, first, most fees are cleverly hidden from most users- by putting the fees on the merchants instead

15:25 <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.

15:26 <kang_> That only changes the question to "would most merchants prefer cheaper transactions over secure ones?"

15:27 <kanzure> it's not really about transactions- it's about the cost of utxos once you want to create utxos

15:27 <kanzure> because channels can be kept open almost indefinitely

15:29 <kang_> Channels between? Addresses? IPs? Idefinitely open channels only make sense in case of recurring payment requirements like say sandglass type flowing microtransactions

15:29 <kanzure> "recurring payment requirements" sounds a lot like sending and receiving payments

15:30 <kang_> General trade is not repetitive. In real life I seldom deal with a person twice.

15:31 <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.

15:31 <kanzure> (using payment channels)

15:33 <kang_> Yes, but doesn't that require the network to be between something? Some unique identifier?

15:33 <kanzure> i don't understand

15:36 <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

15:36 <kanzure> payment channels use many different bitcoin addresses during their operation

15:37 <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

15:37 <kanzure> also https://lightning.network/lightning-network-paper.pdf

15:38 <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

15:39 <kanzure> payment channels can be used for multiple payments

15:39 <kang_> I understand LN but haven't memorised the technical terms so am unclear. Sorry, I'll read and come back.

15:40 <kanzure> cool

15:45 <nsh> i understand nothing

15:52 bedeho has joined #bitcoin-wizards

15:53 <kanzure> nsh: trying to impress the monks?

15:53 * nsh smiles

16:16 Mably has quit [Read error: Connection reset by peer]

16:25 Luke-Jr has joined #bitcoin-wizards

16:27 CodeShark has joined #bitcoin-wizards

16:40 adam3us has joined #bitcoin-wizards

16:40 Luke-Jr has quit [Read error: Connection reset by peer]

16:45 Luke-Jr has joined #bitcoin-wizards

16:48 adam3us has quit [Quit: Leaving.]

16:58 davispuh has joined #bitcoin-wizards

17:03 Quanttek has joined #bitcoin-wizards

17:06 ThomasV has quit [Quit: Quitte]

17:12 arubi has quit [Ping timeout: 252 seconds]

17:16 airbreather has joined #bitcoin-wizards

17:16 AnoAnon has joined #bitcoin-wizards

17:18 roxtrongo has joined #bitcoin-wizards

17:19 ThomasV has joined #bitcoin-wizards

17:21 AnoAnon has quit [Read error: Connection reset by peer]

17:37 ThomasV has quit [Ping timeout: 246 seconds]

17:41 GAit has joined #bitcoin-wizards

17:44 afk11 has quit [Ping timeout: 252 seconds]

17:44 <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"

17:45 <CodeShark> what's your issue with it?

17:46 <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

17:47 <kang_> I say that it would not always be able to find a path through the network of hubs

17:47 roxtrongo has quit [Remote host closed the connection]

17:47 <kang_> Is there any data that proves a pth would always exist?

17:47 <CodeShark> that depends on the routing protocol and the way channels are initally set up - which is not specified in the paper

17:48 <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

17:50 <CodeShark> it's certainly not a trivial problem - but I think the LN paper focuses more on the consensus layer

17:52 <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

17:53 priidu has joined #bitcoin-wizards

17:53 GAit has quit [Quit: Leaving.]

17:53 <CodeShark> yes, all good points

17:54 <CodeShark> there is an incentive, though

17:54 <CodeShark> 3. seems trickiest

17:54 <kang_> Yes, 1 and 2 are problems but seem solvable. My real problem is 3

17:54 <kang_> yes, that

17:55 <CodeShark> how can someone who has no coins join the network?

17:55 c-cex-yuriy has quit [Quit: Connection closed for inactivity]

17:55 <CodeShark> there's always risk in taking on any unknown new node

17:56 <CodeShark> so new nodes might expect to pay most of the anchor transaction fees

17:56 <CodeShark> but they are also in the worst position to actually pay that

17:56 <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

17:57 snthsnth has joined #bitcoin-wizards

17:57 hazirafel has joined #bitcoin-wizards

17:58 <CodeShark> heh - we might need extraprotocol creditors :p

17:58 airbreather has quit [Remote host closed the connection]

17:59 <kang_> Sorry, didn't get you

18:00 afk11 has joined #bitcoin-wizards

18:00 <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

18:01 <kanzure> yes there was discussion about fronting utxos for lightning network onboarding

18:01 <kanzure> i believe it was discussed in here between myself and rusty but maybe some other user

18:02 blackwraith has joined #bitcoin-wizards

18:03 <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

18:04 priidu has quit [Ping timeout: 250 seconds]

18:04 <kang_> Infact, if both are new, rather 2 channels are required, which is actually worse

18:05 <kanzure> i don't think that the protocol requires address reuse

18:06 <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.

18:08 roxtrongo has joined #bitcoin-wizards

18:08 <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

18:08 <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

18:09 <Taek> but if you combine them with CT, you can eliminate the information revealed about how full the channel is

18:09 <Taek> (sorry that was a separate thought not answering a question)

18:10 <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

18:14 snthsnth has quit [Ping timeout: 246 seconds]

18:14 <kanzure> i don't think that node identification needs to use bitcoin addresses

18:15 Yoghur114 has quit [Quit: Konversation terminated!]

18:15 mjerr has joined #bitcoin-wizards

18:17 <kang_> In any kind of a network, there has to be some identifier identifying every node as part of it

18:17 adam3us has joined #bitcoin-wizards

18:21 <CodeShark> it would be terribly unwise to couple transaction authorization too strongly with identity

18:22 roxtrongo has quit [Remote host closed the connection]

18:22 <CodeShark> identity could be managed via another crypto layer

18:23 <CodeShark> i.e. cryptographically generated routable addresses a la cjdns

18:23 <CodeShark> the keys used to sign contracts should be an entirely separate layer

18:24 <CodeShark> giving you the ability to easily rotate them, revoke them, etc...

18:24 <CodeShark> without having to touch the identity layer

18:26 <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

18:26 hazirafel has quit [Ping timeout: 264 seconds]

18:27 <CodeShark> perhaps the onramp will have to involve paying fiat - or getting paid in bitcoin

18:28 <CodeShark> if someone wants to pay you in bitcoin, part of that payment could be put towards setting up a new channel

18:30 <CodeShark> or if you buy bitcoin for fiat, the seller could create a new channel with you

18:30 mjerr has quit [Ping timeout: 272 seconds]

18:31 <CodeShark> you'd probably need to set up at least two channels if you want to be able to replenish your channels

18:31 <CodeShark> without closing them out

18:32 roxtrongo has joined #bitcoin-wizards

18:32 zooko has quit [Remote host closed the connection]

18:32 <CodeShark> best might be to create several channels with completely random peers as part of the initial setup

18:32 <kang_> Doesn't sound like utopian to you?

18:33 <CodeShark> where I draw the line is when it becomes economically unrealistic

18:33 <CodeShark> what I've said so far seems very economically realistic because the incentives are therre

18:34 <CodeShark> if we have to rely purely on people doing good favors and acting altruistically, then yes, it's unrealistic

18:34 zooko has joined #bitcoin-wizards

18:36 <CodeShark> properly aligned incentives are key

18:37 <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!

18:38 <kang_> Simply stating, each new address requires a new channel setup, forever! unless someone wants to reuse identity

18:39 <CodeShark> first of all, "addresses on the blockchain" don't really exist

18:39 <CodeShark> addresses are an application-level abstraction in bitcoin

18:39 <kang_> Yes, technically. But you get what i mean

18:40 <kang_> In the LN paper, Alice, Bob etc are addresses

18:41 <CodeShark> the use of the term "address" as in "Bitcoin address" is an unfortunate misnomer that causes a lot of confusion

18:41 <kang_> replace it with public keys

18:41 <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)

18:41 <kang_> for simplicty

18:42 afk11 has quit [Ping timeout: 244 seconds]

18:42 <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

18:42 <CodeShark> most proposals I've seen don't even assume the signing keys used for contracts will ever be reused at all

18:42 <CodeShark> in fact, they might only be used once

18:43 <CodeShark> furthermore, they have nothing to do with message routing

18:44 <kang_> A "channel" is defined between two addresses. Can you confirm I am wrong about this?

18:45 <CodeShark> where "address" in this sense means something like an IP address?

18:45 <kang_> It means the bitcoin address exactly

18:46 <kanzure> hmm i guess it would be prudent to go look at what the protobuf definition of channel actually is

18:46 <kanzure> here is open_channel https://github.com/ElementsProject/lightning/blob/17471d0788ba14b83a88c8ef0d4e6b5944f3ae87/lightning.proto#L47

18:47 <CodeShark> hmm...I guess in rusty's implementation, a channel is identified by a pubkey used in the anchor transaction

18:47 <CodeShark> or not exactly...

18:48 hazirafel has joined #bitcoin-wizards

18:48 <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

18:48 hazirafel has quit [Read error: Connection reset by peer]

18:49 adam3us has quit [Quit: Leaving.]

18:50 <CodeShark> the actual contract underlying that output is opaque to this layer

18:50 <CodeShark> the way the parties are able to spend the output is an entirely separate layer

18:53 snthsnth has joined #bitcoin-wizards

18:55 <CodeShark> kang_: in the 5.9 version of the paper I don't see any mention of "address" referring to Alice and Bob

18:56 <CodeShark> in fact, it recommends the use of HD keys for transaction signing

18:56 <CodeShark> and as I said earlier, the paper does not specify the actual routing protocol at all

18:57 <CodeShark> just the commitment structures

18:58 <CodeShark> the use of the term "address" in the paper pertains to encoding of either p2pkh or p2sh

18:59 <CodeShark> and the p2sh addresses typically involve pubkeys from both parties

19:00 <kang_> Yes, the paper uses the term parties

19:04 <kang_> A party could be an address, a wallet, pubkeys whichever else identifier you want to use.

19:05 <kang_> Do you understand my concern? Or have been unable to show you the problem I see, yet?

19:05 <CodeShark> not really...

19:06 <CodeShark> I replaced the term "address" with "party" in your "For simplicity imagine" paragraph

19:06 <CodeShark> and I still am not sure I get your concern

19:07 <CodeShark> are you talking about having to close and reopen channels?

19:07 <kang_> A new 'party' entering the system, requires new 'channel' to be setup. Right?

19:07 <CodeShark> yes

19:07 <CodeShark> at least one - preferably more :)

19:08 <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).

19:08 <gmaxwell> The system rusty has been working on is onion routed.

19:09 <kang_> Privacy I understand, but not scalability

19:09 hazirafel has joined #bitcoin-wizards

19:10 <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

19:10 <kang_> I do understand

19:11 <gmaxwell> I am doubtful that you loaded that link and read it in under 10 seconds. :)

19:11 * kanzure lowers his raised hand

19:11 <kang_> No I read it yesterday through your reddit comment

19:11 <gmaxwell> OK

19:12 hazirafel has quit [Read error: Connection reset by peer]

19:12 <gmaxwell> So then I do not see the point of your objection.

19:13 <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

19:13 Luke-Jr has quit [Remote host closed the connection]

19:13 <kanzure> one possible objection is somtehing like "intermediate history will never be cuttable, because outputs are never merged" or something..

19:14 <kanzure> it's a weak objection, because outputs do get merged.. intermediate history can be cut.

19:14 <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.

19:14 <kang_> kanzure: About that gmaxwell wrote that he counted them earlier and there weren't many but now expects them to be significant.

19:15 <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

19:15 <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).

19:16 <kanzure> if payments flow in a circle in a network, you can just cut out the entire circle.

19:17 <CodeShark> the main scalability optimizations are what kanzure just said...and the use of the blockchain ultimately as a last-resort settlement mechanism

19:17 <gmaxwell> The word settlement confuses people.

19:17 <gmaxwell> I've seen this happen over and over again.

19:17 <CodeShark> the blockchain is there to protect you in the event of an uncooperative counterparty

19:18 roxtrongo has quit [Read error: Connection reset by peer]

19:18 <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.

19:18 <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.

19:18 <CodeShark> right, the blockchain is like a court

19:18 <CodeShark> you don't go to court over every contract you enter

19:19 <CodeShark> only the ones where there's a breach

19:19 <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.

19:20 <CodeShark> you'd much rather pry the counterparty into cooperation

19:20 nwilcox has quit [Quit: leaving]

19:20 <CodeShark> if they continue to refuse to cooperate, then you go to the blockchain

19:20 <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.

19:20 <kang_> Every new user needs to sign up with the court, thats the problem

19:20 Luke-Jr has joined #bitcoin-wizards

19:20 <kang_> But I get your point

19:21 <kanzure> yes it's true that there's a rate limit on the number of new (confirmed) utxos that can be created

19:21 <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.

19:22 <kang_> Because new users are indistinguishable. I prefer to appear a new user everytime

19:22 <gmaxwell> (there are way to actually even prevent enrollment, as kanzure notes about circles, but thats an edge case)

19:23 <kanzure> oh that prevents enrollment?

19:23 <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.

19:24 <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.

19:25 <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)

19:25 <gmaxwell> but I think it's not really an interesting case.

19:26 <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.

19:26 <kanzure> yeah ok

19:28 <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 ...

19:28 <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,

19:28 <kanzure> ... only something with access to the full graph/payments data for the whole lightning network?)

19:28 <gmaxwell> you can go cut out the enrollment.

19:28 <gmaxwell> But I think this is not so interesting, I'm just being pedantic.

19:28 <kang_> LN is then a mesh network between all parties using bitcoin ever

19:29 <CodeShark> gmaxwell: what's a better term to use rather than "settlement"?

19:29 <kanzure> "breach remedy"

19:29 <CodeShark> it's the term used both in finance and in law...but I guess breach remedy is more specific

19:29 zooko has quit [Ping timeout: 268 seconds]

19:30 <CodeShark> or less ambiguous, at any rate

19:30 ielo has joined #bitcoin-wizards

19:30 <CodeShark> but it sounds awkward :p

19:30 <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"

19:30 <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.

19:30 <CodeShark> "the blockchain provides well-defined breach remedy guarantees" :)

19:31 <CodeShark> what about Case 3: Sidechain is merge-mined with btc :)

19:31 <kanzure> hashrate is not enough to know whether a chain is "secure"

19:32 <kang_> kanzure: total history of hashrates

19:32 <jtimon> kanzure any hasrate is "secure enough" if you are willing to wait enough blocks for confirmations, no?

19:32 <CodeShark> gmaxwell: that is not 100% true although close - not reusing addresses involves slightly greater overhead in key management

19:33 <CodeShark> and a more-than-insignificant complication in implementation

19:33 <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?

19:33 <jtimon> and by any hashrate I mean any reward (subsidy + fees)

19:33 <kang_> CodeShark: Case 3 is same as 2 because merged mining means being exclusive to a blockchain

19:33 ielo has left #bitcoin-wizards [#bitcoin-wizards]

19:34 <jtimon> kanzure: sure, I mean, for any definition of "secure enough"

19:35 <jtimon> kanzure: the attack costs grow exponentially with the number of block confirmations, don't they?

19:35 <jtimon> that's what I got from the whitepaper

19:35 <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.

19:36 <kanzure> jtimon: yes yes, that's all accurate, but i think kang_ is asking about something else

19:36 <gmaxwell> Case 1: does that mean you stoped using bitcoin entirely the first moment the hashrate went down? :)

19:37 <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

19:37 <kang_> gmaxwell: If it goes below say litecoin, people would definitely switch over

19:37 <CodeShark> sometimes I wish we had something like BIP30 for scriptPubKeys :)

19:38 <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"?

19:38 <kanzure> kang_: what exactly are you comparing with litecoin?

19:39 <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"

19:39 <gmaxwell> kang_: these things are completely incompariable.

19:39 <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

19:39 <gmaxwell> Right now btc mining might even be using less power than ltc mining, and yet no one cares.

19:39 <gmaxwell> (there was a period before ltc mining moved to all asics where it probably was using more power than bitcoin mining)

19:40 Luke-Jr has quit [Remote host closed the connection]

19:40 <kang_> Surprising news to me! If so my questions are settled.

19:40 <jtimon> gmaxwell: the gpu-ltc times (supossedly imporssible accoring to LTC's initial announcement)

19:40 <gmaxwell> lol

19:40 <gmaxwell> Indeed.

19:41 <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.

19:41 <CodeShark> the irony is that the supposed strengths of scrypt over sha256 can't even be used in this context

19:41 <CodeShark> so they are entirely irrelevant

19:42 <kanzure> and your utxos wont be movable during that readjustment period

19:42 <kanzure> well, probably wont be movable

19:42 <gmaxwell> anyone know if there is a git setting to change the date format string?

19:42 <kanzure> GIT_COMMIT_DATE

19:42 <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

19:42 <kanzure> oops

19:42 <kanzure> GIT_COMMITTER_DATE GIT_AUTHOR_DATE

19:42 <kanzure> nope i was right the first time. damn.

19:43 <jcorgan> i think those can be set in the environment

19:43 Newyorkadam has joined #bitcoin-wizards

19:43 <kang_> Many people would be surprised! Is this calculated somewhere? BTC power used vs LTC power consumption?

19:43 Luke-Jr has joined #bitcoin-wizards

19:43 <CodeShark> you can estimate the hash rates and then grab a napkin :)

19:43 <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)

19:44 <CodeShark> each scrypt hash consumes more energy than each sha256 hash - so you need to account for that factor

19:44 <gmaxwell> kang_: which is part of why I was saying that no one cares. :(

19:44 <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

19:45 <dgenr8> kang_: a new channel does require a blockchain tx. otherwise the whole thing can be double spent

19:45 gmaxwell has left #bitcoin-wizards [#bitcoin-wizards]

19:46 <kang_> dgenr8: Yes , but the net broadcasted count is better over time so ..

19:46 * jtimon thows the rock and hides the hand: afk

19:48 <kang_> Is Peter Todd's calculation of >30% the counterargument to IBLT?

19:49 <kang_> Are there any other counterarguments to IBLT?

19:55 roxtrongo has joined #bitcoin-wizards

20:00 roxtrongo has quit [Ping timeout: 260 seconds]

20:02 snthsnth has quit [Ping timeout: 240 seconds]

20:02 <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?

20:03 <kang_> I have a proposal to actually reduce the blocksize, butit could be faulty hence asking about problems with IBLT proposal

20:07 nwilcox has joined #bitcoin-wizards

20:18 dEBRUYNE has quit [Ping timeout: 255 seconds]

20:27 Newyorkadam has quit [Quit: Newyorkadam]

20:28 Newyorkadam has joined #bitcoin-wizards

20:34 roxtrongo has joined #bitcoin-wizards

20:34 roxtrongo has quit [Remote host closed the connection]

20:38 ThomasV has joined #bitcoin-wizards

20:41 snthsnth has joined #bitcoin-wizards

20:41 roxtrongo has joined #bitcoin-wizards

20:42 bedeho has quit [Ping timeout: 255 seconds]

20:43 roxtrongo has quit [Remote host closed the connection]

20:43 ThomasV has quit [Ping timeout: 265 seconds]

20:48 zooko has joined #bitcoin-wizards

20:51 zooko has quit [Remote host closed the connection]

20:54 jtimon has quit [Ping timeout: 264 seconds]

20:57 bedeho has joined #bitcoin-wizards

21:06 c-cex-yuriy has joined #bitcoin-wizards

21:07 GGuyZ has quit [Quit: GGuyZ]

21:12 GGuyZ has joined #bitcoin-wizards

21:29 ebfull has quit [Quit: cya]

21:30 ebfull has joined #bitcoin-wizards

21:34 Newyorkadam has quit [Quit: Newyorkadam]

21:41 GGuyZ has quit [Quit: GGuyZ]

21:41 kang_ has quit [Quit: Page closed]

21:42 Guyver2 has quit [Quit: :)]

21:44 GGuyZ has joined #bitcoin-wizards

21:47 roxtrongo has joined #bitcoin-wizards

21:55 nwilcox has quit [Ping timeout: 255 seconds]

21:58 roxtrongo has quit [Remote host closed the connection]

21:58 Newyorkadam has joined #bitcoin-wizards

22:00 samson_ has joined #bitcoin-wizards

22:03 twoone has joined #bitcoin-wizards

22:22 warptangent has quit [Read error: Connection reset by peer]

22:23 warptangent has joined #bitcoin-wizards

22:24 sausage_factory has joined #bitcoin-wizards

22:24 blackwraith has quit [Ping timeout: 250 seconds]

22:35 nwilcox has joined #bitcoin-wizards

22:37 arubi has joined #bitcoin-wizards

22:38 nwilcox_ has joined #bitcoin-wizards

22:39 GGuyZ has quit [Ping timeout: 244 seconds]

22:43 maaku has quit [Quit: No Ping reply in 180 seconds.]

22:45 nwilcox_ has quit [Quit: leaving]

22:45 nwilcox has quit [Quit: leaving]

22:45 nwilcox has joined #bitcoin-wizards

22:48 maaku has joined #bitcoin-wizards

22:48 maaku is now known as Guest16294

22:48 Yoghur114 has joined #bitcoin-wizards

22:51 Newyorkadam has quit [Quit: Newyorkadam]

23:02 GGuyZ has joined #bitcoin-wizards

23:09 roxtrongo has joined #bitcoin-wizards

23:15 Newyorkadam has joined #bitcoin-wizards

23:18 kmels has quit [Ping timeout: 246 seconds]

23:19 arubi has quit [Quit: Leaving]

23:24 samson_ has quit [Ping timeout: 244 seconds]

23:29 ThomasV has joined #bitcoin-wizards

23:35 arubi has joined #bitcoin-wizards

23:35 dEBRUYNE has joined #bitcoin-wizards

23:38 sausage_factory has quit [Ping timeout: 256 seconds]

23:40 priidu has joined #bitcoin-wizards

23:45 kmels has joined #bitcoin-wizards

23:52 priidu has quit [Ping timeout: 244 seconds]

23:54 ThomasV has quit [Ping timeout: 252 seconds]

23:58 priidu has joined #bitcoin-wizards