--- Log opened Wed Jan 15 00:00:03 2014
--- Day changed Wed Jan 15 2014
00:00 < petertodd> midnightmagic: heh, well with a challenge that was true too, but anyway :P
00:00 < andytoshi> gmaxwell: i can say from personal experience that public schools in BC are not run effectively, they are very much "no child gets ahead" and they were an absolute hell to get through
00:00 < midnightmagic> hehe
00:00 < gmaxwell> I know a number of _good_ high-school teachers who left teaching due to the effects of that legislation.
00:00 < petertodd> gmaxwell: can't blame them, that stuff is just depressing to deal with
00:00 < midnightmagic> andytoshi: you think so? i had the exact opposite experience in BC
00:01 < andytoshi> midnightmagic: i was in cloverdale, it is the cowboy town beside langley, they had no gifted programs
00:01 < midnightmagic> vancouver. interesting.
00:02 < andytoshi> midnightmagic: i finished every hs math class by the end of grade 9, then no more math. 'science' was watching bill nye videos and doing handouts, i was typically done the work for the day in about 15 minutes, then 6 hours or so of staring at walls
00:02 < midnightmagic> i was in the interior, they specifically pushes the smart kids into beneficial grade programs for university entrance.
00:02 < andytoshi> midnightmagic: eventually i found some good teachers who helped me game the system, and i got out 18 months early
00:02 < petertodd> andytoshi: ha, ironic how my highschool was a "inner city" one with a population of almost entirely recent immigrants, very pool, with significant gang violence and... I had a much better experience
00:03 < andytoshi> 2 years early* i stuck around to finish my phys. ed. requirements :P
00:03 < andytoshi> so i don't count that semester as hs
00:03 < petertodd> andytoshi: and then my brother was in a hs in one of the richest parts of the city, upper-upper-middle-class, and... actually lots of gang violence *in* the school, and shit academics.
00:03 < andytoshi> petertodd: fascinating
00:04 < andytoshi> there is a lesson here about anecdotal evidence i'm sure :)
00:04 < midnightmagic> my hs teachers did the optional calculus prep stuff. probably for my specific benefit actually, the rest of the kids were rolling their eyes.
00:04 < andytoshi> maybe we should apologise to midnightmagic for calling his sociologists stupid
00:04 < petertodd> andytoshi: hehe, toronto is not a good source of typical demographic data :)
00:04 < midnightmagic> lol a.k.a. my wife.
00:04 < midnightmagic> no apology necessary, it's a well studied ohenomena.
00:04 < midnightmagic> er.. *non
00:05 < petertodd> andytoshi: over 50% of the toronto population wasn't even born in canada
00:06 < midnightmagic> well, without immigration our pop would be shrinking. :-)
00:06 < midnightmagic> would suck if canada died.
00:06 < andytoshi> petertodd: this is true of vancouver as well, though probably not in cloverdale where i was
00:06 < gmaxwell> Oh I GEDed out of school the moment it was permitted, in florida by statute the GED is absolutely equivalent to a highschool diploma— you even get the same paper the normal graduates get. Was kind of of no brainer. I took the test cold two days after my birthday (earliest time offered) scored a 99th percentile. It was trivial stuff. ::shrugs:: I understand that it wasn't too uncommon to do this in the 70s but the schools fought ...
00:06 < gmaxwell> ... back against it with a bunch of FUD because it was draining them of their most academically capable students.
00:06 < andytoshi> oh, cloverdale is right above white rock, from silk road hitman fame :)
00:07 < andytoshi> so i'll stop saying 'near vancouver' here
00:07 < petertodd> andytoshi: what's the kind of immigrants that vancouver gets anyway? asia? middle-east?
00:07 < midnightmagic> andytoshi: i'm confident nobody thinks you're that guy lol
00:07 < midnightmagic> ha ha ha awesome
00:07 < midnightmagic> petertodd: asian, then east indian
00:07 < gmaxwell> I was impressed by the density of asian people in vancouver.
00:07 < andytoshi> petertodd: east asia, mostly china and phillipines, then india
00:08 < petertodd> gmaxwell: sheesh, that kinda sucks that you were in a position where that made sense
00:08 < midnightmagic> richmond doesn't even have english signage in some places.
00:08 < petertodd> andytoshi: oh, interesting, toronto seems to get much more from the middle east
00:09 < midnightmagic> gmaxwell: how old were you re: GED?
00:09 < midnightmagic> (wife is curious)
00:09 < gmaxwell> 16.
00:09 < petertodd> andytoshi: OCAD had a *tonne* of Iranians for instance
00:09 < midnightmagic> nice.
00:09 < andytoshi> gmaxwell: that's awesome, i wish i had that option
00:09 < andytoshi> maybe i did, it didn't occur to me
00:10 < midnightmagic> i skipped a grade, grad'd at 17. skipping a grade was really horrible. not recommended.
00:10 < midnightmagic> petertodd: what's OCAD?
00:10 < andytoshi> petertodd: interesting, i've only met one iranian
00:10 < petertodd> midnightmagic: I think one of the things the gifted program did a good job at was giving kids reasons not to skip grades...
00:10 < midnightmagic> I love Iranians they're awesome
00:10 < petertodd> midnightmagic: http://www.ocadu.ca/ <- art school I went too
00:10 < andytoshi> midnightmagic: lol, i formally skipped two grades, but my attendence was ~0 so it didn't matter, just let me get out earlier, so i'd recommend it
00:11 < midnightmagic> oh cool
00:11 < petertodd> andytoshi: huh, must be a regional thing that they settle in Toronto
00:11 < midnightmagic> yikes.
00:11 < andytoshi> midnightmagic: agreed re iranians, the one guy i know is so much fun
00:11 < gmaxwell> Its not something that was widely publicized, I think I only knew it was possible as a result of talking to some prof at the local community college who'd done it himself in the 70s... I caused a number of other people to do it.
00:12 < petertodd> andytoshi: also people from Iraq, Palestine, Afghanistan etc.
00:12 < midnightmagic> then again I personally have never met a single US'ian I didn't love so.. dunno if I'm just a people lover or plain lucky
00:13 < andytoshi> petertodd: cool, also know only one iraqi, two afghanis, no palestinians.. vancouver is all east asia and india
00:13 < petertodd> midnightmagic: it's interesting just how much iran has changed for so many of the iraneans I know - practially a different country now compared to the 70's or so
00:13 < midnightmagic> yunan province chinese are awesome
00:13 < midnightmagic> lol
00:13 < petertodd> midnightmagic: most of the ones I knew had grown up here - it was their parents who fled
00:14  * midnightmagic tries to think of a people that irritate him and fails.
00:14 < petertodd> midnightmagic: aussies?
00:15 < andytoshi> haha
00:15 < midnightmagic> petertodd: Hrm, yeah maybe. There's some weird misogyny stuff going on there. But NZ make up for it
00:15 < petertodd> ha
00:15 < petertodd> good, cause my mom's an aussie, and my brother lives there :P
00:15 < midnightmagic> :-)
00:16 < midnightmagic> my cousin is marrying an aussie, he's like the ultimate man's man, great guy
00:16 < petertodd> lol
00:16 < midnightmagic> (in the awesome way, not the chauviniat way)
00:16 < petertodd> sounds about right
00:17 < midnightmagic> :-)
00:18 < petertodd> actually the one group I didn't like at ocad was about half of the Jews from Israel - see, one half left Israel because they couldn't stand the violence, and the other half left Israel because they couldn't stand the violence... and you'd, roughly speaking, have one half of that group be "peachniks", and the other half be downright frightening if you ever got them talking about the security of Israel. Very bizzare in the context of an art ...
00:18 < petertodd> ... school to say the least.
00:19 < petertodd> Really good example of how utterly polarizing that issue can be with people unfortunately. :(
00:30 < gmaxwell> At the IETF many of the Israel folks are super duper heavy pro-surveillance-state (enough that its conspicuous). I've observed this create some pretty awesome dissonance in hallway conversation with americans of jewish dissent. "Goverment tracking and logging everyones activity, surely there is no historical precident for the abuse of this kind of infrastructure!"
00:34 < petertodd> gmaxwell: ha, sounds about right. Really bothered me the one time I heard one of the more militant of them talk about the "Palestine problem" as something that needed a final solution.
00:35 < gmaxwell> Final Solution. Get the case right.
00:35 < petertodd> gmaxwell: good example of how perceived safety works too... the people I knew from Palestine, heck, even Gaza, never seemed to have that kind of hostility.
00:36 < petertodd> gmaxwell: I'll assume they were quoting Ariel Sharon, who gets quotes as saying that in lowercase. :/
00:37 < gmaxwell> I can't even pretend to understand the geopolitics there, but it is interesting to see how different social/cultural backgrounds color positions and perspectives.
00:38 < gmaxwell> I've also seen some people from places with severe organized crime and corruption problems see antisurveillance technology as problematic. In particular because the badguys there have unequal access to it, and because surveillance is _sometimes!_ successfully used against them.
00:39 < petertodd> Yeah. Really unusual that too given there were just as many Israels I ran into it who were truly passionate about the peace process and ending violence; kept running into one of my teachers at protests related to it.
00:39 < gmaxwell> I wonder how different the US perspective on the NSA might be if it were also used to root out a bit of serious corruption in government here and there.
00:40 < petertodd> I think that's a very good point: the middle-east people I knew from OCAD were the first to pick up on the NSA stuff other than tech people I knew.
00:40 < petertodd> While I've yet to hear any Russians bothered by it.
00:43 < petertodd> Of course, Toronto also had the G20, which I think *really* turned public opinion against the police locally with how badly it was handled. First time in my life that all the major papers quite direclty accused the police of lying.
00:43 < petertodd> I think that's rubbed off to survailance stuff in general, at least based on the way people seem to talk about the NSA.
00:44 < andytoshi> petertodd: where i live, there is a general distrust of the "american police state", especially since many vancouverites drive to and from seattle routinely
00:44 < petertodd> andytoshi: interesting! due to border guards?
00:44 < andytoshi> petertodd: yes
00:45 < andytoshi> the american border guards are idiots and agressive, and we all know people who've been barred from the country for trying to bring dope over
00:45 < andytoshi> about 25% of the time you are 'randomly selected' to go stand in line for several hours while they take your car apart
00:45 < petertodd> andytoshi: heh, might have something to do with my co-workers dislike too: we've had hundreds of thousands of dollars worth of really sensitive equipment destroyed by border guards pulling it apart :(
00:46 < petertodd> andytoshi: took the second occasion before they realized they'd jsut have to ship stuff by hand
00:46 < andytoshi> when i fly to the US, customs entering the US is fascinating to watch because the non-canadians have to do the police-state record-all-ten-fingerprints thing
00:47 < andytoshi> meanwhile canadians get a special treatment because they would never put up with that, and they are still hostile to the guards and vice-versa
00:47 < petertodd> andytoshi: it's canadians too sometimes...
00:47 < andytoshi> ..and the poor europeans are basically being strip-searched, watching canadians glare at guards as the stand 2 inches over the line they were told to stand behind
00:48 < andytoshi> petertodd: canadian guards? driving in i have had them be assholes before, though they have never taken my car apart
00:48 < andytoshi> flying in, the "customs" process involved them asking if i went to school in the US
00:48 < andytoshi> i said yep, the guy said ok, sure
00:48 < petertodd> heck, I had a friend who tried to go into the states in the middle of summer, with her dog in her car, and they forced her to leave said dog in the car while they interregated her. The whole time they just stonewalled her as to what was happening to her dog, saying they didn't give a damn. Of couse, in reality it was just a pressure tactic and they'd let it out and gotten it some water, but...
00:48 < andytoshi> jeez
00:48 < petertodd> andytoshi: oh, I mean they give the fingerprint treatment to canadians sometimes
00:49 < andytoshi> oh, i got that when i first got my F1 status
00:49 < andytoshi> very annoying, i'll have to replace those fingertips when i get out of school <.<
00:49 < petertodd> ha
00:49 < petertodd> take up quarts glass blowing, and be clumsy
00:49 < andytoshi> :P
00:51 < petertodd> I was impressed with the european border control when I went to the dark wallet hackathon, which was held in an abandoned building with known cyber-terrorist Amir Taaki: didn't ask me a single question
00:51 < andytoshi> haha, excellent
00:53 < andytoshi> is amir a "known cyber-terrorist"?
00:53 < andytoshi> haha, i see, i've never read his wiki page before..
00:53 < petertodd> I sure hope so! I've got an image to maintain
00:54 < andytoshi> https://en.wikipedia.org/wiki/Amir_Taaki#Activism would certainly classify him as a terrorist in america
00:55 < petertodd> agreed, and Esperanto?! evil
00:55 < phantomcircuit> only on tuesdays
00:55 < andytoshi> that wiki page also claims he is on forbes' top 30 entepreneurs of 2014
00:55 < andytoshi> ..which was published tomorrow o.O http://www.independent.co.uk/news/business/analysis-and-features/meet-the-worlds-next-billionaires--from-mashables-pete-cashmore-to-bitcoin-renegade-amir-taaki-9042710.html
00:55 < petertodd> andytoshi: um... yeah... I belive that guy when he says he's penniless
00:56 < andytoshi> oh, no, that's today's date up top, the article is a week old :P
00:57 < phantomcircuit> petertodd, im pretty sure he has at least like
00:57 < phantomcircuit> 100 euros
00:57 < andytoshi> yeah, the article credits him for darkwallet, but that seems pretty hard to monetize
00:57 < petertodd> phantomcircuit: and one pair of unwashed sweatpants
00:57 < andytoshi> i assume jon matonis was involved in that list ..
00:57 < petertodd> andytoshi: lol
00:57 < phantomcircuit> petertodd, im pretty sure he has only one pair of everything
00:58 < phantomcircuit> maybe he has two shirts
00:58 < petertodd> phantomcircuit: probably both scavenged
00:59 < phantomcircuit> eh probably not quite
00:59 < phantomcircuit> maybe his mom bought them
00:59 < phantomcircuit> (that's always a good way to get new clothes)
00:59 < petertodd> phantomcircuit: works best when you're parents live in northern canada... and they invite you home for chistmas
00:59 < phantomcircuit> which is why i get a nice laugh at people accusing him of doing things for bad reasons
01:00 < phantomcircuit> it's just not how he operates
01:00 < petertodd> yup, he's very genuine
01:01 < petertodd> and you know, quite willing to take criticism, and flexible
01:19 < gmaxwell> phantomcircuit: so... seen cointerra's screenshot.
01:19 < gmaxwell> I am boggled.
01:19 < gmaxwell> http://cointerra.com/wp-content/uploads/2014/01/DSC05521.jpg
01:19 < petertodd> that's fast
01:20 < gmaxwell> because it shows it as having submitted 44k shares to eligius... but that address is not in the payout queue, nor has it been paid on the network... and its not in the list of recent miners on eligius.
01:20 < petertodd> oh!
01:22 < gmaxwell> the address is truncated so I can't go straight to the stats, so it's possible that it mined but not enough to be elegible for payout, but not recently enough to be in the 3 hour active list.
01:22 < gmaxwell> petertodd: it's fast, but it's supposted to be 2TH, so not that fast!
01:22 < gmaxwell> http://cointerra.com/engineering-updates-terraminer-iv-hashing-live/
01:23 < petertodd> gmaxwell: what ASIC tech level is it?
01:24 < petertodd> ah 28nm
02:03 < phantomcircuit> gmaxwell, yeah i saw the video before they posted it
02:03 < phantomcircuit> (aren't i so cool)
02:24 < amiller> got thirty cryptocurrencies aint never been released
02:30 < phantomcircuit> gmaxwell, also it's possible they were using an invalid address, iirc eligius treats that as a donation
02:30 < phantomcircuit> Luke-Jr, ?
02:31 < Luke-Jr> I'm not seeing anything so far.
02:31 < Luke-Jr> but this query will probably take a while
02:31 < gmaxwell> Luke-Jr: well its probably not running now or it would be in the top list.
02:31 < phantomcircuit> iirc he has a share log
02:31 < Luke-Jr> looks like the share log goes back a week
02:33 < gmaxwell> ... weird. well there is a date in the screenshot, also a last block
02:34 < gmaxwell> Luke-Jr: http://cointerra.com/engineering-updates-terraminer-iv-hashing-live/ pic at the bottom
02:49 < gmaxwell> phantomcircuit: it looks like with a slightly different case design they could have fit that in 2u without a problem.
02:51 < gmaxwell> e.g. potentially making it longer and turning the radiators flat. and having airflow that went >_____/
02:57 < midnightmagic> bah
02:59 < gmaxwell> midnightmagic: if its any consolation CT is no track to deliver another never-break-even miner. Though perhaps they'll rock the world with their power usage and eventually make it back.
03:32 < gmaxwell> https://bitcointalk.org/index.php?topic=319146.msg4494688#msg4494688  < looks like the othercoin thing is being sold now.
03:32 < gmaxwell> I don't have the pre-reqs or the time. But I do think that such a thing could be a valuable addition to the bitcoin ecosystem.
03:33 < gmaxwell> It's basically the digital version of the cassius coins... but allows the user to safely fill it, and electronic transmission.
03:33 < BlueMatt> nice
03:56 < stonecoldpat> looks nice, my concern is that initially if BTC is $1k - then it will cost $350
04:01 < gmaxwell> stonecoldpat: yea, it's not viable at that price but presumably that will be fixed once it actually exists at scale.
04:03 < stonecoldpat> yeah i hope so, also looking at the video, you start the 'handshake' between devices using SMS, i'm wondering why he chose SMS and it has been a little worried (I dont know why it does yet)
04:05 < _ingsoc> Any idea why the issues 404 after page 100 on Github?
04:06 < _ingsoc> Closed issues.
04:06 < _ingsoc> Works: https://github.com/bitcoin/bitcoin/issues?page=100&state=closed
04:06 < _ingsoc> 404: https://github.com/bitcoin/bitcoin/issues?page=101&state=closed
04:07 < _ingsoc> I figured it's important if anyone wants to look at the history.
04:09 < nsh> there are numbers higher than 100?!?
04:09 < _ingsoc> Yeah. :)
04:09 < nsh> i'll need to revise a lot of models :/
04:09 < _ingsoc> It's concerning because it really needs to be accessible.
04:10  * nsh nods
04:10 < nsh> does it happen on other repositories?
04:10 < _ingsoc> I'm unsure. Let me check.
04:12 < _ingsoc> Yeah, happens on any project when it's 101.
04:12 < _ingsoc> Is there a record of this somewhere, or are all the issues only stored on Github?
04:14 < _ingsoc> If not, it's like erasing history, one page at a time. :D
04:15 < nsh> i'd suspect it's still accessible through git itself
04:15 < nsh> actually, dunno
04:16 < _ingsoc> Not sure how to access issues using git itself.
04:16 < _ingsoc> Everyone should stop working on Bitcoin right now until we figure out how to stop erasing history.
04:19 < wumpus> you could access them one by one through the github API, and make a mirror
04:19 < wumpus> not with git itself as the issues are not part of the repository, only the code changes
04:19 < wumpus> (and commit descriptions in git itself)
04:19 < nsh> ah, right
04:20 < wumpus> so if github goes down we'd lose the discussions that happened on github
04:20 < _ingsoc> That's concerning.
04:20 < wumpus> (which in most cases is no big loss, but I suppose for history's sake you could archive them)
04:21 < _ingsoc> I want to.
04:21 < wumpus> see http://developer.github.com/v3/
04:23 < _ingsoc> Is there a simple way to get a dump?
04:23 < wumpus> I'm sure someone else already wrote a script for that
07:14 < adam3us> 12hr async conversation, caught up, a couple of comments
07:17 < adam3us> covenants/quinine scripts.  I think relating to a payments ability to require transferable restrictions on the  next transaction.  i think this could be policy dangerous due to the virality.  consider a script that requires follow-on script to have an AML id signature, a few regulations on exchanges, and policy.  i understand it allows useful things like SPV coloring in chain, etc but I think satoshi script is policy safer
07:18 < adam3us> gmaxwell: "So, is there a way with ECDSA, given three messages pick a pubkey,r,s  such that pubkey,r,s is a valid signature of any one of the three messages?" only 2 not 3 i think.
07:19 < adam3us> petertodd: "I think the most fundemental thing I've discovered is the concepts of how mining can be separated into timestamping and proof-of-publication" hmm might've been me that seeded that concept.  or yet-another-rediscovery gmaxwell/petertodd/adam3us (i tend to get there last as i only started catch up 10mo ago)
07:47 < adam3us> petertodd: and i guess timestamp/namespace/bitcoin-ful/bitcoin-spv relation struck me in part because i thought about distributed namespace things (in the OT-like federated but reactive security + public auditability) pre-bitcoin.  and you maybe because you looked at timestamping.
08:23 < jtimon> adam3us: gmaxwell's thread is full of terrible covenants
08:24 < adam3us> jtimon: on bitcoin talk? a cautionary tale of why the virality of covenants can be a risky proposition?
08:24 < jtimon> but is any covenant economically worse than destroying coins (which we allow)?
08:24 < jtimon> I think is "coincovenants: a f** terrible idea" or something similar
08:25 < jtimon> https://bitcointalk.org/index.php?topic=278122.0
08:28 < jtimon> actually, I propose the AML-KYC covenant there
08:29 < jtimon> and I think it can replace our optional "authorizer tokens" in freimarkets
08:29 < jtimon> not sure about the  "issuance tokens" yet, I don't think so
08:32 < adam3us> jtimon: i see that gmaxwell and you share my concern that this is a terrible idea :) this is good.  ethereum will have this problem because its script is TC, as well as stateful and lots of non-amenability to theorem provers, security problems inside the language/scripts, and sandbox interpreter escape.
08:33 < jtimon> but the first really-interesting use case I saw yesterday (again in the context of freimarkets) is a covenant that allows you to always buy back interest bearing assets you issued
08:33 < adam3us> jtimon: a covenant is far worse than destroying bitcoins.  it is viral and so can be used as a lever to change the social contract an meaning of coins against the users wishes.
08:33 < jtimon> say you issue adamBTC at 1% interest but want to buy them back for BTC at 1:1 when you want, not when the lender allows you to
08:34 < jtimon> I'm not worried, by attaching a "bad" covenant you've made your coins unfungible: they're not bitcoins anymore but another asset
08:35 < jtimon> destroying is not strictily "viral" but it's also irreversible
08:35 < jtimon> the effect on the quantity of "pure btc" is the same
09:22 < adam3us> jtimon: destroying coins is relatively harmless systemically.  it reduces 21mil limit, but the divisibility means it just creates some supply contraction.  we cant prevent it really, all we could do is force people to do it in a non-utxo compactable way
09:23 < adam3us> jtimon: the problem with virality is its like coinvalidation, it could virally sweep through the system via centralized policy points and change almost all of the coins semantics.  for a system which aims for user-centric policy choices, that is a big fail.
09:25 < adam3us> jtimon: if a user wanted to make a convenant, thats their choice, the worry is more around centralized points like exchanges, regulated businesses, etc imposing a viral covenant on their users that flows through the system where the user has a choice to lose fungibility or submit to some outside imposed policy against their preference and self-interset
09:29 < jtimon> well, let's use my visacoin example (KYC covenant)
09:29 < jtimon> if I give btc to an exchange and they give me viscoins back, I calll that fraud and never come back
09:30 < jtimon> the main problem would probably be education and smart clients that show a different separated balance for visacoins
09:32 < jtimon> if we solve that, it doesn't matter if 80% of the btc were turned into visacoins: bitcoins are still p2p
09:32 < jtimon> in the case of freicoin is again less to worry about
09:33 < jtimon> both visacoins and freicoins will be destroyed by demurrage, but miners get fresh clean freicoins
09:33 < adam3us> jtimon: given the centralized pressures that exist in the world for control  i think adding covenants would likely end in the loss of decentralization and effective user policy choice.  ie the destruction of bitcoin as a decentralized currency.
09:35 < jtimon> maybe I'm too optimistic or I expect people to be too smart
09:35 < adam3us> jtimon: see our visacoin example, it gives a new outcome other than banning exchanges: ban non AML convenanted coins.  that means u can not transfer a coin to an address that is also not AMLed.  easy there-forward for governments to mandate that policy.  ergo do not build the mechanism for your own demise
09:35 < jtimon> or maybe you're too pesimistic and expect people to be too stupid
09:35 < adam3us> jtimon: seemingly if bitcoin taught us anything its that people are too stupid :)
09:35 < jtimon> and don't distinguish between visacoins and bitcoins
09:37 < jtimon> adam3us: maaku had the same concern when we were discussing freimarkets authorizers
09:37 < jtimon> my believe is that people will tend to prefer non-authorized assets when they can
09:38 < adam3us> jtimon: see there is a hypothetical bootstrap stage where bitcoin density reaches a point where it can continue without exchanges (for some p2p uses).  covenants only makes that worse, because each time you interact with someone who is stupid or doesnt care or need the money in a aml form to dosomethin, it removes free coins, let it run for a year and there will be none left.
09:38 < adam3us> jtimon: i agree, but the virality and incremental leaking effect means you have no remaining effective say in the matter.
09:38 < pigeons> yes, its more than just the technical issue of unaware mixing of covenanted coins and unencumbered coins. As the large, "convienent" options force covenanted coins, some of their partners, customers, and suppliers do too, etc
09:38 < jtimon> and at the same time, there's local communities who want to impose strict rules for their local currencies, and authorizers were the most generic way of allowing them to do so
09:40 < jtimon> if btc are destroyed logarithmically, there will always be some of them left
09:41 < adam3us> jtimon: yes but the remaining free coins are not going up in value (much) so if there are 100btc left for those that care its too few, and bitcoin is dead.
09:41 < jtimon> please, don't say value, say price
09:42 < jtimon> you're making a lot of assumptions
09:42 < jtimon> why would the value of btc be correlated to the value of visacoin?
09:42 < adam3us> jtimon: (ok price) overall this is one of the reasons why tinkering with expanding script language power has far reaching implications, even for the very continued meaningful existence of bitcoin with decentralized policy features, and must be approached with extreme caution.
09:42 < jtimon> if there's 1% btc and 99% visa, btc are much more scarce
09:43 < pigeons> its similar to coinvalidate. you would think no one would want to use a whitelist, but once "everyone else" does
09:43 < pigeons> there become less options to use bitcoin and the only options are to use covenantcoin/visacoin/etc
09:43 < jtimon> what would I use whitelisted bitcoins? that's not a p2p currency
09:44 < adam3us> pigeons: right.  its as likely that the price of free coins would plummet because the people who think about technical freedom are in an economic minority
09:45 < jtimon> technical freedom is what bitcoin is about
09:45 < adam3us> jtimon: scarce as in about to become dodo i thin, due to incremental virality
09:45 < jtimon> if people think that bitcoin will go higher in price after they turn into visacoins they are blind
09:46 < adam3us> jtimon: i think it is more that the economic majority neither thinks, nor cares, they just want to buy a burger, etc.
09:46 < adam3us> jtimon: so why would they care when they spend the last freecoin for a burger, so long as the visa covenant shop accepts it at parity
09:46 < pigeons> well price isnt the concern, its usability and perhaps fungibility, if network effects help increase visacoin usage as the way to go
09:47 < jtimon> please, stop using the "people are dumb" fallacy
09:47 < jtimon> because the burguer costs 1 visacoin (1000 usd aprox) and 1 bitcoin costs 100,000 usd, for example
09:48 < adam3us> jtimon: ok, say the bitcoin wizard guy gets very hungry, and he wants to eat the burger and he has no visa coins in his wallet.  he think h well its only 10mBTC.  repeat viraly by the velocity of money and even people who are smart an care, can end up with no free coins left after a bit
09:48 < pigeons> so i like tools that have lots of options too, but also i've seen the "people are dumb" argument supported too well in bitcoin.
09:48 < pigeons> not reall dumb, just acting naturally for conditions
09:49 < jtimon> people are dumb, but if you need that fact to make a point there's something wrong with your reasoning
09:49 < pigeons> so for these matters i like if the features are supported better, but after there are more options to support the underlying p2p bitcoin and keep it viable in spite of other choices
09:49 < adam3us> jtimon: there you assume the exchange for freecoin/amlcoin diverges.  aml exchanges and shops will accept freecoin at parity i woul think (and convert them into amlcoins)
09:49 < jtimon> I'm just saying that's a fallacy, not that it is false
09:50 < pigeons> when bitcoin is more "entrenched" these outcomes are less of a concern
09:50 < jtimon> why would shops ask you for 1 btc for the burguer if they can sell 0.01 btc for 1 visacoin?
09:51 < adam3us> jtimon: i think covenants just hand a viral weapon of control to policy risk points.  bitcoin has policy risk points: exchanges, regulated businesses and the market success of payment processor policy (say bitpay adopted aml coin, jgarzik resigns in protest, but it has market adoption)
09:52 < jtimon> I could even be fine with assuming most cosnumers and some merchants are dumb
09:52 < jtimon> but certainly not assuming that most shops and producers will be dumb: because they go bankrupt when they're dumb
09:53 < jtimon> ok
09:53 < jtimon> what could happen...
09:53 < pigeons> policy risk points are not about business saavy, they are about external force imposed by regulators
09:53 < adam3us> jtimon: ok agree, no more dugging-krugeresque smugness.  lets focus on the virality issue
09:54 < jtimon> no matter the law, if your business sucks you go bankrupt
09:54 < jtimon> no matter how happy the nsa is with say, coinbase
09:54 < adam3us> pigeons: as we've seen with NSA the'll use / abuse what they can get.  we thought we were secure because of CAs.  in reality government can demand keys, and cooperation from CAs, do MITM and so we are not secure.  i called this risk in 1992 or something.  took 22 years but here we are.
09:55 < jtimon> f they keep on doing stupid things like using databases without consistency they will go bankrupt
09:55 < pigeons> there is much moral hazard about that i'm not so sure that's true
09:55 < jtimon> but CAs are centralized
09:55 < jtimon> no?
09:56 < adam3us> jtimon: not fully, there are 100s of them in dozens of countries, operated by a variety of types of organizations.
09:56 < pigeons> yes CADs are centralized, but bitcoin also has "policy risk points" as adam3us says. exchanges, mining pools, etc that have aspects of centralization
09:58 < adam3us> anyway bitcoin/altcoin focus i think covenant language extensions are dangerous and we should not introduce them.  or we should do language extension with language level provable virality/centralization resisting limits
09:58 < jtimon> I don't know, apparently I  wasn't being able to make my point that, bitcoins != amlcoins
09:59 < jtimon> back to your "bitpay ports to amlcoin" example
09:59 < adam3us> jtimon: i think i get what you are saying.  that by imposing amlcoins, the "attacker" has created an alt-coin.  you are supposing its value will float to the extent that people will not willingly exchange them or wil lthink hard about it
09:59 < jtimon> there will still be people that have eyes to see they're are different currencies
09:59 < adam3us> jtimon: however teh value of the freecoin is heavily hampered by not having access to exchanges.  that may defacto make its price quite close to the amlcoin floor
10:00 < jtimon> so the prices will (at first slightly) differ
10:00 < jtimon> people paying with bitcoins don't want to have their btc valued as if they were amlcoins
10:01 < jtimon> and suddenly the impossible happens: bitpay2 appears
10:01 < jtimon> wait wait
10:01 < pigeons> and there are now more things you can buy with amlcoins than with bitcoins
10:01 < adam3us> jtimon: your argument is analogous to the "attacker creates" alt in commited tx, yes i do get the argument.  but i am not sure the economics work for it in this case.  because the choice is severely limited, and the fungibility reduced which in tur affects the value.  the outcome depends on the balance between preference for freecoin (price up) and loss of fungibility/virality (price down towards amlcoin)  my guestimate is freecoins lose an
10:01 < jtimon> you're now saying that all exchanges in the world will abandon bitcoin in favor of nsacoin at the same hour?
10:02 < pigeons> and yes you lose the advantage of bitcoins, but here is where you have faith that people will see that and reject the amlcoins, but this i would bet against
10:03 < adam3us> jtimon: well its a given that the main risk to bitcoin is regulation.  exchanges alredy impose AML due to regulation.  if we give them a way to make aml viral, i predict governments will seize and make that mandatory
10:03 < jtimon> ok, we found were we disagree
10:04 < jtimon> you think people are too dumb to distinguish between bbitcoin and amlcoin and the people who undesrtand it won't be able to explain it to the world
10:04 < pigeons> not too dumb, just less concerned about the ideals of the issue and more concerned with getting a transaction done
10:05 < jtimon> so I could as well make a falsefreicoin covenant with a demurrage that goes to me instead of miners
10:05 < jtimon> sell them into existence for bitcoin at 1:1 ala mastercoin
10:06 < jtimon> but if bitpay moves from bitcoin to falsefreicoin nobody will notice the difference
10:06 < adam3us> jtimon: it might work :) look at all the scamcoins
10:06 < jtimon> scams work for a while
10:06 < pigeons> and external factors will use these tools to force the social and economic environment so that using amlcoin is either simpler and easier, or the only option for the things the user/business/customer wants to do
10:06 < jtimon> let's see how the scamcoin thing looks in a year
10:07 < adam3us> jtimon: so you agree that bitcoin with no access to exchange services is almost certain to have a lower price?
10:07 < adam3us> jtimon: indeed i hope the scam coins all die :)
10:08 < jtimon> would have a much lower price, yet, I just don't believe anything in the world can close all bitcoin exchanges at once
10:08 < pigeons> no access to large public, in the open, exchange services? because exchange services can take many forms
10:08 < jtimon> why would btcchina care about nsacoin?
10:08 < pigeons> why does it have to be at once?
10:08 < adam3us> jtimon: and similarly i agree with your concept that a freecoin is worth more than an amlcoin in a way slightly perhaps analogous to virgin coins being apparently already worth a premium over used coins
10:09 < pigeons> it inches toward more useful to merchants and users as bitcoin inches aways from it
10:09 < adam3us> jtimon, pigeons: well access to btc-china for non-chinese resident is not  given.  watch the 10% spread bitstamp to mtgox.
10:09 < jtimon> pigeons if it's one by one, btc will start with more exchanges than nsacoin and your arguments are reversed: nsacoin are worth nothing because you can only trade them in 1 exchange
10:09 < stonecoldpat> adam3us: do you mean that a freshly minted coin from miners, has a premium over previously used coins?
10:10 < adam3us> stonecoldpat: apparently yes.  there was someone selling virgin coins for a premium
10:10 < stonecoldpat> haha fantastic
10:10 < pigeons> well my argument isnt about price, im not concerned with the price, im concenred that amcoin adoption and usage forces out bitcoin adoption and usage
10:11 < adam3us> pigeons: yes but jtimon asserts that the freecoin->amlcoin leakage would be stemmed if freecoins become worth a lot more than amlcoin so the price comes into it.  i expect the reverse in net tho there are economic forces pushing in both price directions
10:11 < jtimon> stonecoldpat: I think only if they can buy them anonymously since this way "nobody" knows the source
10:13 < stonecoldpat> jtimon: yeah i guess so - its quite interesting ti has a premium, i guess zero coin should be renamed virgin coin - although the coins link to prev transactions is defo an interesting problem
10:14 < adam3us> jtimon: i would like it if this were the outcome (two alt form, and most people dont use amlcoins) however the regulators have high control over the interfaces to the banking network so it seems the loss of fungibility would create a stronger price down force than the freecoin prefering audience would be able to counter with their econoomic preference
10:14 < stonecoldpat> although removing a coins link* to prev transactions is defo interesting
10:15 < adam3us> stonecoldpat: i suppose another indication is apparently people pay fees to mix coins to reduce the link
10:15 < pigeons> i think even without building toolkits to give regulators/etc an easier time, it will still be an uphill challenge to keep this sort of thing from happening through less technical means not integrated into the protocol
10:16 < stonecoldpat> adam3us: yeah ive seen that mentioned in a few papers (think someone thought of a protocol to do it too without third party?), if i had bitcoins to mix i perosnally wouldnt trust them though
10:17 < jtimon> stonecoldpat: coinjoin solves it by anonymous p2p mixing
10:17 < jtimon> coinswap is even more effective
10:17 < adam3us> pigeons: yes.  bitcoins decentralization comes from users controlling code.  what happens when microsoft makes an auto-updatable microsoft bitcoin wallet, or apple.  lots of captive users subject to the proxy decisions of central risk point with a history of government backdoors/over-compliance
10:18 < adam3us> stonecoldpat: yes coinjoin does that (trustless mix, the mix cant take your coins)
10:19 < pigeons> not that innovation should be abandoned because it can be abused, but the potential consequences should be taken very seriously
10:19 < adam3us> pigeons, jtimon: i'd sooner focus energy on trying to architect to defend against that kind of centralization risk (eg committed tx) than getting too far with potentially decentraliztion-risky expansion of script language language power
10:20 < adam3us> pigeons: which is to say probably covenant risks were considered by satoshi during his selection of the script-language.  i expect.
10:21 < adam3us> road to hell is paved with good intentions, pragmatic programmers, fun science experiments etc.
10:21 < pigeons> hey, we can learn whatever lessons we can from freimarkets authorizers and such hopefully
10:21 < jtimon> adam3us: maybe satoshi didn't thought that much about the language choice
10:22 < jtimon> of course p2p currencies rely on free software, despite Nestcoin users ignoring that
10:22 < adam3us> pigeons, jtimon: well just to say consider virality risk as a security defect, and make sure new script feature dont introduce it.
10:22 < jtimon> what is the commited transactions risk?
10:23 < adam3us> jtimon: commited-tx is a mechanism to reduce the policy control from centralization in  miners.
10:23 < adam3us> jtimon: by making them mine on opaque blobs so they have no information to form policy decisions on (they cant tell who is paying who how much at the time of mining)
10:25 < jtimon> by the way, some of your argumentation against covenants sournd to me like that: "bitcoin will fail because people will prefer easy-to-use proprietary clients and then they'll get screwed"
10:25 < jtimon> oh, I remember
10:25 < adam3us> jtimon: free software.  yes but if someone commercial makes a nice shiny wallet, maybe people will use it.  watch skype success while there were free FOSS voip at the same time
10:25 < jtimon> I though it was another risk
10:26 < jtimon> again, unlike you I'm not very concerened about the censor miners "problem"
10:26 < jtimon> but that's not a problem with voip, only with skype
10:27 < jtimon> it's like saying "linux is flawed because many people prefer windows or macos"
10:27 < adam3us> jtimon: hmm yeah but i've been here before, was worried about CA risk, and it turns out that i was basically right, even tho everyone at the time was like ... nah they wouldnt do that, it would be detectable ,etc and now we see the NSA spent billions doing just that.
10:28 < pigeons> i'll have to read that discussion. i've always been of the satoshi/luke-jr school that miners decide what transactions to include. but satoshi's views where from when all nodes were mining and there could be a wider marketplace for transactions
10:28 < adam3us> jtimon: its not a bitcoin flaw, but it could become a problem perhaps.  clients are individually less powerful.
10:28 < jtimon> that's another fallacy adam3us, just because you were right that time it doesn't mean you're right this time, argument of authority
10:29 < adam3us> jtimon: ha ha, yes you are right.  i just mean as an example that seeming paranoid by todays horizon of considerations doesnt mean you are wrong
10:30 < jtimon> nothing wrong being paranoid, I agree
10:30 < jtimon> just happens that the points where I get paranoid and where you get paranoid are not the same
10:30 < pigeons> jtimon: i agree with your characterization of the argument, "a danger to bitcoin is users taking least resistance paths" but i disagree that means "linux is flawed because of windows" i think its more " be aware of this tendency and engineer more p2p enabling choices to be least resistance"
10:31 < adam3us> pigeons: yes committed tx aims to change that.  minrs have no clue what they accepted.  users chose.  pairs of consenting users should be able to pay each other with no censure, or decide their own policy.
10:32 < jtimon> I agree that having an in-chain anonymous transfer mechanism could be would for several reasons
10:32 < jtimon> I think it could operate alongside a "public" one
10:33 < jtimon> but I tend to like more petertodd's inputs-only transactions (although it's less developed)
10:33 < adam3us> jtimon: there is an argument that if miners became too centralized, they may try to block non-public ones (or transactions with non-public xfer in their history)
10:34 < jtimon> maybe because I tend to get lost in your crypto spell scrolls...I mean...formulas
10:34 < jtimon> yeah, we discussed it other day at lenght
10:35 < jtimon> my argument was that censor miners would rapidly go out of business
10:35 < adam3us> jtimon: the counter argument is that if clients consider evidence of suppression of non-public xfer as an invalid mining event, then hostile miners form an alt-coin with no users, and so they make no profit
10:35 < adam3us> jtimon: i agree.  its like the amlcoin argument u made in some ways.
10:35 < jtimon> of course, I was assuming the distribution has ended, that risk is higher now I guess
10:36 < adam3us> jtimon: not if its done right because users would ignore those miner, so the hostile-miner is on a chain that becomes orphaned or like an alt-chain that is irrelevant
10:36 < jtimon> and I guess is also good that freicoin only has 3 years of issuance ;)
10:36 < pigeons> well i know a few miners who see the control they exert as protecting the network from things like spam transactions
10:36 < adam3us> jtimon: so even their reward would be lost
10:37 < pigeons> and things like the address-reuse deprioritization wouldnt be possible i suppose
10:37 < jtimon> how and why would users ignore censor miners and how they find out what blocks are censored?
10:38 < adam3us> pigeons: the fact that we have pools at all people seem to think was an unfortunate unforseen technology limitation.
10:39 < jtimon> well, my argument is the same that with the ghash.io topic p2pool/eligious pools are not a problem
10:39 < adam3us> jtimon: well thats the objective, to arrange that this would happen.  for it to happen unfortunately i think only committed-tx can be considered valid.  or all clients have a button in them or a switch over mechanism that public tx can be disable in event of widescle problems
10:39 < adam3us> jtimon: its a technical insurance policy or threat.
10:40 < jtimon> I think inputs-only transactions would have a similar anonymity effect and they seem more scalable to me
10:40 < pigeons> its a shame it seems like its not technical limitations keeping p2pool adoption from increasing as much as places like ghash
10:40 < jtimon> and also more "compatible" with regular txs
10:40 < adam3us> jtimon: how does that work?  do u mean where the output is p2sh so the miner cant tell who it is being paid to?
10:41 < pigeons> and its not technical limitations why stratum is much more widepread than gbt
10:41 < pigeons> but yeah the limitations existed at the time pools emerged and grew
10:41 < adam3us> pigeons: ghash also has lots of hw in their datacenter.  but the herd mentality that gets people to give % of their mining reward to miners when it is not necessary is strange yes.
10:43 < adam3us> jtimon: if inputs-only means output addr is obscured via p2sh i think its significantly weaker mechanism.  most of the policy relates to history not static receipt address censor.  its easy to make new addresses (or sender derived address like stealth)
10:43 < jtimon> adam3us: this is ptertodd's very open design https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html
10:44 < jtimon> but let me summarize the way I see it integrated with regular transactions
10:45 < jtimon> transactions only include inputs, not outputs, and miners only include them if none of the inputs they contain have been seen (you need expiries in the TXI set for scalability)
10:46 < jtimon> the inputs may actually be garbage, refer to outputs that don't even exist
10:46 < jtimon> and all the history of the outputs is transmitted directly between users, it doesn't touch the chain
10:46 < jtimon> makes sense?
10:47 < jtimon> well, I haven't really though much about interoperate with regular transactions (going from private back to public)
10:48 < jtimon> the main problem here seems to be: how fees are paid?
10:48 < jtimon> and the only answer seems to be pow fees
10:48 < jtimon> petertodd doesn't go beyond that
10:48 < jtimon> I think you could have a regular blockchain
10:49 < jtimon> and optional pow fees
10:49 < jtimon> which miners can somehow "add" to their per-block PoW
10:50 < jtimon> maybe you want ot combine it with the "orphan blocks count for the total pow of a given chain" thing on that academic paper
10:50 < adam3us> jtimon: btw the first half of that writeup was stuff i summarized to petertodd (the entanglement, timestamp/namespace/minimum validation required) he could've mentioned it... i didnt read the rest of it before to see the txin proposal.  it seems like a subset of comitted tx
10:51 < jtimon> yeah, seems very similar
10:53 < adam3us> jtimon: he could've alternately written "hey here's some stuff adam told me he explored, and i have another idea why dont we tweak committed tx to expose the txin" :)  i think that is a more accurate summary of what he wrote.
10:54 < adam3us> jtimon: the thing is as i said above probably the bulk of the policy risk is based on the history.  the thing about passing history around off-chain was in the committed-tx writeup
10:55 < jtimon> if he had done that I would have explained the txin proposal to you much faster ;)
10:56 < adam3us> jtimon: and to include clear txt tx-in exposes history.  or alternatively if the txin  is unlinkable because its never published (its ambiguous at the end) then what he wrote IS committed-tx
10:56 < adam3us> jtimon: (yeah sorry i was reading the post so i didnt see your explanation above until you wrote quite a bit you were writing while i was reading)
10:57 < jtimon> np
10:58 < adam3us> jtimon: i think gmaxwell said in the committed-tx thread it might nearly but not quite be implementable with script.
10:58 < jtimon> that post of him, reminded me a discussion Ryan and I had about a txid-only chain for one of our ripplecoins
10:59 < jtimon> we wanted to put the powin transactions
10:59 < jtimon> if you made the pow on top of another transaction, the pow was "summed up" (we didn't thought in detail about that PoW addition operation)
11:00 < jtimon> so people will commit their transaction on top of the longest chain they see
11:01 < jtimon> and then we needed a git-like merge
11:01 < adam3us> jtimon: yes i was wondering about something like that.  i had a PoW variant with addition, however it is very approximate addition and has variance reduction so creates mining fairness issues.
11:01 < jtimon> but we realize that didn't prevented doublespendings ;(
11:02 < jtimon> adam3us: ok, but it's good to know that it's not completely impossible
11:03 < adam3us> jtimon: well ghost protocol could reduce sensitivity to how long it takes to reach consensus (ie not so concerned about orphan rate anymore).
11:03 < jtimon> I think it started here? https://bitcointalk.org/?topic=4382.0
11:05 < jtimon> disclaimer: we were mainly interested in ripple, so we just really wanted a minimal p2p timestamping mechanism
11:05 < adam3us> jtimon: i was thinking of something related that ideally you would like to allow users to direct mine for small reward without pools and ended up with something ghost-like.  i was thinking its too complicated and the incentives looked like they could work but wre also more complicated rules, and maybe more bandwidth a bit.  so i thought this is too inellgant.  seemingly the ghost authors thought it ok.
11:05 < jtimon> if this tx id gets into the chain before expiry, all the sub-txs in it are valid, otherwise none is valid
11:06 < adam3us> jtimon: i see in the rfugger thread u linked that you and he had a similar idea about building on non-conflicting orphans.  why not indeed, link them all in by reference.
11:06 < jtimon> sorry don't know ghost
11:07 < jtimon> my latest idea as said was that miners added the user's tx-pow to their block pow
11:07 < adam3us> jtimon: there is an academic paper.  they claim if you dont ignore orphans but hash into the coinbase non-conflicting orphans and change a few things you can have faster block interval without convegence problems
11:08 < jtimon> oh, that's ghost? yeah, that's what I meant by "" maybe you want ot combine it with the "orphan blocks count for the total pow of a given chain" thing on that academic paper "" earlier
11:09 < adam3us> jtimon: see it seems to me desirable that a user can claim anytime during the 2week retarget period any work of even small value.  then we have less centralization risk.  now a way to do that is separate reward from voting.
11:10 < jtimon> the users reward is getting their transaction into the block, why would they get anything else?
11:10 < adam3us> jtimon: so why not mine on a public key that you use to vote..  then the voting power of the public key is related to the amount of pow on it.  and you can use it with a sort of PoS like vote
11:10 < adam3us> jtimon: i mean not specifically about your per tx pow, but that i wanted to be able to solo mine say 0.01 btc and claim it relyably without needing pools
11:11 < jtimon> what's the purpose?
11:11 < adam3us> jtimon: dislike of mining pool cenrtalization risk :)
11:11 < jtimon> the purpose of mining is validation not distribution
11:12 < adam3us> jtimon: so i tried to explore how could i solo mine.  one answer is to be able to mine for smaller amounts.
11:12 < jtimon> but if you're mining old stuff, why should the network reward you?
11:12 < adam3us> jtimon: agreed.  but maybe it can be a two stage process.  stage 1 mine for small coinbase-like reward, stage 2 use PoS on the coinbase reward to vote for fee reward
11:13 < jtimon> I tend to distrust PoS
11:13 < adam3us> jtimon: u would be mining only your public key.  its a kind of micro-level PoS within the 2 week retarget interval only or something
11:14 < jtimon> in freicoin the retargetting is 9 blocks and if bitcoin ever hardforks I would suggest to update to our filter too
11:14 < adam3us> jtimon: agreed PoS is not economically attractive.  centralization of vote via money instead.  not pretty. and many PoS have actual protocol defect to allow mining on multiple candidate block sin parallel so devolve to PoW
11:15 < jtimon> "mining only your public key" how do you mine "on a public key"?
11:15 < adam3us> jtimon: my idea is not at a working stage, this was just as close as i got .
11:15 < jtimon> oh, I see
11:16 < justanotheruser> Do you think PoS could ever work in a currency?
11:16 < adam3us> jtimon: the idea is mining is like to get the right to vote on what the next block is. so i though well why cant i mine on a signature key, and then use the signature key to cast a weighted voted.  maybe i can get the same feature but with more flexibility in minimum mining contribution and minimum reward. and so less dependence on pools.
11:17 < adam3us> jtimon: but it tends to have problems.  could i sell the vote.  could i save up voting power for one transaction to double spend it etc.
11:17 < jtimon> ok, now I get the point
11:17 < jtimon> but I disagree on "the idea is mining is like to get the right to vote on what the next block is"
11:17 < adam3us> jtimon: if thsoe problems could be convincingly fixed, it might be quite interesting
11:18 < jtimon> the idea of mining is sequencing events irreversively
11:18 < adam3us> jtimon: correct, and to vote on their validity (for SPV client reliance)
11:19 < adam3us> jtimon: but interestingly the actual sequence doesnt matter, just that eveyrone agree on a sequence.  if they could do it via coin toss that would be just as good
11:19 < wallet42> stealth addresses are base58_check encoded compressed pubkeys?
11:19 < jtimon> toss?
11:19 < adam3us> jtimon: (except for some issues with 0-confirm security model where network propagation such as it is provide some modest security)
11:19 < wallet42> whats the versionbyte?
11:20 < jtimon> justanotheruser: I think ppc is less secure for having pos, but it would be much more insecure if it didn't had pow at all
11:21 < adam3us> jtimon: (this was part of the entangled design discussion i had with petertodd that he wrote about it a bit in that same post.  at the lowest level you could obtain a distributed consensus sequence from a distributed timestamping service)
11:21 < jtimon> justanotheruser: apart from the "I buy the system to destroy it" attack, as adm3us pointed out: "many PoS have actual protocol defect to allow mining on multiple candidate block sin parallel so devolve to PoW"
11:22 < jtimon> adam3us, of course, the challenge is the infinitely scalable p2p timestamping system
11:22 < adam3us> justanotheruser: gmaxwell gave some arguments that PoS fails because users can rationally vote on both sides of a fork, or on many forks to get higher voting power so it devolves to PoW.  so i think it doesnt quite work in practice with the consensus mechanism as anyone can construct multiple candidates
11:24 < adam3us> jtimon: yes.  well my offline exploration was to see if you could pull the bitcoin design apart, work out the minimum required dependency and features and put it back together in another way with any useful improvement.  that experience led me to declare bitcion design is "entangled" because many security features rely back on the same PoW chain.
11:25 < adam3us> jtimon: and also to declare bitcoin only just works, or the design is fairly optimal.  because each design change i considered of dozens always made things worse or more complicated or less efficient.
11:25 < jtimon> yeah, I agree, I have made similar journey while exploring possibilities for ripplecoin (where the hostcoin was actually more of a problem than a requirement)
11:25 < adam3us> jtimon: the ghost idea was one of these, but i considered it wrose because its more complicated  perhaps i was too hasty on that one they claim its a useful design alternative.  apparently ethereum is considering it.
11:27 < jtimon> adam3us: it looks interesting to me, but of course that doesn't solve all the scalability problems, is just a little bit of help
11:27 < adam3us> jtimon: at this point i would've taken any improvement :) my exploration of the design space was a failure.  pools do seem a problem worth removing.
11:29 < stonecoldpat> are miners pools not just a natural process that cant really be removed? It's a bit like industrialisation...
11:29 < adam3us> jtimon: but like i say adding an indirection between mining and voting seemed to create perverse behavior opportunities with like saving up voting power for one moment of abuse (hashcash had this problem) or selling votes
11:30 < adam3us> stonecoldpat: well one thing is industrial scale mining, thats perhaps somewhat inevitable.  the other thing is people giving their vote to a pool operator while it is the user actually with the mining power.  that should be avoided if we could find a way IMO
11:31 < stonecoldpat> is the vote to choose the correct branch? or how to distribute the coins?
11:31 < stonecoldpat> i remember having a thought about this before christmas (how to distribute coins) - i seen it as a pretty bad problem
11:31 < adam3us> stonecoldpat: correct branch and form part of a kind of distributed signature attesting all the transactions are valid
11:33 < stonecoldpat> adam3us: i dont know if a distributed signature is really necessary, a block with an incorrect transaction won't be accepted by the rest of the community (unless this pool has over 50%) - so it is in the interest of the pool lead to verify the transactions are correct
11:33 < stonecoldpat> adam3us: and choosing the correct branch is hard - since they are both correct. it may lead to greater vulnerabilities (by tricking the voters) - im sure some politician tactics could be deployed
11:33 < adam3us> stonecoldpat: yes but the SPV (smartphone/limited bandwidth) clients accept whatevr is claimed by sampling a few nodes
11:35 < adam3us> stonecoldpat: so eg a smartphone may download only the hashchain and ask for merkle proof that a tx is in a block, and then just assume its valid.  if someone can get enough power to create 6 blocks they could print money in the eyes of SPV clients... so i just mean the distributed signature in the sense that it is hard for someone with << 50% of hash power to win 6-blocks in a row
11:36 < adam3us> stonecoldpat: yes if all candidate blocks are valid tossing a coin to choose a block at random would be just fine.
11:44 < Luke-Jr> I wonder if stealth addresses can be combined with P2SH^2 somehow
11:46 < jtimon> stoencoldpat: the network will never accept an invalid transaction no matter the % of hashing power, the only thing 51 attackers could do is change the order (for double-spending purposes?) or freeze the chain
11:47 < jtimon> stoencoldpat: if you have ideas for coin distribution, maybe you're interested in this: http://foundation.freicoin.org/#/about
11:48 < jtimon> adam3us: about your "pools problem" what about this other approach: *somehow* prevent non-p2pool pools from mining
11:48 < jtimon> adam3us: solo miners could only mine on their own p2pool alone
11:49 < jtimon> /only/always
11:49 < Luke-Jr> jtimon: p2pool isn't special
11:49 < adam3us> jtimon: yes that is an interesting direction (prevent pool security) amiller had some idea relating to this.  i dont think it quite worked however
11:49 < Luke-Jr> there is no reason to prefer it over other decentralised schemes
11:50 < jtimon> Luke-Jr I thought it was (and by p2pool I include eligious, just exclude "centralized pools")
11:50 < adam3us> jtimon: i have a friend who elects to solo mine as a kind of lottery.  it'll take him years to get $25,000 payout.  the limitation is that.  if the reward could be made less lumpy maybe.
11:51 < jtimon> maybe that term is more appropriate centralized vs p2p pools
11:51 < Luke-Jr> jtimon: p2pool is a specific pool, both decentralised and also p2p
11:51 < Luke-Jr> jtimon: BitPenny was the original decentralised pool ;)
11:51 < jtimon> I see
11:51 < Luke-Jr> unfortunately, they died out
11:51 < jtimon> well, I think most frc pools are based on p2pool software, that may have contributed to my confussion
11:52 < jtimon> in frc there's only centralized pools and p2pools
11:52 < Luke-Jr> makes sense, GBT isn't feasable for FRC as-is
11:53 < jtimon> my point for adam3us was "instead of thinking about micro-mining, think of a way were only p2p pools are allowed"
11:53 < forrestv> as usual, Luke-Jr ignores other benefits of p2pool
11:53 < Luke-Jr> ok, but my point is that p2p is a bad thing; what you want is decentralisation
11:53 < forrestv> 's complete decentralization
11:53 < Luke-Jr> forrestv: there are none, to the network
11:55  * jtimon doesn't understand the difference between decentralized and p2p in this context
11:57 < Luke-Jr> jtimon: decentralised = miners create the blocks; p2p = there's no server to coordinate things
11:58 < jtimon> I see, yeah decentralized is enough since all miners validate everything, no?
11:58 < forrestv> Luke-Jr, you really need to use a name other than "decentralized," considering that eligius definitely has a central server..
11:58 < Luke-Jr> well, all nodes validate everything, miner or not
11:58 < Luke-Jr> forrestv: the mining isn't centralised though
11:58 < jtimon> I mean, in a centralized pool, a miner only hashes, doesn't see anything else
12:00 < jtimon> the validation node of a centralized pool can do more harm than the coordination server of a decentralized pool
12:00 < adam3us> jtimon: agreed
12:01 < adam3us> jtimon: a way of putting is it that miners are giving their vote to the pool.  they should exercise their own vote, by doing their own validation
12:01 < jtimon> I don't know how this could work, probably changing the PoW, just wanted to inspire you adam3us
12:01 < Luke-Jr> jtimon: it cannot work.
12:02 < Luke-Jr> jtimon: if you take away centralised mining, hosted mining will flourish
12:02 < jtimon> I don't really like the word vote, then people say stupid things like "miners vote the rules of the system"
12:02 < Luke-Jr> "voice" perhaps
12:03 < adam3us> Luke-Jr: hosted mining is even worse, so that is a bad game theory outcome.
12:03 < helo> shoehorn?
12:03 < jtimon> which degenerates in even more stupid things like "scrypt is more democratic than SHA256"
12:03 < Luke-Jr> adam3us: that's my point
12:03 < Luke-Jr> adam3us: stopping hosted mining is impossible, and that's what we'll get if we take away centralised mining
12:04 < adam3us> Luke-Jr, jtimon: it seems to me what you want is a mining algorithm with diseconomy of scale.  not sure if that is significantly possible however
12:04 < jtimon> Luke-Jr, why?
12:04 < sipa> Luke-Jr: decentralized != trust-free
12:04 < sipa> Luke-Jr: eligius is trust-free, but centralized
12:04 < brisque> "hosted mining" is a sham anyway. there's no reason anybody would rent out mining equipment unless they're expecting their customers to take a loss.
12:04 < jtimon> sipa: yeah, I guess that's the word we were looking for: p2pool and eligious are both trustless pools
12:05 < sipa> yup
12:05 < Luke-Jr> sipa: that might be better terminology, but it's not the common terminology already in use
12:05 < adam3us> Luke-Jr: does eligius reject/not support non-GBT shares?
12:05 < Luke-Jr> adam3us: Eligius supports all protocols at the moment
12:05 < sipa> Luke-Jr: i don't think anyone but you considered eligius decentralized (i know it satisfied some definition of decentralized that's common, though, but not all)
12:06 < adam3us> Luke-Jr: so its trustless to the extent users use GBT then
12:06 < brisque> Luke-Jr: what sort of percentage of users use GBT over stratum?
12:06 < Luke-Jr> brisque: probably near zero :/
12:06 < sipa> trust-free doesn't mean you cannot trust anyone - it just means you don't need to
12:06 < Luke-Jr> the solution is to make decentralised mining just as easy/painless as centralised mining
12:07 < Luke-Jr> sipa: trust-free implies more than decentralisation IMO
12:07 < adam3us> Luke-Jr, sipa: so it seems to me there is some pain. the bw consumption.
12:07 < brisque> Luke-Jr: imagine i'm a miner, is there an incentive for me to use GBT on eligius over Stratum?
12:07 < Luke-Jr> brisque: only for the good of Bitcoin
12:07 < jtimon> Luke-Jr open transaction is trustless but centralized
12:08 < brisque> Luke-Jr: mm, there's the reason why lots of people don't use it.
12:08 < sipa> Luke-Jr: they overlap, but neither implies the other
12:08 < sipa> jtimon: trust-free to an extent - you still need to trust the issuer
12:08 < Luke-Jr> sipa: p2p != decentralisation
12:09 < jtimon> sipa : for non-p2p currencies you always need to trust the issuer anyway
12:10 < jtimon> if you issue usdCoins using colored coins is no different
12:11 < adam3us> jtimon: i think there are two aspects to trust for issued units.  1. the issuer to redeem, maintain 1:1 backing, 2. the network to secure ownership transfer.  so it can still make sense to use decentalized ownership tracking (blockchain) for an issued asset.
12:12 < adam3us> jtimon: (you probably would personally redeem by selling to the unit for another crypto curreny or on an exchange, not via redemption with the issuer)
12:12 < jtimon> adam3us: my point is that, despite being centralized, you don't need to trust the OT server
12:13 < adam3us> jtimon: agree.  i just mean with open transactions you need to trust it for some things but not others  i think in their terminology an issuer is a different entity from a tx server.
12:14 < jtimon> yes, the same issuer can operate in different OT servers at the same time
12:15 < jtimon> the main problem with OT is you can't trade assets that are in different servers atomically, you have to move them all to the same server first
12:15 < stonecoldpat> adam3us: it would certainly add extra-security (if thats a phrase), but the way im thinking about it ... SPV clients arent really part of the hashing power (as they are not mining). As you said - they are just observers. So you would still need to trick over 50% of miners for the attack to work. my comment is probs a bit old now (got distracted at work)
12:15 < adam3us> anyway on the decentralization from pools.  its good that eligius supports GBT and more users should use it.  Luke-Jr is also right that hosted mining is likely even worse.  but an even better outcome would be if there was a way to not need pools.  ie to solo mine with reasonably frequent and predictable payout.
12:16 < jcrubino> does there need to be any protocol level changes for stealth addresses?
12:16 < Luke-Jr> adam3us: I don't think that's very practical on a wide scale.
12:16 < adam3us> stonecoldpat: heaven forbid to let work distact from btc :)  yes i recall the context.  this is true.  but there could be a large payout  you could mint millions and millions of $ of tx that didnt even exist and an SPV client would temporarily accept it
12:16 < Luke-Jr> adam3us: for the low variance many miners want, you *need* to keep a running balance somewhere
12:17 < jtimon> jcrubino: I don't think so, just the payment protocol
12:17 < adam3us> jcrubino: i do not think so.  just client work.
12:18 < jcrubino> and does anyone in here  have bitcoin-dev mailing list archived from the beginning?
12:18 < adam3us> Luke-Jr: yes i am talking spherical cows territory  like changing the minimum reward.  having 100s of mini-rewards per block, such things
12:18 < Luke-Jr> jcrubino: I think SF has an official archive
12:18 < jcrubino> Luke-Jr: can I download it all at once?
12:18 < Luke-Jr> no idea
12:21 < jcrubino> hmm
12:21 < jcrubino> I want to try to do a topic mapping of the messages
12:22 < adam3us> jcrubino: maybe wget -r from the right base url might do the trick
12:24 < jcrubino> adam3us: It looks like the actual messages are id with every other message on SF
13:27 < michagogo|cloud> ;;seen andytoshi
13:27 < gribble> andytoshi was last seen in #bitcoin-wizards 12 hours, 30 minutes, and 7 seconds ago: <andytoshi> i assume jon matonis was involved in that list ..
13:28 < michagogo|cloud> ;;later tell andytoshi Did you make any more progress on the cj client? Let me know if/when it's ready for more testing.
13:28 < gribble> The operation succeeded.
13:32 < wallet42> so stealth addresses are base58_check encoded compressed pubkeys? whats the version byte?
14:25 < justanotheruser> Is it possible to make an easy to confirm hashing function that involves all the previous confirmed tx?
14:26 < justanotheruser> *easy to validate
14:33 < gmaxwell> justanotheruser1: you mean what we're already using in Bitcoin?
14:34 < justanotheruser1> gmaxwell: no I mean your idea that would require miners to have the blockchain
14:35 < gmaxwell> justanotheruser1: I assume you mean easy to validate you mean fully validatable by someone who doesn't have that data?
14:37 < justanotheruser1> gmaxwell: no. I mean easy to validate in general. I thought of two methods, one where the hash you generate would require you to look up a tx based on that hash and include that in a new hash, but I think miners would just end up trying to find hashes of the tx in their cache to circumvent that. The other method I thought of involved having each tx be at the leaf of a merkle tree and the nonce be an adjacent leaf, but that would be hard 
14:38 < gmaxwell> justanotheruser1: I thought I described such an approach in the post about that?
14:38 < justanotheruser1> gmaxwell: I haven't seen your post, just the wiki page. Could you link me it?
14:39 < gmaxwell> you can use the block header to force you to do N lookups and make a hash tree. And then you use the hash of the solved block to select which M of those N lookups to publish.
14:39 < gmaxwell> This way you can publish a relatively small number of values, but grinding the preselection isn't too effective because it's picking N.
14:41 < gmaxwell> e.g. 32 random lookups is not going to do well with a small cache. And then you find a block and you're forced to prove one of them.
14:41 < justanotheruser1> gmaxwell: So N is generated based on the block header?
14:43 < gmaxwell> e.g. H(prev header) tells you to pick N transactions at random. you include a hashtree over them in your block. H(your header) tells you which of the N to include with your solution.  (this can be pooled, to prevent pooling for it, you'd need to put it in the inner loop which makes the pow utxo throughput hard)
14:44 < gmaxwell> I'd also suggested a simplified version where you just do queries on the inputs consumed in the prior block. The rationale being was that we really just wanted you to prove you had the required data to do the validation.
14:45 < justanotheruser1> Why not make H(Prev head) also tell you which N to include? Couldn't miners modify the header to make it so they only have to look at the 1mb of tx they have?
14:45 < justanotheruser1> (in a hypothetical situation where miners only store 1mb of tx to save space)
14:47 < gmaxwell> previous header. as in the prior block.
14:49 < justanotheruser1> gmaxwell: yes, but you are using "your header" to find the block. Couldn't a malicious mining pool make it so their header tells them that they have to include only tx in the set of tx the miners own?
14:49 < justanotheruser1> s/to find the block/to find the tx for the block
14:50 < gmaxwell> only by doing N fold the work of finding a block.
14:52 < justanotheruser1> gmaxwell: well the work of finding a block is memory hard, but finding an easy header isn't.
14:53 < justanotheruser1> unless there's something I'm missing
14:53 < gmaxwell> I have no freeking clue what you're talking about there.
14:54 < gmaxwell> The only point of the proposals of preventing people from mining without the blocks was to stop botnets that just mined using the headers and processed no txns.
14:54 < gmaxwell> The explicit goal of that was not to make the POW memory hard.
14:57 < justanotheruser1> gmaxwell: I thought the purpose was to keep centralized pools that don't require blockchain ownership infeasible
15:00 < maaku> adam3us: there would need to be some infrastructure for recognizing and handling covenants at the user interface level.
15:00 < maaku> users will probably have to whitelist which covenants are accepted under which circumstances... there are some nontrivial problems here.
15:00 < gmaxwell> No. If you want to do that then you need a utxo query throughput pow where the hardness comes entirely from random queries.
15:00 < maaku> but they are solveable. certainly the default should be that added covenants are non-fungible. this is part of why a strongly-typed, simple, theorum-proovable language should be preferred. that way a wallet could ignore / cordon off incoming coins which can't be proved to be covenant-free
15:00 < maaku> and that should certainly be the default behavior
15:00 < maaku> the history of bitcoin is that making sane, conservative, paternalistic choices in the the operation of the reference wallet(s) sufficiently influences the community to keep all but the most determined people from shooting themselves in the foot
15:01 < maaku> but on the whole there are some definite advantages, such as the p2p lending case which was an outstanding unsolved problem
15:01 < maaku> and it has the advantage of the covenant rules being unchangeable / unbreakable. our existing KYC system for example gave the authorizer the ability to vet transactions involving their assets using whatever metric they want at the moment whereas covenants require them to commit to rules upfront.
15:01 < maaku> that's a definate improvement from the user's perspective.
15:02 < maaku> jtimon: you can save significant block chain space, as well as avoid many difficulties with demurrage / interest if you have explicit assets at the protocol level, in which case it also makes pragmatic sense to have token-based issuers
15:02 < maaku> you could do away with token-based authorizers, although adding them would only be a couple of lines of code at this point. they have somewhat different properties
15:02 < maaku> adam3us gmaxwell: please correct me if i'm wrong, but I think greg's opinion is that permanent covenants attached to a non-demurrage host currency is a Bad Idea. I concur. But make the covenants temporary, the coins themselves perishable, or applied to user issued assets (not colored coins but separately issued assets a la freimarkets), and it is a different story IMHO.
15:02 < maaku> justanotheruser1: yes, PoS is an extremely valuable tool. Just not for consensus. People see "proof of X" and assume they substitute for each other. In fact they are entirely different tools with entirely different uses.
15:02 < justanotheruser1> maaku: what?
15:03 < justanotheruser1> Where was I talking about PoS
15:04 < maaku> [08:16:06] <justanotheruser> Do you think PoS could ever work in a currency?
15:08 < andytoshi> michagogo|cloud: i think it's working, now i ship a certfile (which i got from mozilla) along with libcurl DLLs that i built myself
15:08 < andytoshi> http://download.wpsoftware.net/bitcoin/cj-windows.zip
15:08 < jtimon> yes, maaku, we wouldn't remove the tagged assets with defined interest/demurrage
15:09 < jtimon> I'm thinking we might be able to replace validation scripts, thought I would like to check that case by case
15:11 < maaku> what for offers and stuff? I don't know, maybe
15:11 < maaku> it'd be a little convoluted
15:11 < maaku> /offers/options/
15:11 < maaku> the delegation opcode is pretty elegant
15:12 < jtimon> well, we use them in most of our examples
15:12 < maaku> you could move the relevant coins into an output with a covenant attached governing their next use in the option or whatever
15:12 < maaku> obviously that would work
15:12 < jtimon> I was thinking about using the same opcodes somewhere else, but I haven't thought about it deeply enough
15:12 < maaku> but I don't think it's a very natural, succinct, or satisfying situation
15:14 < maaku> i think there are many use cases where the conditions are most naturally applied to the transaction itself
15:14 < maaku> e.g. you are saying "I commit these coins to this particular transaction, but only so long as these additional constraints are met"
15:14 < adam3us> maaku: covenants do allow some things that are currently painful  think for example things involving hashlock could be made trivial.  but i think the more dangerous things are viral covenants that can apply to all further respends indefinitely
15:15 < jtimon> yeah, as said I haven't tried yet, I was just thinking about what could be replaced and what not
15:15 < jtimon> "viral covenants that can apply to all further respends indefinitely" I thought that was the definition of a covenant
15:15 < adam3us> gmaxwell: btw i asked djb and cfrg some questions about ed25519, will see if we get some clarity.
15:16 < maaku> jtimon: we can probably shuffle stuff around, if we start over assuming a more powerful scripting language
15:16 < andytoshi> adam3us: thx much
15:16 < maaku> but i wouldn't get rid of tx-level validation scripts
15:17 < maaku> adam3us: isn't there an rfc process going on? you might want to forward comments to those relevant mailing lists as well
15:17 < gmaxwell> for something like a colored coin, it would be a viral covenant— but one that would let you remove it if you ask nicely. It wouldn't allow you to _add_ it except under the right conditions.
15:18 < adam3us> jtimon: i am not sure.  i thought of something related, then found it described in freimarket, and finally read gmaxwell covenant thread.  maybe i am describing quinine vs covenant, in any case terminology aside a small group of transactions that restrict the next transation is useful, but recursive ongoing or language constructs that allow that by implication are I think existentially dangerous
15:18 < maaku> adam3us: covenants also allow you to do things which you can't currently do, at all (like restricted buy back)
15:19 < gmaxwell> and yeam my covenants thread was intended to point out the existential danger, and also show how easy any sufficiently powerful script can achieve that danger.
15:19 < maaku> that's a very serious pro against a very hypothetical con
15:19 < jtimon> adam3us: not english but I thought: quine = reproduction of code, covenant = viral perpetual quine
15:19 < adam3us> gmaxwell, maaku: yes some kind of language restricted limitation on the power of covenants would be a min-bar for safety i think
15:19 < gmaxwell> adam3us: it seems really hard to achieve that.
15:19 < adam3us> gmaxwell: precisely.  i think ethereum is creating unlimited danger as there are no restrictions and it is intentionally as general as possible
15:20 < gmaxwell> (achieve that while also permitting the good use)
15:20 < adam3us> gmaxwell:  right, hence dont do that please :)  aka i think satoshi as a guess figured out this risk hence the non-extrospection and so non-virality
15:20 < maaku> i think (for reasons obvious in gmaxwell's thread) that the default position should be that if a script cannot be *proven* to come with no strings attached, then it should destroy fungibility and not be treated as bitcoins by the clients
15:20 < maaku> relegated to the equivalent of a spam wallet
15:21 < gmaxwell> adam3us: one thing they may have done right by accident in ethereum is that they seem to have confined the fancy behavior to agents,... which can own coins. It's just a conceptual difference but perhaps a useful one.
15:21 < maaku> we can then experiment and slowly add functionality to allow users to enable certain covenants, pattern matched or detected by theorum proving
15:21 < adam3us> gmaxwell: see i too, once i finally caught up a bit with the aggregate bitcoin brainstormings, though hmm extrospection/limits on outputs, ooh you could do lots of things with that.  and then realize similarly to your convenants thread that this would be a singularly dangerous thing to do, and hence script probably looks the way it does for a reson
15:22 < jtimon> adam3us what do you think about maaku's suggestion of killing fungibility in the clients?
15:22 < gmaxwell> well if you admit theorem proving then you can test for non-virality. But not if the script is turing complete, I suspect.
15:23 < jtimon> gmaxwell: I think the validators maaku has in mind would answer a) It is not a covenant b) I don't know
15:24 < adam3us> jtimon: but that is just a client restriction, not a language, nor protocol restriction.  its better than nothing as defaults carry weight i guess. but only to that extent.  seems like playing with fire and surely there must be other ways to make conveniently composable sub transactions
15:25 < gmaxwell> lol, post on liberation-tech:
15:25 < gmaxwell> As one anecdote, when I TAed the MIT Network and Computer security
15:25 < gmaxwell> course, we assigned "Why Johnny Can't Encrypt" as the first reading.
15:25 < gmaxwell> We asked the students to send us a PGP encrypted & signed message and
15:25 < gmaxwell> tell us how long it took.
15:25 < gmaxwell> If I recall correctly, it took an average of 30 minutes for
15:25 < adam3us> maaku: ie isnt there something one could do to make hashlock convenient, or part of an explicit transaction group, or something that doesnt involve increasing the language power
15:25 < jtimon> adam3us isn't your "all exchanges will port to kycCoin" concern eliminated?
15:25 < gmaxwell> non-existing users to figure out how to use PGP. Think about that.
15:25 < gmaxwell> These were graduate & upperclass undergraduate computer science
15:25 < gmaxwell> students enrolled in a network security course. Everyone had accounts
15:25 < gmaxwell> on the same university system and were mostly using standalone email
15:25 < gmaxwell> clients.
15:25 < gmaxwell> Best of all, someone decided it would be funny to generate a fake key
15:25 < gmaxwell> for me and post it to pgp.mit.edu. Several students fell for the
15:25 < gmaxwell> trick, didn't verify the key, and encrypted their homework with the
15:25 < gmaxwell> wrong key.
15:25 < maaku> gmaxwell: sure you can, an inconclusive result is assumed to be worst-case
15:26 < jtimon> adam3us: the point of all this is precisely to increase the language power
15:26 < adam3us> jtimon: amlcoin via virality risk reduced not eliminated
15:26 < gmaxwell> maaku: ugh, okay I suppose. But you're going to be inclusive an awful lot of the time.
15:26 < adam3us> jtimon: well the point should be to allow contracts to be conveniently expressible  language power = danger also.
15:27 < maaku> over all of program space? sure. but that just means you restrict actual scripts used in the wild to those which are provable
15:29 < jtimon> gmaxwell do you share adam3us concerns on all btc becoming amlcoins without the dumb users noticing?
15:29 < adam3us> jtimon: so long as the contracts catalog that you consider as your benchmark are implementable in a turing completeness sense, with the current script language, maybe its better to focus on a translator from psuedo-legalese to script.  and add minimal script extensions to cover any gaps rather than going for eval like generality and trying to contain the damage
15:29 < gmaxwell> jtimon: Yes. It's not about "dumb" it's about having forced choice.
15:29 < jtimon> maybe maaku and I are too optimistic but to me it seems an exhageration
15:30  * adam3us is loathe to repeat that long thread
15:30 < jtimon> "having forced choice"? I don't understand
15:30 < gmaxwell> sure you could _choose_ to refuse to do business with this or that, or refuse to accept this or that coin. You could also choose to live in a cardboard box under the freeway.
15:30 < gmaxwell> Not all choices are meaningful, even in the presence of perfect information.
15:30 < jtimon> who forces you to accept amlcoins? who forces you to turn your btc into amlcoins?
15:30 < maaku> jtimon: well, we're also thinking about this in the context of having 5% of the monetary base refreshed annually
15:31 < adam3us> adam3us: but in summary as the regulators have much control over the gateways to banking infra, a viral amlcoin enforced at exchanges would already be enough i think
15:31 < jtimon> maaku and they think it from the perspective that deflation doesn't matter, so 1% of the current btc will be ok, and 0.1%, 0.001%...
15:32 < adam3us> jtimon: anyone who only accepts amlcoins that you have a poor choice with (no service or amlcoin, amlcoin as change because of the payment integrator they are using etc)
15:33 < jtimon> the way you talk about it, is like if btc would be dommed if bitpay and gox stopped accepting bitcoin and moved to ltc...
15:33 < andytoshi> adam3us: it occurs to me re your 'redcode' scenario that this is exactly what happened in the real global financial system in 2008
15:34 < andytoshi> ie the legalese that contracts for derivatives are written in is turing complete, and extrospection capabalities are determined by a regulatory regime that did not do cogent incentive analysis
15:34 < adam3us> andytoshi: haha yes.  the system was virus prone.  the fintech/bankster boys dreamed up viral make-money fast schemes that are doomed to crash with OPM
15:34 < andytoshi> which led to things like, eg the cds market hitting a 4 quadrillion cap :P
15:34 < jtimon> " amlcoin enforced at exchanges" you mean prohibiting bitcoin exchanges?
15:35 < adam3us> andytoshi: fascinating analogy.  and we think we can protect that by restricting the contract language? (probably not)
15:35 < gmaxwell> jtimon: it's much harder politically to shut down bitcoin exchanges when to do so you're suppressing bitcoin. Much easier where "on no bitcoin exchanges are fully permitted! they just have to comply with the law…"
15:36 < andytoshi> adam3us: so this is very cool, there is potential here for us to describe the horrible subtlety of financial regulation, in the context of cryptosystem currencies (which i have mentioned before, lets us do a lot of spherical-human economic analysis thanks to trustlessness)
15:36 < adam3us> jtimon: much was said upthread but yes  exchanges already comply with aml, if bitcoin supports viral aml, regulaor will say "ok so use it or shutdown" and users will say ok i want to buy $100k btc i can spend a month on bitcoin-otc (coffee shops for cash) or put u with amlcoin etc
15:36 < jtimon> adam3us: I just don't believe all countries will prohibit bitcoin exchanges
15:36 < andytoshi> and have a very simple-to-describe but very precise "here is where the thinking went wrong" explanation of that whole situation
15:37 < jtimon> " users will say ok i want to buy $100k btc " wasn't your assumption that the users weren't able to get btc out of the exchange anymore, just amlcoins?
15:37 < adam3us> jtimon: i think if the world was as sure as you are about financial regulation and bitcoin the price would be $100k/coin already :D  i thnk oneof the main things holding bitcoin back is just that - uncertaintly about regulation! its not that there havent been multiple non-basket case jurisdictions that have behaved erratically with bt regulation
15:38 < andytoshi> adam3us: re "restricting language", maybe that is exactly what we want to do, combined with maaku's "provably nonviral" ideas
15:38 < adam3us> jtimon: right.  thats what would happen to any exchange that was forced by regulation to use amlcoin covenants
15:38 < andytoshi> because we've seen in real life that pasting "don't act in bad faith" policies onto a turing complete system lets people do weird destructive things
15:39 < adam3us> andytoshi: i dunno sounds like halting problem^2 in hardness
15:39 < gmaxwell> adam3us: no, because as maaku pointed out, you can fail-safe.
15:39 < gmaxwell> If the static analysis can't prove your transaction sufficiently non-viral, its just not valid.
15:39 < andytoshi> adam3us: the result would be basically a whitelist of policies, and if people can prove that new things are safe maybe they could post a SNARK showing that or something, so the hard analysis is on them
15:39 < adam3us> andytoshi: BUT what we can do and i pushed this thought to a few offline people, is have auditable insurance coverage through the insurer, the reinsurer, the assets, the companies balance sheet, revenue, dividendes etc.
15:42 < adam3us> gmaxwell: maybe.  now security depends on a few more components including a theorem prover's comprehension vs virus writers
15:42 < adam3us> andytoshi: nice to have a fast to verify compact proof yes.
15:43 < andytoshi> adam3us: we could maybe put these proofs in the blockchain along with a unique identifier, then require all txes to reference the proof that they are safe
15:43 < nsh> we're on to viral transactions now? great...
15:43 < andytoshi> obviously this is a half-baked idea, as you say theorem proving is not developed enough to do such high-consequence real-world stuff
15:44 < adam3us> andytoshi: maybe.  or we could amuse ourselves with what we can do with non-extrospection languages
15:44 < andytoshi> yeah, i'm really impressed and surprised with what you guys have found to be possible
15:44 < nsh> i'd like to see a fully darwinian transactosphere...
15:45 < adam3us> nsh: suggest looking at ethereum.  will be interesting to spectate :)
15:45  * nsh nods
15:47 < nsh> had a very unbaked and thoroughly handwavey idea about a DSA-authorized capabilities-based distributed computational system over a blockchain with costed access to scripts and (computational) inputs somehow marked to market by utility or complexity
15:48 < nsh> not sure exactly what all those words means though so it'll probably remain pretty deep in my imagination :)
15:49  * adam3us wonders if its considered part of redcode game to write ethereum stealing viruses?
15:49 < andytoshi> that's interesting, if you can infect a majority of hashpower you can "hack the matrix" so to speak :P
15:50 < nsh> (it's always part of the metagame to cheat in ways that haven't be considered and thus explicitly prohibited)
15:50 < andytoshi> i guess i mean, if you can infect almost all the validating nodes
15:51 < gmaxwell> I think I mentioned before, some of these altcoins basically appear to have no nodes... even 'widely' used ones: people just mine directly to exchange accounts.
15:51 < gmaxwell> so you've got a couple of pools, a couple of exchanges, an odd geek or two, and thats it.
15:52 < adam3us> nsh, andytoshi: i was thinking there could be two levels of viral ethereum progrms.  a) within the interpreted execution space, eg viral covenants etc; b) escape the interpreter via sandbox escape.  i wonder though, they probably wouldnt find it funny even if you did
15:52 < gmaxwell> and these are things where there is no huge cost to running a node... the chains are small because there are few txn.
15:53 < adam3us> gmaxwell: ha not only no tx, no wallet, but not even any full nodes.
15:53 < nsh> hmmm
15:54 < gmaxwell> well there are some levels of transactions, but no real reason for someone to run a node. So thats the kind of outcome I'd expect for ethereum, particularly because running a node would be expensive.
15:54 < adam3us> gmaxwell: i was thinking beyond coingen.io why not virtualize the whole thing.  pay for virtual VPS, virtual ASIC hardware,... maybe you can make that provably fair like central but fair dice; i mean what the difference its only a tulip/pryamid coin anyway.  people can speculate on synthetic nothing without wasting eletricity then
15:55 < gmaxwell> adam3us: you could call it "mastercoin"
15:55 < adam3us> gmaxwell: minioncoin.  many someone should fork mastercoin and put it on top of dogecoin
15:56 < gmaxwell> Every dog has his master.
15:56 < gmaxwell> Many leashes. Such dogwalk.
15:56 < gmaxwell> the "exodus" needs to be DogCarRide
15:57 < adam3us> gmaxwell: please can 2014 be the year of the death of tulip coins?
16:00 < kinlo> heh, to see gmaxwell talk dogetalk made me laugh :)
16:03 < michagogo|cloud> andytoshi: Erm, you've given me an error I've never seen before
16:03 < michagogo|cloud> http://imgur.com/ZTcyCyR,kwBmvFO
16:04 < michagogo|cloud> andytoshi: Is the file I got broken?
16:04 < michagogo|cloud> 3836c0fef1bffbb4ed7c35564dbb23ad51295a74df7bc53b234b13e198bf4264 */cygdrive/c/Users/Micha/Downloads/cj-windows.zip
16:04 < gmaxwell> kinlo: that meme was a favorite in my household two months ago. dogecoin is kinda overplaying it at this point.
16:04 < michagogo|cloud> (sha256)
16:04 < maaku> "maybe.  now security depends on a few more components including a theorem prover's comprehension vs virus writers" <-- there's no way you'd want the therom prover to be part of consensus
16:04 < maaku> i was suggesting it as part of the IsStandard check and wallet code
16:05 < adam3us> maaku: they are discussing safe curve RFC on CFRG which i am on, which include ed25519, is there a separate place that a EdDSA RFC is being discussed? or is that what you meant
16:05 < kinlo> gmaxwell: I kinda like the happiness and fun the people have in #dogecoin with using the meme.  It will die out ofcourse, but they do have a strong community
16:05 < gmaxwell> maaku: if its not mandatory then the amlcoin risk exists. "not our problem your wallet isn't showing our payment, durn off this switch, it's broken"
16:06 < andytoshi> michagogo|cloud: strange, i'll refresh the download, one sec
16:06 < maaku> adam3us: I think that's the discussion I heard about
16:07 < andytoshi> michagogo|cloud: that is a bad hash, thx for letting me know, fixed now
16:07 < maaku> gmaxwell: with sufficient user level protections I don't rate amlcoin as a serious existential risk
16:08 < michagogo|cloud> ;;cjs
16:08 < gribble> Coinjoin Status: There is no currently open session. Visit https://www.wpsoftware.net/coinjoin/ or http://xnpjsvp7crbzlj3w.onion/ to start one.
16:08 < michagogo|cloud> andytoshi: woot
16:09 < michagogo|cloud> (so far, so good... no errors this time, it knows there's no open session)
16:09 < andytoshi> michagogo|cloud: excellent :) sorry, i forgot to stand up the testnet instance of the server, will do that now
16:10  * adam3us is old enough to remember people making analogous claims to reason about systematic MITM, CA malfeasance in the CA security model.
16:11 < michagogo|cloud> andytoshi: What's the format of cjclient.conf?
16:11 < michagogo|cloud> atm I see joinerserver = https://wpsoftware.net/coinjoin/cj-client.php in there
16:11 < michagogo|cloud> and that's it
16:11 < adam3us> maaku: (i was complaining at the time.. 1993ish that a dissident trusting CA infrastructure is crazy)
16:11 < maaku> adam3us: so? that was as sensible a thing to say then as now
16:12 < maaku> that doesn't mean you're right on this issue
16:12 < adam3us> maaku: people had all kinds of reasonable arguments how they'd never do that.  it could be detectable.  it was unreasonable etc.  i am seeing analogies in your assumption that viral ecosystem features would not be abused
16:12 < michagogo|cloud> andytoshi: (I mean, what are the other options)
16:12 < maaku> apples and oranges
16:12 < andytoshi> michagogo|cloud: rpcconnect, rpcuser, rpcpassword and rpcport all work as in bitcoind
16:13 < maaku> if the NSA demands the root cert from the CA, it *is* undetectable
16:13 < michagogo|cloud> So to use testnet I'd set rpcport = 18333?
16:13 < michagogo|cloud> 18332*
16:13 < andytoshi> michagogo|cloud: yeah, that should work
16:13 < michagogo|cloud> And what's the URL?
16:13 < maaku> covenants, on the other hand, by their very nature are prominently part of the script
16:13 < andytoshi> http://testing.wpsoftware.net/coinjoin/
16:13 < adam3us> maaku: alternatively then what makes you confident it would not be abused?  good behavior of the incumbent power bases?  the possible motivated parties  include the combined weight of the banking lobby and governments.
16:14 < maaku> to do... what exactly?
16:14 < michagogo|cloud> andytoshi: bleh...
16:14 < michagogo|cloud> Syncing with joiner, session ID unknown
16:14 < michagogo|cloud> Join server: SSL: no alternative certificate subject name matches target host name 'testing.wpsoftware.net'
16:14 < maaku> force me to convert a coin into something which is unspendable because it fails IsStandard, is not relayed, and not accepted by anybody?
16:14 < adam3us> maaku: anything that is expedient if history teaches us anything.  mandate viral amlcoins per example
16:14 < andytoshi> michagogo|cloud: sorry, testing.wpsoftware does not have an SSL cert, just use HTTP
16:15 < michagogo|cloud> Ah, k
16:15 < adam3us> maaku: no thats my point.  things which are not supportable by the infrastructure of all users are harder to foist on the users.
16:16 < adam3us> maaku: its not a given, and its a possible risk point, that all bitcoin wallets will remain open source, depending n the parties that get into the wallet & wallet integration/bundling business
16:16 < andytoshi> michagogo|cloud: ok, how about we do a 1.1 testnet join?
16:16 < michagogo|cloud> andytoshi: "Joiner status: session not found."
16:17 < andytoshi> michagogo|cloud: oh :P click "Session->Forget Session"
16:17 < andytoshi> oh, wait..
16:17 < maaku> adam3us: at least where there is rule of law, taking away someone's capability to use their property is amount to theft
16:19 < adam3us> maaku: i agree, and thats a libertarian argument, but even neutral biz people will propose doing something pragmatic that appeases the regulator so they personally can make money fast.  its not that they are evil, just that they dont care.  if people with this mentality have software deployment power the can cause a lot of damage.  eg apple?
16:21 < spenvo> #go-nuts
16:21 < adam3us> maaku: back on interest and contracts.  is there another way to achieve that?  when i was thinking about extrospection i found it curious that much was achievable via hashlock and dependent transactions
16:21 < spenvo> sorry about that
16:22 < adam3us> maaku: jtimon gave an example of something he claimed was impossible without covenants?
16:22 < maaku> adam3us: but my point is how could their proposal ever fly? people would reject it because their coins would suddenly become unspendable, there'd be lawsuits, etc.
16:22 < maaku> all before it gets far enough along to be entrenched
16:23 < maaku> adam3us: yes, restricted buy-back (of IOUs, to use his example)
16:23 < adam3us> maaku: i dont know.  but the adversary is adaptive and intelligent also.  coinvalidation would itself be viral
16:24 < maaku> you issue an asset with 1% demurrage with an attached covenant allowing you to buy it back at any time for principle + interest (implemented by sending regular coins to the script stripped of the covenant)
16:24 < maaku> /demurrage/interest/
16:24 < michagogo|cloud> andytoshi: I ticked my inputs and clicked view transaction
16:24 < michagogo|cloud> Now it's frozen
16:25 < adam3us> maaku: so what about a micro-channel.  either party can pull-out and claim whats paid to date.  interest paid periodically.
16:25 < andytoshi> michagogo|cloud: aw, shit
16:26 < michagogo|cloud> andytoshi: Oh, wait
16:26 < maaku> adam3us: tx replacement? vulnerable to double-spend
16:26 < michagogo|cloud> Just opened up a tailf on bitcoin's debug.log
16:26 < michagogo|cloud> Looks like it's busy drawing addresses
16:27 < andytoshi> how many output did you ask for?
16:27 < maaku> not to mention you wouldn't be able to move around ownership (resell debt)
16:27 < andytoshi> it shouldn't do an infinite loop if that's what you're seeing
16:27 < adam3us> maaku: or is there a less powerful language feature that could enable the class of use cases?
16:27 < maaku> adam3us: that would be entirely missing the point
16:28 < maaku> we *want* these crazy covenant use cases
16:29 < maaku> it's just doing so with the decentralized host currency that is problematic
16:29 < michagogo|cloud> andytoshi: My output is in the 5 digits
16:29 < adam3us> maaku: most of the examples on the covenant bct thread looked grey-goo like in their end game.
16:29 < michagogo|cloud> andytoshi: I think it's drawing ~21k keys...
16:29 < maaku> well that was the point of the covenant thread
16:30 < andytoshi> michagogo|cloud: hahahaha, ok, i should definitely do a sanity check there
16:30 < andytoshi> (and you probably want to kill it)
16:30 < adam3us> maaku: what i suggested to vitalik whe he asked me something about something  ethereum was using  is that scripts be certified.  then at least users can see who is proposing they do this as a sanity check.
16:30 < michagogo|cloud> It's about half-way done
16:31 < maaku> adam3us: that's something for the payment protocol
16:31 < adam3us> maaku: (he's using some PoW thing i mentioned to him in ethereum it seems)
16:32 < justanotheruser1> maaku: I see. Do you think anything but PoW could work?
16:32 < adam3us> maaku: i mean of the script itself, like maybe you dont want to accept financial covenants unless they are certified as safe and fair by a competent
16:32 < andytoshi> michagogo|cloud: ok, if you're willing to let it go that'll be a good test to see if you can break something
16:32 < maaku> justanotheruser1: what for consenus? no. proof-of-work is absolutely perfect
16:33 < maaku> the defficiencies people often quote are actually what makes it work
16:33 < Luke-Jr> O.o
16:33 < Luke-Jr> far from perfect imo
16:33 < justanotheruser1> maaku: No it isn't. Someone 20% of the processing power could reverse 6 confirmations within a day
16:33 < adam3us> maaku: missed this bit "just doing so with the decentralized host currency that is problematic" thats interesting.  so u think it could be safe for issued assets (peer issued or central issuer issued)
16:34 < maaku> Luke-Jr: idk, the only viable improvement I've seen is gmaxwell's timelock-encryption, although that has more problems than it solves
16:34 < maaku> at the moment
16:34 < michagogo|cloud> 2014-01-15 21:34:29 keypool reserve 17592
16:34 < Luke-Jr> maaku: I didn't say I knew something better, just that PoW isn't perfect :P
16:34 < adam3us> maaku: well i guess eg an issuer like a gold depositary or a mortgage issuer might put some pretty bad terms in the fine print that u are not qualified to evaluate
16:35 < maaku> justanotheruser1: and there's no getting around that. not without compromising what PoW gives you
16:35 < maaku> don't mistake a rule of thumb (6 confirms) with the actual security model of proof of work
16:35 < justanotheruser1> maaku: I never said there is a way to get around that. I just am pointing out that it is an imperfection.
16:35 < maaku> adam3us: sure, who cares if you put a crazy grey-goo covenant on your personally issued asset?
16:36 < maaku> in freimarkets at least, where user assets aren't host currency
16:36 < adam3us> maaku: the person who bought it cares maybe
16:36 < justanotheruser1> whats freimarkets
16:37 < maaku> adam3us: yes, but all your fears about regulation etc. could just as easily be applied to the person who issued it in real life
16:37 < adam3us> maaku: especially if it was expensive or the issuer is a bank say
16:37 < gmaxwell> that goes back to the point I made earlier about distinguishing the currency vs other things and not allowing the grey-goo on the currency.
16:37 < gmaxwell> (nice metaphor)
16:37 < adam3us> maaku: this is true.  well i mean there is regulation in the market weak though it is, and hackable by banksters as it is, to protect consumers from malicious financial instruments
16:38 < maaku> adam3us: the benefit here is that there is a mechanism for stating the conditions of these financial instruments, in a way which can't be retroactively changed
16:38 < maaku> that is actually pro-consumer
16:39 < maaku> (idk. maybe we end up using old-style bitcoin scripts for host currency outputs, to avoid the grey-goo, or disable opcodes)
16:39 < adam3us> maaku: yeah that i like and is a central promise of smart-contracts as applied to block-chain validation
16:40 < adam3us> maaku: but at a high-level would you no want to constrain the covenant to the instrument, not have it infect and convert other assets into the same form somehow.  not sure how to do that.
16:40 < michagogo|cloud> andytoshi: Ah, so you just call createrawtransaction?
16:40 < maaku> justanotheruser1: ok i'm a pragmatist who defines "perfect" as the best which can be actually achieved :)
16:41 < justanotheruser1> maaku: okay.
16:41 < maaku> justanotheruser1: https://bitcointalk.org/index.php?topic=278671.0
16:41 < michagogo|cloud> andytoshi: Hmm, I clicked the "Submit Transaction to Joiner" button
16:41 < michagogo|cloud> Nothing seems to have happened
16:42 < michagogo|cloud> http://testing.wpsoftware.net/coinjoin/ doesn't show there being a session
16:43 < justanotheruser1> maaku: is there a reason this has to be part of bitcoin and not just merged mined with it?
16:43 < maaku> adam3us: I think if you disabled the LOAD_TRANSACTION opcode in host currency, all of these fears would disappear
16:44 < maaku> justanotheruser1: what are you talking about?
16:44 < justanotheruser1> maaku: What do you mean by "an extension of bitcoin"?
16:46 < maaku> justanotheruser1: freimarkets is an extension of the bitcoin protocol. it adds new features by changing the transaction format, introducing new scripting opcodes, and changing the validation rules
16:46 < maaku> this are hard-fork changes
16:46 < justanotheruser1> maaku: does it have merged mining?
16:47 < maaku> justanotheruser1: that's a tangential question. this could in principle be applied to bitcoin in a future hard fork
16:47 < maaku> but given that the chance of this happening in bitcoin itself is approximately nil, we're going to deploy it in freicoin and freicoin will be merged mined against bitcoin
16:48 < maaku> so yes, it will be merged mined, but that's a point separate from the proposal itself
16:49 < michagogo|cloud> andytoshi: aha, the cj-client tries to spend to the mainnet fee/donation address
16:49 < michagogo|cloud> So it fails because that address isn't valid
16:51 < justanotheruser1> maaku: whats the difference between this and protoshares an mastercoin?
16:51 < justanotheruser1> *and
16:51 < justanotheruser1> and coloredcoins
16:51 < maaku> justanotheruser: read the thread
16:51 < justanotheruser> I am
16:52 < michagogo|cloud> andytoshi: Heh, I tried manually creating that transaction
16:52 < maaku> also this one : https://bitcointalk.org/index.php?topic=280292.0
16:52 < michagogo|cloud> On attempt to submit to the coinjoiner's web interface, 413 Request Entity Too Large
16:52 < maaku> (more appropriate to post there if you have technical questiosn than the crowdfund thread)
16:57 < adam3us> maaku: anyway enough from me about hypothetical systemic risks, I am actually quite interested in the potential of smart-contracts, and like the extensions you put in freimarket from a programming perspective.
16:57 < maaku> adam3us: what do you think about simply disabling the load-transaction opcode in the host currency? i feel silly for not thinking of this before the long-winded argument
16:58 < adam3us> also maybe i am not enuf of a forth-fan but bitcoin scripts seem kind of hard to read & program with.  maybe it was envisaged that there would be some higher level language translated into it
16:58 < maaku> yeah forth is kinda on the level of intermediate code
16:59 < adam3us> maaku: i dont know what load-tx does?
16:59 < gmaxwell> adam3us: really? I think forth is basically ideal.
17:00 < gmaxwell> adam3us: The problem with higher level languages is that they're easy to hide subtle behaviors in.
17:00 < adam3us> gmaxwell: taste i guess.  i did some dc programming, kind of reminds me.  yes unambiguity is a good thing
17:00 < maaku> adam3us: load-transaction is how all these covenants are accomplished - it pushes the transaction onto the stack so it can be examined by the script
17:00 < adam3us> maaku: i guess the extrospection hook?
17:00 < maaku> yeah
17:00 < gmaxwell> "oh look, this does exactly the opposite of what you expected because the hostile author took advantage of some order of operations subtly"
17:01 < gmaxwell> The forth is high enough level to express what it means, mostly, but low enough level to also express what it does.
17:01 < adam3us> gmaxwell: only complaint is like readability.  especially with the long OP_BLAH names.
17:01 < gmaxwell> takes more study to understand than something higher level but has a harder time lying to you.
17:02 < gmaxwell> oh well yea, surely better tools could be done for working with it.
17:02 < gmaxwell> including things like pesudo opcodes that compress common and easily explained idioms.
17:04 < adam3us> maaku: does that kill interest bearing loans denominated in freicoin but not in maakucoin (self-issued iou)?  there is some feature downside implied.
17:06 < maaku> adam3us: yes you would have to use user-issued IOUs, although that was the original scenario
17:07 < maaku> in fact I'm not sure how you'd do the loan trading freicoins for freicoins
17:07 < maaku> the point was that you loan the freicoins into existence
17:08 < maaku> you could still do some nasty things based on UTXO state (maybe you disable that as well)
17:08 < adam3us> maaku: doesnt that risk uncontrolled supply side inflation?
17:08 < maaku> that's ... rather the point isn't it?
17:09 < maaku> debt-based IOU currency
17:09 < maaku> maybe there's a misunderstanding here? i'm not sure what it is
17:09 < adam3us> maaku: fair enough there, but in relation to there existing two types: mined freicoins with demurrage and iou ones
17:12 < maaku> well sortof. IOU freicoins are actually freicoins, just a promise from whoever issued them to eventually, someday redeem them
17:12 < maaku> they're only usable as currency in so much as other people are willing to accept that IOU promise
17:12 < maaku> ripple is built on this premise
17:13 < gmaxwell> How is ripple doing btw?
17:13 < adam3us> maaku: but then you have the ripple graph of trust so they can circulate, quite far from the issuer and his immediate friends indirectly
17:14 < maaku> oh i meant pre-OpenCoin ripple. no idea what they're up to :)
17:14 < maaku> adam3us: yes, and with sub-transactions you can build atomic movements of these IOUs through the trust graph
17:14 < adam3us> maaku: i think it'd be fair to call this real-ripple.
17:15 < gmaxwell> meh. I still think real-ripple ought not need a global consensus system.
17:15 < maaku> but where there are gaps in the graph, exchanging IOU-for-freicoin instead of IOU-for-IOU lets you get hard currency
17:16 < maaku> gmaxwell: agreed, except when you want to interact with non-ripple assets like bitcoin/freicoin
17:17 < maaku> jtimon and I are planning on having these user assets be off-chain, but using the same scripting system so you can coordinate movements with the chain when public assets are involved
17:17 < gmaxwell> maaku: well, when you want to interact with them in a way which isn't trusting of an issuer.
17:17 < maaku> yes
17:20 < midnightmagic> real-ripple didn't.
17:20 < midnightmagic> :-(
17:21 < maaku> midnightmagic: unfortunately the distributed protocol was never implemented :\
17:22 < midnightmagic> yah. sad-midnight-face
17:31 < andytoshi> michagogo|cloud: sorry, was afk
17:31 < andytoshi> michagogo|cloud: one moment, cj
17:32 < andytoshi> michagogo|cloud: one moment, cj-client doesn't choose the donation address, the server does, but i forgot to set that for the testnet version
17:57 < andytoshi> michagogo|cloud: gonna head out now, will work on this later tonight, i have having decode problems that didn't happen with mainnet, sorry
17:57 < am42> ?
18:10 < jgarzik> adam3us, unlinkedable static address...  USA! USA! USA!
18:10  * jgarzik waits for the conspiracies to start
18:11 < adam3us> jgarzik: not getting conspiracy part?
18:12 < jgarzik> adam3us, a poor attempt at a joke.  e.g. paid by USA to develop tech whose acronym is USA
18:12 < adam3us> jgarzik: oooh.. didnt notice the acronym :)
18:12 < jgarzik> plus an acknowledgement that the bitcoin community will imagine a conspiracy for all events.
18:12 < jgarzik> It's like the multiverse of conspiracies
18:12 < jgarzik> quantum conspiracy theory
18:13 < adam3us> jgarzik: just wish i could find an efficient spv compatible version (or a replacement for bloom that worked with them).. would be sooo nice to forget about address reuse and battling user confusion and wallet author laziness
18:14 < jgarzik> indeed
18:14 < sipa> that seems contradictory
18:14 < sipa> you want something that achieves privacy from the public
18:14 < sipa> but still want them to do efficient filtering for you
18:15 < jgarzik> adam3us, TBH it's not just laziness.  Even if my bitcoinj-based Bitcoin Wallet was [hopefully] updated to reuse addresses tomorrow, you still have a problem of address reuse being practically mandated by circumstance, in the other direction:
18:15 < adam3us> sipa: when presented with a key though
18:15 < jgarzik> miner payouts, salary payouts, etc.
18:15 < jgarzik> no good way exists to give a payment stream a set of addresses
18:15 < sipa> adam3us: they could reveal that key
18:15 < TD> lol
18:15 < TD> wallet author lazyness
18:16 < TD> adam3us: you can follow HD wallets in bitcoinj development work here: https://code.google.com/r/hearn-bitcoinj/source/list?name=keychain
18:16 < TD> as you can see lots of code has been going in for the past 6-7 weeks
18:16 < adam3us> jgarzik: yes indeed.  well there is a mix of like wallets that only support one address supposedly? and then there are real problems.  signature lines, biz cards, etc they are truly simpler to use and understand and in some use-cases hard to avoid!
18:16 < Luke-Jr> jgarzik: HD wallet spec has stuff for that
18:16 < TD> adam3us: design doc is here, to give you a flavour of how complicated the work is: https://code.google.com/r/hearn-bitcoinj/source/browse/designdocs/Deterministic%20wallets.txt?name=keychain
18:17 < am42> lol
18:17 < am42> guys...
18:17 < jgarzik> Luke-Jr, yes, any derivation scheme fits the use case
18:17 < adam3us> jgarzik: "no good way exists to give a payment stream a set of addresses" well like Luke-Jr said shared subwallet chain-code should work for stream
18:17 < jgarzik> as long as it is standardized
18:17 < jgarzik> and private
18:18 < jgarzik> the whole world doesn't need to track my salary
18:18 < Luke-Jr> but it's so fun! <.<
18:19 < jgarzik> I would love to find a solution for mass payouts killing privacy.  the solution seems to be "send a bunch of little TXs", which is network-unfriendly.
18:19  * TD shrugs
18:19 < TD> the point of bitcoin is to move money, well
18:19 < TD> that's why we need to scale the tech
18:20 < TD> so we're not afraid of making little transactions if that's what it takes to give good privacy
18:20 < TD> adam3us: anyway if you're feeling non-lazy you're welcome to help chip in with the implementation .....
18:20 < adam3us> TD: scary looking spec there.  btw relatedly petertodd was saying that bloom is not that private with default parameters
18:20 < TD> :)
18:20 < TD> yeah current bitcoinj has a default very low false positive rate and a few bugs
18:21 < TD> ways the remote node can trick you into revealing whether you own a particular key, stuff like that
18:21 < TD> we experimented with a higher FP rate in this dev cycle but it wasn't usable on 3G connections. so we need to add a notion of bandwidth modes to the API
18:21 < TD> then if we're on wifi we can ramp it up, etc
18:21 < TD> either that, or some kind of auto measurement/adaptation, but that's harder
18:21 < sipa> well, as long as bitcoinj wallets reuse addresses by default, there's little point in trying to protect privacy using bloom filters )
18:22 < TD> yeah - that's why i'm working on HD wallets at the moment and not bloom filtering :)
18:22 < adam3us> TD: still i wonder if its more private still than the prefix idea prefix leaks to all and interacts badly with existing statisical network analysis
18:22 < sipa> yeah, i know, not commenting there
18:22 < am42> guys i want to buy safe bTC wia Western Union
18:22 < am42> or MoneyGram
18:22 < TD> but as you can see from the design doc ..... well, bitcoinj wallet class got a lot of features over the years, so making sure none of them break and the upgrade is smooth, takes a lot of work
18:22 < adam3us> sipa: ha ha
18:22 < am42> how to do that safe?
18:23 < sipa> am42: not here, try #bitcoin
18:23 < wallet42> td: will bloom filters work with stealth addresses?
18:23 < adam3us> jgarzik: "I would love to find a solution for mass payouts killing privacy." this seems like a coin control issue.
18:23 < TD> i don't know. i haven't really worked through the details of ... lets call them "routing addresses
18:23 < adam3us> wallet42: i think not
18:24 < TD> but yeah there's an obvious conceptual issue there - bloom filters are intended to hide what the node should be looking for. but with stealth/routing addresses, the client doesn't know what it's looking for either, in a way
18:24 < adam3us> TD: i was suggesting unlinkable static (vs the current static aka reused).
18:24 < TD> with the payment protocol it might be different because then you don't have to find payments only via the chain
18:25 < TD> adam3us: yeah but i think "static" is jargony
18:25 < adam3us> TD: exactly.  the client would have to give the node a private key to scan with.  and that scanning is like heavy
18:26 < TD> if the payer submits the tx directly to the payee via bluetooth/http/other payment protocol methods that issue goes away of course
18:26 < TD> but then you have to be online
18:26 < adam3us> TD: and then i think there's no ambiguity left for bloom to work with.  unless you upload a few other peoples private key also
18:26 < TD> or have a dropbox of some kind
18:26 < adam3us> TD: yes.  i guess we cant or dont want to accept that as an assumption  and also one or other part could get lost.
18:27 < adam3us> TD: routing address is not bad.
18:28 < adam3us> jgarzik: didnt petertodd write something called dust be gone that swept up all the tiny tracking spam payments into a corner so your wallet doesnt auto grab them?  or coin control to not use them until you run out of bigger coins.
18:32 < TD> i think it paid dust outputs to miner fees
18:43 < EasyAt> I don't understand the use of these tracking outputs.  Is it because if the TX is to me I will relay it, whereas if it isn't mine I'll drop it because it's dust?
18:44 < adam3us> EasyAt: apparently they send tiny payments to lots of people, then watch them be respent.
18:44 < EasyAt> Can't I just track outputs from a target address without tagging it
18:44 < adam3us> EasyAt: your wallet just grabs random inputs from whats in the wallet, "coin control" is not clever yet apparently.  its like someone giving you marked pennies.
18:45 < adam3us> EasyAt: well not if someone is not reusing addresses so much.
18:45 < EasyAt> Yea, but once they target my address they can just watch all outputs and the chain of TXs following?
18:46 < maaku> EasyAt: these addresses are one-use only
18:46 < adam3us> EasyAt: i guess you could say its a way to force someone to reuse an address against their wish... send them unsolicited dust to their address.
18:46 < maaku> oh n/m
18:47 < sipa> i really prefer a model where you have to ask for every transaction you have to send first
18:47 < sipa> but it seems the bitcoin economy hasn't evolved that way
18:47 < adam3us> EasyAt: your wallet contains like 100 addresses and the wallet tries to not reuse them.  so they know this particular address is yours for some reason.  maybe the point is the dust payment is to the same address, and may get used in a different payment (even tho its the same address its a different txout)
18:48 < EasyAt> adam3us: Is it in the hopes that you will spend the dust with another output from a different address, thus leaking some info?
18:49 < adam3us> EasyAt: its not automatic that all payments from the same address would go in the same payment.  its not balanced based so each txout is spent separately.  if they see one of those dust payments respent with an address of yours they didnt know was  yours, they do now
18:49 < adam3us> EasyAt: but i dont know who would care enough to waste btc dust to find out really.  maybe some academics doing analysis or something?
18:50 < EasyAt> adam3us: Indeed, I follow you
18:50 < EasyAt> tainting people
18:50 < EasyAt> Or address grouping, I suppose
18:51 < EasyAt> sipa: In your model I would need permission from the receiver?
18:52 < adam3us> EasyAt: yes probably the latter.  yes his model is that and would work, in an older version there was sent via IP which could've been more perission based as there was an interactive link anyway
18:53 < EasyAt> Interesting, thank your for the input
18:54 < adam3us> in an ideal world we'd have better privacy so people could send you small payments and it wouldnt matter.
18:55 < sipa> EasyAt: i would like that yes
18:55 < sipa> EasyAt: that you could not send coins without permission from the receiver
18:56 < EasyAt> How would cold wallets receive funds in that case
18:56 < sipa> nothing prevents it from being presigned
18:57 < EasyAt> Hm, then wouldn't I need prior knowledge of the TX?  How about a cold wallet used for donations?
19:00 < adam3us> EasyAt: maybe there could be a separate key for permission to send sig than for spending.  (like the chain-code being in an online computer and the private key in the offline)
19:01 < adam3us> sipa: it would also solve address reuse.  new address on each signed payment permission
19:03 < EasyAt> Or, maybe a way to publish a ruleset in the blockchain for acceptable payments to an address
19:04 < EasyAt> Though, by doing so I am giving up my pubkey... I think
19:04 < EasyAt> Well, I can't think of a way not to give it up
19:05 < sipa> adam3us: well, it's exactly what the payment protocol intends to bring back
19:09 < adam3us> sipa: yes.
19:21 < jcrubino> was a rename decided for stealth addresses?  I would like to propose "quiet addresses" or "silent address"
19:23 < adam3us> jcrubino: i think we have a winner from jeremy spilman "reusuable address"
19:23 < jcrubino> sounds good
19:23 < gmaxwell> I like reusable address.
19:24 < maaku> very nice
19:25 < adam3us> gmaxwell: yea me too.  i am not sure of the level of enthusiasm for this all being a done deal tho "I have high hopes for this feature. The war *against* address reuse may soon be a distant memory." (Jeremy on bitcoin-dev list)
19:25 < adam3us> gmaxwell: seems to me there is a big open question about SPV compatibility.
19:25 < jcrubino> so if I send a payemtn from a reusable address to another resuable address does zerocoin still have a use or case?
19:25 < gmaxwell> ugh yea, I really have mixed feelings on the whole feature.
19:25 < sipa> they are not a solution fo everything
19:25 < gmaxwell> adam3us: it's neither SPV compatible or incompatible.
19:26 < sipa> jcrubino: bitcoin doesn't provide anonimity
19:26 < sipa> even with reusable addresses
19:26 < adam3us> gmaxwell: well an spv client doesnt know what to put in its bloom filter absent another channel then shall we say
19:26 < maaku> adam3us: you'd use prefix filters for SPV
19:26 < gmaxwell> adam3us: well it can be specced with the bloombait idea.
19:27 < adam3us> maaku: yeah same thing i guess (my terminology was bloom bait, petertodd prefix) but that has privacy problems
19:27 < gmaxwell> then you can pick your anonymity set tradeoff. But its an extra thing that has to be 'decided' which is lame.
19:27 < maaku> adam3us: well bloom filters in general have privacy problems...
19:27 < adam3us> gmaxwell: its worse than bloom i think with its apparently small anon-set.  because its public to all and the statisitcal analysts will latch on to it
19:28 < gmaxwell> yea, it's worse than bloom, we don't have anything like bloom for it which is as secure in the semi-honest node model.
19:28 < adam3us> maaku: and use it multiple times in your potential graph to narrow in on you.  privacy leak stats is cumulative
19:28 < gmaxwell> In bloom you're completely private unless you connect to unfriendly nodes (well ignoring that our links aren't encrypted). So thats not terrible _casual_ privacy.
19:29 < gmaxwell> it's not privacy against powerful forces but its not half bad.
19:29 < adam3us> gmaxwell: yup and prefix is like permanent global record with cumulative privacy loss effect on stats.  as if we didnt have enuf stats build up problems.
19:32 < gmaxwell> so an improvement would be to make the bait hmac(tx_nonce,secret)[n-bits]  then you have to hand over a secret to the party you wish to scan for you... but it's not unforgable like handing over the agreement key.
19:32 < adam3us> gmaxwell: hmm bit of lateral thinking.  giving up on getting much from the reusable address.  but other than a bloom bait, what about some kind of randomized fingerprint, that you can illuminate different parts of in a bloom like way with help of the assisting node.  created by the sender based  on the reusable key
19:33 < gmaxwell> e.g. I could just pick any collection of transactions on the network and search for a secret that makes them part of the same group.
19:34 < gmaxwell> so someone who says "I ran a SPV node and found out adam3us's secret is π and thus these transactions are his" can be challenged with "no way, thes transactions are three different other people with these other secrets"
19:34 < adam3us> gmaxwell: yes maybe a public key versoin of that
19:34 < gmaxwell> the fact that its not public key is what makes it forgable. :)
19:34 < adam3us> gmaxwell: so long as its a fuzzy match...
19:34 < gmaxwell> basically there exists some secret such that any selection of baits are related, but finding it takes work related to how specific you want to make the matching.
19:35 < gmaxwell> yea, thats why I said n-bits. it has to be small enough that searching for forgeries is easy.
19:35 < adam3us> gmaxwell: maybe could allow different query for same data somehow
19:35 < adam3us> gmaxwell: yeah i got that
19:36 < adam3us> gmaxwell: also in the hmac how do u get the key to the sender...
19:36 < gmaxwell> dunno maybe there is a way of constructing it with a linear code so that the match is always fuzzy but your real transactions will always have a hamming distance < x.  and then you ask for all <x solutions.
19:37 < gmaxwell> adam3us: you put it in the address.
19:37 < adam3us> gmaxwell: yes but then its not a secret, so ah ok its better than a prefix however got you.
19:38 < gmaxwell> yea its just a secret keyed prefix, with a denyable secret, unlike using the derrivation keys for scanning since they aren't denyable.
19:38 < adam3us> gmaxwell: already an improvement on prefix, and Jeremy's about to like write an RFC level of "awesomely done"
19:39 < gmaxwell> down side is that someone scanning for you can't precompute anything to index it... prefixes have that nice property.
19:39 < adam3us> gmaxwell: so the other feature we'd like is pecomputation
19:39 < adam3us> gmaxwell: yes
19:41 < adam3us> gmaxwell: ok i am gonna sleep on it (literally, getting late) interesting problem, with quite useful implications if it can be cracked (I mean I share Jeremy's interest, just not his conclusion about it being solved yet!)
19:42 < gmaxwell> well so, H(nonce) and then split into 16  16 bit parts.   pick a part at random, and compute part^secret_bait = prefix  and put the prefix in the transaction.
19:42 < gmaxwell> When you ask someone untrusted to scan for you you give them a set of secret baits you're insterested in, including a number of bogus ones you really don't care about.
19:43 < gmaxwell> and they return any transaction where any one of the part^prefix = one of your baits.
19:43 < gmaxwell> e.g. someone doing stats doesn't know which of the token the part is xored with.
19:43 < gmaxwell> obviously some parameter scaling needs to happen to make it sensible, I picked random numbers.
19:44 < gmaxwell> hm. they should probably be 8 bit. in any case, there you go.
19:45 < adam3us> gmaxwell: not bad i think
19:47 < gmaxwell> in any case, this is a member of an infinite space of related schemes based on locally decodable error correcting codes. Effectively this is a fountain code, effectively, the transaction picks a random high dimensional vector space, and when combined with the prefix the result is a codeword in that space which is always within a certian proximity of your secret bait... and there is a cheap test of proximity.
19:48 < adam3us> gmaxwell: is that precomputably indexable?
19:48 < gmaxwell> it's still vulnerable to statstical analysis, in that you can keep intersecting things if you have a prior that they're related until you recover the bait.
19:48 < gmaxwell> adam3us: yea with overhead, e.g. you'd put every transaction in N indexes.
19:49 < gmaxwell> N picked based on how big the vector space is that you're embedding in.. More dimensions means more area covered by a given radius.
19:50 < gmaxwell> e.g. for my 16/32 example you'd be putting each transaction in the index 16 times. But thats okay, I mean, bloom filtering also pulls multiple keys from a transaction.
19:50 < adam3us> gmaxwell: my public key comment was that then it would not be bait recoverable.
19:51 < adam3us> gmaxwell: yes.  it seems reasonably good.  definitely a couple of increments better than prefix
20:33 < phantomcircuit> that reminds me
20:33 < phantomcircuit> nvm
22:05 < andytoshi> michagogo|cloud: i have refreshed the windows build, the only change is that it saves the rpcport= setting in cjclient.conf, before that would get overwritten
22:06 < andytoshi> michagogo|cloud: but i've got the testnet server working properly, it was just permission issues because i git clone'd the mainnet joiner over on my own unix account :P
23:25 < EasyAt> Where is the correct channel to ask about sybil attack mitigation in a decentralized WoT?
23:33 < amiller> EasyAt, maybe you want #bitcoin-wot
23:34 < amiller> but i'd like to hear about it here too
23:43 < EasyAt> amiller: One second, I'd like to state this concisely
--- Log closed Thu Jan 16 00:00:49 2014