--- Log opened Wed Oct 30 00:00:21 2013
01:56 < gmaxwell> I went to the Silicon Valley Bitcoin Users meetup today. It was interesting.
01:57 < gmaxwell> amiller: I wouldn't say that it's strictly superior to coinjoin, as it requires four transactions in total, so it's not as good for casual usage. And it cannot be completely blind like coinjoin.
01:58 < gmaxwell> However of 2 of 2 wallets became popular the transactions would be higly inconspicious.
01:58 < gmaxwell> the anonymity set could be much larger than coinjoin.
01:59 < gmaxwell> Also petertodd deserves some credit too, my initial protocol was bugged, and he fixed it and the fix made it vastly better (e.g. made the transactions indistinguishable).
02:00 < gmaxwell> amiller: I think you're a little overly pessimistic with coinjoin and DOS, but yea, tolerating dos is a major potential source of complexity.
02:01 < gmaxwell> And sure, I love all manner of ZKP. But well, fuck coding. Real cypherpunks transact. All the pretty protocols in the world are nothing but angles dancing on the head of a pin if no one uses them.
02:02 < Luke-Jr> gmaxwell: interesting how? :p
02:03 < gmaxwell> lots of people. uh.. maybe 30?  All nice and excited about bitcoin, and basically all of them would make the least sopiciated users that show up in IRC seem like technical geniuses.
02:03 < Luke-Jr> lol
02:04 < Luke-Jr> did any of them recognise you or your name? :p
02:04 < gmaxwell> there was some debate about what a hash tree was between some of the more technical people there, and one thought to ask me to explain it, and I spent 10 minutes on the subject and blew their mind.
02:05 < Luke-Jr> rofl
02:05 < gmaxwell> No. Well, I was kinda keeping a low profile. So more might have if I'd talked to more.
02:06 < gmaxwell> There was someone presented on their site where people can play board games against each other for btc, looks pretty neat. during his presentation someone asked how he was processing payments, coinbase API and he made some offhand comment about how he keeps his coins in a dozen online wallets because you never know which one is going to get hacked or shut down next, and the room is nodding.
02:07 < gmaxwell> He demoed the site by logging into his coinbase account to transfer some coins into it ... everyone at the room is seeing their username and the length of their password... and the $40k in bitcoin in their account.
02:08 < Luke-Jr> >_<
02:08 < Luke-Jr> sounds like a.. profitable.. group
02:08 < pigeons> what's his mother's maiden name?
02:08 < gmaxwell> in any case, they all seemed nice, even intelligent folks, but really clueless from my perspective. A lot of them inhabit a very different bitcoin world than I do.
02:09 < Luke-Jr> wait, he knew how to run a site?
02:09 < Luke-Jr> omg, what if these kind of people run some of the exchanges?
02:09 < gmaxwell> I was thinking it would be fun to give some presentations— they have a fantastic meeting space, but after meeting the people there, I'm unsure where to find the greatest overlap between my interests and their interests.
02:10 < gmaxwell> Luke-Jr: primarly a business person, hired coders in like serbia apparently. He extolled the virtues of offshore coders. :)
02:10 < pigeons> Luke-Jr: http://coinjar.io/about "Ryan is a veteran entrepreneur and Bitcoin guru. Technically and commercially adept, he’s founded several successful startups and remains a prominent figure in the Bitcoin community. "
02:11 < Luke-Jr> gmaxwell: somehow that didn't make me feel any better
02:11 < Luke-Jr> pigeons: "He [Asher] also brings lunch for the CoinJar team." <-- at least he does something
02:12 < pigeons> heh
02:12 < Luke-Jr> is that the exchange Gavin said he uses? <.<
02:12 < pigeons> yes
02:13 < gmaxwell> before going I thought if they asked me to talk about something I might talk about the transaction teleportation (Which jcorgan suggests calling CoinSwap) stuff, since its fresh on my mind, but like.. I think I'd have to spend an hour on bitcoin 101 before I could explain anything more that "coin starts here, ends up there, you can't explain that." :)
02:13 < gmaxwell> (I think they'd be interested in more technical things, but for many of them there appeared to be a big knowldge gap)
02:14 < gmaxwell> And well, I guess thats victory that you don't have to be a cryptographic protocol guru to build a bitcoin business.
02:15 < Luke-Jr> that'd be victory if he had a security expert on his staff who didn't let him touch the wallets..
02:17 < Luke-Jr> (suddenly I understand what bankers' real job is..)
02:32 < petertodd> gmaxwell: we've created a monster
02:33 < petertodd> gmaxwell: yeah, I'm fairly active in the toronto bitcoin community, and I always get the impression I've got at least an order of magnitude more clue than anyone else :(
02:33  * Luke-Jr blames petertodd
02:33 < maaku> gmaxwell: was this the hacker dojo group?
02:34 < petertodd> Luke-Jr: heh, if you want to give me all the credit go ahead :P
02:34 < Luke-Jr> petertodd: so you admit to being Satoshi?
02:35 < petertodd> Luke-Jr: yup, and jdillon, and gavin. (the latter because a good actor has versatility)
02:44 < gmaxwell> petertodd: I'm still editing but: https://bitcointalk.org/index.php?topic=321228.new#new
02:51 < petertodd> make sure you mention how in an actual implementation Alice can also play the role of Carol; specifically how a p2p network doing this would have people play either role depending on what is convenient
02:57 < gmaxwell> jcorgan had initially suggested eliminating bob and making it just alice and carol and alice prime.
02:57 < gmaxwell> But I think it's still easier to follow imaginging it as three parties.
02:58 < petertodd> I explained it to two of my coworkers yesterday, and they got hung up on Bob as well
02:58 < gmaxwell> Another way to represnet it as four. e.g. Alice, Carol, Carol', and Alice'
02:58 < petertodd> Alice, Carol, Carmen and Amy
02:59 < petertodd> ...shit, I've dated all those girls
02:59 < petertodd> Heck, I'd leave Bob in the protocol, but have Bob be a passive recipient only.
03:00 < gmaxwell> Yea, well a version could be drawn with Alice Carol, Carol', Alice', Bob
03:00 < petertodd> right, well, Bob and Dave
03:00 < gmaxwell> so a month or so ago someone was on IRC I think proposing a protocol like this, but without the hashlock so it was totally holdup vulnerable.. e.g. just 2 of 2 escrows.
03:00 < gmaxwell> I ought to credit that person but I can't remember who it was.
03:01 < petertodd> yeah, I think that's come up a few times. Heck, I probably mentioned it at some point in relation to fidelity bonds.
03:11 < petertodd> gmaxwell: CoinSwap is more efficient than four transactions per swap: if the software lets you either play the role of Alice or Carol two simultaneous payments from Alice and Amy to Bob and Bryan take four transactions.
03:12 < gmaxwell> petertodd: well not if alice has to play the role of Bob in order to make your implementation easy and avoid having to coordinate three people.
03:12 < petertodd> gmaxwell: no, even in that case it's fine, because the transactions moving coins from the escrow simply move them to Bob and Bryan
03:13 < petertodd> (for instance five transactions is never required)
03:15 < gmaxwell> K, fair point.
03:22 < petertodd> oh nice: with replace-by-fee we can make CoinSwap be as efficient as a regular transaction: Alice and Amy want to pay Bob and Bryan respectively, so they first jointly author tx0 which sends their coins partially to fees, partially to an unspendable address. Both parties don't want tx0 to be broadcast. Then they author tx1 and tx2, paying Bryan with Alice's coins, and Bob with Amy's. If either party cheats, broadcast tx0.
03:22 < gmaxwell> there is still a chance that the cheat is successful
03:23 < gmaxwell> CoinSwapOfFaith.
03:23 < petertodd> Yes, a chance, for instance if tx1 and tx2 don't get mined at the same time, but you can probably reduce that chance to the point where a fidelity bond can cover it.
03:24 < gmaxwell> petertodd: speaking of bonds, someone is talking about doing something mintchip like with bitcoin private keys.
03:24 < petertodd> I think I'm going to call this new protocol DangerSwap
03:24 < gmaxwell> ohhh. :P
03:24 < petertodd> oh yeah?
03:24 < gmaxwell> ChickenSwap.
03:25 < petertodd> haha, ChickenSwap is good. Or NashSwap
03:25 < gmaxwell> petertodd: it's like a Casascius coin but implemented via something like mintchip.
03:26 < gmaxwell> https://bitcointalk.org/index.php?topic=321085.0
03:26 < gmaxwell> petertodd: NashSquareDance.
03:27 < petertodd> gmaxwell: the latter is wonderfully misleading with its politeness
03:27 < petertodd> gmaxwell: The Great Canadian Coin Swap
03:28 < petertodd> "Armed with cryptographic proof of any fraud, we can force the participants to apologise."
03:31 < gmaxwell> hahahaha
03:34 < Luke-Jr> lol
03:37 < petertodd> Announce/commit sacrifices: The better way to say "Sorry!"
03:39 < Luke-Jr> someone in #bitcoin-otc claims Coinabul is being investigated by the FTC? :o
03:39 < petertodd> ?!
03:41 < Luke-Jr> [07:33:57] <diakin564> FYI - BBB and FTC reports now launched on scam site Coinabul
03:41 < Luke-Jr> [07:34:05] <diakin564> and started FBI investigation
03:41 < petertodd> what scams are they accused of?
03:43 < Luke-Jr> a bit ago, I read bitcointroll threads claiming the (p.m.) coins were "lost" in the mail and coingenuity saying his insurance refused to cover it or something
03:43 < Luke-Jr> dunno much about it
03:51 < gmaxwell> that thread is boring and bogus.
03:51 < gmaxwell> Hopefully this is at least about something other than that thread.
03:52 < gmaxwell> That thread was metal "lost" in the mail. Insurance wouldn't cover it. coingenuity actually sent the guy replacement metal out of his own pocket, but the guy really wanted the bitcoins returned (the price of bitcoin went from $10 to $100 shortly after the sale)
03:53 < petertodd> ha
03:53 < gmaxwell> coingenuity believes (rightly or wrongly) that the guy was just trying to scam him into giving the coin back after he had regrets about the price going up.
03:54 < gmaxwell> and, as a result took forever to resolve it, I suppose something you could rightfully fault him for... in general a number of people have complaints about his services' timelyness, though having had a lot of discussion with coingenuity I'm generally pretty sympathetic.
03:56 < Luke-Jr> I seem to recall him saying he was having problems with banks though
03:56 < Luke-Jr> hopefully it didn't blow up into something
03:59 < Luke-Jr> gmaxwell: I do think the insurance refusing to cover it was ridiculous though
04:01 < Luke-Jr> (not that I doubt the insurance did something ridiculous)
04:01 < gmaxwell> Luke-Jr: yea thats been part of whats been causing him delays, you've heard that lots of people have had banks randomly closing accounts of people who mention Bitcoin. Now imagine that you're in a business moving hundreds of thousands of dollars of precious metal for bitcoin and dealing with banks...
04:04 < Luke-Jr> I hadn't heard that about banks (closing personal accounts who mention Bitcoin..)
04:04 < gmaxwell> amiller: FWIW, I think I originally proposed the hashlock for binding cross chain.
04:06 < gmaxwell> Luke-Jr: yea, us bank, capitol one, bank of the west, and chase are known to have closed random personal accounts on account of bitcoin activity.
04:06 < gmaxwell> Commercial accounts have had an even harder time.
04:18 < gmaxwell> amiller: in any case, please feel free to go post how awesome you think that transaction pattern is on the coinswap thread. petertodd likewise, posting some smart things would be nice.
04:18 < gmaxwell> Otherwise the thread may start off with derping people.
04:21 < adam3us> gmaxwell, Luke-Jr: you need a real bank, not one of those pennyante us jobs; credit-suisse/UBS with an actual swiss account, then any stupidity has to be approved by swiss court, and they dont take 'please do this' even from the US, they demand verifiable proof before they act; 'course you dont get one of those without $500k min deposit, but thats the correct approach - disclose it on your tax forms, etc but you're outsourcing due-process to
04:22 < Luke-Jr> adam3us: do they do business with US citizens still? :o
04:22 < Luke-Jr> adam3us: and do they take initial deposits via wire? :p
04:22 < adam3us> luke-jr: fuck no
04:22 < Luke-Jr> aka bitcoins
04:23 < Luke-Jr> so not really an option
04:23 < adam3us> luke-jr: well i guess I jest, I think they would, though they will insist on disclosure
04:26 < adam3us> luke-jr: but seriously there is no sane reason anyone with > $500k liquid assets would keep a red cent in the US (or most other wesetern countries) .  I am half swiss so i might be biased (mother is from Zurich)
04:27 < Luke-Jr> adam3us: I'm not sure US citizens really have a choice anymore. :/
04:27 < adam3us> luke-jr: it has zero to do with tax avoidance (do NOT do that, especially in the US) and everything to do with ensuring legal due diligence in any third party decisions about your wealth, and US is 100 yrs behind .ch in legal system impartiality & political independence, due process, etc
04:29 < Luke-Jr> I'm sure, but last I heard the US made it pretty much impractical for any non-US banks to do business with citizens
04:30 < maaku> some, not all
04:30 < maaku> there's some carribian banks that haven't felt the pressure yet
04:31 < adam3us> luke-jr: as I understand it, the result was .ch min deposit and min annual fee went up - they dont want to deal with US related admin costs unless its worth it
04:31 < Luke-Jr> I guess the hard part, if they really want $500k min deposit, will be getting a single $500k withdrawl from some exchange :/
04:34 < adam3us> luke-jr: its probably etiquette to go there with your passport for acct setup, zurich is a nice place, they are not offering anonymity, just the application of swiss banking confidentiality (pseudonymit with them holing your real id in escrow) - anything illegal by their laws, and with proof a swiss court has verified will be disclosed/seized; but the bar is pretty high: proof of tax evasion, extortion, organized crime, terror is what its me
04:35 < Luke-Jr> I don't have a passport.
04:35 < petertodd> !
04:35 < maaku> Luke-Jr: if you can show assets (walk into a UBS branch with documentation), then they will work with you to handle the deposit over multiple transactions
04:35 < maaku> and get a passport
04:35 < Luke-Jr> adam3us: btw, your lines keep going over freenode's limit and getting cut off
04:36 < Luke-Jr> yeah, I should get a passport. but that's so much trouble.
04:36 < adam3us> luke-jr: there are other AAB+ rated swiss only banks (no branches or personnel outside .ch) that are more immune to real-politic foreign influence; the UBS problems a few yrs back were because of pressure the US could exert because UBS had US branches
04:37 < adam3us> luke-jr: i dont think the US actually has any literally any AAB+ rate banks period; if you want your money to still be there in 100 years, its the only option; i think the smart money is in these swiss only banks
04:38 < maaku> Luke-Jr: on the other hand, St. Vincent is only an hour or two away from you, doesn't require a passport, and has stricter secrecy laws than .ch
04:39 < adam3us> maaku: yes but i doubt st vincent has any AAB+ banks either, so if you are paranoid about the safety and continuity of your wealth (think Allen Stanford carribean bank scam), .ch is the gold standard
04:40 < adam3us> maaku: i know a guy here in malta, who's dad lost his shirt in the Stanford ponzi scam, the Stanford guy had put a lot of effort into building a credible bank profile and reputation
04:41 < Luke-Jr> no government lasts forever, not even .ch
04:41 < adam3us> luke-jr: they lasted longer than yours so far :P
04:41 < Luke-Jr> adam3us: which is all the more reason they might fall first :p
04:42 < adam3us> luke-jr: and they're politically neutral, armed to the teeth, and are holding 1/3 of the worlds offshore wealth, no one, not even the nazis wanted .ch to fail - politicians dont piss where they have their money hidden
04:42 < Luke-Jr> that was 50 years ago
04:43 < Luke-Jr> frankly, if I lived almost anywhere in Europe today, I'd probably be taking up arms against the government
04:43 < adam3us> luke-jr: they still have 1/3 of the worlds offshore money thats a big chunk of real-politic leverage
04:43 < Luke-Jr> maybe
04:44 < adam3us> luke-jr: .ch is also not politically part of .eu - they had a referendum and the citizens were against it
04:44 < Luke-Jr> adam3us: but they ratified the UN CRC
04:46 < adam3us> luke-jr: i think their focus as a country is to retain their gold standard banking status, because their livelihood depends on it, they have no natural resources other than cheap hydro, and they are almost the wealthiest country per capita in per capita income, they dont want to screw that up
04:46 < Luke-Jr> yeah, it might be good enough for just holding money
04:46 < Luke-Jr> but still, I'll have to figure out this passport nonsense first
04:47 < maaku> Luke-Jr: you can do it by mail. is there something holding up your case?
04:47 < adam3us> luke-jr: it aint that bad, get somebody to do the paper work for you - i hate paper work also
04:47 < Luke-Jr> maaku: pretty sure you can't here
04:47 < Luke-Jr> I think you have to go in and get fingerprinted and all sorts of garbage
04:49 < Luke-Jr> and yeah, I expect trouble with my case because of past legal problems with a certain insane State too
04:50 < adam3us> btw about this mintchip thing for bitcoin private keys, offline etc; i think the guy is missing to know about observer protocols, this can be done with an 8-bit smartcard CPU, not read coinswap yet is there another thread
04:50 < maaku> well unless it's a child support issue or your have outstanding warrants, i don't think they have the right to deny you
04:50 < maaku> sucks about the situation though, hope it gets sorted out
04:51 < Luke-Jr> maaku: yep, it's a child support issue
04:51 < adam3us> luke-jr: if you were serious about account, i do not think its a hard requirement to visit switzerland to setup an account, you'd have to ask them to check that is still the case (was about 10 yrs ago for sure)
04:52 < Luke-Jr> Nebraska thinks my wife and I should pay child support to the State for our children, because they kidnapped them for 3 years
04:52 < maaku> wtf.. jesus. that is fucked up, and yet not suprising. my condolances.
04:53 < Luke-Jr> (which is a big part of why I have zero tolerance for the UN CRC which purports to do away with parental rights entirely)
05:00 < petertodd> Too bad organizations like http://www.parentalrights.org seem to be all coming from the "strict parental rights" side of things - myself I'm in favor of something more like a third option where for many issues neither the state nor the parents should have rights over their children. (IE access to contraceptives should be something neither the state nor parents should be able to prevent)
05:02 < Luke-Jr> contraceptives should be blanket illegal for everyone in all cases
05:02 < petertodd> ha, I thought Catholic thinking on that subject had been relaxed these days?
05:02 < Luke-Jr> Catholic teaching is perfect and thus never changes.
05:03 < petertodd> Don't you mean our records of the past teachings of the Church must be wrong?
05:03 < Luke-Jr> no.
05:03 < petertodd> (aka, the 1984 doctrine :P)
05:04 < Luke-Jr> I have no idea what you're talking about.
05:04 < Luke-Jr> all recorded Church teaching is consistent with current Church teaching…
05:05 < petertodd> As in, in my model I'm saying Catholic teaching can change in reality, but of course everyone knows it doesn't, therefore any inconsistencies are obviously imperfect records of the past. (I jest obviously)
05:05 < Luke-Jr> except there are no historical records to support that
05:06 < petertodd> Luke-Jr: it's a joke!
05:06 < Luke-Jr> jokes are supposed to be funny.
05:06 < petertodd> Luke-Jr: funny is subject to consensus problems :p
05:07 < petertodd> proof-of-comedy would be an aweful way to do an alt-coin...
05:09 < petertodd> anyway, in all seriousness, my other point is you don't want a standard based on "the best interests of the child" because you want diversity in society. For instance, you could make an argument that homeschooling isn't in "the best interests of the child" and stop parents from doing so, when we're much better off having that diversity in society.
05:11 < petertodd> The right approach is "Does this cause sufficient provable harm that we can't accept it?"
05:13 < petertodd> on topic: WTF is with 122.108.150.47, it reports nServices as 00002017
05:14 < petertodd> Five bits set in total.
05:18 < Luke-Jr> petertodd: not quite. the problem is that the question doesn't exist.
05:18 < Luke-Jr> governments do not have *jurisdiction* over child custody/care
05:19 < Luke-Jr> they have no grounds to even set any standard at all
05:20 < Luke-Jr> so even if it can be demonstrated that Joe Parent's way of raising his children is harmful, nobody has the authority to kidnap his children
05:21 < petertodd> ok, so can I murder my own kids?
05:22 < Luke-Jr> hopefully someone would stop you
05:22 < petertodd> indeed, maybe someone paid by my tax dollars
05:23 < Luke-Jr> maybe
05:23 < Luke-Jr> they still can't kidnap your children, though
05:23 < Luke-Jr> and if you actually succeed in killing one, you're then a criminal who can be locked up
05:23 < petertodd> ah, see, now that could be closer to a reasonable standard: if it's not behavior that would get the parents criminal charges, maybe the state should keep it's hands off
05:25 < Luke-Jr> actually, on that note, that's part of why the US is as bad as it is
05:25 < Luke-Jr> since there's no criminal charges filed, they never have to prove anything
05:25 < petertodd> that's a very good point
05:25 < petertodd> child protection actions should absolutely be held to standards of due process
05:40 < adam3us> luke-jr: btw i wasnt saying move to .ch i was saying put your money there and declare it on your US tax form, in that way your funds are protected from US court decisions, the swiss model is they have  jurisdictional authority and do not accept foreign courts and law enforcement unproven claims, they require to see the proof
05:41 < adam3us> luke-jr: and the activity has to be illegal by swiss laws, not by foreign laws - and their laws are generally more sensible, and more fairly interpreted with less risk of political interference
05:41 < adam3us> luke-jr: of course I wouldnt doubt the US law enforcement would present outright forged evidence to try get their way if they were worked up enough
05:43 < adam3us> back on topic: posted some crypto comments on the mintchip like "othercoin.com" guys thread https://bitcointalk.org/index.php?topic=321085.msg3440818#msg3440818
05:44 < adam3us> i think its far more efficient and he doesnt need crypto hw accel that he's giving up openness and signing NDAs to get access to
05:44 < adam3us> and probably 10x the hw cost for also
05:45 < petertodd> interesting
05:46 < petertodd> what's available for open source smartcard devel?
05:46 < petertodd> when I looked I couldn't find remote attestation, so you'd be stuck with a trusted distributor
05:46 < adam3us> retep: brands is a genius :) u dont need anything much to do the observer part
05:47 < petertodd> ?
05:47 < adam3us> retep: just cx+w mod n (one 256-bit mod mul, one 256-bit add these are integers not point ops)
05:47 < adam3us> retep: that can be done in software, now crypto accel on an 8-bit card in a timely fashion; about hw tamper resistance i am not sure
05:47 < adam3us> retep: correction now=no
05:49 < petertodd> right, but these cards are stuck implementing ECDSA exactly like bitcoin needs, there's no alternative
05:49 < adam3us> retep: to my way of thinking, relying on the good behavior of a hw manufacturer central or a small pool is the antithesis of user controlled blockchain security, and its not far removed from an AES encrypted balance and MAC msgs flowing between cards with a shared key
05:50 < petertodd> (other than revealing d and locking coins to H(d), but that doesn't have verifiability)
05:50 < adam3us> retep: is there anyway we could get EC schnorr sigs deployed w/out a hrd fork
05:50 < petertodd> yeah, we can add anything we damn well want in a soft-fork
05:50 < adam3us> i'll volunteer to implement EC schnorr and write the BIP
05:50 < petertodd> it's not going to happen for a long time
05:50 < adam3us> there are dozens of wins from schnorr over the wretched DSA
05:51 < adam3us> eg k of n, n o n sigs in teh space of one sig
05:51 < petertodd> all of which don't matter because even I don't know what you're talking about :P
05:51 < adam3us> blding etc
05:51 < petertodd> we can't even get people to support p2sh... asking for new sig methods is hopeless in the near future
05:51 < adam3us> retep: schnorr is better and enables  many things; dsa is a cheap and inferior knock off of schnorr
05:52 < petertodd> as I say, it's completely irrelevant because the politics of changing anything in bitcoin is a nightmare
05:52 < petertodd> go propose it to litecoin instead
05:52 < adam3us> retep: i started out anti-alt-coin, but the more i see this kind of thing, the more its weakening that reasoning
05:52 < petertodd> yup
05:52 < adam3us> retep: i prefer the bitcoin staging approach to lite-coin
05:52 < petertodd> I'd give it 50:50 that you could get that implemented in litecoin in, say, two years
05:53 < petertodd> bitcoin staging is hopeless because there's no financial incentive, litecoin is your bitcoin staging
05:53 < adam3us> retep: why dilute the digital scarcity with a param tweak if you're not even one of the first week "soft premine" winners
05:55 < adam3us> retep: i just mean its destructive of the meaning of digital scarcity, to lend support to param tweaks like litecoin, if you want to o it, i think do it with the bitcoin-staging mechanism with or without foundation buyin
05:55 < petertodd> meh, we can live with one tweak
05:55 < adam3us> retep: as that retains the 21 mil coin cap and doesnt start a fresh gold-rush
05:56 < adam3us> retep: yes we could but its partly a matter of principle: why should we enrich a bunch of param-tweakers, just because bitcoin itself cant change quickly due to security validation risks of soft forks/hard forks, hence bitcoin staging
05:56 < petertodd> destructive or not, doing stuff in litecoin is viable, and has the advantage that the competition can induce bitcoin to actually change
05:57 < petertodd> anyway, go write the code! we can figure out how exactly to deploy it later
05:57 < adam3us> retep: scrypt(1) is broken for its design objectives... its even a bad param tweak - its not even memory hard
05:57 < petertodd> all this stuff is the exact same codebase
05:57 < petertodd> who cares? litecoin exists and has ameniable politics
05:58 < adam3us> retep: true
05:59 < adam3us> retep: maybe the observer proto can be made to work with ECDSA but i am not looking forward to the slog of figuring out if or how, it just seems so stupid to be using DSA given the multple clear advantages of Schnorr were its all trivial
05:59 < petertodd> explain the observer protocol?
06:03 < adam3us> retep: so with schnorr, similarly to dsa, the signature is computed all mod n not group values (except for the initial witness r=kG in DSA and analogus a=kG in schnorr)
06:04 < petertodd> right
06:05 < adam3us> retep: so in ECDSA sig is r,s where r = R.x from R=kG, and s=k^-1(H(m)+rd) mod n where in EC Scnorr: sig is a,s: a=R.x, s=k+H(a,m)d mod n
06:06  * Luke-Jr ponders why adam3us is using retep for petertodd
06:06 < petertodd> Luke-Jr: it's backwards day
06:06 < adam3us> retep: verification is ECDSA sR=?H(m)*G+rQ in ECSchnorr its rG =? A+cQ whre c = H(a,m)
06:06 < petertodd> right
06:06 < Luke-Jr> ?yllaer
06:06 < adam3us> luke-jr: he has a ridiculously long handle & ive been typing too uch and its his bitcointalk handle :)
06:07 < Luke-Jr> adam3us: .. you don't have a real IRC client? :p
06:07 < petertodd> don't you have copy-n-paste?
06:07 < Luke-Jr> pe<tab> is sufficient
06:07 < adam3us> luke-jr: its pidgin and i am a irc client n00b so i am probably missing existing features
06:07 < petertodd> BTW, I prefer to be called by my full name: peterkevin-georgetoddthethird
06:08 < adam3us> petertodd: (hot damn thanks luke-jr TAB works)!
06:08 < petertodd> (or if you're british: thehonorablepeterkevin-georgetoddthethird
06:08 < Luke-Jr> didn't IRC have a 7 character limit to nicks? or was it 11?
06:08 < Luke-Jr> <.<
06:08 < petertodd> Luke-Jr: it got turned up to 11
06:09 < adam3us> petertodd: ok so the interesting thing about schnorr is there is no dreaded k^-1 factor so its easy to do 2 of 2.. just add the k & c*d contributions together, DONE!
06:09 < warren> <petertodd> destructive or not, doing stuff in litecoin is viable, and has the advantage that the competition can induce bitcoin to actually change
06:09 < warren> <---- has already happened
06:10 < warren> <adam3us> retep: scrypt(1) is broken for its design objectives... its even a bad param tweak - its not even memory hard
06:10 < adam3us> petertodd: now observer, because of the flexibility there is a DL generalization called the representation problem instead of Q=xG you can have Q=xG+yH for two generators G & H whic no one kows the DLof
06:11 < warren> <---- yes, it's true, and that doesn't actually matter
06:11 < adam3us> warren: really whats the example of already happened?
06:12 < adam3us> petertodd: now you can give x to the smart card and H to the wallet/phone and the issuer can do the a=kG work, so the wallet only has to do r1=cx+w mod n
06:12 < warren> adam3us: at the simplest level, we exposed bugs in several components before they were merged into bitcoin-0.9.  More complicated: we influenced the recent security releases with our own research meant to protect the bitcoin network.
06:13 < warren> adam3us: there remains more we are not disclosing to the public because it would risk to the bitcoin network
06:13 < warren> adam3us: the recent lively discourse about NODE_BLOOM remains unresolved and is related to one of those issues
06:13 < adam3us> petertodd: the extended EC schnorr sig is a, r1, r2
06:14 < adam3us> warren: ok, thats v. interesting and good to know, but i still prefer bitcoin-staging if it could be got off the ground
06:14 < warren> adam3us: good luck
06:16 < warren> adam3us: I'm not married to litecoin.  I just looked at the state of things in March when I joined, found Litecoin to be "unmaintained, totally broken and without political opposition to fixing things" so I used that as a means to learn the codebase.  I've been increasingly branching into fixing things in Bitcoin.
06:16 < adam3us> warren: re scrypt(1) apparently ROMix (also by colin percival) is provably memory-hard, memory hardness (freedom from time-memory tradeoffs) was not a design requirement of Scrypt(1)
06:16 < warren> adam3us: I began coin dev in May 2013, all of the failures you're talking about were long before my time.
06:16 < adam3us> warren: bitcoin armory is using ROMix for key derivation rather than Scrypt for this reason
06:18 < adam3us> adam3us: eg if you like you can make an scrypt implemntation (hardware or sofware) that is using mem=128kB parameter, but 16kB ram or 1kB ram - just more inner round repetition
06:18 < warren> adam3us: i'm fully aware of the TMTO thing, and i don't care.
06:18 < adam3us> warren: someone should try that, maybe you can mine scrypt faster on a gpu or fpga that way => profit
06:18 < warren> adam3us: people have tried
06:18 < warren> and I don't care what users do
06:19 < adam3us> warren: would be curious what the optimal scrypt tmto params were for diff hw
06:19 < warren> adam3us: the standard GPU miners use a 50% memory TMTO which seems to maximize performance for scrypt on that hardware.  there's apparently FPGA and ASIC's hapening soon too.
06:20 < adam3us> warren: yes i hear the asic rumor will be interesting to see how that compares perf
06:20 < warren> adam3us: like I said earlier, the failure of the original scrypt parameters has nothing to do with the soundness of the network and its ability to defend itself
06:21 < warren> adam3us: I personally would be more concerned about the coins that invite regulatory hazard through properties like centralization
06:23 < adam3us> petertodd: so the observer conclusion is its a special form of 2 of 2 sig where the smartcard cant even tell which sig it contributed to (privacy) and yet can prevent double spending (up to hw tamper resistance) the observer is the smartphone/computer the card connects with which can prevent inflow/outflow subliminal channels
06:23 < warren> adam3us: I had already spent months testing a hybrid of 0.8 and 0.9 with Litecoin, so I reused most of that work in a Bitcoin branch with fixes and features.  https://bitcointalk.org/index.php?topic=320695  Exposing more bugs before 0.9 while bringing some features to users sooner.
06:23 < adam3us> warren: agreed on both fronts, that was my motivation for committed transactions
06:23 < petertodd> adam3us: right, so explain in 30 seconds what's the big advantage of schnorr? is it flexibility? privacy?
06:24 < adam3us> petertodd: both
06:24 < petertodd> adam3us: ok, so what's the list of what it'll make possible? (remember, I need to explain this to a pool op, for instance)
06:24 < adam3us> petertodd: efficiency, flexibility, privacy, O(1) vs O(n) compactness of k of n sigs
06:24 < petertodd> adam3us: not clear enough
06:25 < petertodd> Like, give me a really simple example of something I can't do now, but will be able too.
06:25 < adam3us> petertodd: so you can make k of n sigs where the public key is a single public keya nd the private key is split into n pieces so you can have k of n sigs
06:26 < adam3us> petertodd: you can also after-the-fact combine your public key with another user to create an after the fact 2 of 2 (or n of n) that is represented by a single public key on the transaction
06:26 < petertodd> My inner Joe Public is saying "Huh?"
06:27 < adam3us> petertodd: so this results in smaller n of n sigs and privacy of how many people even are behind an address
06:27 < petertodd> huh?
06:28 < adam3us> petertodd: if n of n or k of n become widely used the sigs are smaller .. one sig vs n which saves block chain space, and makes chain validation n times faster
06:28 < petertodd> why are you fucking up Bitcoin? Bitcoin is perfect already, all hail Satoshi!
06:28 < petertodd> why all this complexity with n's and k's when you have bitcoin addresses and my balance!
06:29 < adam3us> petertodd: the primary risk for bitcoin is centralization and scalability, if that fails, bitcoin fails when dust becomes $10k and everyone switches to using lame trust me centralized "offchain", everyone shoudl care about this :P
06:30 < petertodd> The wiki says Bitcoin scales to VISA levels! Says so! Why change what already works!
06:30 < adam3us> petertodd: u need n of n for like type2/type3 exchanges, escrow situations etc so I expect them to become more common over time
06:31 < adam3us> petertodd: yeah right - i also can say something scales (with the unstated assumption that i can invent, implement and deploy not yet invented innovations that may not even be mathematically feasible) :D
06:31 < petertodd> type2/type3 exchanges? why do we want exchanges? decentalized exchanges is what we need like localbitcoins!
06:31 < adam3us> petertodd: u run a nice devils advocate line btw
06:31 < petertodd> heh
06:32 < petertodd> or in this case, devils mouth-breathing southern cousin :/
06:32 < warren> well, I give up, I cant' actually test mac builds/runtime so I can't fix this.
06:33 < adam3us> petertodd: u want type2/type3 because they are trustless - they cant steal your bitcoins, but they can green color tx so that settlement is faster allowing you to onwards trade and avoid volatility risk
06:33 < adam3us> petertodd: thogh i am also a fan of p2p atomic trade (must go reread those protocols and see if they are actually secure from abort/extort attacks)
06:33 < petertodd> heh, even I don't know what "type2/type3" exchanges are...
06:34 < adam3us> petertodd: type2 is like what bitalo is now working on, exchnge escrows fiat, but only does a2nd 2 of 2 sig n the transfer to finalize it; the actual ownership and authority is with users, a time lock ensures the user retains their bitcoin even if the exchange goes down without warning
06:35 < warren> I looked into installing a hackintosh VM to test this, but the amount of time needed to do it appears more than the time value of just buying a mac.
06:35 < adam3us> petertodd: type3 is if you have blockchain tradeable assets like litecoin vs bitcoin, or colored usdcoin from an issuer vs bitcoin or goldcoin; then the xchange isnt even escrowing fiat
06:37 < petertodd> right, I've never heard those terms myself
06:40 < adam3us> petertodd: probably cooked up in offline colorcoin discussions - to save having to describe a paragraph worth just give them a ame
06:40 < petertodd> huh, you gotta admit though, that's politically going to be seen as a very niche reason to change stuff
06:40 < adam3us> petertodd: sounds cool to VCs too ;)
06:41 < petertodd> you ever looked at the bitcointalk archives re: p2sh? just getting that was horribly painful
06:42 < adam3us> petertodd: probably scalability changes and decentralization are far higher priority however as far as I see its mostly an open research question if anything fundamental (non-incremental) can be done with scalability
06:42 < adam3us> petertodd: i didnt, but i think i got it; maybe i am missing something though?
06:44 < petertodd> one ugly thing with scalability is it's just as likely that bitcoin won't scale with regard to verification, so we'll see centralization, and rather than fix that the alternative instead will be people start using other systems that also don't scale, but have sufficiently low usage that they work in practice
06:44 < adam3us> petertodd: most people on the scalability idea exploration end up reinventing consensus ripple, and finally realizing how bitcoin defends against sybil and then "oh now i get it" :)
06:44 < petertodd> huh? who is even working on scalability other than myself and gmaxwell?
06:46 < adam3us> petertodd: multiple people think distributed offchain/scalability magic is the holy grail and are queueing up to pay for it to happen
06:46 < petertodd> such as?
06:46 < adam3us> petertodd: i'm not saying they got anywhere technically, i am saying they magically wish it could happen... and see $ for whoever could deploy it first
06:47 < petertodd> inputs.io and coinbase, among others, have actually deployed it, and it works just fine
06:47 < adam3us> petertodd: thats not distributed
06:47 < petertodd> it's dead simple and trading off counter-party risk is perfectly acceptable to a lot of people.
06:48 < petertodd> you mean decentralized, and so what? centralized solutions built on top of decentralized ones mean you've always got the decentralized system to fall back on
06:48 < adam3us> petertodd: well if that goes to its logical conclusion in 5 years and everyone is using trust me big 10 offchain bitcoin is dead for its assumed value/purpose of auditability, zero trust
06:48 < TD> you mean, working on scalability, other than maintaining an entire SPV implementation ... :)
06:49 < petertodd> the real problem there is "worse is better" and things like inputs.io already exist, so even incremental imrpovements become hard
06:49 < petertodd> adam3us: meh, you can audit off-chain stuff easily.
06:49 < adam3us> petertodd: right, i think its pressing problem even if bitcoin scales for a few years, because momentum "good enuf" will push everyone onto inferior centralized solution
06:49 < petertodd> adam3us: again, an auditable, decentralized base is what you build on.
06:50 < adam3us> petertodd: right, but how
06:50 < petertodd> adam3us: yes, either "good enough" will be the worst possible off-chain solutions with no auditing at all, or SPV clients with no auditing of the blockchain and a small number of centralized full-nodes/miners
06:51 < adam3us> petertodd: if coinbase and 20 more like them rule 99.99% of tx in a few years, and they settle between them on the block chain at $1mil at the end of the day.. how is that bitcoin
06:51 < petertodd> adam3us: at least with the former you can bolt-on auditng at any time
06:51 < adam3us> petertodd: they'd just as well settle with a wire transfer
06:51 < petertodd> adam3us: simple example, you can audit that backing funds exist with merkle sum trees
06:51 < adam3us> petertodd: agree, auditability is good
06:51 < petertodd> adam3us: heck, have you read any of my fidelity bonded banking stuff? not only can you audit, you can punish fraud
06:52 < petertodd> adam3us: that's bitcoin because for $10 or $100 or whatever it ends up being you can pay that tx fee too and have equal access that anyone else does.
06:53 < adam3us> petertodd: alternatively you can add auditability to banking networks, they probably will at some point as its more secure than firewall and fiat balance in a db - at that point its all the same thing
06:53 < petertodd> adam3us: Bitcoin isn't about making things *free*, it's about making barriers to entry be based on proof-of-work and nothing else.
06:53 < adam3us> petertodd: i think what you lose is the bearer / ecash property
06:53 < petertodd> adam3us: auditability is much less interesting than decentralization of control
06:53 < adam3us> petertodd: agreed
06:54 < petertodd> adam3us: the issue isn't banks committing fraud, it's banks commiting *legal* fraud. Everyone knows currencies are inflated, it's not a secret.
06:54 < adam3us> petertodd: i made a claim that ecash is not ecash unless its irrevocable and unseizeable/unfreezable
06:54 < adam3us> petertodd: and i'm more interested in ecash that ripple iou networks which are just papalizing banking networks and will revert to form in 5 years
06:55 < petertodd> Well, worst case with 1MB blocks forever and the dumbest possible off-chian solutions is that you can make your savings irrevocable and unseizable/unfreezable. That's pretty damn good.
06:55 < petertodd> With fidelity bonded banking, you're savings are much harder to revoke or seize, because the moment you do so you can prove to the world that has happened, and the world can chose to go to another bank.
06:56 < adam3us> petertodd: yes two things: digital scarcity is a new commodity class, and separately ecash is better than a claim on a balance on a server with its bitcoin denominated or usd, block chain audited or not
06:56 < petertodd> Right, but the onus is on you to figure out how you can have your cake and eat it too, because in it's current form Bitcoin is fundementally unscalable. The "solutions" to scability are all to introduce more centralization.
06:57 < adam3us> petertodd: are you sure your funds are unseizable in a $10k dust rule network with coinbase model? you dont even have your private key...
06:57 < adam3us> petertodd: what if you dont have enough funds to pay the min fee
06:58 < petertodd> adam3us: The first $10k of your funds got seized, but your other $100k didn't. That's a huge improvement over the whole lot being seized because Bitcoin mining has long sicne become a regulated activity with blacklists.
06:58 < adam3us> petertodd: "The "solutions" to scability are all to introduce more centralization." yes so far and that is a negative and worrying tren d for bitcoins meaningful continued existence
07:00 < adam3us> petertodd: i thought chris odom opentx model showed promise as a direction; his voting pool tx servers are auditable and rebuildable by users using the sum of the tx receipts they receive
07:00 < petertodd> BTW, lets suppose Bitcoin is worth 100 trillion, and 1% of that amount every year goes to miners in the form of fees. That works out to $20/kilobyte transaction fees, rather affordable!)
07:01 < adam3us> petertodd: not bd, but how many Gbps is a full node feed ;)
07:01 < petertodd> no, I'm saying we keep 1MB blocks in that example.
07:02 < adam3us> petertodd: probably need satellite network for globalbroadcast or the interwebs will melt with many full nodes
07:02 < petertodd> Why?
07:02 < adam3us> petertodd: n^2 everyone on the planets cup of 2nd cup coffee
07:03 < adam3us> petertodd: whats the famous canadian coffee shop? maybe it was timhortons ;
07:04 < adam3us> petertodd: clearly it can scale to some extent but its less interesting if its a clearing network than a direct user network
07:04 < petertodd> oops, I got that calculation wrong... lol, $20,000/kilobyte tx fees, not so affordable. However, lets say 100 billion valuation, 1 billion a year to miners, and you're at $20/KB.
07:04 < adam3us> petertodd: if it gets that large i expect the people running the show could just as well turn off their miners and sign clearing agreements
07:05 < petertodd> (right now tx's cost about $20 already in fact due to the inflation subsidy...)
07:05 < adam3us> petertodd: yeah thats kind of scarcy... hidden cost.. people say btc costs 2c but its actually 1000x worse
07:06 < petertodd> Fucking hell, who cares how "interesting" it is for your morning coffee? What's important is that we have a solid decentralized store of value with a decent way to move it around. We can improve upon that later, but don't fuck up the base.
07:06 < petertodd> Fundemetnally we have to figure out how to make validation scale.
07:06 < petertodd> Second fundemental is we have to figure out how to make transaction selection scale.
07:07 < adam3us> petertodd: u mean validation scale is reduce the broadcast bandwidth feed fr a full node? or cpu?
07:07 < petertodd> CPU isn't very interesting, don't focus on that. Bandwidth is what's interesting because censorship-resistant bandwidth is hard to come by.
07:08 < petertodd> Censorship-resistant CPU power is availble at stores around the country...
07:09 < adam3us> petertodd: yes;; so a ultra-crude what-if is say divide the n^2 into 1000 subgroups, payments are then either in-subgroup or cross subgroup, and mergemine subgroups
07:09 < adam3us> petertodd: cross subgroup takes 2 tx but thats stil smaller than 1 tx broadcast 1000x wider
07:10 < petertodd> yup, I proposed that one a few months ago
07:11 < adam3us> petertodd: yes i think multiple people proposed the same what-if
07:11 < adam3us> petertodd: I did, vitalk did also probably others... but its not clear how well that could work
07:12 < petertodd> AFAIK I was first :P The issue actually comes up with fidelity bonded banking, because you need to ensure that proof-of-fraud can be effectively published, and you need to have proof that you know about all fraud published for some given domain.
07:13 < petertodd> Anyway, I hope we agree that until a viable system for subgroups is proposed, and it's possible to mine blocks in a decentralized fashion, it's deeply dangerous to tinker with the scalability of Bitcoin.
07:15 < adam3us> petertodd: i'm not sure - you're saying dont change anything until we know the best longer term scaling approach or the scalability patches might actually make things worse?
07:15 < adam3us> petertodd: decentralized mining... yes i think that could be a nice partial win if that could be figured out
07:15 < petertodd> adam3us: remember that we've got people in this community who want to remove blocksize limits entirely while leaving the rest of the system as-is.
07:16 < petertodd> That's the idiotic opposition you're up against, not people who have a deep understanding of Bitcoin.
07:17 < adam3us> petertodd: gotcha, yes i agree with your previous arguments that upping he bw requirements aggressively is dangerous for decentrailzation (and also why i said i'm not sure i buy the "bitcoin scales to visa" type of hand-waving - oh yes, how and at what cost)
07:18 < petertodd> adam3us: With sufficient trust you can make any pig fly. :P
07:18 < adam3us> petertodd: u know i hear swift itself is nominally p2p
07:18 < petertodd> Ha, yup!
07:18 < adam3us> petertodd: so if the way we reach visa scaling is to run 50 bitcoin nodes on a closed network contrlled by big banks i am not so intereste
07:19 < petertodd> Exactly. And in between now and that, there's a lot of trade-offs.
07:19 < petertodd> 10MiB blocks aren't so, bad, 100MiB kinda iffy etc.
07:20 < adam3us> petertodd: we need something fundamental new insight .. the picture so far is moderately clear, but no clear path forward is in sight
07:20 < petertodd> Now where the "just remove the limits entirely" thing is so obnoxious is that the basic idea, just let miners chose, is such a fundemental misunderstanding of the nature of validation and trust in Bitcoin.
07:21 < petertodd> of course there's no clear path forward, every path has different costs to different people!
07:22 < adam3us> petertodd: u might wonder if there is some moderate incremental scalability gain lurking in using accumulator tree vs hashtree
07:22 < petertodd> heck, there's a decent enough chance that nothing at all will happen and Bitcoin will remain, technically, identical to it's current form for a long, long time.
07:22 < adam3us> petertodd: yes but that way lies doom unfortunately, if the tx and users continue to scale
07:23 < petertodd> adam3us: do you understand how TXO commitments can be re-worked into a shardable blockchain?
07:24 < petertodd> adam3us: nah, $20 uncensorable transactions of unseizable electronic money is a pretty damn good outcome. Be nice if we can do better than that, but just that alone is pretty good.
07:24 < adam3us> petertodd: i think vaguely is there a forum link or search term?
07:24 < adam3us> petertodd: $20 i agree
07:24 < petertodd> I've explained it in IRC, haven't written anything up on bitcointalk
07:25 < petertodd> Yup. The real danger with off-chain stuff isn't that transactions will be expensive, is that they'll be too cheap! Bitcoin's inflation rate goes to zero in the long run, and at some point the minimum reward to miners will become low enough that the security of the whole system is threatened.
07:25 < adam3us> petertodd: well one argument could be for unseizable digital scarcity wealth storage and not high tx  at all, that is interesting in itself even without p2p tx at any high volume beyond a few tx per year per user
07:26 < petertodd> yup
07:26 < petertodd> you can always build upon that layer
07:26 < adam3us> petertodd: interesting observation, yes offchain success threatens chain security at the limit
07:27 < petertodd> Yeah, on the other hand, what matters isn't what transaction fees are, but rather what profit margin there is. Or to be exact, how much money is uselesslessly spent on overhead rather than mining itself.
07:27 < adam3us> petertodd: without naming names some people seem a little impatient and short-termist and they may steer things into dangerous directions without really thinking things through - i do like how you focus n the long term big picture
07:27 < adam3us> petertodd: its like chess, you dont win by looking at the next move, but at the end game from the start
07:28 < petertodd> People without a good understanding of economics have often argued that we need larger blocks because we need lots of transactions so the fees can support miners, but if those fees go into network bandwidth and harddrives, we haven't gained anything.
07:29 < adam3us> petertodd: and there is lots of scope for extremely plausible long term thinking sabotage disguised as rational short-term pragmatism; i get of assertive short-termists who cant explain or dont wish to entertain long term implications
07:29 < petertodd> For sure. There's a lot of pressure in this community for people like me to stop talking so much about the long term and focus on "real world engineering", but that's the kind of thinking you see at web 2.0 startups, and they have an alarming tendency to die early deaths.
07:30 < adam3us> petertodd: /i get ^suspicious of^ assertive.../
07:30 < petertodd> Ha, for sure, once you start assuming possible malice all this stuff gets really ugly. :P
07:30 < adam3us> petertodd: precisely
07:31 < petertodd> Reminds me: the more I think about it, the more I think I should be encouraging abuse like timestamping and data-in-the-chain so we get a good understanding of the parameters of that abuse before making decisions based on assumptions about what demand there is to do such things.
07:31 < adam3us> petertodd: i've been through a few startups, and without embarrassing the guilty, a guy who wanted to code and stop wasting time thinking and architecting the right solution, within 1year it deadended
07:31 < MoALTz> one idea is that some coin gets lost in every transaction, as well as fees. reason: the "loss" is actually donating value to the network as compensation for bandwidth, hard-drive storage, cpu usage; the losses mean that all the remaining coin gets more valuable
07:32 < petertodd> adam3us: Absolutely. This isn't a standard engineering problem where the solution space is well understood.
07:32 < adam3us> petertodd: it only didnt get ugly at company future level cos i rewrote it from scratch in a 80/hr week skunkworks
07:32 < adam3us> petertodd: 1 week of the right thing vs 1 year x 10 people of "stop talking big picture write code" ... thats the true picture
07:33 < petertodd> adam3us: Heh. Another case in point: maaku has spent a lot of effort implementing UTXO commitments with authenticated radix trees, and meanwhile I come up with TXO commitments seem to have made all that effort obsolete.
07:33 < petertodd> A month in the lab saves a day in the library. :/
07:33 < MoALTz> writing code that does something is indeed better. i need to do more of that.
07:35 < petertodd> Equally though, code is needed too... The lesson is just to understand the problem well before you start getting into code.
07:35 < adam3us> petertodd: that company later sold for $100m that probably wouldnt have happened w/out that rewrite... startups are full of random unproductive "code fast" shit that amazingly frequently ends up in the dustbin, ZKS was like that also
07:35 < adam3us> petertodd: exactly
07:35 < MoALTz> petertodd: easy to overdo it the other way
07:35 < adam3us> petertodd: problem is its very very hard to see any big improvement
07:37 < adam3us> petertodd: i think because of the interconnected cross dependencies; each important piece is fulfilling 3 or 4 functions, and while each function could get scaling by omiting a feature you cant change anything because overall it only just works with all the cross deendencies in place
07:37 < petertodd> MoALTz: The problem with my way is it's hard for people who don't understand the issues in great detail to tell the difference between smart people thinking hard about a problem, and wasting time doing nothing of real value. Code on the other hand can be evaluated for volume relatively easily.
07:38 < adam3us> petertodd, MoALTz: i can actually code, damn fast too; but mostly i am trying to solve the hard problem - if i crack a hard problem, will be coding like a demon :)
07:38 < petertodd> adam3us: Yup. I run into that at my day job all the time, because our system is extremely tightly coupled and unavoidable so. I've quite literally done projects that involved 8 months of design, followed by a week or two of implementation, with the implementation working pretty much perfectly the first time.
07:39 < adam3us> MoALTz: but yes there are multiple pressing issues that have gotta be worked on now that are defined
07:39 < MoALTz> adam3us: i tend to think of ideas, test them in my mind a lot, but cannot keep myself coding up a test implementation for them long enough to test them
07:39 < petertodd> adam3us: I've also had projects with 8 months of implementations, followed by realizing that was all a waste and I should have done a month of design up-front.
07:40 < adam3us> petertodd: a problem in startup culture that contributes is that management thinks of the work so far as "investment" so they cant change path even when they see the writing on the wall that this is a very bad path
07:41 < adam3us> petertodd: when hat you've done so far turns out to be wrong, yo need to be willing to rip it up and start again, they rarely can do that
07:41 < adam3us> petertodd: so ayway more back ontopic: i was wondering about disentangling bitcoin mining dependencies
07:41 < petertodd> Yup. I'm lucky to have a boss who's willing to accept that sometimes you've got to throw away what you've done, but even then it's hard.
07:42 < adam3us> petertodd: as i think in isolation nicer things can be done, just not on the interdependent version
07:43 < adam3us> petertodd: eg if you're talking about reward only (not relating to validation) you could probably direct mine with 0 variance work and no need for mining pools
07:43 < petertodd> Ok, before you get too deep, so lets check: what are the main functions of mining?
07:43 < adam3us> petertodd: so leads to can you separate reward from validation
07:43 < adam3us> petertodd: confusingly many :)
07:43 < petertodd> Yeah, reward != validation.
07:44 < petertodd> OTOH, in practice you need things like tx fees so you can figure out which tx should be in a block.
07:44 < adam3us> petertodd: so reward, blockchain evolution voting, spv client validation, sybil attack defense
07:44 < adam3us> petertodd: did i miss some?
07:45 < adam3us> petertodd: ah yes you reminded converging on a block definition
07:45 < petertodd> See, you're talking about a level farther removed than what I would have said.
07:45 < petertodd> For instance, proof-of-publication is really important.
07:46 < adam3us> petertodd: ah yes arbitrating which tx is first in double spends
07:46 < petertodd> Right, so timestamping.
07:46 < adam3us> petertodd: i was thinking one way to look at it is (apart from spv validation) bitcoin is actualy implementing a timestamping service
07:46 < petertodd> But do you understand what's so important about proof-of-publication? (or to be exact, proof-of-readership)
07:47 < adam3us> petertodd: and actualy something slightly more also: a namespace (like a timestamp but where names are strictly and cryptoraphically  first come first served)
07:48 < adam3us> petertodd: maybe .. are you saying like wht defines a tx as confirmed is taht you see it (and not a double-spend) in the block chain
07:48 < adam3us> petertodd: i think it cn be equated actually to an auditable namespace, where the "name" is the txout
07:48 < petertodd> See, proof-of-publication/readership is what makes timestamping useful to prevent double-spends.
07:49 < petertodd> Do you understand why?
07:49 < adam3us> petertodd: do spell it out, its probable we are saying the same thing, but with different terms; i call that an application of an auditable namspace
07:51 < petertodd> So secure timestamping - or to be exact ordering - is necessary but not sufficient: a timestamp is only valuable if I can be guaranteed to know about the conflicting transaction. Thus the blockchain serves as a publication medium, where anyone accepting a payment can be confident that by looking in the blockchain they are aware of all possible double-spends.
07:52 < adam3us> petertodd: i am unclear why you say readership though - the fact that a random powerful miner (or a lucky weak miner) voted on a tx does not guarantee that everyone saw it
07:52 < petertodd> Of course, because double-spends are invalid, *as an optimization* we don't allow them into blocks. But remember, that's just an optimization!
07:52 < adam3us> petertodd: ok yes, we are saying the same thing
07:52 < petertodd> Sure, but it is proof that the people doing the miner saw it.
07:53 < petertodd> Yeah, and currently Bitcoin is a really, really primative proof-of-publication system, because the blockchain itself has no structure, so to convince *yourself* that a double spend doesn't exist you need the whole damn thing.
07:53 < adam3us> petertodd: i made an observation that an auditable namespace is actually the same function .. ie if you set the txout to the nme you can build that on a decentralized auditable namespce, or conversely you can use bitcoin as an auditable namespce if you encoe you rname in the txout (or in its hash inputs)
07:53 < petertodd> Yup.
07:54 < petertodd> So, UTXO commitments are then just a way of getting proof that some data - a spend of the txout - was *not* published in the blockchain without having the whole chain.
07:54 < adam3us> petertodd: hence namecoin - i guess those guys saw the same thing as their motivation but i wrote about auditable namespace in 2001 http://www.cypherspace.org/p2p/auditable-namespace.html
07:55 < adam3us> petertodd: (not so interesting) but it useful simple concept to think about
07:56 < adam3us> petertodd: yes.  so is this the idea to encode them in a trie so you can more efficiently have a compact proof of present/notpresent in a tree?
07:56 < petertodd> So back to our original point about decoupling, when it comes to proof-of-publication, using proof-of-stake to prove publication would actually be totally reasonable. (for instance)
07:56 < petertodd> adam3us: Yes: take the whole UTXO set, put it in a merkelized radix tree, and commit to the top-level hash in the block somewhere.
07:56 < adam3us> petertodd: yes i think proof of stake is an interesting strengthening factor over pure mining anti-sybil, it maybe able to help
07:56 < petertodd> Even though proof-of-stake for mining reward is horribly flawed.
07:59 < petertodd> Yeah, I think proof-of-stake is going to be found to be a necessary but not sufficient requirement to get new crypto-coin systems bootstrapped in the future.
08:00 < adam3us> petertodd: k lets continue this problem definition .. i feel you should possibly sleep :) and i need some breakfast its 1pm here :)
08:00 < petertodd> So, as an example, you could have a proof-of-publication by proof-of-stake coin that looked like this: 1) assume the existance of a secure timestamping service 2) publish transactions to a blockchain 3) use proof-of-stake to show that a supermajority of coin owners know about the transaction 4) trust any transaction that everyone knows about.
08:00 < petertodd> ha, nah, I woke up crazy early...
08:01 < petertodd> *that everyone knows about and isn't a double-spend
08:04 < adam3us> petertodd: ok ... i think its interesting that other than spv clients you dont even need validation (miners to check inputs add up etc) just double use of signature (ordering enforcement or namespace of txouts)
08:04 < adam3us> petertodd: it mybe that one way to untangle the dependencies would be to say screw spv, try to improve things without it then get the otpimal solution, and try to figure how to resupport spv afterwards
08:05 < adam3us> petertodd: otherwise i think we're stuck in a local design maxima area of very polished satoshi design but possibly non-global optimum
08:06 < petertodd> Interesting isn't it? Bitcoin could have absolutely been designed as a system that did nothing more than give miners the opportunity to create arbitrary 1MB blocks of data; what that data actually means can be determined later by upper layers in the system.
08:06 < adam3us> petertodd: (i know a gifted programmer/crytpo guy who makes very elegant, clever but entangled designs, one of my satoshi suspects)
08:07 < petertodd> adam3us: heh, entangled is a great word for this.
08:07 < adam3us> petertodd: and i think it wouldve been a better system for it
08:07 < petertodd> Me too! Pushing validation to clients is a very good thing for the security of the system as a whole.
08:08 < adam3us> petertodd: yes less smarts in the network enforced rules = more security from coding bug mishap
08:08 < petertodd> Interestingly parasitic consensus systems like Mastercoin and Colored Coins are re-learning this, although I don't think the people behind them fully understand this stuff. (or even partially understand)
08:08 < petertodd> Yeah, of course, having some structure in blocks sure is convenient, but just don't forget that the structure is purely an optimization.
08:09 < petertodd> (yet another thing I need to write a paper on...)
08:09 < adam3us> petertodd: dont you need ordered chunks in blocks?
08:10 < adam3us> petertodd: ie like hash of public key or something with enforced non double use
08:10 < adam3us> petertodd: with committed transactions thats actually all i ended up relying on - the networ validation is disabled as it cant read the tx contents, cant tell who is paying who how much
08:10 < petertodd> Nope. Just validate the whole chain and make sure the transaction was the first one spending the txout. Subsequent ones can be ignored.
08:11 < petertodd> Again, the fact that subsequent ones are *banned* allows you to *optimizise* by only reading part of the chain, but that's an optimization, not a requirement.
08:11 < adam3us> petertodd: i see, even better; all you need is a timestamping server
08:12 < adam3us> petertodd: maybe you could scale via a tree of time-stamp servers
08:12 < petertodd> Yup. And this line of thinking shows you how the "proof-of-publication" domain required is on a per-txout basis: you need to know about double-spends for a particular txout, not all double-spends.
08:12 < petertodd> Obviously this is inherently shardable!
08:13 < adam3us> petertodd: yes thats an interesting line; however maybe you also need to know the non-double spent status of the previous 6-blocks worth of inputs the output depends on
08:14 < adam3us> petertodd: well i guess you mean youre valiating htem all anyway so just wait until the tx you care about is 6-blocks deep
08:14 < petertodd> For instance, you could define a system where every Bitcoin node maintains some small part of the TXO space, ordered lexographically: the blockchain still exists as a means of timestamping/ordering data, and you can determine if a double-spend exists by examining whatever small shard of the TXO data would have a spend of your transaction.
08:15 < adam3us> petertodd: yes
08:15 < petertodd> The definition is now that a transaction is considered confirmed once the proof-of-publication is sufficiently confirmed.
08:15 < adam3us> petertodd: yes
08:15 < petertodd> Wonderful isn't it?
08:15 < adam3us> petertodd: yes thats pretty f'ing cool :)
08:15 < petertodd> You don't even need to care if other inputs to the transaction are valid! That's the responsibility of the receiver to check, not the miner!
08:16 < adam3us> petertodd: right, ala committed transactions
08:16 < petertodd> If a transaction is invalid because some inputs were double-spent, so what? That's just some extra baggage in the blockchain.
08:16 < adam3us> petertodd: so long as they pay fees for their baggage it no worse than mastercoin
08:17 < petertodd> You also don't need to know about those inputs either: they can be hidden behind a merkle tree, and the miner doesn't need to have them.
08:17 < petertodd> Yup
08:17 < adam3us> petertodd: yes i reached somewhat analogous conclusion in thinking about the limits of respending committed transactions without revealing to the block chain
08:18 < adam3us> petertodd: does it reduce blockchain bandwidth though?
08:19 < petertodd> So the only issue with this, is you need *some* way to control the total volume of data, but that's not a big problem: shard this data into more and less expensive versions. Now you can determine what security level you're interested, while allowing people with really low-value transactions the ability to play in their dangerous playground.
08:19 < adam3us> petertodd: i am thinking it maybe could, with committed tx a problem i ran into was people stuffing the blockchain with forged spens, making your tx unspendable as you couldnt prove that spend was faked
08:19 < petertodd> adam3us: summed over the whole system, no, but the increase is along the lines of log(n), however it does reduce the minimum bandwidth required, and that's the important part
08:19 < adam3us> petertodd: but other than that (and maybe there are otherw ays to fix that with protocol changes) all you need is a hash output
08:20 < adam3us> petertodd: so the other thing i was thinking, is order doesnt actually matter
08:20 < adam3us> petertodd: ie you need to known an order, but you dont care which order is chosen it could be random for all you care
08:21 < petertodd> Right. So a subtety here is that for the sharding to be useful, if a transaction spends a txout it must be considered a valid spend regardless of whether or not the rest of the transaction is invalid.
08:21 < petertodd> What do you mean by random?
08:22 < adam3us> petertodd: say with committed tx; the miner sees which tx arrived first from his point of view, but he has no idea what the tx is about its an opque crypto blob to him, so if he sees also a double-spend of it, it doesnt actualy matter whcih he chooses
08:22 < petertodd> Ah, yeah, the only order that matters is the order in the blockchain.
08:22 < adam3us> petertodd: he dosnt have to be honest to what he received over the network first
08:23 < adam3us> petertodd: so then the other thing is the miner and a given user could be in collusion (so called 51%)
08:24 < petertodd> yeah
08:24 < adam3us> petertodd: you could imagine multiple network hop encryption of the tx before ordering so that the miner and his cheating buddy cant even recognize which tx is which at that stage
08:24 < petertodd> right, but anyway, the fundemental thing is that consensus on order has to be based onw hat's in the blockchain, end of story!
08:25 < petertodd> don't worry about in flight transactions and other stuff
08:25 < adam3us> petertodd: yes... so its not really arbitration of what comes first, its just pick a random tx and enforce it ... coin toss if you like
08:26 < adam3us> petertodd: which is weaker than an auditable first come first served namespace
08:26 < adam3us> petertodd: or publication as you put it
08:27 < adam3us> petertodd: so can you securely define a globally consistent transaction order after the fact without thte timestamper having any input involvin your transaction?
08:27 < adam3us> petertodd: i think... maybe
08:27 < adam3us> petertodd: the timestamper timestamps random numbers
08:28 < adam3us> petertodd: you later apply some arbitratoin logic using the 6-block old timestamp output as a becaon to drive that decision deterministically
08:28 < petertodd> So here's the other thing: with this "proof-of-publication" sharded blockchian, what a transaction should look like is you would have a merkle-sum-tree of transaction inputs, that is a reference to the previous output, and a scriptSig, and then a corresponding inverse merkle-sum tree of *outputs*. Now from any output, you can audit back to any input, and because it's summed in both directions you're guaranteed for the amounts to add up. IE: an output is considered valid if you can prove a path back to a sufficient number of valid inputs.
08:29 < adam3us> petertodd: truncated at IE: an outpu
08:30 < petertodd> IE: an output is considered valid if you can prove a path back to a sufficient number of valid inputs.
08:34 < petertodd> So, now lets look at the proof-of-publication side of things: what's the absolutele minimum thing you need to prove has been published? So we can define transaction outputs uniquely as H(txout)=txoutid. That txoutid commits to the scriptPubKey associated with the txout. Thus what you want to know, is has there ever been a valid scriptSig for that scriptPubKey ever published? This means we can take the entire space of all possible txouts, turn it into a radix tree, and at the base of the tree either have NULL or a "never been published" txout, or H(txin) if the transaction output has been spent.
08:35 < petertodd> (did that get cut off?)
08:35 < adam3us> petertodd: after turn it int
08:35 < petertodd> turn it into a radix tree, and at the base of the tree either have NULL or a "never been published" txout, or H(txin) if the transaction output has been spent.
08:35  * petertodd googles irssi split messages
08:37 < sipa> petertodd: http://scripts.irssi.org/scripts/splitlong.pl
08:37 < petertodd> sipa: what's the magic thing to actually load that?
08:37 < sipa> put it in ~/.irssi/scripts/autorun :)
08:38 < sipa> or use /scriptload <filename>
08:38 < sipa> /script load, sorry
08:38 < petertodd> ha, cool, thanks
08:39 < adam3us> petertodd: catching up "valid if sufficient number of valid inputs" but i think the miners dont care whats in the block i think you have to go back to genesis
08:39 < adam3us> petertodd: not that thats a problem
08:39 < petertodd> anyway, so mining is now a matter of making new versions of that radix tree, and mining fraud is confirming a transaction output as spent when no valid scriptSig existed
08:40 < petertodd> you still need blocks, but blocks are just proof that you manipulated the radix tree in the right way, and how much of that tree you choose to store is up to you.
08:40 < adam3us> petertodd: wel there are two possible lvels of validation i think you are still valdiating sigs at mining level, with committed tx i didnt even do that
08:41 < adam3us> petertodd: so maybe you are heading back towards increasing validation again in a diff design towards an alternate spv model with this input/output trie
08:42 < petertodd> Right, see, if miners didn't validate sigs, this system would work only slightly differently: the bottom of the radix tree would be a list of data items. Generally the data items would represent spends of the transaction that could be validated, but they wouldn't have too.
08:42 < petertodd> Again, the fact that there can only be one data item stored in the chain per txout is an optimization.
08:42 < adam3us> petertodd: yes
08:44 < petertodd> So now ask, as a Bitcoin 2.0 user, how do I know a transaction was valid? Well, this is where it gets a bit ugly: for every input required by that transaction output, you need to prove to yourself that the part of the radix tree that committed to the fact that your txout was unspent, has always been unspent.
08:44 < adam3us> petertodd: problem encountered at detail level when trying to do this with committed tx is that you ave to be able to prove to your recipient that a forged spend is bogus and you cant do that with hashes (not easily ... i didnt see a way) so i had to use a MAC so you can prve ok if you see the mac & sym encrypt so you can give the recipient hte enc key and they can see it matches the mac but decrypts to junk
08:45 < petertodd> IE, by doing that, you've proven that miners have been honest, with respect to that particular transaction output.
08:47 < petertodd> Ah, ok, so this is an interesting point: lets suppose a miner changes the state of the TXO set they commit to from, say, unspent to spent, but you've never actually spent the transaction? What then?
08:48 < petertodd> This is really ugly, because you can't prove a negative: the bottom of the tree is a hash, and you can't show that the has is invalid!
08:48 < adam3us> petertodd: yes that sounds probably analogous - what i found was i need to be able to demonstrate to my recipient that the spend is fake
08:49 < petertodd> All you can do is show that every block ever mined *didn't* have a transaction in it spending that txout.
08:49 < adam3us> petertodd: precisely
08:49 < petertodd> Which gets to the other issue: this radix tree shouldn't be all TXO's ever, it should only be the TXO's in some time period! Now you *can* show this, by providing proof on a block-by-block basis.
08:49 < adam3us> petertodd: i had to possible solutions: requre that it be signed, and you reveal your pub key ontly the recipient nd hten they can see this is garbage
08:50 < petertodd> um, retype that?
08:51 < adam3us> petertodd: so eg what goes i the tree is ecdsa r, s value rather than hashouput, so no-one has a clue what it means (except tweaked in some way so they cant compute Q from r,s via ecdsa recovery)
08:52 < petertodd> So maybe to keep this proof small, what we want is to "merge" old history: first commit to the transactions that were in the past block, then all in the past two blocks, then four blocks and so on. The proof is now "I prove a valid spend didn't exist in the past 1 block, or the two blocks, prior, or the 4 blocks prior to that etc."
08:52 < petertodd> You can prove fraud, simply by showing that a spend did exist at layer 2^n, and layer 2^n+1 didn't include it.
08:53 < petertodd> adam3us: hmm... I'll have to read up on that again... I'm not familiar enough with the details.
08:55 < adam3us> petertodd: basically (i forgot also details) but you want to ensure that you can prove forgeries are garbage via encryption, or signature so that while someone can forge "spends" you can prove they are garbage, using the advantage that ou have the signature private key of the undisclosed public key hashed in the address
08:55 < petertodd> Basically what this 2^n scheme is doing is making miners make commitments to what txouts were spent over increasingly larger fractions of the blockchain. The *point* of it, is to be able to recover from the case where an invalid tree is committed, and no-one catches it: you give the person you're sending the coins to the proof of miner incompetence, and they take that into account. (or conversely, a miner distributes that along with their block)
08:55 < adam3us> petertodd: so then its not proving no spends, its proving no spends or all spends are forgeries
08:55 < petertodd> Ah I see.
08:56 < adam3us> petertodd: not in a clever way... you just give the recipient a key to decrypt all of the forgeries and then test them as if they were dsa sigs.. if they are not the recipient throws them away
08:56 < petertodd> yeah
08:58 < adam3us> petertodd: so it circles back to your comment that suppressing doublespens being stored is just a storage optimization; if you give the miner some way to verify the sig, he can throw them away himself
08:58 < petertodd> adam3us: Yes... and no. Someone's gotta have this !@#$ data at some level.
09:00 < petertodd> As clever as all of the above is, without the data it's just commitments. Even worse, without the data you can't change what is being committed too.
09:00 < adam3us> petertodd: the objective with committed tx is to keep the miner in the absolute dark so he knows nothing, as that robs him of policy based decision making and so the amount, sender, and recipient are all hiden
09:01 < petertodd> Yeah, see here, the miner doesn't need to know anything about what coins the transaction spent, just that some scriptSig satisfied some scriptPubKey
09:01 < adam3us> petertodd: maybe there would be a way to have additional non-identifying info with the previous tx out, which can allow the miner to discard forgeries without having him be able to censor transactions
09:01 < petertodd> OK, so, remember what I said about transactions being two merkle trees?
09:02 < adam3us> petertodd: well a problem can be he scriptPubkey i recognizable to the previous spender in the chain, and who could collude with the miner to block the tx
09:02 < petertodd> See, if you have a txout in this scheme, there's no way to know what the rest of the transaction was, even though the txout irrovocably commits to it.
09:03 < adam3us> petertodd: thogh maybe committed tx itself has problems with that scenario .. its not censor resistant just leaves decisoins up to consenting users
09:03 < adam3us> petertodd: yes
09:03 < petertodd> You can also construct your transaction tree to commit to a nonce in the middle, and then reveal the nonce to others to prove to them the txout is actually linked to the txins, rather than just some data you bizzarely want to publish.
09:04 < petertodd> So yeah, I think this scheme does have the unlinkability that you want.
09:05 < adam3us> petertodd: well i think there is a dependency on the hash of public key being deterministic (precluding nonce) and meaning the previous spender if upset can try to get your onwards tx blocked
09:06 < petertodd> ?
09:06 < adam3us> petertodd: if the public key hash is allowed to have a random element (nonce) you cant prove to other people this key is not spent
09:06 < petertodd> So, a transaction output contains the following: (scriptPubKey, merkle-root), that's it
09:07 < adam3us> petertodd: actually H(scriptpubkey)
09:07 < petertodd> right, that's possible, but not required
09:07 < petertodd> remember that the txout id, is H(scriptPubKey, merkle-root)
09:07 < adam3us> petertodd: yeah depends if you're aimng for committed tx uncensorability or not
09:08 < adam3us> petertodd: yes but it is unprovable if that is spent or not in committed form i think
09:08 < petertodd> Ah, ok, so, lets ask what is being committed?
09:09 < adam3us> petertodd: what i had to do is commit the tx and commit the pub key as well
09:09 < petertodd> So here you're not committing to transations, your committing to things that spend transactions.
09:09 < petertodd> *that spend transaction outputs
09:09 < adam3us> petertodd: and the doublspend protection came from checking no one made a sig or spend with  key tht hashes to that pub key commit
09:10 < adam3us> petertodd: yes well both as a pair: a pair of commitments
09:10 < petertodd> Right, this is kinda like that.
09:10 < petertodd> So, going back to that radix tree, the default state is that a valid scriptSig has never been presented for H(txout) right?
09:11 < adam3us> petertodd: yes so without giving the miner more info or visibiity, i think you have to use h(scriptpub) as a second commit, and therefore the person who gave you that input if upset can try to get your onwards spend blocked
09:11 < petertodd> Well, when you show that scriptSig, what you also commit too is the rest of the transaction, but you only need to commit to H(tx) of course.
09:11 < adam3us> petertodd: right
09:12 < petertodd> So basically, in Bitcoin a block commits to a list of transactions. Here we commit to a list of spends of transaction outputs, and the transations themselves are committed to by the spends!
09:12 < adam3us> petertodd: something like that
09:12 < adam3us> petertodd: so how much does it help, what new unentangled things have we been able to optimize by this
09:13 < petertodd> This also means you don't give someone money by committing a transaction to the blockchain, rather, you give someone money by committing to one or more spends of a previous transaction, and then giving them that transaction!
09:14 < petertodd> Ok, so, the big deal re: unentanglement: because mining isn't about validating whole transactions, just individual spends of transaction outputs, to mine some part of that txout space you don't need any adjacent data at all.
09:15 < petertodd> This is a huge win, because that lets mine only a small part of that txout space, and you only need the bandwidth associated with that small part.
09:15 < petertodd> So, basically you need to keep up to date with that part, keep your part of the big radix tree up to date, but no more than that.
09:17 < petertodd> For users, when they receive funds, they are getting proof that some amount of hashing power was mining various parts of the blockchain history and that hashing power all considered there to have never been a conflicting spend.
09:17 < adam3us> petertodd: that sounds a pretty big potential win; i wonder if that fragments hashcash security though?
09:17 < petertodd> They can prove it to themselves by getting a complete copy of that small part of blockchain data.
09:17 < adam3us> petertodd: or i suppose full nodes hash as you said everything else from the last merkle roots they saw also
09:18 < petertodd> I don't think so: the security is about resistance to changing history, what the history itself actually is is ireelevant, because you're supposed to validate that yourself.
09:19 < adam3us> petertodd: one other unstated in the above list of what is bitcoin mining doing: its making a very compact proof of work: one valid one per 10mins (after orphan pruning) anything more distributed will tend to create multiple small proofs to store, not that they are very big .. a proof is probably < 64-bits
09:20 < petertodd> Right, I haven't talked yet about what exactly is going on re: the PoW.
09:20 < adam3us> petertodd: yes but bitcoin single chain model presents a one-true-history path for validatin that rejects orphans
09:20 < petertodd> So does this model, it's just that the history doesn't need to be "true" :P
09:21 < adam3us> petertodd: i think you could have a thicket where each proof of work hashes as inputs all non-conflicting proof tops
09:21 < adam3us> petertodd: i figured out i think that should actually work in the past, but i was thinking meh thats goig to be less space efficient; but maybe actually its not so bad
09:22 < adam3us> petertodd: its a fun fact yes; we dont care what history is, just that it doesnt change
09:22 < petertodd> Pragmatically speaking, so what does a wallet look like then? Well, I think wallet software should be programmed to keep up with enough of the blockchain data to prove, block by block, that your txout hasn't been spent. (particularly fraudulantly spent)
09:22 < petertodd> thicket?
09:23 < petertodd> Hidden problem: what's the incentive exactly to broadcast this data? In Bitcoin, it's because if you don't broadcast, people won't build upon your block. Here you have to figure out something similar.
09:24 < adam3us> petertodd: without the one-true-pow chain (orphans are killed) there becomes a bunch of valid non-conflicting small pows growing up in parallel, each should hash as inputs all non-conflicting tops it saw)
09:24 < petertodd> non-conflicting top? what do you mean by tops? (and for that matter, conflicting)
09:24 < adam3us> petertodd: yes my thicket idea got some hairy incentive scheme, so that was another meh part to.... change bitcoin it becomes worse because tis entangled, and also quite optimal
09:25 < adam3us> petertodd: say for simplicity you want to maintain two chains rather than one going upwards, each time you add to it, you include both chains as an input
09:25 < petertodd> yeah, see, re: incentives, one part to fix this could be to require mining to have the consent of some fraction - proof-of-stake style - of your neighbors in the UTXO space.
09:26 < petertodd> Ah right.
09:27 < adam3us> petertodd: it was another meh moment: bitcoin is entangled and highly optimized - i thought i could make it work, but it was more complicated (incentive rules) and bigger (more blocks) more redundant (repeated data in blocks) and so forth
09:27 < adam3us> petertodd: i mean it did seem to work, but it was worse on 2 or 3 fronts
09:28 < adam3us> petertodd: "pos consent of utxo neighbours" yes maybe
09:30 < adam3us> petertodd: i wonder if not caring about history means miner validation (vs pool validation) doesnt even matter; just mine some random crap blind, it'll define history
09:48 < petertodd> net died
09:48 < petertodd> ok, so, the only way I can find that gets around this issue is to entangle mining and keeping history
09:49 < petertodd> for instance, imagine a system where to get 1/256th of the reward, you had to prove, by mining, that you had 1/256th of the blockchain data
09:50 < petertodd> each enough to do: just require your valid PoW's to have randomly chosen fragments of the blockchain data.
09:51 < petertodd> it's a bit ugly, but it will work
10:24 < amiller> petertodd, adam3us, i'm trying to figure out a way to embed the constitutional rules more strongly
10:24 < amiller> to make it so that any deviation from the rules ruins all the signature security, for example
10:24 < amiller> like any blockchain that contains an invalid commitment also has a trapdoor that lets you make a valid-looking commitment for any signature
10:24 < amiller> something like this would give teeth to the thing everyone says bitcoin currently has, that "21 million limited inflation is guaranteed by a math algorithm cryptography!" which isn't even true, it's only guaranteed by the relative difficulty of getting everyone to change their minds at once
10:26 < petertodd> amiller: I don't think you'll manage to do that with crypto, but as a definition thing you easily can
10:26 < amiller> instead, if you built in something like this feature i'm describing, any attempt to tweak the rules to let in an extra million, even "only just this once",  would require porting over everyone's signatures to some new thing all at once
10:27 < amiller> easily?
10:28 < petertodd> amiller: yeah, just make it possible to steal block rewards given proof of fraud
10:28 < amiller> i'm more optimistic the other way around... if i have a good definition, i can find someone who can do the relevant crypto, or i can wait 5 years and pinocchio or tinyram will be fast enough
10:28 < amiller> to steal anyone's block rewards?
10:28 < amiller> i don't think that solves it
10:28 < amiller> because it's still a simple "tweak" to the rules to make one particular fraud not count
10:29 < amiller> i'm not talking about someone sneaking in a deviant block undetected
10:29 < amiller> i'm talking about publicly getting everyone to agree to tweak a rule and then just accepting it
10:29 < petertodd> ah, hmm... sounds like magic :)
10:30 < petertodd> anyway, if everyone agrees, they can just as easily agree to change the rules to turn your system off
10:31 < amiller> right but then it's all or nothing
10:31 < amiller> this is meant to prevent tiny rule changes
10:31 < amiller> that otherwise preserve the system in tact
10:31 < petertodd> they had to agree to change validation...
10:31 < amiller> which makes it more plausible that you could convince everyone to agree to go along with it
10:31 < amiller> which means the system could plausible evolve over time
10:31 < amiller> if you actually wanted to bake in certain rules permanently then you could use this technique
10:33 < petertodd> well, anyway, if you figure out how to I'll be impressed all the same
10:33 < amiller> i think the trick is to relate signatures to block validation
10:34 < amiller> the signature scheme would have to be able to use knowledge of a violated rule as an alternate way of being accepted
10:35 < amiller> this means if a miner can include a block that violates a rule, he can also sign anyone's signatures
10:35 < amiller> the point is you could still just switch to another blockchain, but you would have to leave everyone's keypairs behind
10:36 < amiller> another way of putting it is that when you generate a spending keypair, you'd be making that keypair affixed to particular set of constitutional rules
11:00 < gmaxwell> petertodd: http://www.reddit.com/r/Bitcoin/comments/1pjiv4/coinswap_a_transaction_protocol_to_trade_coins/
11:00 < petertodd> nice
11:00 < petertodd> although, I suspect the headline won't be understood as to me teleporting value...
11:08 < gmaxwell> Well, I added: http://www.reddit.com/r/Bitcoin/comments/1pjiv4/coinswap_a_transaction_protocol_to_trade_coins/cd2xqif
11:09 < petertodd> that looks better
12:30 < adam3us> amiller: so for example say by modifying the constitution you are allowed to add a factor of our chosing to the coin public keysand hence to know the discrete log and spend them
12:31 < amiller> i think - something like that
12:31 < adam3us> amiller: or alternatively people seem really scared of even soft forks ;P, so maybe its not essential in pracitce, but its an interesting question
12:32 < amiller> it's easier for me to think of this in terms of generic zero knowledge and circuits
12:33 < amiller> a public key is like the SNARK for a circuit that is valid if *either* the signature for the transaction is correct *or* you have evidence that the previous block hash contains an invalid rule
12:33 < adam3us> amiller: so what i mean is if the factor you add during your mining in constitutionally valid ways (no variation) are definitoinally things you cant know the discrete log of (as they are hash outputs eg)
12:33 < adam3us> amiller: gotcha actually thats sort of generic ZKP or model
12:34 < adam3us> amiller: and yet by varying u get more freedom in the factor so could chose it maliciously
12:35 < adam3us> amiller: thats not actually the same of course, what you are saying via ZKP or is that not only could you be malicious if inclined, but you definitinally create teh risk by introducing an OR zkp
12:36 < amiller> yes
12:36 < amiller> it's tricky though because
12:37 < adam3us> amiller: i could ctually see that working no?
12:37 < amiller> transactions ordinarily just refer to the transaction graph, separately from blocks
12:37 < adam3us> amiller: yes there is a block / tx mismatch, that is quite inconvenient
12:37 < amiller> so i don't see immediately how to rule out that you could still just change the protocol and keep using the same public keys
12:38 < amiller> this doesn't have the desired effect if you could just interpret the existing signing keys with a different validation circuit
12:38 < amiller> the approach should be to somehow make the signing keys totally useless except in the context of valid blocks
12:38 < adam3us> amiller: right; seems like that might need something more sophisticated concept
12:39 < adam3us> amiller: like all sigs are based on SCIP/SNARK but bound to the constitution hash so that if its varied the proofs no longer are valid
12:39 < amiller> i still think this is definable just using zero knowledge and arranging things carefully
12:39 < amiller> yeah exactly
12:39 < amiller> it would turn "small one-time-only tweaks/exceptions" into suddenly *everyone's* problem that has any coins
12:41 < adam3us> amiller: yes the use-case is clear; prevents special pleadings by governments as now - bending constitutional rules due to political expediency ina  time of financial difficulty
12:41 < amiller> right
12:41 < adam3us> amiller: if the cost is everyones money goes up in smoke, thats clearly worse; financial armageddon
12:42 < amiller> as it concerns bitcoin, i believe that currently people *overestimate* the relatively ease of convincing everyone to go along with an incrementally rule-bending change that doesn't really affect them and might as well go with the flow
12:42 < amiller> at the same time, even a tool like this isn't a perfect solution to everything
12:42 < amiller> the ability to change rules through consensus is actually a pretty positive thing so far
12:43 < adam3us> amiller: i was just talking with petertodd about even well meaning short-termism creating problems through lack of focus on the big picture (upthread)
12:43 < amiller> i can imagine having some rules baked in this way and other rules able to change like currently through hardfork
12:43 < amiller> it seems like it would be clearly a useful tool to add but it's not obvious how best to apply it
12:44 < adam3us> amiller: yes; probably the main risk is bitcoin has a quite entangled hard to modify design, and code bug could screw core value up; would be useful if there was a way to finalize core value protection and do other higher level features separately without risking it
12:45 < adam3us> amiller: 21mil coin cap & mining production rate function are good candidates
12:46 < amiller> yeah, 21mil coin cap definitely the most fun one to aim at with this
13:00 < adam3us> amiller: so what if u made each ecdsa sig instead zkp of knowledge of DL of Q (bound to H(tx) aka ECDSA(tx) OR NOT (reward ==25 || epoch==2 & reward==12.t ...)
13:01 < adam3us> amiller: if you make a soft fork on reward, suddenly everyone will be able to spend anything
13:02 < adam3us> amiller: thats even a compact proof using representation problem (extended schnorr)
13:02 < adam3us> amiller: brands stuff can prove ==, NOT (aka !=) and OR is generic
13:04 < adam3us> amiller: could be more simply referring to currentReward()
13:50 < gmaxwell> Man, dealing with users is hard: http://0bin.net/paste/e6R8Cv8TJEdr-Fq0#c36UxiHSURdA06LPQPNiCvyiOIQ++XGScvPoTvJ/lEg=
14:47 < K1773R> gmaxwell: those ppl deserve loosing their coins S:
14:47 < gmaxwell> K1773R: we need those people happily using bitcoin to make it have a functioning economy. :)
14:48 < K1773R> gmaxwell: unfortunately yea
14:49 < amiller> adam3us, so actually.... the trick must be to allow the miner to hide the tranasction signature
14:50 < amiller> if the user submits an actual signature, then the miner can construct a ZKP that hides either (the attached signature is valid OR the prev block hash is bad)
14:50 < amiller> uh hm that still has that problem that you could give a different ZK proof for the same signature :/
14:51 < amiller> this isn't a clean change but you could require that all transactions are interactive and the tx itself requires a signature of the most recent block
15:02 < amiller> this would sort of be a general approach to having a non-reusable signature scheme
15:02 < amiller> normally signatures can be taken out of context
15:03 < amiller> i could be participating in a game where i use my gpg key to sign chess moves
15:03 < amiller> but someone else could pick some new protocol that also uses my signatures and maybe they conflict in some way
15:24 < MC1984> oh this is real.....
15:35 < sipa> is this the real life?
15:40 < gmaxwell> Or is this fantasy?
15:40 < gmaxwell>            ^just
16:35 < gmaxwell> joining #eligius right now may be good for popcorn.  The operator of betcoin.tm waynetbarclay is mad about eligius blocking his (SD style) 'dice' transactions and appears to be making veiled threats of DDOS attacks.
16:39 < warren> pastebin log?
17:43 < sipa> maaku: the name compactisgnature actually comes from the fact that not using DER is more compact
17:43 < maaku> ah
17:44 < sipa> adding the recovery bit was later i think
18:24 < gmaxwell> petertodd: Luke-Jr apparently wasn't aware that the DBG transaction wasn't getting mined.
18:25  * Luke-Jr figured petertodd figured out a way around it :p
--- Log closed Thu Oct 31 00:00:27 2013