--- Log opened Thu Jan 16 00:00:49 2014
00:14 < amiller> gmaxwell, i'm finally starting to realize you're right about snarks
00:14 < amiller> that so far they all require an obnoxious trusted setup
00:18 < maaku> amiller: but it's okay if you trust yourself, right?
00:18 < amiller> no not really
00:18 < gmaxwell> amiller: ones that don't are certantly possible (PCP theorem + fiat shamir shows its possible) though they would not be as compact as the GGPR ones, which are just ludicrously compact.
00:19 < amiller> if i wanted to show someone that the bitcoin community has already been pointing this out, would you recommend a forum post of yours?
00:19 < gmaxwell> maaku: if you don't care about public verifyability then you can use a like an interactive protocol. I'm pretty sure that GGPR is still ZK if the CRS was malicious generated.
00:20 < amiller> i've sort of not noticed it despite mouthing off about how cool my nonoutsourceable puzzle is based on snark
00:20 < amiller> it's more immediately relevant to zerocoin though
00:20 < amiller> i mean, they're aware of it too
00:20 < maaku> gmaxwell, I mean hypothetically if the scriptPubKey were the hash of the SNARK verifying key, and the scriptSig were the verifying key and proof (p2sh replacement)
00:21 < gmaxwell> amiller: http://www.reddit.com/r/ZeroCoin/comments/1uy35p/matthew_green_to_speak_about_new_zerocoin_version/ceo17ut
00:21 < amiller> maaku, creating a SNARK verify key requires someone to have some secrets they are trusted to delete
00:21 < gmaxwell> amiller: A GGPR-12 SNARK.
00:21 < maaku> amiller: yes, see ^^
00:21 < amiller> yes i just got back from that and chatted with him and his student about this
00:21 < maaku> amiller: if that snark is created by you and only used by you, why is it a problem if you have the trapdoor?
00:21 < gmaxwell> amiller: Eli supposidly is also working on a Linear PCP based on some fiat-shamir transform of a locally testable code, but none of the recent papers are about this.
00:22 < amiller> maaku, if that's the case sure, that's just a much different use case than what i have in mind (or what zerocoin/cash has in mind)
00:22 < gmaxwell> maaku: for _some_ applications it might not matter, for some it would.
00:23 < gmaxwell> maaku: "You can spend these coins if you solve my puzzle" "psyche... I just spent them out from under you even though the code said I couldn't because I can create false proofs for this verification key."
00:24 < gmaxwell> amiller: the upside is removing the CRS the downsides are that the proofs are much larger (tens of kilobytes) and the zero-knoweldge is no longer perfect.
00:25 < amiller> i see.
00:26 < gmaxwell> amiller: well I'm glad your koolaid tap on the CRS stuff ran out. I dunno why everyone thinks its so acceptable.. it is in some cases, not others.
00:26 < gmaxwell> What they're talking about doing in zerocash I think its completely unacceptable.
00:26 < gmaxwell> then again, for that application 20kbyte signatures is probably also unacceptable.
00:27 < amiller> how far do you think they can smear around the anytrust kind of setup
00:27 < gmaxwell> (and for that matter, q-power knoweldge of exponent, bilinear pairing stuff is by itself probably unacceptable)
00:27 < amiller> that was a question someone asked, matt green answered affirmatively, i didn't seek any details
00:28 < gmaxwell> What was?
00:28 < amiller> whether you could distribute the setup among N parties
00:28 < gmaxwell> yea, I think thats half BS
00:28 < amiller> where any of the N parties has to delete their data
00:28 < amiller> okay
00:29 < gmaxwell> I don't know of any systems for _active_ secure MPC that don't themselves require a zk-snark, certantly none that are implemented.
00:29 < gmaxwell> (you can take any semi-honest-secure MPC scheme and make it active secure if you make all the players do their work under ZK-proof that they're obeying with the protocol)
00:29 < maaku> gmaxwell: i see
00:30 < gmaxwell> It's possible in theory at least. But what does N need to be? and where is even a beginning of an implementation?  even with just three parties it would be the largest MPC task ever attempted.
00:30 < amiller> yeah everything attempted in practice so far has been semi honest
00:30 < amiller> afaik
00:31 < gmaxwell> Yes, as far as I can tell.  And I think we have a chicken and egg problem here. We have almost pratically efficient snarks actually implemented but in the CRS model.
00:31 < gmaxwell> You could, in theory, make the CRS with MPC.  .. but active secure MPC that looks remotely pratical is a passive MPC + SNARKS.
00:32 < gmaxwell> and the CRS computation isn't horrible but there is a lot of it ... for zerocoin they're talking about 1.6GByte prover keys (which actually sounded small to me).
00:33 < gmaxwell> So somehow you've got N party active secure MPC and you're going to compute 1.6 gbytes of CRS in it?
00:33 < gmaxwell> And realistically I think N can't just be 3.  Start talking about 30 and thats more interesting.
00:33 < amiller> yeah. i came to that conclusion pretty quickly too
00:34 < amiller> sell tickets to the big setup phase MPC as your fundraiser gimmick!
00:35 < gmaxwell> I mean there are neat things you can do... one of the mpc nodes should be in a faraday cage in a bunker filled with C4. And you should exploide it when the computation is finished.  People would pay to see that. :P
00:36 < amiller> david blaine could do one too
00:36 < gmaxwell> the undetectable compromise part is part of what makes this so bad for ZC where it wouldn't be an issue elsewhere.
00:37 < gmaxwell> lots of room for fud.
00:37 < gmaxwell> "NSA supercomputer cracked the crypto to recover the key whole cloth, and now the US government can print unlimited coins! Prove me wrong!"
00:38 < gmaxwell> at least if it were detectable you could freeze new spends and deploy another ZK proof system (perhaps a less efficient one)
00:39 < amiller> i learned about a formalism called "covert security" that's weaker but promises detection like that...
00:39 < amiller> but i couldn't find any trace of someone actually getting any cheaper construction that way
00:40 < gmaxwell> well the GGPR12 stuff is super brittle to knowing the CRS. Its easier to compute a fake proof than validate a proof if you know the CRS.
00:41 < gmaxwell> and I think the way the perfect zero knoweldge is achieved it must be that way.
00:42 < gmaxwell> (because you can basically show that for any set of passing input group elements some CRS exists thats makes those element a valid proof, regardless of the statement being true or not)
00:44 < gmaxwell> In any case, Iddo has given me the impression that I'm not the only person who's seen the limitations of the CRS model.
00:46 < amiller> i've seen some modifications to CRSs to make them more useful and composable but not that get rid of the trusted/private state somehow
00:47 < amiller> i don't have any idea what comes next
00:52 < gmaxwell> amiller: why not post to the http://www.scipr-lab.org/ mailing list and whine about the CRS trust assumptions and ask what they're going to do about them? :P
00:52 < gmaxwell> As I said, I /think/ they're also working on a backend without one.  But I don't know anything about it as it's not mentioned in their papers on their tinyram work.
03:01 < nsh> gmaxwell, if it helps, didactically, you can compare the security of the CRS model to the security of DUAL_EC_DRBG....
03:06 < gmaxwell> Hm!
03:06 < gmaxwell> point.
06:17 < adam3us> gmaxwell: so while i agree that H(nonce)[rand(32)] ^ prefix is an interesting incremental improvement of raw prefix, with an example 8-bit prefix, and [] being byte index, ^=xor, it still publicly allows elimination.  ie with probability (255/256)^32=88% it eliminates you as a payee of any given reusable payment.
06:17 < adam3us> gmaxwell: (posted this and related on bitcoin-dev)
07:56 < jtimon> somebody claimed here (I don't know if it was you maaku), that some people were suspicious about scrypt being GPU mined from the beginning
07:57 < jtimon> does anybody have any reference to that?
08:04 < jtimon> hmm, is this it? https://bitcointalk.org/index.php?topic=63365.0
08:04 < jtimon> I'm considering mentioning rumors about it and putting a link on an article about p2p currencies I'm finishing
08:07 < jtimon> I don't know...wasn't coinhunter a scammer?
08:07 < jtimon> "Artforz publicly admitted to creating a GPU miner for litecoin numerous times" any link to this?
08:08 < jtimon> I'll keep searching, just browsing out loud in case anybody can give me some clues or a better link
09:17 < Emcy> hmm apparently GCHQ couldnt crack truecrypt with the password "$ur4ht4ub4h8"
09:17 < Emcy> they had to sling the guy in jail and sweat it out of him
09:18 < Emcy> isnt that a weak password? Is that a bit surprising.
09:18 < adam3us> jtimon: ha thats pretty interesting  the guys claim seems quite plausible.  casts coblee / artforz in a bad light if so.  i was before now supposing the failure of scrypt params chosen to be yet another alt param fail on their part.  but maybe it was a "fail" ie not real! they designed it that way and exploited it to the max until someone else figured it out
09:18 < adam3us> Emcy: yeah i saw that.. my thoughts also, we have nothign to worry about :) combined might of GCHQ cant crack that short/low entropy password.. chortle.
09:19 < adam3us> Emcy: what we dont know however is the program used.  maybe it has some memory hard stretching or something preventing fpgas or whatever gchq has
09:19 < Emcy> and yet a skilled cracker with a good custom dictionary and a handful of radeons might
09:20 < adam3us> Emcy: if it was unstretched, for sure; lot of former gpu miners coul crack that with their own cards!
09:21 < Emcy> ok i assume it was truecrypt
09:22 < Emcy> http://www.bbc.co.uk/news/uk-25745989 look hes got a beard so hes probably up to no good!
09:22 < adam3us> jtimon: analogously i was similarly suspicious of dan larimer with his momentum hash and protoshares.  that no GPU status fell pretty fast though he fought the claim all the way down
09:23 < Emcy> adam3us isnt it fairly common knowledge that someone was mining LTC rather faster than should have been possible early on
09:23 < tacotime_> I recall artforz had mentioned he implemented it on GPU And it was slower
09:24 < tacotime_> The algo itself is slower on GPU if you don't use the TMTO trick (only store every other value in the memory pad and look up the others on the fly)
09:25 < tacotime_> There's a little bit of reason to believe that solar designer and artforz may have been the same person, but I won't eloborate
09:25 < adam3us> Emcy:  I dont know wasnt paying attention at the time. tacotime_: the thread jtimon posted above says their programmer spent 4hrs and made something 150x faster than artforz claimed best.
09:26 < tacotime_> You honestly trust something coinhunter said?
09:26 < tacotime_> The guy who has stolen hundreds (probably thousands) of BTC from the community over the past 2 years? ;)
09:26 < adam3us> tacotime_: solar designer is pretty crypto sharp, he posts on cpunks/crypto lists a lot and seems to have clues.  seems to me if that is artforz alter ego he'd have the sharps to do a little TMTO
09:27 < adam3us> tacotime_: yeah i heard of solid coin by infamy/reputation only wasnt paying attention back then.  he's that guy?
09:27 < tacotime_> yeah
09:27 < tacotime_> RealSolid/CoinHunter, same person
09:28 < tacotime_> http://www.openwall.com/lists/crypt-dev/2013/03/21/1
09:28 < adam3us> tacotime_: apparently his antics were so stupid/evil/greedy as to remain the subject of lore 3 years later :)  thats how i heard about solid coin at all
09:28 < tacotime_> I'm not sure where mtrlt was updated to the desynchro/TMTO trick though
09:29 < tacotime_> Or if pooler had first picked it up when optimizing his LTC miner
09:30 < adam3us> tacotime_: i think i saw solar designers TMTO experiments, he mustve cross posted to one of the crypto lists
09:30 < tacotime_> yeah
09:31 < tacotime_> mtrlt also ran off with a load if bitcoins after claiming he would implement primecoin miner on gpu
09:32 < adam3us> tacotime_: it was the same story again with larimer/protoshare/invictus momentum "cpu only" memory hard PoW, someone showed a few weeks into an impressively large VPS rented power driven difficulty ram that it was duh TMTOable and so worked just fine in GPU
09:32 < tacotime_> He did release some really broken source code, but then just fucked off
09:32 < tacotime_> If it's parallelizable, I find it difficult to believe that a GPU won't run faster even if you need memory
09:33 < tacotime_> GPU vRAM bandwidth is always going to be greater than the DDR3 bus on the main board
09:34 < adam3us> tacotime_: they tend to need unique memory per mining instance, so momentum aimed for 750MB but then someone TMTO'ed that with bloom filter in place of hash-table.  (unreliable but much smaller hash-table)
09:34 < tacotime_> So when I hear about "dagger" I don't pay much attention either... implement it on GPU and play with it for a couple weeks, otherwise don't say it's hard to run on any single piece of hardware
09:34 < tacotime_> mm
09:35 < adam3us> tacotime_: yes.  but GPU ram bus is wider.. like 256-bit, 384-bit etc vs CPU at 64-bit cache line.  so that erodes a bit of the throughput.  and the access is random and usually like 64-bit word size (or should be for this reaso)
09:36 < adam3us> tacotime_: 256-bit might be quite ideal for dagger :) its a merkle tree.
09:38 < adam3us> tacotime_: the only thing dagger is adding is to use coelho's use of fiat-shamir to make verification faster (and a few more links in the tree to make calculating all merkle steps slightly less skippable) its mostly a tweaked coelho merkle PoW.  i mentioned the coelho merkle pow to vitalik its where he got the idea from.
09:40 < killerstorm> hi. does anyone have an idea when OP_RETURN outputs will be usable on the mainnet?
09:41 < jtimon> adam3us, tacotime_ : that's the problem. The story seems plausible, but solidcoin is not a reputable source...
09:41 < jtimon> adam3us, tacotime_ : the fact that "you would be making mining bitcoin and selling them for ltc if you really want the ltc" (I read that somewhere)
09:42 < jtimon> adam3us, tacotime_ : seems to point out in that direction, if ltc mining was less competitive, it should have been more profitable
09:42 < jtimon> maybe it was just a botnet what caused that
09:44 < adam3us> killerstorm: i am guessing that is a color coin related question ;)
09:46 < killerstorm> adam3us: yep. it's possible to do coloring without it, using otherwise unused nSequence is appealing, but people freak out and ask about OP_RETURN
09:47 < killerstorm> also it looks like non-tech people think that use of OP_RETURN makes protocol better and more legitimate :-/
09:48 < jtimon> which reminds me...adam3us seems like enabling "joyscript" in all assets, but disabling the ops needed for quines/covenants on the hostcoin would be a good compromise
09:49 < jtimon> adam3us: you know I don't share yyour same fears, but we don't know of any use case that requires covenants in the hostcoin
09:49 < jtimon> killerstorm: yeah, some freicoiners thought it would allow people to use the chain for messaging, files...
09:51 < adam3us> killerstorm: here's some replayed history from a few days back
09:51 < adam3us> (06:42:24 AM) justanotheruser: "So, with some reluctance, I recently merged pull request #2738 : “Relay OP_RETURN data TxOut as standard transaction type.”" - gavin andresen
09:51 < adam3us> (06:42:36 AM) justanotheruser: So will it be standard in .9?
09:51 < adam3us> (06:42:52 AM) Luke-Jr: hopefully not
09:51 < adam3us> (06:43:04 AM) gmaxwell: 21:38 < gmaxwell> as of right now in git bitcoin allows data in OP_RETURN though given what people are saying I hope we back that out.
09:51 < adam3us> (09:46:35 PM) adam3us: gmaxwell: "as of right now in git bitcoin allows data in OP_RETURN though given what people are saying I hope we back that out." dont object to backing out (say NO to block-chain spam!), but what are they saying missing context?
09:51 < adam3us> (10:37:04 PM) gmaxwell: adam3us: there have been a number of articles about how bitcoin has been "upgraded" to enable "distributed storage" and such horrifying things like that.
09:51 < adam3us> (10:40:32 PM) adam3us: gmaxwell: ah yes.  its a scary situation indeed.  the flip side is there are then people who will stego encode then in multisigs if you dont, and create needless non-compactable TXOs and on.
09:52 < adam3us> (10:41:17 PM) gmaxwell: adam3us: thats why I didn't oppose it initially. Though the trade off of people thinking it is a good non-antisocial and supported application is concerning.
09:52 < adam3us> (10:41:39 PM) gmaxwell: Esp what happens if abusive use arises and it must be turned back, but there is also non-abusive use?
09:52 < adam3us> killerstorm: (end of few days old discussion paste)
09:54 < jtimon> I don't see it as such a bad thing, I think timestamping is a legitimate use of the chain, but it's sad how people understand it
09:55 < jtimon> about using the nsequence fields...I don't know, some people want to use it for microtransactions channels
09:55 < jtimon> I think the probable solution is for microtransactions to be directly off-chain, but I don't know...
09:55 < adam3us> jtimon, killerstorm: coloring is lower bandwidth than mastercoin (which sends even bid and meta-messages over the blockchain) but its still in theory non-btc tx bandwidth use.
09:56 < adam3us> jtimon: time-stamping at least typically is putting a single hash which is the merkle root of many documents
09:57 < jtimon> adam3us: yeah, I don't think you need to allow more than a single hash after return
09:57 < killerstorm> adam3us: by the way, gmaxwell mentioned that P2SH^2 would make storing data in blockchain impossible, but this is not true, it just makes it more expensive: people can simply 'mine' hashes which have prefixes they need and share data through those prefixes.
09:57 < jtimon> being not in-chain validated, it can be transffered off-chain as well
09:58 < jtimon> p2sh^2 ??
09:58 < killerstorm> jtimon: as far as I know, nSequence is basically dead, it was a bad idea in the first place. It is possible to do same thing (but better!) using multi-signature scripts.
09:58 < adam3us> killerstorm: yes this was mentioned somewhere.  he viewed it as closer.  also there are multiple stego encoding opportunities, eg unused not obviously invalid 1 of 2 multisig addresses etc.  but just because you could stego encode with increasingly lower bit rates doesnt make it a good thing :)  was talking about this with petertodd in the mastercoin context.. for them they'd as well use a separate merge mined chain IMO
10:00 < jtimon> killerstorm oh, this doesn't use replacements https://bitcointalk.org/index.php?topic=244656.0
10:00 < jtimon> I guess nobody has a use for it then
10:03 < jtimon> adam3us do you know of any proposed use of replacements? https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains this needed it?
10:04 < jtimon> well, that can be replaced with coinswap, which doesn't need nseq iirc
10:08 < adam3us> jtimon: i dont know, others would know better
10:09 < adam3us> jtimon, killerstorm: i think killerstorm implemented atomic swap in is chromawallet (color coin wallet) if i recall the announce
10:10 < jtimon> adam3us but that is atomic swap between colors in the same chain
10:10 < jtimon> the link and coinswap is cross-chain
10:11 < killerstorm> transaction replacements are usable under condition that all miners are honest. this just doesn't make any sense.
10:11 < jtimon> well, coinswap can also be used in the same chain for mixing
10:11 < killerstorm> trading-across-chains doesn't need replacements
10:12 < jtimon> killerstorm: yes, you're completely right, miners should just get the transaction with higher fees when they receive double-spends
10:51 < jtimon> I guess we should just remove the seq field in freimarkets...
11:10 < adam3us> jtimon: the seq field was designed for revisable bids?
11:11 < TD> it is designed for mempool replacement
11:11 < TD> basically for high frequency trading between a set of parties (to use satoshis terminology)
11:14 < jtimon> adam3us, TD: yes, but as killerstorm says there's no reason for a miner to accept seq=5 over seq=3 if seq=3 has a hegher fee
11:16 < TD> of course there is
11:16 < TD> this kind of nonsense reasoning about game theory is so destructive
11:17 < TD> the reason is that if useful and compelling apps rely on that functionality, that increases demand for bitcoin and thus the value of their fees and inflationary rewards
11:17 < TD> miners are not thinking only 20 minutes into the future, you know
11:17 < TD> it's sort of like saying "bitcoin can't work because miners have incentive to merge together and then do 51% attacks to double spend"
11:18 < TD> what we actually see is the opposite, where pools throttle themselves if they get too big because to do otherwise would hurt the value of their money
11:18 < pigeons> the same pool that did double spend?
11:18 < pigeons> or facilitate it i mean
11:19 < TD> other pools have done the same thing in the past
11:19 < TD> deepbit, btc guild etc
11:19 < gmaxwell> deepbit was DDOSed off the network for a week solid when it reached 50% I don't believe it ever regulated itself.
11:21 < gmaxwell> I'd like it to be true, but the self regulation is not working well, it's not like 40% is at all okay. Ghash.io stole several hundred btc from betcoin dice when it had just 25% (possible due to betcoin accepting unconfirmed) and then continued to grow to >40% after that.
11:21 < gmaxwell> I dunno about the game theory stuff, I agree it's wankery. But at the same time the observed behaviors are not good either.
11:21 < TD> correctly configured incentives don't magically make better solutions appear though
11:22 < gmaxwell> We agree.
11:22 < gmaxwell> (well you and I at least on that. :) )
11:22 < TD> they exert pressure in the right direction, but someone still has to do all the work to create an actually better situation :)
11:23 < gmaxwell> the concern with things like the nseq in my mind isn't the incentives so much as the vulnerability of it— like betcoin taking unconfimred payments.
11:24 < TD> we lack tools, documentation and experience to help business do risk analysis. but over time i expect risk analysis to play a bigger and bigger role in bitcoin
11:24 < TD> like, where the block chain becomes a very strong signal that is nonetheless blended with others
11:24 < TD> betcoin took a bet and lost
11:25 < gmaxwell> sure, 99.99% of the time it'll be great. But in that remaining 0.01% ... watch out.  Attacks aren't random though, at least when non-trivial amountes are involved a probablistic approach doesn't always work well.
11:25 < jtimon> TD: "the value of their money" you assume miners are always at the same time btc speculators, they can just sell them
11:25 < TD> businesses all have to do crazy risk analyses today to accept existing forms of payments, it's not really an alien concept for them. so we'll see. next dice site will have to weigh up the prospect of being double spent, at least until/unless the mining situation improves
11:25 < TD> jtimon: for how much?
11:26 < TD> jtimon: all miners are speculators to some degree because they have amortised costs
11:26 < jtimon> like saying "bitcoin can't work because miners have incentive to merge together and then do 51% attacks to double spend" <--
11:26 < jtimon> no, it works because it's easier and more long term for them to just make money out of honest mining
11:26 < gmaxwell> of course if you're able to trust the payer... why even bother with fancy protocols. "Pay me what you owe eventually."
11:26 < TD> jtimon: in theory a miner who has paid off all his hardware and has no electricity/ongoing costs wouldn't care what the price is indeed. but i guess that won't be true for a long time
11:26 < TD> well that's what in practice we do already with unconfirmed transactions.
11:27 < TD> the block chain has a sweet spot where it's really useful and appropriate. other times it's not so helpful
11:29 < TD> though i'm kinda looking forward to the day that people are dropping nitrogen-cooled ASIC farms into the middle of the desert with a solar farm next door
11:30 < jtimon> well, don't want to take my description as assuptions, just wanted to pointed out that you're assuming to much about miners but...
11:30 < jtimon> when you compare capital, say a pub, a building and a mining rig
11:31 < TD> we don't know if i'm assuming too much or not because we never got a chance to try. the feature was disabled due to DoS/surface area risks a long time ago.
11:31 < TD> perhaps one day we'll get a chance. in the absence of a killer app for the feature though, it's a bit hard to justify right now
11:31 < jtimon> you compare them by capital yield, doesn't matter if you're doing it with your own money or with borrowed money
11:31 < jtimon> if it's your money you don't have more incentiveto accept low yields
11:32 < jtimon> you could lend/invest more profitably somewhere else
11:33 < jtimon> TD: I mean you're assuming too much about miners by assuming they keep the btc for more than 100 blocks
11:33 < TD> my assumption is really just that they care about the price
11:33 < TD> which is pretty basic, yes
11:35 < jtimon> my assumption (another simplification of reality) is that they care about yields and only indirectly about price, I don't know about their preffered unit of account, tend to asume is fiat
11:35 < jtimon> anyway, they won't destroy bitcoin by taking the higher fee when receiving double-spends
11:35 < jtimon> with or without seq
11:36 < jtimon> and if seq relies on that, well, then it is not very secure
11:36 < TD> of course they would
11:36 < TD> that would be the absolute worst thing miners could do
11:37 < TD> no unconfirmed transactions? watch the price collapse
11:37 < jtimon> why?
11:37 < TD> many miners would never make back their ASIC investments then
11:37 < jtimon> mhmm
11:38 < jtimon> what satoshi proposed for "unconfirmed transactions" were services that contracted with pools to connect directly with them I think
11:38 < jtimon> it's in the snack machine thread I think
11:39 < TD> no
11:39 < jtimon> killerstorm also says that the high "frequency tunel" use case doesn't need seq
11:39 < TD> in the snack machine thread he pointed out merely that the cost of double spending would be higher than the value of the snack
11:39 < TD> and that it could listen for double spends on the network anyway
11:40 < TD> it doesn't need tx replacement as long as the micropayment channel flows in one way direction
11:40 < TD> if you want more flexible arrangements it does.
11:40 < TD> fortunately for many interesting applications, one direction is enough
11:41 < jtimon> TD https://bitcointalk.org/index.php?topic=423.msg3867#msg3867
11:41 < jtimon> "No, the vending machine talks to a big service provider (aka payment processor) that provides this service to many merchants.  Think something like a credit card processor with a new job.  They would have many well connected network nodes."
11:41 < TD> any node can do that. pools didn't even exist back then
11:42 < TD> so he obviously wasn't talking about contracting with pools
11:42 < TD> :)
11:42 < jtimon> correct he didn't said pools, just well connected
11:42 < TD> once double spend relaying is done, you won't even need to be very well connected
11:42 < TD> so this is not really a big deal
11:42 < jtimon> maybehe was thinking about mining farms?
11:43 < jtimon> "double spend relaying" I'm not sure that's really secure
11:43 < TD> he said what he was thinking of - a service provider that performed the job of watching for double spends
11:43 < TD> why not?
11:43 < jtimon> if it was secure we wouldn't need PoW
11:43 < TD> i think you're confused
11:44 < TD> double spend alerts tell you that there has been a double spend. it does not tell you which spend will win.
11:44 < jtimon> oh, sorry
11:44 < jtimon> I thought it was some of those proposals to "prvent double spending"
11:45 < jtimon> I think there's even a paper about that
11:45 < TD> no, i said "double spend relaying"
11:45 < jtimon> sorry again
11:45 < TD> np
11:46 < adam3us> so about (2-way) pegged side-chains again.  the security insulation from not accepting more coins than moved, is good.  but i think to avoid eg fractional reserve building up in the side-chain, i think the SPV proof needs history back to the coin migration?
11:47 < jtimon> TD I still think future miners will just mine the highest fee transaction (even with double spend relay)
11:47 < TD> *shrug* and i think you're wrong. guess we're done :-)
11:48 < jtimon> adam3us: preventing fractional reserve? I must have missed something about the proposal...
11:48 < jtimon> TD hehe, yes, well we can detail how each other see the future
11:48 < adam3us> jtimon: well that is not part of the proposal, i'm thinking of the min requirements to prevent it happening.  the code in the side chain is subject to change
11:49 < jtimon> TD I think instant transactions won't be in-chain because in-chain transactions will be expensive
11:49 < jtimon> TD in-chain will be used for debt settlement mostly
11:49 < adam3us> jtimon: that assumes we cant make it scale quite a bit more.
11:49 < TD> these conversations are all years old
11:49 < TD> tbh i'm tired of them
11:49 < TD> back in 2010 it was interesting
11:50 < adam3us> petertodd: is the man to wind up for game-theory arguments.
11:51 < jtimon> adam3us I think we can make it scale it more, just not enough to process all the world's transactions
11:51 < jtimon> adam3us which I also predict will be many more in the future
11:51 < adam3us> jtimon: i am not sure. maybe pegged side chains offer another flexibility.
11:53 < jtimon> adam3us: still if each node processes the whole world transactions, there won't be many full nodes
11:53 < jtimon> or miners
11:53 < adam3us> jtimon: think multiple side-chains, maybe shard the transaction set
11:53 < petertodd> jtimon: the scalability future will be in blockchains that are sharded, and it's feasible to "process the worlds transactions" with such structures
11:54 < jtimon> we advocate for private chains, though the most promising scalability improvements can only come from more data being directly exchanged between parties without toughing the chain
11:55 < jtimon> petertood: yeah something like sharding could make me wrong, but I'm unconvinced that's feasible for now
11:55 < jtimon> not that I don't think about that myself
11:55 < petertodd> jtimon: I disagree there, off-chian is a nice safe way to get better scalability, but I think the best is to reduce the consensus "size" required
11:55 < TD> it's already done: alt coins
11:56 < petertodd> indeed it is, what's interesting is how to better integrate multiple chians into a cohesive whole
11:56 < jtimon> TD altcoins are very wasteful the way they are right now, they're just highly subsidized by seignoriage greed and stupidity
11:57 < TD> the p2p chain-trade thing would seem to be the best way. not that anyone is really exploring it properly
11:57 < TD> jtimon: so they take some of the stupid-load off the bitcoin chain. win :-)
11:57 < petertodd> jtimon: though also I see *no* reason to think you can get fast, let alone instant, consensus requried for retail payments
11:57 < jtimon> just adding more altcoins doesn't scale, not even with merged mining, miners still need to process everything
11:58 < TD> jtimon: what i was thinking is that the world could shard into eurocoins, americoins, or by subject (bitcoins for the internet, corpcoins for big corporate payments, etc)
11:58 < TD> jtimon: then you'd have exchange rates between them. but that's painful.
11:58 < TD> easier to scale the tech, i suspect
11:58 < jtimon> petertood: "reduce the consensus "size"", that's what I meant here " though the most promising scalability improvements can only come from more data being directly exchanged between parties without toughing the chain"
11:58 < petertodd> TD: ha, for once we're on agreement on scalability (at least on what we should do in the short/medium term)
11:59 < jtimon> TD ok I get your point
11:59 < TD> i'll go  out and celebrate tonight :)
11:59 < jtimon> TD but that's assuming no merged mining :(
11:59 < petertodd> TD: and for long-term, we can probably agree that we don't know yet becaues the research hasn't been done :)
12:00 < TD> the scaling issues with bitcoin aren't really mining, they're to do with management of the chain/transaction rates/etc. so merged mined altcoins are fine.
12:00 < TD> indeed!
12:00 < jtimon> yeah, maybe I'm just envisioning the worst-case scalability scenario, and still future looks bright
12:00 < petertodd> jtimon: ah, well depends on your definition of "the chain" - I think long-term we can create systems where, very roughly speaking, you have multiple chains where the "timestamping" PoW is all merged, but the proof-of-publication isn't
12:01 < petertodd> jtimon: so your tx on *a* blockchain might be subject to consensus by an audience of 10,000 or whatever, but the "audience" timestamping it may be millions
12:02 < petertodd> jtimon: and most likely the tech will be such that the more valuable transactions end up paying higher (absolute) fees, and are "seen" by a larger audience
12:02 < adam3us> TD: i'm more excited about pegged side-chains (aka alts but with bitcoin price pegging in lieu of new scarcity races) as a building block to explore sharding and other features.  then each guy with a crazy idea can go knock himself out on a side chain without creating dust on bitcoin main meta-coin style, and without creating a new tulip coin with scarcity race sales-hook being his "feature"
12:02 < jtimon> petertodd: I just don't know how you're going to do that
12:02 < petertodd> jtimon: the open research problems are all related to how does security work there
12:03 < jtimon> petertodd: as said some kind of sharding  would be very nice
12:03 < petertodd> jtimon: well, I've got some ideas - day before yesterday I outlined one on -wizards
12:03 < jtimon> yeah you half-explained me one, but I was unconvinced
12:04 < petertodd> adam3us: yeah, merge-mined sharding w/ pegged value is probably a reasonable way to upgrade bitcoin 1.0 to this kind of technology
12:04 < jtimon> I'm happy that you're thinking about these things though
12:04 < petertodd> adam3us: but as I say, the specifcs are an open question right now
12:04 < adam3us> anyway its not doom & gloom, we're not all out of ideas, maybe petertodd is full of it or maybe he finds the magic formula :)
12:05 < jtimon> petertodd: one idea I had in mind was partitioning the sequencing itself
12:05 < helo> sharding is sending bitcoin to an unspendable bitcoin addresses to mint altcoin?
12:05 < adam3us> petertodd: right exactly.  so lets build pegged side-chain and let a dozen people and startups go try see if they can figure it out
12:05 < jtimon> but I haven't found a way to make it p2p
12:05 < adam3us> helo: no sharding is generic... just means split up the volume somehow
12:06 < helo> ok
12:06 < adam3us> helo: pegged side-chain involves proof of transfer (you can move the coin back too, not destroyed as such)
12:06 < petertodd> adam3us: heh, worst comes to worst all my off-chain stuff *does* work just fine subject to the semi-centralization involved, and it has the enormous advantage that implementations of it can fail and won't take down the whole system with it
12:06 < jtimon> helo: like having half transactions in one chain and the other half in another chain
12:07 < jtimon> helo: I meant that for sharding
12:07 < adam3us> petertodd: it is highly likely that at least one person will try to claim solving it via a centralized server.  well we have open transactions even :) federated but auditable, and rebuildable from receipts
12:07 < petertodd> jtimon: yeah, atomicicity of transactions in sharded systems is a really interesting question
12:08 < petertodd> adam3us: yup, my actualy claim to fame in that space is only better systems of auditing and fraud punishment - the idea itself is so simple as to get reinvented constantly
12:08 < petertodd> adam3us: *actual
12:08 < jtimon> let me explain how would it work "centralized", maybe you can come up with a way to make that p2p
12:08 < adam3us> petertodd, jtimon: so pegged side chain, like 100 of them merge mined, coins moved via SPV proof of move or atomic cross chain swap.  seems not implausible
12:08 < jtimon> or someone else
12:09 < petertodd> jtimon: see fidelity bonded banks where the machine readable fraud proofs are what makes it possible to do it p2p
12:09 < jtimon> adam3us: that still requires fat validation miners
12:09 < petertodd> jtimon: no it doesn't, mining is scalable because miners don't have to validate all chains
12:09 < jtimon> petertodd you don't know what I'm going to say yet
12:10 < adam3us> jtimon: it merged mined, but maybe some model can be found for mining without having all 100 full tx feed.   its not like most mining power right now is even looking at the tx...
12:10 < jtimon> petertodd: there was no sharding in adam3us not implausible comment
12:11 < jtimon> "pegged side chain, like 100 of them merge mined, coins moved via SPV proof of move or atomic cross chain swap.  seems not implausible"
12:11 < adam3us> anyway we dont have to solve it today... more worried about how to provably preventing someone sneaking fractional reserve into a side-chain at this moment.
12:11 < adam3us> jtimon: yeah is just a definitional thing.  you could consider the 100 side chains 100 shards
12:12 < petertodd> adam3us: well, like I said above, the trick is to separate timestamping form the proof-of-publication - merge-mined side chains can naturally work that way if they are genuinely merge-mined, as opposed to just a soft-forking change
12:12 < adam3us> petertodd: yes this is a kind of open transactions argument.  i buy that as a plausible thing to explore.
12:12 < jtimon> well, since we don't know how to shard yet and you didn't explicitly mentioned it, I thought you meant we could still scale doing that without sharding
12:13 < adam3us> jtimon: i was thinking of a use-case of (multiple identical) pegged side-chains as a mechanism for sharding
12:13 < petertodd> jtimon: well, remember my thought example of the tree-like consensus system? if your top node in that tree is the bitcoin blockchain, then the two leaves logically are your merge-mined side-chains
12:14 < petertodd> jtimon: which is why coming up with a backwards-compatible upgrade is actually fairly plausible - ugly, but feasible
12:15 < jtimon> adam3us: but the pegging thing is to solve the "exchange rate" problem TD mentions
12:15 < adam3us> petertodd: its the beauty of pegged side-chain, the side chain (or lots of them, or competing lots of them) can go do experiments while retaining bitcoin main fungibility
12:15 < petertodd> adam3us: yup
12:16 < jtimon> adam3us: I'm saying I don't know a technical solution for merged mining + sharding in the first place, seem kind of incompatible to me
12:16 < adam3us> jtimon: right.  but pegged side-chains also form security firewalled experiment zones for interesting things, like sharding, freimarket script extensions, utxo compaction, zerocoins, comitted tx... anything within reason
12:17 < adam3us> petertodd: the limitation is oniy i think it has to be not too alien for bitcoin to not be able to consume the side-chains SPV proof of move
12:18 < jtimon> adam3us: security firewalled? what in pegcoin makes it more attractive to merge mine than say, devcoin?
12:18 < petertodd> adam3us: nah, I'd say the bigger limitation is that long-term PoW security needs to be paid for by fees, and the basic economic model is screwy there and has a high potential of failure
12:18 < adam3us> jtimon: incentive you mean? ask petertodd he's the incentive / game-theory gur ;P
12:18 < petertodd> adam3us: it's the think with off-chain stuff: it becoming too effective is a huge risk in the long-term!
12:19 < petertodd> adam3us: now that's like, 10 years away long term hopefully, but it's a problem that needs solving eventually
12:19 < adam3us> petertodd: it seems like the biggest open q about it really.  incentives.  but its not like that solved in main.  $25k/block or $150k/6-block is the price to admission (x the failure rate to build a chain long enough)
12:20 < jtimon> petertodd are you suggesting off-chain technology working nicely and securely is a "huge risk"? what do you mean?
12:21 < adam3us> petertodd: Maybe its a TD thing.  we (humans) want and need this to work, so maybe most honest people will do it and that will carry the day
12:21 < petertodd> adam3us: yup, currently my best guess is per-tx PoW schemes (and actually, maybe per *txin* PoW schemes) with anti-pooling stuff and PoW algorithms more resistant to ASIC centralization is what'll work, but those are all -wizard level questions and lots of research to be done
12:21 < adam3us> jtimon: he's worried about an incentive break down leading to attacks
12:22 < jtimon> adam3us well I ask you because you made the firewall claim, but I'm happy receiving an explanation from anybody
12:22 < petertodd> adam3us: in the meantime, honesty and other non-ideal second order effects will help the existing system limp along for a lot longer than it deserves too
12:22 < petertodd> jtimon: yes, in the long term the PoW security needs to be paid for, and one of the few reasonable ways to do it is transaction fees, no-txs == no pow security in many very plausible future models
12:23 < adam3us> jtimon: the firewall is its not plausible for bitcoin main to consider accepting transfers back from a side chain (2-way peg) unless there is assurance that fraud or security bugs on the side chain can cause holders of bitcoin main coins to be dilluted or lose btc
12:23 < jtimon> petertodd: another is demurrage BUT why would you expect not to have any in-chain transactions? off-chain transactions cannot be p2p currencies
12:23 < adam3us> jtimon: /can/can not/.  fortunately that seems possible to assure, hence 2-way peg excitement
12:23 < petertodd> Keep in mind, it's not that I disagree with TD's hope's of people playing nice, it's that if you're depending on that you've got a system with much weaker security guarantees than one that doesn't need honesty.
12:24 < petertodd> jtimon: why pay for an on-chian tx when an off-chian one works well enough? it's simple, less demand for on-chian tx's means less fees, and thus less security
12:25 < adam3us> petertodd: yes.  i think 51/33% attacks, incentive in btc main, and merge mined alt & sidechains is far from a done thing.  r& d community need to figure  out the optimal game-theory and protocol strategies
12:25 < jtimon> petertodd: if an off-chain system has all the properties bitcoin has, why should we fight to maintain a less efficient system?
12:25 < petertodd> jtimon: e.g. suppose fairly secure DRM w/ remote attestation was being shipped to consumers: you can easily turn that into a pretty good off-chain tx system with pretty good security that will get used a lot. That'll take a lot of money away from miners, reducing the security of the underlying system.
12:25 < petertodd> jtimon: because plausible off-chian tx systems *require* bitcoin to exist under the hood
12:26 < adam3us> jtimon: in this side-chain model bitcoin main is the sole home of reward mining.  its the hub at the center.
12:26 < petertodd> jtimon: without bitcoin they don't work
12:26 < jtimon> DRM needs proprietary software, which means we can't trust it
12:26 < jtimon> proprietary soft/hardware
12:26 < petertodd> jtimon: so what? trust isn't a binary thing
12:27 < jtimon> oh, I see "nbecause plausible off-chian tx systems *require* bitcoin to exist under the hood" this is what I was missing
12:27 < petertodd> jtimon: if I can trust it *enough* I can use it for less valuable payments and save the more expensive on-chian tx's for more valuable stuff
12:27 < jtimon> freimarkets private blockchains don't need public chains to work
12:27 < petertodd> and if bitcoin still exists, I can use techniques like fidelity bonds to make cracking the DRM system a lot less attractive
12:27 < adam3us> petertodd: there's a guy making offline bitcoin stuff using TPM cards that are microsd sized (via encrypted exchange of private keys) some people see to be excited enuf to be making him non-trivial btc onations
12:27 < jtimon> they can just interoperate with them
12:28 < adam3us> jtimon: is it drazan?
12:28 < jtimon> of course they don't have all the properties bitcoin has
12:28 < petertodd> adam3us: indeed, I'm thinking of buying a pair to support him
12:29 < adam3us> jtimon: drazvan https://bitcointalk.org/index.php?topic=319146.msg4494688#msg4494688
12:29 < adam3us> jtimon: its kind of cool.  not secure at the limit, but maybe it works for low value offline tx.  its only the users that lose if it goes wrong, nor online btc holders
12:29 < jtimon> so your concern is that off-chain systems relying on bitcoin are so useful that nobody uses in-chain transactions
12:30 < petertodd> jtimon: doesn't have to be "nobody", just has to be sufficiently less demand for on-chian that total fees doesn't pay for enough security
12:31 < jtimon> well, since I'm not against credit, I'm fine if people use other-things-than-bitcoin offline, so these kind of things don't excite me that much, I haven't read the thread yet though
12:31 < adam3us> petertodd: or maybe some trust/certification/ripple stuff sneaks in and mining contribution is reduced
12:32 < jtimon> petertodd I tend to worry more about "too much security" in the chain than about "too little of it"
12:32 < petertodd> my rough guess is something like 0.1% to 1% of the total value of all Bitcoins should go to PoW security per year. Satoshi should have let that happen with either never-ending inflation, or better yet, explicit demurrage. Doing mining that way give a very simple and stable security guarantee, and importantly works regardless of how many on-chain tx's are done.
12:32 < adam3us> jtimon: they are bitcoins, just transfered by encrypted exchange of private keys, in the model that the user doesnt know the private key and the TPM microsd card wont give it to them (or moare accurately tries to prevent cloning, you can load and unload them)
12:32 < petertodd> jtimon: "too much" just means you're wasting money - not a big deal.
12:32 < petertodd> jtimon: too little and some malicious 51% attacker destroys the whole system and we're fucked - big deal
12:32 < adam3us> petertodd: but he should do NFC or QR code, not SMS :(
12:32 < petertodd> jtimon: 0.1% to 1% are pretty low numbers that can be ignored as "rounding errors"
12:33 < petertodd> adam3us: isn't that just a software detail? the hardware itself isn't what does SMS
12:33 < adam3us> petertodd: sure
12:33 < jtimon> maybe I'm too hippy or something, too much you're wasting resources, destroying more nature than you need and all that
12:33 < adam3us> petertodd: nfc/qr = network privacy. sms=privacy leak.
12:34 < petertodd> jtimon: well, meh :) I'm sure conventional transaction systems tend to spend at least similar amounts of money per year on security, likely usually much more than that
12:34 < petertodd> jtimon: I mean, hell, I'm sure with credit cards the numbers are about that *per transaction*
12:34 < jtimon> well, I'm pretty sure 2PC ripple doesn't waste more resources than it needs
12:34 < petertodd> jtimon: wastes a lot of human brainpower on person-to-person trust relationships
12:35 < jtimon> credit cards need to feed fat cats, thus their high fees, but that's another story
12:35 < petertodd> jtimon: that's a shitty way to talk about the situation and makes you sound like an occupy activist
12:36 < jtimon> petertodd I disagree on that I don't have to think a lot when a friend of mine wants to borrow 10 eur
12:36 < petertodd> jtimon: well I think you're dead wrong there :)
12:37 < petertodd> more to the point, if you can only borrow 10 eur from each friend, then actually using ripple for any large tx gets tough
12:38 < jtimon> whatever, I can say it more correctly but it's just takes longer
12:38 < jtimon> was just laziness
12:38 < jtimon> credit cards are a very unefficient system for multiple reasons, I was talking about efficient systems like @PC Ripple
12:38 < jtimon> 2PC
12:38 < jtimon> petertodd: you see I believe in both counterpartyless money and credit monies complementing each other
12:40 < jtimon> to me, people that plainly reject credit as an exchange toold often sound like braindeath cultists goldbugs
12:40 < jtimon> just like people plainly rejecting counterpartyless money and only accepting mutual credit sound like fanatic
12:40 < petertodd> jtimon: You see, I belive in "This Bitcoin thing just requires me to install an app on my phone. This ripple things requires me to dick around convincing my friends to extend credit relationships to me and sounds like a shit-load of work."
12:40 < jtimon> that's just to me
12:41 < petertodd> jtimon: "Also, it's gonna be really awkward to turn down Bob because of his gambling problem."
12:41 < jtimon> petertodd: organizing a ntework of mutual credit local currencies is even more work
12:41 < petertodd> jtimon: "Nice guy, but still hasn't paid me back that $1000 I gave him when he got fired three years ago and needed to pay rent."
12:41 < petertodd> jtimon: "But I'd rather not bring that up again...."
12:42 < jtimon> I agree that a ripple-like network has harder critical mass problem than bitcoin
12:42 < petertodd> jtimon: Meh, software can do that automatically, and more likely we'll have schemes where the exchange rates don't float.
12:42 < petertodd> jtimon: It's orders of magnitude harder.
12:43 < jtimon> luckily it can start with other currencies like backed currencies, bonds, coupons, shares...
12:44 < petertodd> it's totally irrelevant what currency ripple works on, the problem is the social dynamics of it
12:44 < jtimon> maybe it never goes beyond that, but I think coupons can be more imporant than many expect in the future
12:45 < jtimon> if you have a pub and people accept some of your "I owe you a beer at my pub" currency, why wouldn't you do that?
12:46 < petertodd> *if* people accept it
12:46 < petertodd> if they don't, then you've put a lot of effort into a system that never got used
12:47 < jtimon> mutual credit is widely used right now
12:47 < jtimon> much more than you think
12:48 < jtimon> I just want to give this systems a plattorm to securely inter-operate
12:48 < petertodd> I know, it's why I've said before that ripple is much more likely to catch on for b2b transactions given that 30-day-credit relationships are extremely common
12:49 < petertodd> but fundementally you have to ask why you would use the ripple *technology* to manage those relationships? if transaction fees are sufficiently low, there isn't necessarily a compelling reason to bother
12:49 < jtimon> yeah, b2b, so called "barter networks" (they're really just another currency), coupons, local currencies...
12:50 < jtimon> to interoperate with others
12:50 < jtimon> to be able to pay with your spanish local currency in germany
12:50 < petertodd> well, again, what does ripple bring to the table? the ability to do cut-thru credit relationships, what does that do for you? potentially reduces transaction fees
12:50 < petertodd> if fees are low enough, why bother?
12:50 < jtimon> you just need a market path from the spanish local currency to the germany one
12:51 < jtimon> what fees?
12:51 < jtimon> bitcoin fees?
12:51 < petertodd> remember, ripple is all about optimizing who owes who, but why do you care exactly?
12:51 < jtimon> that's what money is all about
12:52 < jtimon> "bitcoin is about who has what, but why do you care?" I don't understand your point
12:52 < petertodd> what money is about doesn't matter for the end-user, they just want to solve a business problem
12:52 < adam3us> petertodd: freimarket includes real-ripple as a sub-component so freicoins that are IOU based can interop with frecoins that are mined (minus demurrage)
12:53 < jtimon> seriously I don't get your point about not caring
12:53 < jtimon> how would you don't care about who owes you and who you owe too?
12:53 < adam3us> petertodd: i think its a logical and self-consistent system, remains to be seen on adoptions.  some of adoption is first to market, network effects etc.
12:54 < jtimon> petertood: you don't see any value in a ripple network or in credit in general?
12:54 < petertodd> jtimon: because my *business* problem is "I want to make money, and I can make money if I sell icecream, and if my icecream distributor loans me some stock, I'll pay him back and we'll both make money."
12:54 < adam3us> jtimon: i think petertodd is still on competition & adoption, his q. why would someone prefer freimarket IOU freicoin over btc
12:54 < petertodd> jtimon: The "meaning" of money means absolutely nothing to either party in that transaction.
12:55 < jtimon> petertodd: people don't want money, people want the stuff they buy with it
12:55 < adam3us> jtimon: its also a value store i guess.
12:55 < jtimon> it's not about preferring, you have your wares that by definition you don't want and want to sell
12:55 < petertodd> jtimon: and that's the thing, "I'm an icecream mfg, I need milk, now if you farmers give me some milk, I'll give you some money once I sell my icecream" - that's another business relationship
12:56 < jtimon> exactly
12:56 < jtimon> that can be done with "money" or credit
12:56 < petertodd> jtimon: ripple says "hey! this forms a cool graph when we add the customers into a big decentralized distributed database!" and can make those credit relationships magically collapse when the customer buys the icecream or soemthing
12:57 < jtimon> the important stuff is are the icecream and the milk, the rest are just numbers to make that happen
12:57 < petertodd> jtimon: meanwhile the business say "Who cares? Doing it the old way is plenty efficient and the new way requires a bunch of software and buy-in from a zillion parties."
12:57 < jtimon> that's the ideal situation in ripple, try to come back to the b2b stage
12:57 < jtimon> you sell icecream in summer
12:58 < jtimon> I go to you and say "do you accept ourtown's local currency for the ice cream"
12:58 < jtimon> you say "no, I prefer bitcoin"
12:58 < jtimon> "ok, ?I don't have bitcoin, keep your icecream"
12:59 < jtimon> if you want milk and you can buy it with both local credit currency and bitcoin, why reject any of the two?
12:59 < petertodd> and that's the problem, any real business will say "Why the hell do I care about these local currencies? Let someone else figure out how to convert FooDollars to and from Bitcoin so we can focus on making icecream, our core competency."
13:00 < jtimon> hehe, you remind me to people talking about real businesses and bitcoin a while back...
13:00 < petertodd> You might not be aware of this, but one of the reasons Net 30 day works is because there exist third party credit rating agencies that specialize in figuring out whether or not your counterparty will pay you back.
13:01 < jtimon> the magic of ripple is that you will only ever receive the currencies you accept
13:01 < petertodd> ...and when those agencies aren't good enough, the reason why Net 30 day works is because often suppliers have special insights into their customer's businesses, and thus credit worthyness, that is otherwise really hard to get.
13:01 < jtimon> and the payer doesn't need to bother about conversions neither: the system does them
13:01 < jtimon> yes, I'm aware
13:01 < petertodd> jtimon: That's not magic at all.
13:01 < jtimon> no, it's not magic
13:01 < jtimon> it's tech
13:02 < petertodd> jtimon: That's the magic of "I price my icecream in dollars."
13:02 < adam3us> petertodd: well i guess bitcoin doesnt do it
13:02 < petertodd> jtimon: You don't need ripple for that
13:02 < adam3us> petertodd:  bitpay et al let you though, ok
13:02 < jtimon> you can say "I price my icecream in gbp, I accept btc, bristol pounds or gbp"
13:03 < petertodd> adam3us: Exactly! bitpay, and the exchanges they work with, managed to outsource all that highly specialized work related to figuring out how to convert bitcoins to dollars
13:03 < jtimon> I go there with frc and sevillan pumas
13:03 < adam3us> petertodd: probably where a difference comes in is its hard to take out btc denominated loans because its volatile and trending up in price.
13:03 < jtimon> I push "pay 1 gbp to this merchant" the system says "want to pay X frc or Y pumas?
13:04 < jtimon> what's the unconvenience?
13:04 < jtimon> petertodd: a ripple network can do what bitpay does!!
13:04 < petertodd> jtimon: the unconvenience is that you needed this big ripple thing with a zillion credit relationships for it to work, when the alternative is to let some specialist handle it for you
13:05 < jtimon> no, I said the merchant just accepted 3 currencies, that's 3 credit relationships
13:05 < petertodd> jtimon: See, if tx fees to and from sevillan pumas are low, then you're customer, or you, can just as easily use that specialist to convert it for you.
13:06 < petertodd> jtimon: That's a *low overhead* solution to the problem that doesn't require much adoption to work. Ripple is the exact opposite.
13:06 < jtimon> but the point of the system is unite the infrastructure of the different currencies NOT TO NEED the specialist
13:06 < jtimon> whatever, I don't think I can convince you
13:06 < petertodd> jtimon: Modern economics has realized over and over again that specialists are excellent solutions to most problems.
13:07 < jtimon> so please, answer my previous question "you don't see much value in a ripple network or in credit in general?"
13:07 < petertodd> I see lots of value in credit, because people use credit all the time. Ripple, not much value at all.
13:07 < jtimon> petertodd, argument of authority fallacy, your authority: "modern economics"
13:08 < jtimon> Ripple = credit
13:08 < petertodd> jtimon: No, ripple is a way to manage credit. There are other ways to manage credit.
13:08 < jtimon> it's just the same thing with a more convenient infrastructure
13:08 < petertodd> jtimon: You think it's more convenient, I don't for a whole host of reasons.
13:09 < jtimon> what's the difference between an international payment and a ripple transaction?
13:09 < jtimon> transitive credit, it's the same thing
13:09 < petertodd> And the biggest problem with Ripple is the value of it is network effect dependent, so if only a small network of people use it it has very little value. That's a enormous bootstrapping problem on top of all the other problems of it.
13:09 < jtimon> you know, banks took all that overhead of trusting each other
13:09 < adam3us> jtimon: if u really lend people money in small amounts, often you dont get it back.  thats my experience.  and lending money to friends & family generally is not a good idea.  when something goes wrong it leads to problems.
13:10 < petertodd> jtimon: yes, and banks are specialists at that task. Ripple is asking everyone to get in the business of doing that, which goes against the tendency in modern economies to specialise.
13:11 < petertodd> adam3us: yup, it's worth noting that Net 30 day credit relationships are declining as businesses become more complex and transactions more convenient.
13:11 < jtimon> I'm saying it won't start with personal credit, but with b2b, local currencies, p2p markets gateways...
13:11 < adam3us> petertodd: i think the notional advantage of ripple.com is that they can cancel out some debts and so reduce the fees
13:11 < jtimon> the small participants can join later
13:11 < petertodd> adam3us: yup, which means it's in competition with every solution that reduces fees... and there are a huge number of ways to do that
13:12 < jtimon> just to be clear, I'm talking about ripple the concept not ripple.com
13:12 < petertodd> jtimon: doesn't work that way, often those small participants are what make the ripple network loops happen that let credit relationships get canceled out - the core thing that ripple does
13:12 < adam3us> petertodd: actually ripple.com is very poorly explained online.  i am not sure if it also has issued values other than iou values mixing on its network.
13:12 < petertodd> adam3us: ripple.com is an abomination and we shall not refer to it again
13:12 < jtimon> the way you trust in ripple.com is very risky for users
13:12 < adam3us> jtimon: yes.  thats why i put ripple.com when i wanted to refer to them
13:12 < jtimon> because it assumes 1 aaaUSD = 1 bbbUSD
13:13 < adam3us> petertodd: hehe the R-word.
13:13 < jtimon> that's not necessarily true in 2PC ripple or freimarkets
13:14 < maaku> jtimon: replacements can be used for microchannel payments (e.g. utility bill)
13:14 < petertodd> See, fidelity bonded banks are an excellent example of something where ripple can work very well, and one of the reasons that works is because the whole point is to keep tx fees low, 1 aaaBTC == 1 bbbBTC, and all the logic about the trust relationships can be handled in software (talking about the ideal fidelity bonded bank stuff here)
13:15 < petertodd> But that's a crazy-specialized example, and the whole concept of fidelity bonded banking is just as likely to get pushed out by other ways of getting low tx fees.
13:15 < jtimon> aaaBTC/bbbBTC should be just a market like any other
13:15 < petertodd> jtimon: that's a market with very little depth to it
13:16 < jtimon> that depends on the issuers, aaa and bbb
13:16 < petertodd> jtimon: if the issuers are big, then you've got something that looks suspiciously like standard systems and the cancellation advantages of ripple don't apply, if the issues are small, then you've got the network effect problems and it doesn't work
13:17 < jtimon> maaku why a miner should accept seq = 5 over seq = 3 if seq = 3 has a higher fee ?
13:17 < petertodd> jtimon: because TD and Gavin asked nicely
13:18 < jtimon> petertodd: if I'm the issuer of both aaa and bbb I can make that volume infinite no matter how small I am
13:18 < petertodd> jtimon: if you issued both, they there weren't two separate things
13:18 < jtimon> "jtimon: because TD and Gavin asked nicely" what did they asked?
13:19 < petertodd> the difference between aaaBTC and bbbBTC is that the issuer is differnt, and thus the default risk is different
13:19 < petertodd> jtimon: to not do "selfish" replace-by-fee of course
13:19 < maaku> jtimon: what if they have the same fee?
13:19 < jtimon> whatever system you had in mind to make  "1 aaaBTC == 1 bbbBT", it can be simulated with a market
13:19 < maaku> agreed that nseq is dangerous, but just pointing out the (only) application I know of which nseq handles but nothing else does
13:20 < petertodd> maaku: then you want to accept whatever has the lowest orphan risk, which is whatever you think everyone else accepted, modulo the fact that accepting updates uses precious bandwidth so why encourage that?
13:20 < jtimon> killerstorm said you can do that use case with multisig
13:20 < maaku> petertodd: true. then is there any other valid use for nseq?
13:20 < maaku> (still catching up to scrollback)
13:20 < petertodd> maaku: to fork alt implementations :P
13:21 < petertodd> maaku: nSeq is also the *only* user-settable field in a txin that is signed by the signature - an unfortunate limitation
13:21 < petertodd> maaku: useful for colored coins, as an example, as nSeq can be the mapping of colored input to output
13:21 < jtimon> killerstorm wants to use the unused nseq to put CC metadata instead of using OP
13:21 < jtimon> OP_RETURN
13:22 < petertodd> jtimon: yeah, I suggested that to him
13:22 < jtimon> but some people are telling them that the field will be re-enabled later
13:22 < jtimon> petertodd: yes, he said so in bitcoinX
13:22 < petertodd> so what? using it that way is compatible with transaction replacement in fact
13:23 < jtimon> he came here to ask about that
13:23 < jtimon> arguing against the security and the use case of nseq
13:23 < petertodd> well, just think about it: if nLockTime=0 and nSeq != max, the tx is final and nSeq irrelevant
13:23 < jtimon> so I concluded we could just remove it in freimarkets
13:23 < petertodd> (to the replacement code)
13:24 < jtimon> I see, so there's no contra at all for using them for CCs
13:25 < petertodd> yup
13:25 < adam3us> jtimon, petertodd: are we all done with the sales/system competition-level arguments about freimarket/real-ripple/ripple.com/banking system?  so many ore interesting things to talk about... ;)
13:26 < petertodd> the real risk is nSeq will be defined to be something else entirely, and there's some possibilities there, but worst comes to worst you can just upgrade the CC software ina  "hard-fork" - not a big deal
13:26 < petertodd> adam3us: lol, distracting me from stealth addresses as it is
13:27 < adam3us> here's one for you... how do you bootstrap mergemine security in a side chain (or an alt in general).  find miners to merge mine as a favor before there is fee incentive?
13:28 < adam3us> petertodd: some stealth discussion on bitcoin-dev.. also did u see gmaxwell idea for a better fuzzy bloom-bait/prefix?
13:29 < jtimon> still, I see no reason to keep them in FM
13:29 < jtimon> adam3us I don't think we were advancing much
13:29 < petertodd> adam3us: remind me again?
13:29 < adam3us> petertodd: he posted it also on bitcoin-dev
13:29 < petertodd> jtimon: it's 4 bytes per txin, meh
13:29 < petertodd> adam3us: one sec
13:31 < jtimon> adam3us: our approach to MM start without it untill we have our own miners, than hardfork for MM and convince Luke-Jr to MM it
13:31 < jtimon> I think we could do it already, but maybe we won't be able to hardfok once again for freimarkets then
13:31 < jtimon> petertodd 4 bytes we won't use. we're hardforking, why not?
13:34 < jtimon> well, when we start MM I think we will approach all big pools
13:34 < petertodd> adam3us: gregories idea doesn't scale as well
13:35 < petertodd> adam3us: the big advantage of the prefix thing is it's trivially compatible with sharding ideas and so on - note how I talked about putting the ephm pubkey in the txout too
13:35 < adam3us> petertodd: nearly.  its also indexable just more indexes, and it allows some parameterizable fuzziness.  but it also has stat analysis problems nearly as bad as bare prefix
13:35 < petertodd> adam3us: to be efficient, you're going to need 16 lookup table versions for instance
13:36 < petertodd> adam3us: exactly, and at the same time, how bad is the analysis problem anyway? it's *not* an issue for coinjoin the way people seem to think it is, given the version where the bait goes in the txout
13:36 < adam3us> petertodd: yes its not cost free, but its still indexable and the privacy is slightly less bad.
13:36 < petertodd> jtimon: just make sure that a signature can sign stuff in the scriptSig then
13:36 < petertodd> jtimon: there really needs to be a mechanisms to do that
13:37 < petertodd> adam3us: meh, that's not exciting me very much - highly unlikely that version of it will wind up being made into miner committed indexes for instance
13:37 < jtimon> petertodd I don't understand, why is nseq necessary for the signature?
13:38 < petertodd> jtimon: the point of it in the CC example is that you want to sign something in the txin itself because you have some additional data that needs to be signed, but that data isn't known until the tx is created
13:38 < adam3us> petertodd: for example with 1 byte prefix, it cuts your anon-set by 256x.  mix in a bit of time correlation, change glomming on input, and any non-trivial use of reusable addr and its a lot worse i think
13:38 < petertodd> jtimon: the OP_RETURN txout solution to that is worse, because it doesn't play well with coinjoin
13:39 < petertodd> adam3us: remember that prefixes are denominated in bits...
13:39 < maaku_> petertodd: we support colored coins explicitly. is there some other reason you'd need data attached to the txin?
13:39 < petertodd> maaku_: upgrading CHECKSIG in a soft-fork is an excellent example
13:39 < maaku_> can you explain?
13:40 < adam3us> petertodd: either bits is enuf to create an anon-set problem, or bits is so small that it doesnt scale
13:40 < petertodd> adam3us: what makes you think it doesn't scale? I mean, shit, without prefixes the idea works reasonable well with 1MB blocks - there isn't that much data to manage
13:41 < petertodd> maaku_: suppose I want to add a signature over the fees paid to CHECKSIG, if I could just make a merkle tree of the txin values, and put that merkle root in the scriptSig, then I could soft-fork that feature in by defining SIGHHASH_CHECKFEE_MERKLE_ROOT
13:41 < petertodd> maaku_: I can't do that right now because any additional data in the scriptSig is unsigned
13:42 < petertodd> adam3us: fundementally the problem is what's the chance of all these extra indexes getting adopted? I'd say nero-zero
13:42 < adam3us> petertodd: i mean doesnt scale to non-full-nodes
13:42 < petertodd> adam3us: near-zero
13:43 < petertodd> adam3us: no, it's just a bandwidht trade-off, a desktop SPV client isn't gonna care about downloading even all blocks frankly, and 1/8th (say) gets to be more and more reasonable
13:43 < adam3us> petertodd: well if u wanna take the 'we cant change shit' stance i guess we hae to take solutions that cause big privacy problems because of that.  hmm.
13:44 < jtimon> petertodd I don't understand the use case, probablyit can be made without a new op
13:44 < adam3us> petertodd: your smart phone might care
13:44 < petertodd> adam3us: well hey, this is a much smaller privacy problem then what we have right now
13:44 < adam3us> petertodd: i disagree, its a worse privacy problem.  thats my point.
13:44 < petertodd> jtimon: think about it more, it can't
13:45 < petertodd> adam3us: reality is people are going to connect to untrusted SPV nodes, and it's *very* likely that attackers will start (or alredy do) run them for data collection
13:45 < adam3us> petertodd: gmaxwell went over this yday and i wrote about it in detail in one of my bitcoin-dev posts.  the privacy issues
13:45 < petertodd> adam3us: additionally we *need* to solve SPV scalability, and prefix indexes are a big part of that (electrum works that way for a reason)
13:45 < adam3us> petertodd: yes.  but.  as gmaxwell said thats different to putting the privacy leak in the indelible global record
13:46 < petertodd> adam3us: well for instance his analysis re: coinjoin is just wrong
13:46 < adam3us> petertodd: yeah but lets at least try do it in a privacy preserving way eh.  we can scale things also by doing other scary things.
13:47 < petertodd> adam3us: that's what I'm trying to do you know...
13:47 < adam3us> petertodd: i think my analysis on bitcoin-dev about the anon-set overlaid on network analysis is correct.
13:48 < petertodd> adam3us: my point is, remember what he said about it reducing the anonymity set in CJ? that's just wrong - it doesn't help you distinguish change and non-change for instance
13:48 < adam3us> petertodd: ok fair enuf.  i am just saying, its worse, not better; depending on your threat model, and i think targetted attack is less dangerous than after the fact global analysis attack
13:49 < petertodd> adam3us: as a thought experiment, consider how it'd work if you made the grinding bloom filter compat: that's basically what gmaxwell is proposing
13:49 < petertodd> adam3us: (specifically with a random nTweak value)
13:49 < adam3us> petertodd: well actually it might  if non-change is an prefixed reusable addr and change is a one-use adr
13:49 < maaku_> jtimon petertodd: well i think this particular application could be better done wih etotheipi's WITHINPUTVALUE sighash mode
13:49 < petertodd> adam3us: the whole point is that you can't distinguish a prefixed reusable *output* and a change output
13:50 < petertodd> maaku_: yes, but where in the scriptSig do you sign the input value?
13:50 < petertodd> maaku_: again, if the signature covers some of the scriptSig, that's easy
13:50 < adam3us> petertodd: i know.  but prefixes are unchanging.  there lack of presence eliminate some tx from the network analysis.  that effect can be cumulative.  it might leak more bits of entropy per edge than a coin join with random (possibly malicious join to self parties) adds
13:51 < jtimon> petertodd maaku_ I can't think about it because I don't know what is trying to be done
13:52 < maaku_> jtimon: he's trying to have his signature cover the fee, by signing both the input values and the output values
13:52 < adam3us> petertodd: ( i mean if i know because its public your prefix is FF and i see a coinjoin that doesnt have FF in the output then i know you're not in it with that addr.  maybe there's another CJ feeding into the previous and it does have FF in it.)
13:52 < petertodd> adam3us: again, you're totally missing my point here. you can't distinguish the output in the prefix-tx, so all you've maanged to do is narrow down who the tx might pay in terms of probabilities (and even worse, you can't rule out stealth addreses with longer, or no, prefixes)
13:53 < jtimon> ok, first solution: using joyscript and a load_utxo-family opcode (I know, this is another opcode)
13:54 < maaku_> jtimon: and doesn't work for hostcoin
13:54 < petertodd> jtimon: anyway, just look up what I've written on bitcointalk about OP_CODESEPARATOR
13:54 < maaku_> hrm, well this is actually an interesting question about a more expressive script - sighash will have to be implemented differently
13:54 < adam3us> petertodd: ok look at it from a black box perspective.  there's 1000 tx going into a cluster of CJ, two inputs have FF on them, two output have FF on them.  there are two uers we've noticed who use CJ who have FF, anon-set reduction by factor of 1000
13:54 < jtimon> maaku_ to disable covenants you just need to disable load_tx
13:54 < jrmithdobbs> petertodd: OP_CODESEP is just bottom really isn't it?
13:54 < petertodd> jrmithdobbs: ?
13:55 < maaku_> jtimon: ah, reading failure
13:55 < jtimon> maaku_ how so?
13:55 < maaku_> jtimon: you're fine i misread what you said
13:56 < petertodd> adam3us: again, you can't distingish outputs using stealth and ones that aren't
13:56 < jrmithdobbs> petertodd: give me a few and i'll restate ;p
13:56 < adam3us> petertodd: i think you said it yourself even "all you've maanged to do is narrow down who the tx might pay in terms of probabilities" right exactly :) it weakens the already fragile anon-set coming from CJ with random parties.  there are flood attacks on mixers near and dear to people who analysed mixaster remailers which apply
13:56 < maaku_> but about sighash, the issue is that how it determines what script to put in the serialization only really makes sense for a linear language
13:56 < adam3us> petertodd: correct. but that doesnt stop you ruling out a given stealth address.
13:57 < adam3us> petertodd: full node stealth addresses are of course immune as they can have zero prefix.
13:58 < petertodd> adam3us: look at it this way, I agree with you that there is an info leak, is it enough to say "wait stop! lets not implement this and delay!" no
13:58 < adam3us> petertodd: so either you are saying they arent used, or if they are used they decrease anonymity.  less than address reuse, but more than one-use address.
13:59 < petertodd> adam3us: what gmaxwell proposes is a linear increase in anonymity set size, with a linear increase in peer work because of extra indexes. will that be implemented? I'm not seeing it
13:59 < adam3us> petertodd: well it was for me.  i figured out the same stuff on bct and thought, hmm no thats not good for privacy, put in bucket of fun but not quite safe things.  (other than for full-node use case)
13:59 < gmaxwell> ditto, fwiw.
13:59 < gmaxwell> (That this idea wasn't new to me— I knew it from bytecoin's thread, but I simply thought it wasn't good enough)
13:59 < petertodd> adam3us: tough, it's a hell of a lot safer than the *actual* alternative people are going to be using
14:00 < adam3us> petertodd: what are they going to be using
14:00 < petertodd> adam3us: don't live in a dream world of users doing what's absolutely optimal vs. "Hey, this works!"
14:00 < adam3us> petertodd: TD is working on HD wallet for bitcoinj.
14:00 < petertodd> adam3us: they're going to re-use addresses left right and center
14:00 < jtimon> maaku_ is there any reason not to make withinput value the default?
14:00 < petertodd> adam3us: that's got nothing to do with it
14:01 < petertodd> adam3us: HD is orthogonal to the problem stealth addrs try to solve
14:01 < gmaxwell> having your security depend on unknown factors esp including the attacker's statistical prowess... kinda lame and sometimes less secure than no privacy at all.  In any case, it's worth at least doing the thought to get the best design within that space we can.
14:01 < adam3us> petertodd: i think it has a lot to do with it.  most addr reuse is on bitcoinj dependent smart phone wallets i hazard
14:01 < maaku_> jtimon: yes, that's been my thinking. just have to be careful about compatability
14:01 < maaku_> petertodd: so you'd want a some sort of code-separator like device for the scriptSig?
14:02 < petertodd> gmaxwell: I forget if I got around to proposing it, but the wider blockchain data thing that be made more private in exactly the same way as you're proposing by having full-nodes maintain redundent indexes
14:02 < petertodd> adam3us: that's change addr reuse, not payment related
14:02 < petertodd> adam3us: I'm solving the user-payment side of things, and that's a hard problem without bi-directional comms
14:02 < adam3us> petertodd: aslo while you and jeremy spilman are in implemention mode why not focus on full node case?
14:02 < jtimon> valitationScript may serve too, but again I'm missing the practical use case of the problem, small memory nodes?
14:03 < petertodd> adam3us: because that's stupidly limiting
14:03 < petertodd> adam3us: anyway, long-term this prefixing stuff will either end up being common for scalability in general, or bitcoin doesn't scale...
14:04 < petertodd> adam3us: equally, in the near future we're going to see prefix lookups being used for wallet syncronization, so that part of the infrastrucutre is getting implemented
14:04 < petertodd> adam3us: did you read my blockchain privacy paper btw?
14:05 < jtimon> I'm not following the stealth addresses discussion in detail, but petertodd are the prefixes needed for sharding?
14:05 < petertodd> jtimon: exactly
14:05 < adam3us> petertodd: thats just admitting defeat.  i dont think we've necessarily hit a tech wall yet. eg gmaxwell cooked up the fuzzy bloombait in a few mins yesterday.
14:05 < maaku_> jtimon: it's an avenue for future expansion of capability, by being able to include stuff in the scriptSig which is covered by a signature
14:06 < adam3us> jtimon: no he's just trying to make addresses recognizable but with some privacy in a bloom subset like sense
14:06 < adam3us> petertodd: blockchain privacy? where was this?
14:06 < petertodd> adam3us: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03612.html
14:06 < jtimon> petertodd then I guess you need to convince people sharding is feasible to make it count as an argument in the stealth address discussion
14:07 < petertodd> jtimon: sharding isn't just related to blockchian structure, it also works even in the "big-block" scenario because it lets nodes handle a subset of the blockchain bandwidth
14:07 < jtimon> adam3us: I think he uses it for two purposes I don't understand the one you mentioned, but don't bother I still have too much to read from stealth addresses
14:08 < adam3us> jtimon: yes like views it as somehow inevitable for sharding maybe.. i dont get that bit either ;) (talking about you third person there petertodd)
14:09 < petertodd> adam3us: read that paper first...
14:09 < petertodd> adam3us: there is logic to it :P
14:09 < jtimon> petertodd: so it could work even without changing anything, miners could just do it to be able to manage a partition
14:10 < jtimon> petertodd I am understanding what you're saying?
14:10 < jtimon> ma I
14:10 < jtimon> am I
14:10 < jtimon> ug
14:10 < petertodd> jtimon: miners can't mine without the whole blockchain right now, but full-nodes passing around archival data and serving SPV can easily shard and process bandwidth subsets
14:11 < petertodd> jtimon: they can do so securely with the committed (U)TXO stuff that's been floating around
14:11 < jtimon> assuming we already have commited utxo
14:11 < jtimon> what's the next step for sharding?
14:12 < petertodd> jtimon: very simple: adversie what prefix of the UTXO space some full node has, and SPV clients connect to full nodes with the data they need
14:13 < petertodd> jtimon: well, and make "full" nodes themselves only get tx's from their peers matching the prefixes
14:13 < jtimon> I see, thanks
14:13 < jtimon> wait
14:14 < jtimon> full nodes also select a part of the UXTO, where do the prefixes come in?
14:14 < jtimon> oh, sorry
14:14 < petertodd> jtimon: the prefix is what part they select
14:15 < petertodd> jtimon: obviously they're not actually doing full validation here, but you can set things up so that all the blockchain data is "covered" by multiple partial validators
14:15 < jtimon> the smaller the prefix, the bigger part of the uxto you have
14:15 < petertodd> jtimon: with fraud proofs if anyone finds a problem, everyone can be informed that the block needs to be rejected
14:15 < petertodd> jtimon: exactly
14:17 < adam3us> petertodd: ok read.  i think i skimmed it a bit before (remember the bloom issues you identified.. i asked TD about it early on and he said yes there are a few bugs)
14:17 < jtimon> ok, I'm trying to compare it with maaku_'s stateless validation proposal...
14:17 < jtimon> in that one, miners only have the root of the utxo
14:18 < petertodd> jtimon: this *is* his proposal
14:18 < petertodd> jtimon: it's something you can do with it basically
14:19 < jtimon> ey, wait
14:19 < petertodd> adam3us: good, now see my point how this stealth structure fits in very well with where blockchian indexes are going? this is something we can actually get implemented, and solve a lot of real problems very quickly
14:20 < adam3us> petertodd: block chain indexes? you mean the above koorde like sharding of data?  (nodes store things near to them in some artificial space)?
14:20 < petertodd> adam3us: yeah exactly
14:21 < petertodd> adam3us: remember, the big issue with bloom is it's not indexable
14:21 < petertodd> adam3us: to query against a bloom filter requires matching against all transactions for every query, which sucks
14:21 < adam3us> petertodd: i dont quite accept that as a valid design rationale though.  'could shard this way' for a speculative what-if => lets do prefixes even though they have self-admitted linkability problems
14:22 < adam3us> petertodd: yeah bloom has its issues.
14:22 < petertodd> adam3us: there's nothing speculative about it, electrum does just that, and will add prefix queries soon
14:22 < adam3us> petertodd: maybe there's a third way
14:22 < adam3us> petertodd: speculative in there being full-nodes that focus on some prefixes only.
14:23 < jtimon> petertodd: with your proposal, how miners validate foreign blocks that contain tx that refer to a part of the utxo they don't have?
14:23 < jtimon> Are miners also supposed to send the full update proofs to each other like with maaku_'s?
14:23 < jtimon> If so, what do miners hold any of the utxo at all (apart from the root)?
14:23 < petertodd> adam3us: electrum servers *are* an example of a full node serving SPV clients
14:23 < petertodd> adam3us: SPV != bloom you know
14:23 < petertodd> jtimon: in the current design of bitcoin that's not really possible
14:23 < adam3us> petertodd: yes i know, and i agree
14:25 < jtimon> petertodd: which of the two things are not possible?
14:25 < petertodd> adam3us: yes, so, the question really is how do you index data such that you can match approximately, with the in-chain data being less approximate then the indexes the SPV-serving nodes have, gmaxwell has a proposal, but again, how would you ever end up with a miner committed index of it?
14:26 < petertodd> jtimon: the validate txins referring to utxo they don't have
14:26 < adam3us> petertodd: well bloom results are not committed
14:27 < petertodd> adam3us: I know, and like I said, stealth addrs could be implemented as "match this bloom filter index with this nTweak"
14:27 < adam3us> petertodd: or are they.  hmm.  i mean can you verify the entire result set from the fuzy bloom query tie into the containing block hash?
14:27 < petertodd> adam3us: but that's not scalable on the index side becuse of all the possible nTweak's
14:27 < jtimon> petertodd: I think maaku's proposal with updatable trees require clients to send the complete proofs miners need to check validity having only the root of the utxo
14:28 < petertodd> adam3us: obviously miners could commit to boom filters, but then you'd run into the problem that to use gmaxwell's solution you have to have them commit to n different versions of the filter
14:28 < petertodd> jtimon: ah, sorry, yeah, if you adopt that then miners can do that
14:29 < jtimon> that's stateless validation
14:29 < jtimon> it seems better than sharding for miners
14:30 < adam3us> petertodd: getting sleepy but it seems more like a public key watermarking problem.  ie there are people who thought about and may be even have solutions to this problem.  i am not sure if they are going to be indexable or not.  but we could explore it.  if its expensive also maybe there could be fees.
14:30 < petertodd> jtimon: think about how much bandwidht they're using in that example...
14:30 < jtimon> maybe all the proofs should go hashed in the block
14:30 < petertodd> adam3us: it has to be a solution that isn't expensive or this isn't gonna happen and we'll still have address reuse
14:30 < jtimon> petertodd yes, bandwith is the bottleneck in this case
14:30 < petertodd> adam3us: hell, this has to be a solution with pretyt damn low programmer complexity to have any hope of being adopted
14:31 < jtimon> petertodd but your approach is not secure for miners
14:31 < petertodd> jtimon: wait, the sharding?
14:31 < petertodd> jtimon: forget miners
14:31 < jtimon> yes
14:31 < adam3us> petertodd: yea yeah.  i know the life of a privacy tech crypto guy, people emand the impossible and then turn their noe up when you pull some minor miracle that its not as easy or as cheap as doing something privacy invasive.  been there. done that. got the t-shirt
14:31 < petertodd> jtimon: sharding for miners is a much harder problem then sharding for full-nods that want to serve SPV
14:32 < maaku_> jtimon: i got stateless validation from petertodd
14:32 < petertodd> adam3us: exactly, OTOH we've got this stealth addresses proposal that's gotten like three reimplementations in a few days, and we can actually get adopted. Let that process happen and we can *upgrade* it later to be even better.
14:32 < jtimon> petertodd, full nodes too, but miners are spending money hashing....oh, ok, you're not talking sharded miners
14:32 < petertodd> adam3us: I'm specifically trying to design stealth addresses themselves to be backwards compat upgradable you know.
14:32 < maaku_> or it came out of a discussion between petertodd and gmaxwell, iirc
14:33 < maaku_> here on -wizards
14:33 < jtimon> petertodd I thought you needed prefixes in stealth addresses for sharded mining
14:33 < petertodd> adam3us: when we figure out a more clever way of doing prefixes, we can add a field to the stealth addr data that says "Hey! if you know how to handle this, you can also pay me with this fancy index scheme, but otherwise do the old thing."
14:34 < petertodd> jtimon: sharded mining eventually, sharded full nodes soon
14:34 < adam3us> petertodd: so maybe could it reasonably said that stealth addresses are used only here in the vanity/bizcard kind of use case.  or is this going to turn into another 'yeah address reuse, sorry cant persuade user or wallet maker to stop' scenario
14:35 < adam3us> petertodd: ie they just jam them into their wallet, and reuse them ad nauseum for plenty of non-bizcard scenarios
14:36 < jtimon> petertodd sharded mining is what's hard for me to believe you're near to solve, but sharded full nodes seems a good enough use case to justify prefixes on stealth addresses
14:36 < petertodd> adam3us: hey, at least with an upgrade path we only have to convince the wallets incrementally
14:36 < adam3us> petertodd: btw i have another solution to address reuse.  one-show signatures.  (reuse it at your peril, do that and it leaks your private key via simultaneous equation) the tech is very simple to do it too.  how about i propose that on bitcoin-dev and draw some diagrams about the advantages of a final solution :)
14:36 < petertodd> adam3us: meh, users reuse addrs if you let them
14:36 < petertodd> adam3us: pff, good luck, that's user obnoxious
14:37 < adam3us> petertodd: well the client sw would say "error cant reuse"
14:37 < petertodd> adam3us: that's the kind of thing you build into a new system, not something you do as a *downgrade* to an existing one (form the users perspective)
14:37 < petertodd> adam3us: we can hardly convince wallet authors to not reuse change addrs, give it up
14:37 < petertodd> adam3us: never mind you're risking user funds
14:38 < Luke-Jr> lolwut, someone emailed me a complaint - they don't like me using proper nettiquite on bitcoin-dev
14:38 < adam3us> petertodd: well i guess i was just going with the flow you know... proposing things that are risky, and using first to implement arguments for my being right :P
14:39 < adam3us> petertodd: it has uses too.  double-spending becomes much harder!
14:39 < petertodd> adam3us: no, you're doing almost the exact opposite to what I'm doing: "I got this idea and lets impose it because it's good, fuck users."
14:39 < Luke-Jr> you all coming to Miami? :p
14:39 < petertodd> adam3us: I'm saying "How can I offer something to users that they'll actually accept and make things easier?"
14:39 < petertodd> Luke-Jr: nah
14:40 < adam3us> Luke-Jr: someone paying flights?  kind of far for a weekend...
14:40 < Luke-Jr> far from where :P
14:40 < adam3us> Luke-Jr: malta (europe)
14:41 < Luke-Jr> ah, yeah that's a bit far
14:41 < jtimon> yeah spain's far too
14:41 < maaku_> jtimon (and anyone else) : I'm reaching out to the concatenative language community to see if they have any input for a joyscript. let me knkow if anyting is missing : http://0bin.net/paste/kMkgAK+zO2+mTK0E#Lua4/1g5fGVyv44fpRkftnd37RetgnrDrItXAp9FyvA=
14:43 < petertodd> bbl
14:43 < adam3us> petertodd: i get that they might accept it and find it easier (they already like reusing addresses because its conceptually simpler) but it cant replace one-use adresses, because other than for full node (0-length prefix) its strictly worse on privacy.  i mean the whole thing is about privacy, so you cant say its easy to use or they accept, if it makes privacy worse (for non-static uses)
14:46 < adam3us> maaku_: nice write up
14:47 < adam3us> maaku_: i guess also that interpreter escape would be calamitous if that is not impled!
14:50 < maaku_> adam3us: good, i'll add that
14:58 < jtimon> maaku_ reading now
15:10 < jtimon> maaku_ looks great, nothing comes to mind to add
15:16 < jtimon> very good idea to approach those commmunities
15:17 < jtimon> I guess petertodd still prefers forth and gmaxwell and sipa still prefer the AST
15:19 < jtimon> but it will be interesting to see what those forums think, where are you sending that maaku_?
15:19 < maaku_> the concatenative yahoo group
15:19 < maaku_> also #concatenative
15:19 < jtimon> ughh, yahoo groups...
15:20 < maaku_> [13:59:44] <gmaxwell> adam3us: really? I think forth is basically ideal.
15:20 < maaku_> I think sipa is the only one interested in a more imparative AST
15:21 < sipa> imperative?
15:21 < sipa> if anything i prefer it is not imperative...
15:21 < jtimon> now they want my phone number...
15:22 < maaku_> jtimon: just sign up for the mailing list, no yahoo account required
15:22 < maaku_> jtimon: i'm not a fan of programming in concatenative languages... yuck, honestly. but this is the textbook case for where they excell
15:24 < maaku_> sipa: very poor choice of words on my part
15:25 < maaku_> but is there any advantage to the system you advocated before over a concatenative, point-free language?
15:26 < maaku_> i tried to think of an example the last time we talked, but couldn't
15:26 < sipa> it's a bit vague to me what that means
15:26 < sipa> i'll look up joy
15:28 < jtimon> AST are used in a phase of compilation I think, so sipa's point is I think for maybe having different compilers to the AST (also being a tree, easily merklizable)
15:29 < sipa> it may be possible to convert joy to an AST of the type i suggested
15:29 < maaku_> well it's loose terminology so i'm not sure what exactly is meant
15:29 < jtimon> and everybody uses the same AST, well, I'm just speculating about his reasoning
15:30 < maaku_> Forth-like language such as Joy have an AST as well
15:30 < sipa> anyway, i like the idea of these types of script to essentially be an expression
15:30 < jtimon> yes, compile joy to an ast should be possible, maybe you can ask that too "should we use joy or the AST compiled from joy?"
15:30 < sipa> it has a natural merkleization
15:31 < sipa> is trivial to analyse wrt to execution time
15:31 < maaku_> sipa: http://evincarofautumn.blogspot.com/2012/02/why-concatenative-programming-matters.html
15:31 < maaku_> and http://www.kevinalbrecht.com/code/joy-mirror/j01tut.html
15:31 < maaku_> probably the best introducitons
15:32 < jtimon> maybe we can even write the scripts in python and compile them to ast, I'm sure the pypy guys have something to build from
15:32 < maaku_> with a Merklized Joy, you'd consider quotations to be a branch of the AST
15:32 < maaku_> so, for example, an if statement is: pred [true-branch] [false-branch] if
15:32 < sipa> what advantage does joy/... have?
15:33 < maaku_> you can separately merklize the true and false branches
15:33 < jtimon> sipa I think maaku_'s point is that dealing with the AST directly is ugly and joy is a functional lisp-like lang
15:33 < maaku_> sipa: implementation and type analysis is very simple (unless you f' up the language design)
15:34 < sipa> i don't understand what's ugly about it
15:34 < sipa> it's just an expression
15:34 < jtimon> oh, and then the strong typing thing, but that's cat, no?
15:34 < sipa> it's pretty much the most natural way of writing *simply* conditions i can think of
15:36 < sipa> but maybe we need to actually try to write some actual things in these sorts of languages first
15:38 < sipa> i guess my usage of the word 'AST' is also a bit confusing, as that's just an compiler step
15:39 < maaku_> sipa: you won't find an argument about concatenative languages being better than lambda abstraction or vice versa, because they are equivalent
15:39 < sipa> i'm *certainly* not planning to introduce lambdas
15:40 < sipa> i'm a big fan of higher-order strongly-typed functional languages, but lambda's would make implementation significantly more difficult, and analysis even more so
15:40 < maaku_> but as an intermediate language, stack based concatenative languages are trivially simple to implement in an imperative or JIT interpreter (close to the machine), and do so safely
15:40 < sipa> evaluating an expression tree is surely even simpler
15:40 < maaku_> sipa: a concatenative language like Joy has the power of lambda abstraction without those added complexities
15:41 < sipa> maybe i should just write a toy implementation...
15:44 < sipa> maaku_: heh, i guess i didn't realize this before
15:44 < sipa> i presume joy is turing complete?
15:45 < sipa> with some recursion primitives, i'm sure it is
15:45 < maaku_> yes
15:46 < sipa> right, i'm not aiming for that
15:47 < sipa> if you need that, a concatenative approach is probably easier to implement than having higher-order functions and lambdas in an expression language
15:47 < sipa> but i'm unconvinced about the need for that
15:49 < maaku_> well need is a word that carries baggage
15:50 < maaku_> i was recently convinced of the utility of turing complete scripting, which is to say i understand the desire for it and it is worth experimenting with
15:50 < sipa> right, sure
15:50 < maaku_> but "need" encompasses so many tradeoffs I'm not comfortable making yet :)
15:50 < sipa> i'm just talking about a bitcoin script 2
15:50 < sipa> not about anything more ambitious than that
15:53 < andytoshi> maaku_: nice links. i just clued in that 'postfix' the language is named for 'postfix' the notation :P
15:59 < jtimon> I thought joy hadn't recursion because didn't need it
16:00 < sipa> well, the wikipedia article on it has an example with a 'binrec' primitive
16:01 < jtimon> this sentence is very confusing to me "Combinators in Joy behave much like functionals or higher order functions in other languages, they minimise the need for recursive and non-recursive definitions."
16:02 < jtimon> I'll keep reading the links, hopefully I'll have a clearer idea after that
16:02 < maaku_> jtimon: it doesn't have recursion in the traditional sense, but it has the equivalent of an 'eval' opcode
16:02 < maaku_> and since code is data, that's enough to build whatever you need
16:03 < maaku_> combinators (like binrec) are just a variety of built-in variants of this idea
16:04 < jtimon> I don't really have a strong opinion on joy vs ast really
16:06 < sipa> i *really* dislike code==data
16:06 < jtimon> maybe allowing everyone to build their own python, lisp, js, C or whatever to AST compiler and letting the AST interpreter itself be the "consensus sensible"  part is a better solution
16:06 < sipa> it makes analysis horrible
16:07 < killerstorm> are you discussing new awesome cryptocurrency?
16:07 < jtimon> yeah, I would definitely ask the concatenative guys what they think about using an AST directly and then compile from other language
16:08 < jtimon> killerstorm: new awesome scripting language that among other things, could be used for native colored coins
16:08 < sipa> that requires an OP_EVAL like sturcture :S
16:09 < sipa> which means you cannot possibly analyse without executing...
16:09 < killerstorm> native colored coins can be implemented using OP_CHECKCOLORVERIFY (https://bitcointalk.org/index.php?topic=253385.0)
16:09 < killerstorm> I mean the basic kind.
16:09 < jtimon> although some people don't like the idea of covenants in the hostcoin
16:09 < jtimon> killerstorm, yes, but that's 1 op = 1 use case
16:10 < jtimon> thi, being more generic, would allow many other things
16:11 < jtimon> within freimarkets for example it would allow you to always be able to buy your p2p interest-bearing debt back
16:11 < killerstorm> I'm afraid that implementing anything non-trivial via scripts will result in a huge bloat
16:11 < jtimon> http://0bin.net/paste/kMkgAK+zO2+mTK0E#Lua4/1g5fGVyv44fpRkftnd37RetgnrDrItXAp9FyvA=
16:11 < jtimon> I still think tagged CCs are better
16:12 < maaku_> [13:06:14] <sipa> it makes analysis horrible
16:12 < maaku_> not with a strong type system
16:12 < maaku_> killerstorm: yeah sortof, a scripting extension/replacement that will probably make it into freimarkets
16:12 < jtimon> I don't even think interest/demurrage bearing assets are possible with them
16:12  * andytoshi waits as "rustcoin" stops being funny and starts being considered..
16:12 < jtimon> /with/without
16:13 < amiller> wtf is the point of opcheckcolorverify? the color checking operation is massive/exponential/bad
16:13 < sipa> maaku_: well, then code isn't data :)
16:14 < sipa> maaku_: as the type system can determine in advance what is executable
16:14 < maaku_> sipa: not sure i follow
16:14 < killerstorm> amiller: The idea is to add color tags to utxo db. then it is trivia.
16:14 < sipa> maybe you mean something else by code==data than i do... for me it means i can construct a random string/sequence operations/whatever using code, and then execute it
16:15 < maaku_> jtimon: the "common AST" *is* a concatenative language. there's a reason the JVM and .NET intermediate languages are concatenative...
16:15 < maaku_> everything compiles down to that
16:15 < sipa> JVM bytecode language is certainly not an AST
16:15 < amiller> killerstorm, a lot of effort goes into keeping the utxo as small as possible, how do you quantify what change that incurs?
16:15 < maaku_> yes, it's a stack-based language
16:15 < sipa> it's an imperative stack-based language, afaik
16:15 < maaku_> exactly
16:16 < sipa> i need to stop using the word AST, as it's much wider than what i mean
16:16 < jtimon> amillar the point is making CCs SPV-friendly
16:17 < maaku_> killerstorm: the scripts are in the scriptSigs, so they're immediately pruned
16:17 < amiller> jtimon, ok well fair enough, that is indeed a good way to do it, but you probably also need a way of discouraging utxo bloat
16:18 < jtimon> amiller I advocate for explicit colors
16:18 < amiller> jtimon, yes i advocate for it too, i just don't see what the solution is for discouraging utxo bloat now that you add a functionality that increases it
16:19 < jtimon> if nobody has to store the full utxo, utxo bloating is not that much of a problem
16:20 < maaku_> amiller: this doesn't result in any utxo bloat...
16:20 < amiller> do coins have at most 1 color or something?
16:20 < maaku_> scripts are in the txin, not out
16:20 < killerstorm> amiller: color tag is just a hash of genesis transaction or something like that. ~32 bytes per UTXO won't hurt.
16:20 < maaku_> amiller: yes
16:21 < amiller> ok that sounds pretty nice.
16:21 < amiller> adding that single op code and that single change to UTXO is by far the simplest way of getting fairly scalable colored coins usage.
16:22 < killerstorm> jtimon: there is no difference between OP_CHECKCOLORVERIFY and explicit colors. OP_CHECKCOLORVERIFY can be in scriptSig.
16:22 < amiller> i'd be really interested to see that
16:22 < jtimon> killerstorm: in fact, in the next version of freimarkets specs, you can save the tag, by ommiting it you mean "the same color as the previous output"
16:22 < killerstorm> jtimon: I mean I'm not aware of any practical difference.
16:22 < amiller> that sounds pretty great to me
16:22 < amiller> how about a reference impl that deviates minimally from satoshi client?
16:24 < maaku_> amiller: what scheme are you talking about?
16:24 < killerstorm> Well I've heard iXcoin guys are interested in implementing this, but they lack developers. (Essentially it is just the guy who does the marketing...)
16:24 < killerstorm> I've outlined the spec although I'm not sure about some decisions.
16:25 < jtimon> saposhi nasakyoto I think (I can't believe ixcoin is alive, and there's still people who say MM kills altcoins...)
16:29 < jtimon> but yeah, why not use it to experiment
16:30 < jtimon> is already MM, it's in a great position to be used for this things
16:31 < killerstorm> It got new life: new PR/marketing team :)
16:32 < killerstorm> MM means that it is 100% controlled by ghash.io
16:32 < jtimon> killerstorm, how do you implement per-asset interest/demurrage with OP_CHECKCOLOR ?
16:32 < jtimon> only ghash.io merge-mines it?
16:33 < killerstorm> No, ghash.io has 40% of bitcoin hashpower and is mining alt-coins. Since some Bitcoin miners do not do merged mining, this means that ghash.io hash more than 50% of hashpower of Namecoin and IXCoin
16:34 < petertodd> killerstorm: +1 wish people realized that earlier
16:39 < warren> http://en.wikipedia.org/wiki/Savitch's_theorem
16:39 < warren> (for those thinking of memory hard to hash but easy to validate PoW, would this theoretical limit apply?)
16:42 < petertodd> I'm not seeing the connection
16:49 < jtimon> I don't see why memory hard is better
16:50 < warren> I didn't say it was.
16:50 < warren> people were discussing it here in past months
16:50 < petertodd> jtimon: the theory is memory hard targets memory, which is most likely to be an availalbe commodity product and thus escapes the ASIC centralization trap
16:51 < petertodd> jtimon: however, practical memory hard that really is ASIC-hard appears to be a very difficult problem
16:51 < petertodd> jtimon: reasonably easy to do in cases where the work to be done in non-parallizable, but crypto-consensus systems must be parallelizable
17:01 < jtimon> I don't see why ASICs are worse
17:05 < warren> IMHO, mining pool centralization is the real problem, not ASIC's.
17:07 < jtimon> warren, agreed, and I thought that was solved with trustless pools (p2pool, eligious...)
17:07 < petertodd> jtimon: ASICs centralize control in the hands of a very small number of chip fabs
17:08 < maaku_> petertodd: meh, coordinated quality control could mitigate that
17:08 < petertodd> jtimon: and p2pool and getblocktemplate don't "solve" the problem because there's no incentive to use either
17:08 < petertodd> maaku_: huh?
17:08 < maaku_> petertodd: a scanning electron microscope is not hard to get access to
17:09 < petertodd> jtimon: they *do* help with "non-selfish" actors, but they fall short of the security ideal where bitcoin is secure in the presense of selfish actors
17:09 < maaku_> there should be efforts to take asic chips at random from batches and do SEM scans of their circuits
17:09 < maaku_> then anyone with tools can verify that they are not backdoored
17:09 < petertodd> maaku_: the problem isn't hardware that's bugged, the problem is getting hardware at all - those chip fabs can easily *publicly* control the bitcoin network
17:10 < jtimon> can't the operator of a centralized pool cheat you somehow?
17:10 < maaku_> jtimon: out of your shares, yes
17:10 < jtimon> or decide for you what transactions to, say censor?
17:11 < petertodd> jtimon: they can cheat you in lots of ways, that doesn't change the fact that per unit hashing power they'll be more profitable in many scenarios
17:11 < maaku_> jtimon: using GBT you can choose your own transactions
17:11 < petertodd> jtimon: after all, they might own the hashing power too you know in which case cheating doesn't even come into it - ghash.io owns much of their physical hashing power
17:11 < petertodd> maaku_: in theory, in practice pools don't allow that - very high bandwidth cost
17:12 < maaku_> well, eligius does
17:12 < jtimon> maybe centralized operators aren't being as malevolent as they "should"
17:12 < petertodd> maaku_: yes, and eligius is being operated by alturistic people
17:12 < petertodd> jtimon: who cares? what matters is that our security isn't as good if we have to rely on that
17:13 < maaku_> meh, i would say that eligius is operated by knowlegable people/person
17:13 < sipa> it's my theory that if every actor started out as malevolent/selfish/rational, bitcoin would never have worked
17:13 < sipa> it's an experiment in building a system that doesn't need trust in many actors
17:13 < maaku_> as bitcoin matures i expect more pools to act like Luke-Jr
17:13 < sipa> but we'll need to get there step by step
17:13 < jtimon> sipa you're probably right, the start was incredible difficult
17:14 < maaku_> or maybe the causality is reversed - bitcoin will never mature unless more pools act like Eligius does
17:14 < maaku_> either way once it happens, it happens
17:14 < jtimon> I mean, I wasn't around, but...it's surely the hardest part
17:15 < petertodd> sipa: yes, we got incredibly lucky there
17:16 < petertodd> fact of the matter is that relying on alturism is dangerous and subject to sudden changes
17:16 < petertodd> never mind the fact that what were were talking about, ASIC-hardness, has nothing to do with alturism
17:17 < sipa> yup, but removing much it suddenly is equally dangerous
17:17 < petertodd> sipa: what do you mean by "removing" it?
17:17 < petertodd> sipa: no-one is proposing removing anything
17:17 < sipa> oh, i'm not saying that
17:18 < sipa> but if suddenly many people/miners/whatever started acting selfishly, i'm sure it could hurt bitcoin's survival chances
17:18 < sipa> +suddenly
17:18 < petertodd> oh sure, but the fact that it would hurt just shows that bitcoin is poorly designed
17:18 < sipa> i'd say it just isn't evolved enough :)
17:19 < petertodd> heh, equally true statement
17:19 < petertodd> though the ugly thing is changing the design is probably an economic change so...
17:20 < petertodd> anyway, as I said about the selfish miner attack, these attacks are real, and we're damn lucky that for now the big players are acting alturisticly, take advantage of that time to study alternatives so we'll have them ready when they're needed
17:20 < jtimon> come'on miners have to attack MM chains because "the good of their coin is their good", but they cannot trustless mine because "it is not selfish enough"?
17:21 < petertodd> jtimon: what do you mean by trustless mine?
17:21 < jtimon> p2pool, eligious
17:21 < sipa> p2pool/gbt?
17:21 < jtimon> yes
17:21 < petertodd> jtimon: remember, my point re MM attack was that if you have a big pool, then your MM chain is in a dangerous position
17:22 < petertodd> jtimon: my point with trustless mining is that it *costs more* than just pointing your hashing power at ghash.io
17:22 < jtimon> my point now is to apply your same "for the future of the coin" reasoning for miners to use p2pool/gbt
17:22 < petertodd> after all, this all came up with mastercoin when I got hired to analyze what type of blockchian they should use, and the result was "Why use anything less secure?"
17:23 < petertodd> jtimon: that's a very bad comparison - you're comparing the behavior of a large pool to a small hasher
17:24 < jtimon> a large pool is composed of small hashers
17:25 < jtimon> if anything, they should be more stupid in groups, no?
17:25 < petertodd> not at all, think in terms of incentives to defect and do what's better for you, but worse for the group
17:25 < petertodd> IE, I earn more money for less work if I hash at ghash.io
17:26 < petertodd> vs. "I'm a 30% pool and killing off FooCoin is cheap and easy and the public doesn't like it anyway so the PR will be good for me."
17:26 < petertodd> (especially relevant in my advice to mastercoin you know...)
17:26 < jtimon> IE, I earn more money for less work if I MM instead of attacking a "competing" coin
17:26 < petertodd> oh piss off, scale makes the incentives very different
17:26 < sipa> merge mining a tiny currency doesn't gain you anything significant
17:27 < jtimon> your advice to mastercoin was to use your proof of sacrifice design draft?
17:27 < jrmithdobbs> jtimon: you're failing to control for internet assholes
17:27 < jtimon> sipa how much you lose by gbt vs ghash.io ?
17:27 < jrmithdobbs> "Some men just like to watch the world burn."
17:28 < petertodd> again, the first time this came up I had a paying contract to tell mastercoin if they should, or shouldn't, stick with putting data in the blockchain. I said the existing design was very secure if you used steganography for anit-censorship, PoW chains were possible to 51% attack, and merge-mine would make 51% trivial by a big pool
17:28 < jtimon> jrmithdobbs I don't follow
17:28 < petertodd> given that censorship of MSC txs in the blockchain is *way* harder than people realize, obviously I told them some techniques to improve on that and stick with what they had
17:28 < petertodd> (this is why MSC adopted an encoding scheme where the data looks like valid pubkeys)
17:29 < jrmithdobbs> jtimon: just because it is in their economic interest to mergemine instead of attack alt coins doesn't mean that is the decision that will always be made.
17:29 < sipa> bah
17:29 < petertodd> sipa: heh, I think lots of people didn't realize that was so easy...
17:29 < sipa> petertodd: this is a nice example of what i'd call suddenly changing how selfish a particular party acts
17:29 < petertodd> sipa: indeed, and BTC better realize how easy what MSC did is
17:29 < jtimon> jrmithdobbs  just because it is in their economic interest to mine at ghash.io instead of using p2pool/gbt doesn't mean that is the decision that will always be made.
17:30 < jtimon> that's my point, how is difffernt?
17:30 < petertodd> sipa: basing scalability assumptions, esp re: the UTXO set, on "oh, people will play nice" is idiotic
17:30 < Luke-Jr> hmm, I wonder if deploying P2SH^2 might not be as hard as we think
17:30 < petertodd> Luke-Jr: MSC is P2SH^2 proof
17:30 < Luke-Jr> petertodd: I mean real bitcoin
17:30 < jrmithdobbs> petertodd: i think sd proved that already.
17:30 < petertodd> Luke-Jr: "real bitcoin"?
17:31 < petertodd> Luke-Jr: I mean, adopting P2SH^2 *doesn't* stop the MSC encoding scheme (well, with the trivial modification to wrap the CHECKMULTISIGs in P2SH txs)
17:31 < Luke-Jr> petertodd: I'm not sure what MSC came up for, I'm talking about Bitcoin itself
17:31 < petertodd> jrmithdobbs: no, they stopped
17:31 < Luke-Jr> petertodd: why do I care about that?
17:31 < jtimon> petertodd: I see your point, MM is less secure than MSC, true, but it's also more scalable
17:31 < jrmithdobbs> petertodd: like a year later
17:31 < petertodd> Luke-Jr: oh, I'm assuming you meant P2SH^2 to stop MSC
17:31 < sipa> Luke-Jr: MSC is putting data in bitcoin's chain...
17:31 < Luke-Jr> petertodd: no, P2SH is to stop data spam
17:31 < Luke-Jr> ^2*
17:31 < Luke-Jr> sipa: ⁈
17:32 < petertodd> Luke-Jr: well, that's my point, you can't stop data spam *except* to stop it from getting in the UTXO set, and even that's weak
17:32 < Luke-Jr> petertodd: you can
17:32 < petertodd> Luke-Jr: you can't stop schemes that encode hashes in the UTXO set, and there's lots of usees for that
17:32 < Luke-Jr> scriptSig can require preimages or valid ECDSA sigs too
17:32 < Luke-Jr> petertodd: not really, no
17:32 < petertodd> Luke-Jr: read this: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03524.html
17:33 < petertodd> Luke-Jr: without some pretty drastic changes to the way scripts work you can't
17:33 < sipa> Luke-Jr: then the preimage would be in the blockchain
17:33 < Luke-Jr> sipa: not necessarily
17:33 < petertodd> Luke-Jr: also, stopping data spam 100% stops you from soft-forking in a lot of potential new features, for instance new signature algorithms
17:33 < sipa> Luke-Jr: that would prevent you from validating it afterwards
17:34 < Luke-Jr> I'm assuming the P2SH^2 enforcement is done by miners only
17:34 < petertodd> Luke-Jr: and timestamp/proof-of-publication spam is really handy to a lot of protocols, and bloats the UTXO set even
17:34 < Luke-Jr> and tx relay
17:34 < sipa> Luke-Jr: then it only requires an out-of-chain deal with a miner to put it in anyway
17:34 < Luke-Jr> petertodd: there is no need to bloat the UTXO set
17:34 < petertodd> Luke-Jr: e.g. P2SH^2, even gmaxwell's v2.0 version, doesn't stop you from doing namecoin int he UTXO set
17:35 < petertodd> Luke-Jr: for many protocols abusing the UTXO set is cheaper and more secure and there's fuck all we can do about it other than ask nicely to stop
17:35 < jtimon> what's P2SH^2 please?
17:35 < jtimon> link?
17:35 < Luke-Jr> petertodd: *technically* yes
17:35 < Luke-Jr> jtimon: miners only mining stuff that is proven to be a hash
17:35 < petertodd> jtimon: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg01987.html
17:35 < sipa> jtimon: have P2SH-only in the txouts, but to relay a transaction, you must add SHA256(script) to it
17:36 < petertodd> Luke-Jr: yes, and getting a hash into the UTXO set is enough to implement namecoin
17:36 < sipa> jtimon: so you prove that the data in the P2SH output is a real hash of something, and not data
17:36 < Luke-Jr> petertodd: it makes it more expensive
17:37 < petertodd> Luke-Jr: namecoin is already expensive, irrelevant
17:37 < Luke-Jr> the point is to make blockchain bloat more expensive than merged mining
17:37 < petertodd> Luke-Jr: as I told Mastercoin, their transactions are worth a lot more than the least valuable Bitcoin transactions, so they'll be able to outbid those and still get their data in the chain
17:37 < petertodd> Luke-Jr: that's irrelevant, merge-mining is less secure
17:38 < Luke-Jr> only if you're scamcoining.
17:38 < sipa> i'm not sure what intent has to do with it
17:38 < petertodd> Luke-Jr: sure, which is why I told Mastercoin to stick with the current system!
17:39 < petertodd> Luke-Jr: After all, what is or isn't a scamcoin is a matter of public opinion, so you're safer assuming people think you are and acting appropriately.
17:39 < Luke-Jr> sipa: if you're just interested in the security, you can do merged mining in a secure way
17:40 < Luke-Jr> if every Bitcoin block is a valid Altcoin block, and Altcoin uses the same difficulty and requires merged mining, then the worst someone can do is equivalent to not participating
17:41 < petertodd> Luke-Jr: that's not at all true and stop saying that
17:41 < sipa> petertodd: totally different subject; if we'd have a system with TXO MMR's... that would require every wallet to remain up-to-date with all blocks, to find operations that affect the path of its unspent outputs to the roots of the range?
17:41 < petertodd> Luke-Jr: you've just come up with a system where the block interval is really long if there isn't that much hashing power, that is still vulnerable to 51% attack
17:41 < killerstorm> I have a question about Bitcoin security: do we need to  assume that majority of miners (hashpower-weighted) are not colluding (i.e. making a secrete arrangements) with each other for Bitcoin to be secure? Or do we assume that they are rational and rational miners won't collude?
17:41 < maaku_> petertodd: it's disengenous to say that merged mining is insercure too
17:42 < Luke-Jr> petertodd: only if the attacker 51%s bitcoin as well
17:42 < petertodd> sipa: nothing explicitly of course
17:42 < maaku_> bitcoin-parasitic vs merged mined alt? of course the parasitic option is better
17:42 < petertodd> Luke-Jr: no, think about it: altcoin is 1% of hashing power, so the block interval is 10min * 100, I can still 51% attack that by mining more blocks than the other miners regardless of the interval
17:42 < maaku_> merged mined alt vs non-merged mined alt? that's a different story
17:43 < Luke-Jr> petertodd: no, you may have 51% of blocks, but you cannot reorg it
17:43 < maaku_> killerstorm: depends on the context. colluding to do what?
17:43 < Luke-Jr> petertodd: you'd need to have 51% of *bitcoin* blocks and reorg bitcoin, to reorg the altcoin
17:43 < sipa> short-term-selfish miners will always collude if they can
17:43 < petertodd> Luke-Jr: ah, but if I can't re-org it, and it's a timestamp system, then what happens if I mine a longer chain in secret and reveal it?
17:43 < maaku_> but in many cases yes, 51% is sufficient to censor the chain, for example
17:44 < Luke-Jr> petertodd: you'd need a longer *bitcoin* chain
17:44 < petertodd> Luke-Jr: mining a block doesn't magically make it available to the world
17:44 < sipa> as it means their 51% becomes 100%
17:44 < petertodd> Luke-Jr: no, bitcoin block #10 mines altcoin block 1, bitcoin block #11 mines alt block 2a, bitcoin block #12 mines alt block 2b
17:44 < petertodd> Luke-Jr: was 2a or 2b the valid best block?
17:45 < Luke-Jr> petertodd: altcoin does not have a prevblock header.
17:45 < Luke-Jr> it is ALWAYS tied to the bitcoin chain
17:45 < petertodd> Luke-Jr: yes it does, the prevblock header just happens to skip a few steps
17:45 < Luke-Jr> your scenario is not possible
17:46 < Luke-Jr> if bitcoin block 11 mines alt block 2, then bitcoin block 12 must mine alt block 3
17:46 < petertodd> Luke-Jr: after all, if the miner of bitcoin block #11 doesn't tell anyone he mined 2a, then how does 2b know that?
17:46 < petertodd> Luke-Jr: remember, this is a merge-mine chain: participation is voluntary
17:47 < sipa> i wasn't aware of the fact that merged-mined chains had no own prevhash
17:47 < sipa> but it seems to make sense
17:47 < Luke-Jr> sipa: the existing ones do, but that's not the system I was talking about
17:47 < Luke-Jr> petertodd: ok, I remember this now.
17:47 < petertodd> sipa: luke's very mistaken...
17:47 < Luke-Jr> petertodd: I forget if I found a solution to that issue or not
17:47 < maaku_> sipa: they do, i think Luke-Jr is describing something novel/different
17:47 < sipa> ok
17:48 < sipa> i'm not sure what the problem is with it that petertodd is describing
17:48 < petertodd> Luke-Jr: you realize I've proposed basically the same thing with my zookeyv proposal, and I even took advantage of that by ensuring that proof-of-sacrifice "blocks" in the scheme were always visible in the bitcoin blockchian, so you could know if a 51% attacker was waiting to reveal their attack to the world and outspend them
17:48 < petertodd> Luke-Jr: tl;dr: I'm way ahead of you :P
17:50 < petertodd> sipa: the problem is that if you tie things as tightly to the bitcoin chain as luke is suggesting, the moment someone mines an alt-coin block but *doesn't* publish it you're screwed because all alt-coin clients can see the block header commitment, but dont have the data to go along with it
17:50 < petertodd> sipa: OTOH if you're system doesn't have that vulnerability, it's still longest chain wins and your 51% attack vulnerable
17:50 < Luke-Jr> .. unless we softfork bitcoin
17:50 < petertodd> Luke-Jr: sure, but then it's not a merge-mined chian anymore
17:50 < Luke-Jr> petertodd: sure it is
17:50 < petertodd> Luke-Jr: No, you've just made the blocks bigger with a fancy hash commitment.
17:51 < Luke-Jr> bitcoin miners can enforce disclosure of the merged data to some degree
17:51 < petertodd> Luke-Jr: the whole point of merge-mining is that it's *voluntary*
17:51 < Luke-Jr> petertodd: hence the degree limit
17:51 < petertodd> Luke-Jr: yes, and if disclosure is enforced you've just made the blocks bigger and contain extra data
17:51 < sipa> yup, i see the problem
17:52 < Luke-Jr> only bigger for miners
17:52 < petertodd> Luke-Jr: so what? that's the problem we keep trying to solve
17:52 < killerstorm> OK, let's formulate in a different way: is there a game-theoretic research of Bitcoin? Particularly, double-spend-via-a-bribe attack: somebody wants to double-spend a large amount of money and will pay miners a bribe to help him to do that.
17:53 < sipa> killerstorm: yup, will work for large amounts; you just need to have enough confirmations that reverting it costs more than what one might pay a miner to revert it :)
17:53 < petertodd> killerstorm: yeah, and the results are ugly, don't accept 1 conf payments for $1million and do irreversable things based on them
17:54 < petertodd> killerstorm: notably it's why tx fees being the only thing paying miners leads to really ugly consequences
17:54 < jtimon> killerstorm exactly, the bigger the transaction the more you have to wait, it's not 6 blocks
17:54 < sipa> the 6 blocks number is based on statistics that assumed a much less centralizing mining landscape in any case
17:54 < petertodd> FWIW peter from the bitfoin foundation asked me last summer if I or someone else would be willing to do some research to make up a whitepaper and similar tools to advice merchants on exactly that issue.
17:55 < petertodd> dunno if that project ever went anywhere, but it's an important one
17:55 < killerstorm> I'm afraid it's much worse than you think...
17:56 < Luke-Jr> personally, I don't think merchants want to have to read a paper..
17:56 < petertodd> killerstorm: lots of people forget an attacker might be ripping off multiple people at once for instance
17:56 < petertodd> Luke-Jr: indeed, which is why peter's vanesses idea was to eventually create some calculators for said merchants to do the thinking for them
17:56 < petertodd> Luke-Jr: Like, input in the value of the tx and spit out how long they needed to wait. (subject to certain assumptions about the attacker)
17:58 < Luke-Jr> petertodd: re MM, the problem we need to solve is not forcing people to store data against their will, but also enable innovation beyond Bitcoin taking advantage of the same securing hashpower
17:58 < petertodd> Luke-Jr: yeah, well, MM isn't necessarily that innovation
17:58 < adam3us> Luke-Jr: that seems like an interesting idea.  (merge mine where the bitcoin blocks are valid alt-chain blocks)
17:58 < Luke-Jr> present-day MM style does that just fine, really. the 51% risks aren't really a real concern.
17:59 < petertodd> Luke-Jr: you realize that one of the reasons mastercoin hired me was because they realized they needed someone to study that
17:59 < Luke-Jr> petertodd: MM is what is needed to *enable* that innovation
17:59 < petertodd> Luke-Jr: again, MM fails in a hell of a lot of scenarios
17:59 < adam3us> Luke-Jr: I agree
17:59 < adam3us> petertodd: so lets see if we can improve it
18:00 < petertodd> adam3us: heh, what do you think I'm working on?
18:00 < adam3us> petertodd: judging from the above stego encoding msc into btc? :P
18:00 < killerstorm> Well, here's what I'm thinking about: Suppose we have 100 independent miners each having an equally powerful mining rig (thus one of them solves the next block with equal opportunity). Block reward is 25 BTC, normal tx fees are negligible. Somebody sends a transaction with Y BTC in it. Gets 6 confirmations. Then publishes a transaction which pays X BTC to fees. What happens next, super-rational miners realize that all super-rational miners will tr
18:00 < killerstorm> y to do a reorganization. Only 6 miners are NOT interested in reorganization, thus we'll have 94 miners working on a fork.
18:00 < killerstorm> Note that X is not used in equation: it can be very low. Like 1 BTC.
18:00 < petertodd> adam3us: in the mean time, my advice *without* those theoretical - and maybe impossible - improvements is that stego encoding has a hell of a lot of advantages
18:00 < adam3us> petertodd: fair enuf.
18:01 < killerstorm> You can get 25 BTC of a normal reward, or 25.1 BTC of reward + bribe, what do you do?
18:01 < petertodd> adam3us: and remember, knowing that stego encoding is useful, and damn near impossible to stop, is very valuable knowledge for bitcoin too
18:01 < adam3us> petertodd: yes i think however that its a bit of a dead end.  it much more attractive to have secure pegged side-chains or unpegged alt-chains for innovation
18:01 < killerstorm> All super-rational miners will decide to take bribe. So one only needs, say, 0.6 BTC to buy them all.
18:02 < maaku_> adam3us: I don't think you can call pegging "secure" until you get rid of the SPV trust
18:02 < killerstorm> Which basically means that if miners are super-rational and there are many of them, we should just pack and go, it doesn't work.
18:02 < killerstorm> What am I missing
18:02 < maaku_> and incidentally, i have an ignore bit to the topic until that is done :P
18:03 < petertodd> adam3us: it's a "dead end" only because I've shown that you don't need to go any further with the theory; I solved the problem modulo invasive censorship like whitelists, or P2SH^2 v2.0 - and that isn't very likely to get implemented
18:03 < petertodd> killerstorm: 0.6BTC isn't enough because the work done to get all that reward is done and there's a valuble return
18:03 < adam3us> petertodd: yeah i already figured out the stego and kept it to myself :)
18:04 < petertodd> adam3us: heh, did you figure out the timelock crypto version of it?
18:04 < petertodd> killerstorm: for the miners if they don't reorg and keep trucking they get to keep the block rewards that are already there
18:04 < jtimon> petertodd parasitism is more secure and unstoppable, fine, who cares? it doesn't scale MSC can't do the things willet wants atscale with parasitism, at some point you will have to tell him that
18:05 < killerstorm> Well, first miners to win a block will pay 0.5 BTC to OP_TRUE, script, second will pay 0.4 BTC and so on. Each one will collect only 0.1 extra BTC, but it is nice and shiny.
18:05 < petertodd> jtimon: which is why my job there is more aimed at making *bitcoin* scale
18:05 < killerstorm> All super-rational miners think in the same way, so they will find a strategy which rewards everybody who are working on the fork.
18:05 < petertodd> jtimon: (we're all lucky they have enough cash around and pr to consider to do things that may not be stricly economically rational)
18:05 < adam3us> petertodd: no, but better.  just publish the key.  i think you do not need consensus on the key because consensus is reached on the ciphertext and its non-malleable.  same argument s committed-tx
18:06 < petertodd> adam3us: publishing the key doesn't guarantee consensus though - the idea being the timelock crypto is to be able to guarantee that
18:06 < petertodd> adam3us: e.g. if the key doesn't get published, and is uncrackable, you'll never know for sure if one isn't waiting to be published
18:07 < jtimon> ok, then I guess I would just ask you to encourge parasitism over altcoinism more openly, not just over MM
18:07 < killerstorm> petertodd: I think you're missing that 6 miners will get rewards through chain which appeared earlier, and 94 miners will get reward through a fork. Basically, 94% of hashpower will work on forking chain in these conditions.
18:07 < petertodd> killerstorm: ok, I see your point, but the problem is there's no way for those super-rational selfish miners to know they're all working on the same fork, and if they aren't, then defection makes sense
18:07 < jtimon> as always, my claim is that MM is better than independent mining
18:07 < adam3us> petertodd: no i mean dead end like focusing all energy ontop of bitcoin may saturate bitcoin tx throughput and hit its scaling limits, and damage crypto currencies generally.  i think there is better scope for innovation if we can focus on uncoupling innovation (btc denominated with pegged side-chain and other with mm alt-chain)
18:08 < petertodd> adam3us: that's a nice concern, but for the individual alt-coin thing they're incentive is still to defect and do what's best for them individually
18:09 < petertodd> adam3us: simple example: I want to timestamp a document. Why do I care about the "bitcoin environment" when I just want to easily timestamp something and my desire not to lose the timestamp is worth more than the tx fee to bloat the UTXO set?
18:09 < adam3us> petertodd: yes but even selfishly there is interest to succeed.  mking bitcoin fail and going down with it is not useful to either the meta-coin nor bitcoin
18:09 < jtimon> and I don't think "MM is better than independent mining" is the message that people perceive from bitcoin devs
18:10 < petertodd> adam3us: meh, if you were right then peopel would never pollute, but they do
18:10 < andytoshi> petertodd: it might be interesting to think about an alt with a fixed 1-coin reward, and which capped miner fees at, say, 0.05 coins (and the rest would be destroyed)
18:10 < petertodd> adam3us: remember, we've got anonymous systems here where social pressure doesn't work very well
18:10 < jtimon> people somehow perceive that "all experts prefer scrypt and quark, it's just that bitcoin is not going to hardfork on that now"
18:10 < andytoshi> capped total fees per block*
18:11 < petertodd> jtimon: depends on what bitcoin devs your talking about - gavin regularly writes about how alts are stupid and harmful
18:11 < jtimon> andytoshi what for?
18:12 < jtimon> petertodd: I know there's not one voice
18:12 < adam3us> maaku_: SPV proofs and pegged sidechain.  yes.  the issue is that you dont really want to rely on as part of the protocol expecting bitcoin validators to follow the side-chain traffic or vice versa
18:12 < andytoshi> jtimon: to change the miner incentives to accept crap in exchange for high fees
18:13 < adam3us> petertodd: yes but it hasnt failed yet.
18:13 < petertodd> bbl
18:14 < andytoshi> jtimon: this would also reduce the potential for fee extortion, since with fees capped at 5% of income there'd be lots of people who simply don't care
18:14 < andytoshi> (this is a far future problem for bitcoin ofc since fees are not even 0.05%)
18:14 < jtimon> 0.05% of total reward to miner?
18:14 < adam3us> killerstorm: your super-rational miner strategy seems plausible
18:15 < andytoshi> jtimon: yeah. (am i wrong?)
18:15 < jtimon> andytoshi I don't know I'm not sure I understand
18:16 < jtimon> if you hash more than 0.05 in fees in a block you only get 0.05 in fees
18:16 < jtimon> but 0.5 will be less and less as inflation increases
18:16 < andytoshi> jtimon: that's right, and any other fees that transactions had included would simply get burnt
18:16 < adam3us> petertodd: you realize he just made the $25k per block fraud shrink a lot?
18:16 < andytoshi> jtimon: right, as will 1.0 (the block reward)
18:16 < jtimon> I think the reward will be eventually too small
18:17 < jtimon> 1.05 will eventually be 0.0000000000000001% of the total supply
18:17 < andytoshi> jtimon: no, currency loss will stop it getting that far i'm sure
18:17 < andytoshi> but i haven't done any detailed analysis to think about how far it will get
18:18 < andytoshi> maybe it will go too low and kill security, i don't know
18:18 < jtimon> oh, I guess you're right, is there any analysis on currency lost? how you do that?
18:19 < andytoshi> jtimon: it's hard to say, numbers exist for physical currency destruction, but that's obviously possible to measure, while cryptocurrency numbers are not
18:19 < adam3us> maaku_:  however there are some factors.  a) bitcoin is still security firewalled (it wont accept coins that didnt come from its chain), b) individual users/miners may choose to full validate; c) atomic swap is the much more frequently used method and that can be full validated; d) spv proven transfer back is liquidity event for imbalanced in demand, and a little bloated.
18:19 < andytoshi> so perhaps you can import the physical numbers as "percent carelessness" and get a swag
18:20 < adam3us> maaku_: e) 100 block confirmation on spv liquidity transfer on merge mine is still quite secure
18:21 < jtimon> adam3us how is any pegging scheme more secure than non-pegged MM ?
18:21 < andytoshi> jtimon: in the absense of demurrage, i don't think it's possible since people can store physical keying material, and that's identical to the network to a lost coin
18:21 < adam3us> jtimon: its not
18:21 < andytoshi> no matter how much magic crypto (eg OWAS) you throw at it
18:22 < andytoshi> but otoh with demurrage, measuring the velocity (which is easy) would give you an estimate of supply
18:22 < jtimon> adam3us and how pegging encourages or facilitates innovation?
18:23 < adam3us> warren: u know re mem hard complexity limits, dan larimer/bitshare/invictus momentum hash (birthday) does actually kind of work and is very fast to verify (modulo a non-catastrophic TMTO) would be interesting to see if the TMTO could be fixed.  see also google for cuckoo hash proof of work
18:23 < adam3us> jtimon: it allows people who are attached to doing things with btc scarcity rather than new scarcity to do so on a different chain and make changes and features that suit their use case.
18:24 < adam3us> jtimon: (rather than for example arguing that bitcoin main should incorporate their changes which imposes dev cost and security risk for btc main and so would tend to be rejected or progress slowly and conservatively)
18:25 < jtimon> I don't quite understand this part "people who are attached to doing things with btc scarcity rather than new scarcity"
18:25 < jtimon> the second sentence seems to apply for both pegged and non-pegged MM
18:26 < adam3us> jtimon: well if they dont care about using btc currency they can do a MM alt-chain with its own distribution params or auxilliary distribution PoW already
18:27 < warren> adam3us: how bad is the TMTO?
18:27 < adam3us> jtimon: i quite like btc scarcity, virtual gold property, capped supply, the supply curve, human policy inflation proof etc.
18:28 < jtimon> what if they do care, and want to experiment but just don't want pegged-MM's inferior security? say they're zerocoin
18:28 < jtimon> btc is still scarce no matter how many altcoins you create
18:28 < jtimon> 21 M at most
18:28 < adam3us> warren: bad enough that some guy claimed $5000 "break the PoW" bounty for demonstrating it would run on a GPU when they thought it would take 750MB per instance.
18:29 < maaku_> adam3us: 100 block wait is not secure. all you need is one global consensus bug and people can start printing money before it is resolved
18:29 < maaku_> it's a non-starter as far as I'm concerned
18:29 < petertodd> adam3us: how did I make what shrink?
18:29 < adam3us> petertodd: what?
18:30 < adam3us> maaku_: they cant print money from btc main perspective, because the SPV proofs have to track back to specific previously moved coins, and that will be allowed only once per moved coin.
18:31 < petertodd> adam3us: momentum (birthday) hashes may work from a theoretical point of view, but like I've said before, from a practical asic hard point of view they don't because they can be implemented with highly specialized content addressable memory techniques
18:31 < petertodd> adam3us: < adam3us> petertodd: you realize he just made the $25k per block fraud shrink a lot?
18:32 < adam3us> petertodd: yeah.  i agree with you.  came to same conclusion - i guess we talked about that a while back. (asic vs memhard).  just curious about the design of them to be memory low verify
18:32 < petertodd> adam3us: as for cuckhoo hashes as far as I can tell where they fail is they are parallizable, and an optimal implementation would be some crazy distributed routing layer ontop of some ram
18:33 < petertodd> adam3us: ah
18:33 < adam3us> petertodd: ah yes.  killerstorm was talking about a super-pragmatic or such miner greed where they could be bribed by paying $25k+10c if game theoretically they knew most of the other miners might do the same thing
18:33 < petertodd> adam3us: yeah, the low memory verify aspect is pretty neat, same with cuckhoo hashes
18:33 < sipa> cuckoo...
18:34 < petertodd> adam3us: right, and I'm saying that game theoretic makes too many assumptions about what information each miner knows each miner knows
18:34 < petertodd> sipa: rarely do you correct my engrish :P
18:34 < maaku_> adam3us: ok /print/steal/
18:35 < maaku_> i really don't think pegging adds much at all
18:35 < petertodd> adam3us: see, what *is* interesting about cuckoo hashes is that the memory *latency* hard part of them looks pretty solid, so in situations where you need a pow and it's not parallelizable, they work great
18:35 < maaku_> most of the interesting alt applications ahve to do with issuing new assets
18:35 < adam3us> jtimon: "what if they do care, and want to experiment but just don't want pegged-MM's inferior security? say they're zerocoin"well its a good example, but it kind of illustrates my point.  green et al seemed to think bitcoin would adopt their protocol.  when it turned out people didnt like the bloat, they were disppointed.  with pegged side chain they could've gone and done it themselves
18:35 < petertodd> adam3us: timelock crypto could be one such example
18:36 < petertodd> maaku_: those new assets are more useful though if you can make contracts exchanging them for bitcoins
18:36 < jtimon> maaku_ apparently it solves a philoshophical problem related to non-scarce scarcity...
18:37 < maaku_> mmm marginally more useful
18:37 < jtimon> adam3us what's wrong with zerocoin not being pegged to btc ?
18:37 < maaku_> not everyone is convinced bitcoin has the right economics to play that role
18:37 < adam3us> jtimon: again with the zerocoin example now with zerocash, they took tht lesson and they're talking about making a zerocash alt coin.  so thts a net loss, probably some bitcoin users would like to be able to get zerocash anonymity for their bitcoin, but with a floating rate and an alt the zerocash might not be much fun to use, nor very secure.  merge mine would be  good step either way
18:38 < jtimon> + 1 for MM zerocash, I don'
18:38 < jtimon> t see how non-peggin is a net loss
18:39 < jtimon> I hope they MM, maybe they prefer to be "anti-specialized-hardware"
18:39 < adam3us> jtimon: not centrally motivating ("philoshophical problem related to non-scarce scarcity.") i agree issued assets are the most useful thing to make smart-contracts interesting.
18:40 < jtimon> again, I don't see the loss of zercoin and bitcoin floating: they're different currencies with different properties, why should they have the same price?
18:40 < adam3us> jtimon: but i think bitcoin is also the most interesting digital scarcity, basically because it got there first, and has the most merchant integration, intrinsic (transactional) value etc, but thats history - its here now, the investors took real risks early to bootstap it and the supply curve is tapering, and its the most secure.
18:41 < jtimon> so this is all about bitcoin winning the race? that sounds greedy...
18:41 < adam3us> jtimon: so given an interest in smart-contracts, issued assets, and bitcoins it seems natural to me that you'd want to be able to do in-chain contracts between those 3 types of things
18:41 < jtimon> what if zerocoin wins, what would the world lose ?
18:42 < jtimon> a nice logo?
18:42 < adam3us> jtimon: hey i missed the first 4yrs 3mo of the race, i'mnot the winner here
18:42 < petertodd> adam3us: re: digital scarcity, so what would you think of a alt-coin using my demurrange + balanced mining ideas for zero inflation, where to get said coins you had to prove a bitcoin sacrifice? that maintains scarcity I would argue, even if where the coins go has different economic structure
18:43 < maaku_> adam3us: we are still way, way early in the adoption curve
18:43 < maaku_> most institutional support for bitcoin is using it as a payment network, not for wealth storage
18:43 < adam3us> jtimon: well if that were the only risk, i'd say go for it, lets see who wins in the market.  but i think the outcome could be worse.  see what if litecoin overtkes bitcoin or gets clsoe... the bitcoin price plummets?  give it a few month and litecoin notice feathercoin is gaining fast, do that a couple of times and the even concept of digital scarcity could be irrepairably damaged, it might go in the history bookss like a digital tulip.
18:44 < killerstorm> petertodd: Well, I don't know much about game theory, but here's how it might work in practice: suppose somebody makes a patched version of bitcoind which implements this kind of a strategy, let's call him a-bitcoind. Miner Bob can see that if everybody upgrades to a-bitcoind, but he doesn't, then his payouts will be lower. If we assume that miners think identically, they will either all upgrade to a-bitcoind, or keep using bitcoind.
18:44 < maaku_> adam3us: if that happened, who would be hurt? people sitting on bitcoins, but not the institutional players
18:44 < maaku_> they make their money (counted in fiat) on activity not market caps
18:45 < adam3us> maaku_: humanity because digital scarcity is a useful thing
18:45 < petertodd> killerstorm: right, but we *can't* assume miners think identically, and neither can those miners
18:45 < jtimon> adam3us this is not logic: if litecoin gets greater than bitcoin, feathercoin will get greater then litecoin
18:45 < justanotheruser> Proposal for distributed storage without polluting the blockchain in a few sentences: There is a web of trust to choose mediators trusted mutually between the uploader and the host. The uploader send the file to the hosters and the mediators after making a tx that gives a small amount to the hoster given that either the uploader signs it, or M of N mediators sign it. The mediators take hash(random nonce0,file), hash(random 
18:45 < killerstorm> petertodd: and, again, in practice, a-bitcoind might leave a certain mark in coinbase transaction which identifies it. but I'm not sure if we can use it in game-theoretic model as that mark can lie.
18:45 < maaku_> meh i don't think that makes sense as an economic argument
18:45 < jtimon> and the two propositions are very unlikely independently
18:45 < adam3us> jtimon: point is it sets a precedent
18:45 < petertodd> killerstorm: you can make mechanisms for those miners to *co-ordinate* their actions, e.g. soft-fork majority upgrade mechanism, but when you're talking about delibrate re-orgs that's much tricker
18:46 < jtimon> I think that's likely to happen, but with something better than bitcoin, not litecoin
18:46 < jtimon> bitcoin 2.0 if you like
18:46 < jtimon> and I don't have any problem with that
18:46 < petertodd> justanotheruser: bootstrapping your mediator trust is a damn nightmight
18:46 < petertodd> *nightmare
18:46 < maaku_> adam3us: your argument hinges on the thing overtaking bitcoin being "just another" coin
18:46 < maaku_> i see no rational basis for that ever happening
18:46 < adam3us> petertodd: exodus eh?  did u see there was one proposed recently a new alt, like mastercoin except by proof of burn?
18:47 < maaku_> but if something came out genuinely better, the story would be different
18:47 < petertodd> adam3us: yup, last I checked they got like 500 coins
18:48 < adam3us> jtimon: markets doing work based on propositional logic, but by herd behavior and economic decisions and a large port of psychology and emotive reaction of individuals
18:48 < justanotheruser> petertodd: Any solutions for bootstrapping mediator trust?
18:48 < petertodd> justanotheruser: solve that and you're halfway to making a crypto-currency...
18:48 < adam3us> petertodd: holy moly 500 btc !
18:48 < petertodd> adam3us: probably even more now :/
18:48 < petertodd> adam3us: not much source-code to it either...
18:49 < justanotheruser> petertodd: couldn't you bootstrap your mediator trust by making non-mediator transactions successfully?
18:50 < jtimon> adam3us so since markets are irrational, it is more rational to peg them?
18:50 < adam3us> maaku_: yes litecoin & ftc are currently not plausible to overtake, but warren does try to do innovation, and maybe eg if btc-china had started pushing ltc while it was 60% of market volume (charlie & bobby lee being brothers) or some new feature is added to litecoin (say zerocash).. who knows
18:50 < petertodd> justanotheruser: define "successfully", and for that matter, how are you going to prove they were successful in a mathematical way?
18:50 < adam3us> petertodd: counterparty that was what it was called (the msc-like meta coin  with PoB)
18:51 < justanotheruser> petertodd: I don't understand what you mean. It is a web of trust like bitcoin-otc. Success is defined by trusted people trusting you.
18:51 < maaku_> adam3us: again, if warren turns litecoin into a genuine improvement over bitcoin, then there is no reason the world need collapse if it overtakes bitcoin
18:51 < petertodd> justanotheruser: where's the root of trust?
18:51 < petertodd> adam3us: yeah, counterparty
18:51 < justanotheruser> petertodd: you are the root of trust for yourself
18:52 < adam3us> jtimon: the peg is just a firewall mechanism between two versions of what would be by intent the same coin.  it could be applied to any alt-coin.
18:53 < petertodd> adam3us: https://blockchain.info/address/1CounterpartyXXXXXXXXXXXXXXXUWLpVr <- 1,165 BTC now
18:53 < adam3us> maaku_: i think that would be challenge.  i am not sure how people would react.  maybe they just take it as competition and say great the new better bitcoin
18:53 < petertodd> adam3us: that's actually more than msc got in dollar value
18:53 < maaku_> adam3us: it is a cool concept. it has applications if it could be made safe enough to deploy, which it is not yet. but i don't thik it does everything you think it does
18:53 < adam3us> petertodd: amazing.
18:53 < adam3us> petertodd: i know!
18:54 < maaku_> wait, did people just irrecovably destroy $1MM of coins?
18:54 < petertodd> adam3us: gonan be a lot of disappointed people I suspect...
18:54 < petertodd> maaku_: yup
18:54 < adam3us> maaku_: yes
18:54 < maaku_> w. t. f.
18:54 < justanotheruser> I wish people would use OP_RETURN
18:54 < petertodd> maaku_: based on a few hundred lines of code and a shoddy specification...
18:54 < justanotheruser> seems like it is from "XPC Proof of Burn"
18:55 < adam3us> maaku_: well from their perspective its still a comparable investment as msc they are investing in the future potential of the idea
18:55 < adam3us> maaku_: the only difference being xcp has now no btc to fund development
18:55 < petertodd> justanotheruser: heh, original counterparty burn tx's used OP_RETURN to embed a *message* and the coins were still burnt to a address
18:55 < maaku_> and yet we've been able to find just 3 people to donate <$1000 to freimarkets :\
18:56 < jrmithdobbs> i don't even want to think about how much the coins i sold at various points would be worth right now
18:56 < adam3us> maaku_: its a sad fact that scammy/grandiose advertising works seemingly in crypto currency space.
18:56 < justanotheruser> petertodd: how were they burnt to an address? No public key can spend them can they?
18:56 < petertodd> justanotheruser: it's a vanity address with like 12 X's in it... rather unlikely they have the sec key
18:57 < adam3us> petertodd: i thought at one point they burnt them to miner until someone pointed out a miner could mint unlimited coins
18:57 < petertodd> adam3us: ha, I know eh
18:57 < petertodd> adam3us: someone mentioned my announce/commit scheme at one point, but as I said to them, using an address has a lot of advantages re: advertising
18:57 < justanotheruser> petertodd: OP_RETURN?
18:58 < petertodd> justanotheruser: https://blockchain.info/tx/685623401c3f5e9d2eaaf0657a50454e56a270ee7630d409e98d3bc257560098
18:58 < justanotheruser> petertodd: oh, multiple outputs
18:58 < petertodd> justanotheruser: yup
18:59 < justanotheruser> what is the usual reason for their proof of burn?
18:59 < petertodd> justanotheruser: what do you mean?
19:00 < adam3us> maaku_: "3 people to donate <$1000" i a not sure what this says about the crypto currency market.  seems like so far its telling us that scamcoins and crazy but high PR things get the most money.  if the market keeps voting that way an the money is used accordingly (ie nothing good morphs out of bad money) ... hmm depressing
19:00 < jtimon> maaku_ adam3us re not the end of the worl: specially if litecoin was MM
19:00 < adam3us> jtimon: but its different PoW
19:01 < maaku_> adam3us: yeah, depressing :(
19:01 < jtimon> yeah, I mean assuming it was a SHA256 improvement instead of a scrypt one
19:01 < adam3us> petertodd: do something good with msc money to restore our faith in humanity :) please!
19:01 < killerstorm> people regularly ask me how to buy colored coins, I have a hard time telling them that it's impossible :). they do this much research before "investing"...
19:01 < petertodd> adam3us: don't worry, going to vegas with my first paycheck to find some strippers
19:02 < maaku_> pics or it didn't happen
19:02 < petertodd> killerstorm: lol
19:02 < jtimon> re: 1M usd destruction it would be funny if the guy said "it was a joke"
19:02 < petertodd> jtimon: the guy is anonymous
19:02 < maaku_> killerstorm: that sounds like every investor conversation Jorge and I have had (save one, maybe something will come of that)
19:02 < jtimon> petertodd does it make it less funny?
19:03 < petertodd> jtimon: it makes it more plausible
19:03 < petertodd> jtimon: well, more likely
19:03 < maaku_> he sure as hell is going to stay anonymous now
19:03 < adam3us> petertodd: did someone look at the code of xcp? it claims to actually have stuff working?
19:03 < maaku_> adam3us: honestly the crypto currency investment market reminds me of Lemmings
19:04 < petertodd> adam3us: I did, not much too it
19:04 < killerstorm> BTW is anybody interested in reviewing design/implementation of colored coin client (NGCCC aka ChromaWallet)? We don't have people who are familiar with bitcoin clients in our team, I just want to confirm we aren't doing something stupid...
19:04 < adam3us> maaku_: i think there is a lot of dumb money.  people who got lucky with various mining/buying things and are not considering it real money
19:05 < warren> adam3us: maaku_: I'm open to diverging more from bitcoin.  it just isn't clear what are the good ideas at the moment.
19:05 < killerstorm> We can probably allocate some bounty for it (review).
19:05 < warren> adam3us: maaku_: meanwhile litecoin has mainly been useful in discovering bugs that are in bitcoin
19:06 < adam3us> warren: could try zerocash but integrated in the way zerocoin was planned if you like being a canary
19:06 < warren> adam3us: the original zerocoin?
19:06 < maaku_> adam3us: unfortunately that pool of dumb money will eventually empty itself on mostly useless projects :(
19:06 < maaku_> there's some other interesting ones out there
19:06 < adam3us> warren: well u recall that it was a trustless mix attached to the block chain
19:06 < maaku_> but quality of the project seems to be inversely proportional with funds received
19:06 < jrmithdobbs> maaku_: nah that's not the sad part
19:07 < warren> adam3us: I'm actually very interested in P2SH^2 and something like p2pool in the standard client
19:07 < warren> adam3us: I don't like data storage in the blockchain and mining centralization is a long-term existential threat.
19:07 < killerstorm> Oh, BTW, is anybody working on cryptocurrency which uses something other than ECDSA?
19:07 < adam3us> warren: whereas now that bitcoin said "nah too heavy" with zerocash which is actually light enuf to be sensible, they're taken the msg that they will create an alt instead.
19:07 < maaku_> warren: be careful the trapdoor in zerocash though... not ready for prime time imho
19:07 < jrmithdobbs> maaku_: the sad part is that it's self fullfilling and there doesn't seem to be a way to break the chain, it's like people actually actively attempt to invest in the worst ideas in the space because they think they have intuition for the system they're buying into when they really have no fucking clue what's going on
19:07 < warren> maaku_: I'm aware
19:08 < maaku_> killerstorm: we're eventually going to add schnorr and laport signatures
19:08 < jrmithdobbs> maaku_: but maybe i'm just jaded :)
19:08 < adam3us> killerstorm: gmaxwell investigated using EdDSA as a bitchoin
19:09 < adam3us> killerstorm: new sigtype which is schnorr and so has some nice features (compact k of n sig, blind sig)
19:09 < jtimon> maaku_ lol lemmings
19:09 < warren> Is the latest thoughts on P2SH^2 written anywhere?
19:09 < warren> I lost my IRC logs.
19:09 < adam3us> maaku_ warren: yes the setup time trapdoor is a problem someone has to be trusted to delete it
19:09 < justanotheruser> maaku_: I think it's already been implemented, it's just not public
19:10 < killerstorm> maaku_: I think it would be interesting to implement optional upgrade-to-lamport. I.e. script references both ECDSA pubkey and Lamport pubkey, normally only ECDSA pubkey is used, but optionally if ECDSA is broken :), one can use Lamport pubkey without revealing ECDSA pubkey
19:10 < adam3us> warren: if you dislike centralization and have not much SPV clients? you could consider committed-tx experiments
19:10 < petertodd> warren: I can send you my logs
19:11 < maaku_> killerstorm: that would be perfectly doable using multisig
19:11 < warren> adam3us: regarding zerocash, even if it is efficient in terms of blockchain bloat, I am concerned about the regulatory implications.  The current situation with bitcoin less-private-than-case-even-with-coinjoin might strike a good balance of needed transactional privacy with the need to prevent unfettered criminal uses.
19:11 < adam3us> warren: i agree mining centralization is bad.  committed-tx is an attempt to have user polic choice even with quite high centralization by denying miners information with which to make policy on
19:12 < warren> less-private-than-cash
19:12 < adam3us> warren: yeah the risk is not lost on me.  hence "if you want to be a (regulatory) canary"
19:12 < maaku_> you'd accomplish this by sighash extension, so the signature itself specifies which scheme is used (of course it would have to match the pubkey)
19:12 < petertodd> adam3us, warren: committed txin may be even more interesting along those lines
19:12 < warren> adam3us: mastercoin is asking to be a regulatory canary
19:13 < warren> adam3us: I think centralization should be a top priority, it is an existential threat.
19:13 < maaku_> killerstorm: lamport sigs are big ... even in a post-quantum world i think we'd still use elliptic curves
19:14 < warren> centralization is *THE* existential threat
19:14 < petertodd> warren: +1
19:14 < adam3us> warren: btw i think its not as clear cut as all that.  you can make different privacy tradeoffs by choice.   zerocash is a building block as much as ecdsa.  you could have fungible coins with new "wallet addresses" that have a similar payment level linking as today.
19:15 < adam3us> warren: sign me up no that call too "centralization = existential threat"
19:15 < warren> petertodd: I'd like logs covering all the recent P2SH^2 discussion
19:15 < adam3us> warren: which i think is a quite interesting tradeoff.  no more private than current, but fully fungible.  (coinvalidation falls on its face)
19:16 < warren> is zerocash's design published?
19:16 < maaku_> warren: no
19:16 < adam3us> warren: ie current privacy at payment level, but fungible/anonymous at coin level.  so if you trade a bad actor you ask them to reimburse you but you cant freeze the coin
19:16 < petertodd> warren: sent
19:17 < adam3us> warren: gmaxwell knows more about it (zerocash)
19:18 < adam3us> warren: also there was a podcast recording of matthew green talk on it at real world crypto conf, can google for
19:18 < killerstorm> maaku_: I think the idea is to have something as a backup IF shit hits the fan. E.g. if ECDSA vulnerability is discovered, people can use Lamport signatures temporarily, and then hard-fork upgrades cryptocurrency to something small and safe.
19:19 < adam3us> warren: you could always build holes to plug it into, then wait for zerocash to release their code & link in the library
19:19 < warren> IMHO, I rather focus entirely on the centralization existential threat.
19:19 < warren> That's uncontroversial.
19:19 < adam3us> warren: ok.  see if u can do something with committed tx.
19:20 < adam3us> warren: are you willing to complicate SPV model to do it?
19:20 < petertodd> killerstorm: you realize that lamport sigs are implementable easily in even bitcoin's original scripting system right?
19:20 < petertodd> killerstorm: not possible now that op_cat is disabled, but it doesn't take much
19:21 < killerstorm> Well, how do you hide ECDSA pubkey?
19:21 < Luke-Jr> meh, "disabled" really means "removed" in this context :/
19:21 < warren> adam3us: it depends, need to read all the current thinking on committed tx.  is this written down anywhere?
19:21 < petertodd> Luke-Jr: yup
19:21 < warren> adam3us: I really dislike the current way SPV is done.
19:21 < jrmithdobbs> petertodd: ya well the disabled ops have enough to implement salsa/chacha too (inefficiently and insecurely)
19:21 < jrmithdobbs> heh
19:22 < petertodd> jrmithdobbs: well, scripts are limited to 10,000 opcodes so... probably not, lamport however is practical within the limits (modulo disabled ops)
19:22 < petertodd> warren: what do you want changed re: SPV?
19:22 < adam3us> warren: sort of but not really cleanly  bct thread https://bitcointalk.org/index.php?topic=206303.0 ask if it doesnt make sense
19:22 < jrmithdobbs> petertodd: i think that's still true for at *least* chacha with the real limits
19:22 < killerstorm> Ok I guess it isn't hard to hide it...
19:22 < jrmithdobbs> petertodd: not that anyone should do so, ever
19:22 < maaku_> warren: anti-centralization is uncontrovertial. some of the side effects of relevant proposals are worrisome on the other hand
19:23 < petertodd> killerstorm: "can implement lamport" is probably a good minimum test for whether or not your scripting system is general enough!
19:23 < maaku_> there's no clear cut path forward which decentralizes the network without tradeoffs
19:23 < warren> petertodd: 1) easy to MITM 2) easy to determine which keys you have 3) no way of doing authenticated peerings 4) expensive to the server
19:24 < petertodd> warren: right 1) committed (U)TXO  2) all the lessons in my blockchain privacy paper  3) add SSL or SSL-alike  4) prefix-filters w/ appropriate indexes
19:25 < warren> maaku_:  multiple competing scalable p2pool-like things with a trustless accumulators and more GBT pools would be low hanging fruit
19:25 < petertodd> warren: electrum actually is reasonably close to solving all that, modulo committed indexes
19:25 < warren> petertodd: yeah
19:25 < adam3us> petertodd, warren: prefix have worse privacy properties than bloom.
19:25 < petertodd> warren: problem is we have to make it *more* profitable to mine with p2pool/decentralized, and that's going to require changing economics
19:25 < maaku_> petertodd: well, Thomas is waiting on me for the indices
19:25  * maaku_ gets back to work
19:25 < petertodd> adam3us: depends on your attack model
19:26 < petertodd> adam3us: again, did you read my paper? :P I strongly think in practice with real users prefix has better real-world privacy
19:26 < adam3us> petertodd: broadcast vulnerable info is like worse because it can be analysed later by anyone, vs sent to one random node
19:26 < adam3us> petertodd:  i did, i just disagree.
19:26 < petertodd> adam3us: well, least you read it finally, ha
19:26 < warren> petertodd: the lower orphan rate should help.  currently the too-many-txo's in coinbase is a problem.
19:26 < adam3us> petertodd: yeah i skimmed it before also.  as i recall gmaxwell has the same view as me on that risk.
19:27 < warren> petertodd: the trustless accumulator should help that
19:27 < petertodd> adam3us: problem is bloom naturally leads to a situation where people broadcast the *exact* contents of their wallets over and over again to random peers, and that's just nasty
19:27 < petertodd> adam3us: android wallet has 1 in 16k specificity for a reason - users want fast syncs
19:27 < petertodd> adam3us: that could really kill coinjoin the moment attackers start running SPV nodes to collect wallet data
19:28 < petertodd> warren: no it won't - it still requires all the expense of running a full node
19:29 < adam3us> petertodd: they are both non ideal solutions.  it is considered in privacy that you should pick a random node and stick to it.  if its going to analyse you it already did.  if you explore random nodes eventualy you'll find a hostile one.  tor doesnt do this yet either, but theyre planning to fix it.
19:29 < petertodd> adam3us: anyway, prefix *queries* are a categorically better model than bloom filters from the point of view of lookup privacy
19:29 < adam3us> petertodd: that might be.  also electrum is like central/trusted type of solution right?
19:30 < petertodd> adam3us: now forcing your txouts to match prefixes may or may not be the right approach, but only prefix queries lets you distribute the load, and thus query specificity leak, accross multiple nodes
19:30 < petertodd> adam3us: electrum is not different from bloom SPV in principle
19:30 < petertodd> adam3us: in practice maybe more secure in some models because there are fewer electrum servers
19:30 < petertodd> adam3us: and their operators are better known
19:30 < adam3us> petertodd: but in practice, i thought electrum have a few central servers
19:31 < petertodd> adam3us: meh, picking random nodes and sticking to them isn't very feasible without a "small number of nodes run by volunteers" model
19:31 < adam3us> petertodd: yes if u trust electrum.  the other model as said above, pick a random node and try to stick to it.
19:31 < petertodd> adam3us: and even in that model you're better off with prefix queries
19:31 < petertodd> adam3us: electrum *is* the pick a random node and stick to it mdoel
19:32 < adam3us> petertodd: well its electrum advertising them selves as a trustworthy node.  sometimes that is a flag to say dont trust them.
19:32 < petertodd> adam3us: anyway, my prefix solution may leave some statistical data in the chain, but it has the enormous advantage that it doesn't fail hard the moment an attacker does a sybil attack. it also doesn't give that attacker a reason to do that sybil attack
19:33 < petertodd> adam3us: note how prefixes gives you decent security even *if* you're connected to the nsa
19:33 < warren> We could just forget about SPV, finish ultraprune and stop worrying about this.
19:33 < adam3us> petertodd: if u use prefix with one-use addresses t seems ok no?  no need for explicit prefix
19:33 < petertodd> adam3us: (prefixes + addr grinding)
19:34 < petertodd> adam3us: no! unless your addresses in your wallet are clustered around a prefix, for a given amount of bandwidth you have to have very specific prefixes and thus are leaking a heck of a lot of data
19:34 < CodeShark> what's the prefix solution? using the first few bytes of a pubkey or script hash rather than a bloom filter?
19:34 < petertodd> warren: ultraprune doesn't help with bandwidth
19:34 < petertodd> CodeShark: yeah, there's two parts to it, first for queries you can always query by prefix
19:34 < adam3us> petertodd: could be block range constrained + closeness metric to tune like bloom
19:35 < petertodd> CodeShark: secondly you can always force your addresses in your wallet to *all* be clustered around soem prefix, which means you only have to do a single query
19:35 < petertodd> CodeShark: the beauty of the latter is even if you're querying the NSA for blockchain data they learn very little about what's in your wallet, the disadvantage is you leak *some* stat information to the blockchain permanently
19:35 < adam3us> petertodd: yeah but then you're back to broadcasting anon-set reducing info to the block chain for the stats analysis guys to party on.
19:36 < petertodd> CodeShark: I argue leaking some all the time is much better than leaking your exact wallet contents the moment you manage to connect to the NSA
19:36 < petertodd> adam3us: the types of people who have the resources to do stats analysis have the resources to just run 50% of the available nodes to connect too
19:36 < adam3us> petertodd: if you query the NSA with a prefix, they learn the anon-set you are in.  just info o help triangulate you no?
19:37 < adam3us> petertodd: eh no?  academics do it for like 3rd year project
19:37 < petertodd> adam3us: I mean, shit, I was running about 10% of all public nodes for a few hours to test an attack
19:37 < petertodd> adam3us: yeah, all they learn about is the prefix, and then the stats leaks stops
19:37 < adam3us> petertodd: oh ok, u mean on the low side, gotcha
19:38 < petertodd> adam3us: vs. without prefixed addresses *in reality* users set very specific prefix/bloom filters, and then you leak very specific contents of your wallet
19:38 < adam3us> petertodd: but a bloom filter with some decent params can do that also no?
19:38 < petertodd> adam3us: yeah, from the point of view of "clustered wallet addresses" bloom and prefix are identical
19:38 < CodeShark> petertodd: right now with BIP0032, you can have at most 2^31 different keys from a particular master seed - so say you use  k bit prefix - that reduces the number of keys to 2^(31 - k), no?
19:38 < adam3us> petertodd: so say TD fixed improved the params
19:38 < petertodd> adam3us: if you're not clustering wallet addrs, bloom and prefix are identical, it's just the latter is way more scalable
19:39 < jtimon> petertodd is there any reason why you can't use several prefixes in your wallet? more bandwith but more privacy
19:39 < jtimon> ?
19:39 < petertodd> CodeShark: well BIP32 has problems there
19:39 < petertodd> adam3us: it's impossible to fit the params, it's a specificity/bandwidth tradeoff
19:39 < petertodd> adam3us: s/fit/fix/
19:39 < jtimon> say, use 3 prefixes, n instead of 1
19:39 < petertodd> adam3us: if you think params has anything to do with it you didn't understand my paper...
19:39 < adam3us> petertodd: bloom/prefix similar with no addr clustering... yes.
19:39 < CodeShark> perhaps we should expand the BIP0032 child index to 64 bits :)
19:40 < petertodd> jtimon: more prefixes *of the same length* just means you're using more bandwidth
19:40 < petertodd> jtimon: remember this is a bandwidth/anonymity set tradeoff
19:40 < adam3us> petertodd: you claimed the default params were too specific, so make them les so, while still tolerable bw.
19:40 < petertodd> adam3us: the reason why they are so specific is because users aren't tolerating more bandwidth
19:40 < jtimon> petertodd yes, my point is you can make the tradeoff configurable
19:40 < petertodd> jtimon: yes, and you can do that with prefix clustering too
19:40 < CodeShark> petertodd: I'm also thinking about how deterministic m-of-n script chains could work with this prefix model
19:41 < adam3us> petertodd: well more importantly u also said as i recall there was no feature to change the params
19:41 < jtimon> yes, yes, with prefixes
19:41 < petertodd> jtimon: the fundemental problem is that if you don't cluster all your addresses in one prefix or bloom index, then naturally you have to have fairly specific filters, which overtime become more specific and let you be attacked
19:42 < petertodd> adam3us: in the library and wallets no, but the bloom filter specification does let you change the params easily by making the filter smaller
19:42 < petertodd> adam3us: smaller filter == less specific
19:42 < CodeShark> there is in my library :)
19:42 < petertodd> CodeShark: good
19:42 < jtimon> but with prefixes, can't you just ask for more info than you need?
19:42 < petertodd> jtimon: that's the whole point of prefixes!
19:43 < jtimon> I know, more bandwidth
19:43 < petertodd> jtimon: gah, have you read that paper of mine?
19:43 < jtimon> my point is I don't see the bad side, with prefixes you can have the best privacy of them all at the cost of bandwith
19:44 < petertodd> jtimon: ah, well, that's why I'm pushing the idea :) sounds like we're in agreement
19:44 < jtimon> sorry, no
19:44 < petertodd> jtimon: you should, because everyone loves debating this without actually reading the damn thing and why I think it's worth making these tradeoffs
19:44 < petertodd> jtimon: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03612.html
19:45 < petertodd> I mean, hell, it's paragraph three where I outline that my threat model is an attacker controlling a reasonable number of the nodes you're SPV client is going to connect too... which is a *very* reasonable attack model.
19:46 < petertodd> Again, saying this because I've actually done this personally by throwing some cash at Amazon EC2
19:46 < jtimon> yes, I don't understand adam's objections, yet I don't know what's the alternative, but yes, as said earlier to adam you shouldn't bother much explaining me this because I haven't read steakth addresses yet, really my fault for trying to follow again, sorry
19:46 < petertodd> jtimon: thanks
19:47 < CodeShark> jtimon: there's so much stuff going on in this space right now you'd be excused for not reading absolutely everything :)
19:47 < adam3us> petertodd: btw backing up a bit time-lock and stego, i dont think consensus is affected by unavailibility of the key, and the key can be encrypted for the recipeint and stored in the block chain
19:47 < petertodd> adam3us: no, the recipient is the public
19:47 < adam3us> petertodd: so then its  simple matter if people do not reveal the key, they cant respend
19:47 < petertodd> adam3us: that's got nothing to do with it
19:48 < CodeShark> the recipient's key is already a hash of a pubkey
19:48 < adam3us> petertodd: yes for your other use case.  but then make it available from all nodes (its validatable against the ciphertext)
19:48 < petertodd> adam3us: the problem is that miners who know a tx is part of some consensus scheme may want to censor the tx and not mine it, yet the tx data *must* be guaranteed to be made public to everyone for a consensus scheme to work, thus, use timelock to force miners to either delay *all* transactions, or give up trying to censor
19:48 < jtimon> CodeShark yes, that's why I was "passing on stealth addresses for now", as a filter, but then I shouldn't try to follow the discussions about it intervening in them
19:49 < petertodd> adam3us: there is no way to prove publication unless you can guarantee that the data can be decrypted
19:50 < CodeShark> whether or not keys are encrypted has no effect on privacy as long as the keys (encrypted or not) can be associated with a wallet
19:50 < adam3us> petertodd: i guess you are assuming a network where 90% of miners and nodes hate msc spam and want to kill it ;) so then you cant rely even on relaying and it maybe difficult to find a node with the key?
19:50 < petertodd> adam3us: consider a key:value(s) consensus system: if it's just encrypted, I could hold onto the key, then release it after the fact, changing the consensus suddenly
19:51 < petertodd> adam3us: that's the whole fucking point of it: how to make an embedded consensus system that's uncensorable unless miners implement whitelists
19:51 < petertodd> adam3us: of course I'm assuming that - if I wasn't it wouldn't be much of a result
19:52 < petertodd> adam3us: I mean, hell we've got an existance proof that if only some miners hate you you can still get your tx's mined...
19:53 < adam3us> petertodd: ok then; it a bit slow tho time-lock.  maybe you can find a subnet of msc-relaying nodes
19:54 < petertodd> adam3us: well sure, but that's not unlike making the block time longer - perfectly acceptable for a lot of applications
19:55 < petertodd> adam3us: I'm not claiming mastercoin should go and implement it right now - I'm pointing out that they could
19:56 < adam3us> petertodd: yep.  i have some more stego end-game ideas.  still holding them back :)
19:56 < adam3us> petertodd: meaning i dont disagree the steganographer wins. in the en game
19:57 < petertodd> adam3us: meh, do everyone some good and just publish them so people stop making shitty assumptions about scalability
19:58 < adam3us> petertodd: they are not so interesting, just silly things you could do if you had to (if bandwidth was no obstacle).  you probably already thought of them.
19:59 < petertodd> adam3us: ah, well if they're less efficient don't bother
20:00 < petertodd> adam3us: anyway, the interesting thing is how to make crypto-currencies where utxo bloat and so on doesn't matter, and I think we're close to solving that pretty thoroughly
20:00 < adam3us> petertodd: cant u get get consensus by time-stamping and using a separate msc-only network for the data?
20:00 < petertodd> adam3us: consensus isn't just time-stamping
20:01 < petertodd> adam3us: proof-of-publication matters, and it's really not trivial
20:01 < petertodd> adam3us: heck, maybe there is no general solution to it
20:01 < adam3us> petertodd: well i mean if you tolerate jamming.  just have nodes stop if they cant obtain a full explanation of the time-stamp merkle tree.
20:02 < petertodd> adam3us: the point of proof-of-publication is to tolerate jamming you know...
20:03 < adam3us> petertodd: hmm so you want to send the (time-lock) encrypted msg in the chain because then its atomically delivered so either you get it or you dont.
20:03 < petertodd> adam3us: frankly I think many in the bitcoin community are letting their desire to keep data out of the chain blind them to how fucking hard it is to make these things secure
20:03 < adam3us> petertodd: stego wins.  i know it :)
20:04 < adam3us> petertodd: even if you have to use like morse code in the lsbit!
20:04 < petertodd> adam3us: it's not about "stego winning" - it's that people keep pushing MM and similar schemes not because it's better for the consensus system in question, but because it's better for bitcoin
20:05 < petertodd> adam3us: and whenever those consensus schemes take that advice, we bitcoin devs fool ourselves 
20:05 < adam3us> petertodd: oh diff meaning.  ok well given the scalability limitations, absent a robust scalability fix, as you said sharding seems better.  so a MM chain is a crude form of sharding.  if security is important buy some kncminers to tip the balance.  or work on educating users to not use big pools etc.
20:05 < petertodd> adam3us: and you know, unless you honestly look at the incentives and attacks possible, you're not going to come up with MM schemes that *actually* work
20:06 < adam3us> petertodd: sure.
20:06 < petertodd> "educatiing users" fuck off
20:06 < petertodd> we've got a system where you *earn more money* mining at a big pool
20:06 < petertodd> that's fundemental to how bitcoin works and isn't going to change
20:06 < adam3us> petertodd: there are other ways to "educate" users you know.  that may require tor for the educators safety...
20:07 < petertodd> adam3us: all solutions that don't help *decentralized consensus systems*
20:07 < adam3us> petertodd: i wonder if any o fthem are selfish mining
20:07 < maaku_> petertodd: currently, you earn more money mining p2pool...
20:07 < petertodd> maaku_: not if you take your time into account for many miners...
20:07 < adam3us> maaku_: yes.  this is very puzzling to me.
20:07 < adam3us> petertodd: but its just as easy to pick p2pool from the list
20:08 < maaku_> adam3us: you don't pick p2pool from a list, you run a local daemon
20:08 < petertodd> maaku_: like it or not we probably have to get to the point where pools *can't* exist, and simultaneously fix scalability
20:08 < maaku_> but i've found it to be very stable at least
20:09 < adam3us> maaku_: i htought one of the miners i tried seemed to support p2pool out of the box (if it ran a daemon itself maybe)
20:09 < maaku_> petertodd: i like getting rid of pools. i don't like the negative side effects i've seen come attached to such proposals
20:09 < petertodd> adam3us: did you have a full node? if not you weren't using p2pool
20:09 < adam3us> petertodd: i did yes
20:09 < petertodd> maaku_: meh, just means you have to keep working on the proposals
20:09 < maaku_> adam3us: that'd be great if it does, but it probably just connected to a public p2pool node
20:10 < maaku_> which is really no different than a centralized pool as far as this conversation is concerned
20:10 < petertodd> maaku_: don't think I'm saying I have a perfect solution yet, I'm just saying we're incredibly naive in this community thinking stuff like p2pool is much of a fix
20:10 < petertodd> heh, heck, adam not knowing exactly what his hashing power was doing is a great example of why this is hard...
20:10 < adam3us> warren: maybe in your p2pool fixing budget you could try get a shiny nice UX GPU / ASIC scrypt/hashcash miner that bundles p2pool and makes it the default
20:11 < petertodd> adam3us: meh, that shiney p2pool bundle is an easy thing that people are already working on for free
20:11 < warren> adam3us: p2pool requires high CPU and disk i/o performance to be efficient =(
20:11 < adam3us> petertodd: i think the UX might be the key though.  if someones doing it for fre fine
20:12 < maaku_> warren adam3us: really all you need to do is bundle up a py2exe virtual environment for p2pool with gitian builds of bitcoind and bfgminer
20:12 < petertodd> warren: I set my p2pool node to mine very small blocks for that reason
20:12 < maaku_> let bfgminer --p2pool set up the services
20:12 < petertodd> warren: I think it's set to like 0.01BTC/KB fee or something
20:13 < warren> adam3us: I don't have a p2pool fixing budget, I just made large donations out of pocket to the only person working on the problem to give him more incentive.  I'm not happy that the larger bitcoin community isn't taking the issue seriously, and I'm at my limit of what I'm willing to fund out of pocket.
20:13 < petertodd> warren: and you know, don'
20:13 < warren> adam3us: I paid about $30k out of pocket during 2013 to various people who helped upstream bitcoin or p2pool
20:13 < petertodd> warren: don't get me wrong, that was money well spent, it's just that in the wizards part of the community we should be working on better
20:14 < petertodd> warren: we're supposed to be thinking medium to long term here, fixing p2pool is short to medium
20:14 < jrmithdobbs> petertodd: but the p2pool thing highlights a real problem
20:14 < warren> adam3us: that money came from people who were concerned about litecoin dying entirely due to lack of developers.  I don't expect future revenue potential to be anything like that special case.
20:15 < jrmithdobbs> petertodd: we have functional-enough-for-now technical solution to this, but (practically) noone using it
20:15 < petertodd> jrmithdobbs: yes, that's because it's a tech solution operating in a vacuume, not one that actually takes economics and incentives into account
20:15 < warren> petertodd: p2pool and eligius are attacking the low hanging fruit.  I don't have the cycles or money to attack the long-term issues myself.
20:16 < adam3us> warren: i see.  (re money situ/history).
20:16 < jrmithdobbs> petertodd: but there's noone (very few) willing to pay the people capable of the technical solutions and give them the context
20:16 < petertodd> warren: that's fine, I do for now
20:16 < jrmithdobbs> petertodd: how do we solve that?
20:16 < adam3us> warren: low hanging short term is good too.  people are not even using what they could and yet we are concerned about that as a systemic risk.
20:16 < petertodd> jrmithdobbs: foundations tend to be good at that, but they aren't going to solve that if people don't even accept this stuff is a problem
20:17 < jrmithdobbs> petertodd: or when major players in said foundations deny it's a problem.
20:17 < petertodd> jrmithdobbs: I can hardly even convince people *here* that p2pool isn't a very good solution
20:17 < petertodd> jrmithdobbs: heh, that too
20:17 < jrmithdobbs> petertodd: that's not a solution, that's an admittence of failure, really
20:17 < adam3us> warren, petertodd: which says maybe boring things like user education, nicer UX, more bundling, advertisement are perhaps necessary strange as that seems to a tech mindset
20:18 < warren> adam3us: it's no secret that I've been planning a 501(c)(6) foundation that focuses on development, with issues like centralization as a top priority.  A few big players are interested in funding it.  I've been too busy with my own career to create it.
20:18 < petertodd> adam3us: I don't have a tech mindset remember... I know damn well boring stuff works in the short term, but I'm not foolish enough to think we aren't up against genuine economic perverse incentives
20:19 < adam3us> petertodd: agreed.  but sometimes short-term stupid action gains its own momentum and defacto "way-it-works" that leads to development cementing the stupidity.  so it maybe worth fixing these short-term what-users-are-doing when they coud do better issues
20:20 < jrmithdobbs> kinds are part of the types really
20:20 < jrmithdobbs> err wrong chan
20:20 < petertodd> adam3us: hence why I'm not against people improving p2pool; I'm against people who could use their talents to do even better spending their time on p2pool
20:21 < warren> adam3us: uncontroversial things for the new foundation to tackle: centralization, anti-DoS, anti-sybil, scalability, timestamping tech.  I rather not prioritize regulatory canaries when there are plenty of uncontroversial existential threats.  Others can work other issues.
20:21 < petertodd> adam3us: the people who can do that work can't do consensus system theory (and mostly vice-versa)
20:22 < adam3us> petertodd: yeah maybe  it just pains me to sit around watching needless stupidity create short term network scale risks.  like 40% miners (that can and did to double spend attacks) when there is no sane reason to do it.
20:22 < warren> Go ahead and call me chicken, after centralization is fixed.
20:23 < adam3us> warren: canaries are a special breed.  seemingly matthew green has what it takes :) he claim's he's gonna make an alt out of zerocash.
20:23 < petertodd> adam3us: well like I said, for that issue you've got a hell of an uphill battle... we just to complain about hashers to point their hardware at ghash.io, but the reality is from their point of view there's nothing very stupid about it
20:24 < adam3us> petertodd: actually ghash doesnt charge fees i think.  (like eligius and p2pool) otherwise often the big miners are charging like 5% and people are still using them over eligius or p2pool
20:24 < warren> ghash has other ways to make money (trading commissions...)
20:24 < petertodd> adam3us: I know, that's one of the reasons they're so big
20:25 < warren> If p2pool improved substantially, grew bigger and flexed its orphan advantage it might be able to compete.
20:25 < adam3us> petertodd: but i mean wtf why not put it up to 10% and see if they still stay there? do they even care about money?
20:25 < petertodd> adam3us: and 5% isn't much money - remember that when I talk about pools being "profitable" that includes non-monetary "compensation", as well as lower costs, and less perceived risk
20:26 < petertodd> adam3us: business risk is a funny thing - ghash.io has a perception to maintain
20:26 < adam3us> petertodd: u know there's one with 100% fee (aka it stopped paying out) and it still has significant TH
20:26 < petertodd> adam3us: equally, people's perception of value is often that higher cost == better
20:27 < adam3us> petertodd: i suspect its bigger == better thinking here.
20:27 < petertodd> adam3us: hey, if you look at that and say "WTF?!" rather than "yeah, I can see why" then you don't have the insights to understand this stuff
20:27 < petertodd> adam3us: yeah, well duh
20:27 < adam3us> petertodd: if u have no clue and someone forces you to make a too technical or arbitrary decision, you'll tend to follow what others are doing...
20:27 < petertodd> adam3us: that's why I said above you probably have to create tech where pools aren't just discouraged, but are actively disabled in various ways
20:28 < petertodd> adam3us: yup
20:28 < petertodd> adam3us: having to research the right way to do something is a huge cost
20:28 < petertodd> adam3us: heck, ahving to make choices at all is a huge cost
20:28 < adam3us> petertodd: but 5% eh.  maybe a 50point font mining pool fee % & profit calculator in the miner sw
20:28 < jrmithdobbs> petertodd: you're trying to say that not only do you need to be able to recognize that "bigger == better" thinking but realize that a) it's not necessarily wrong and b) it's ingrained for a reason and isn't something that can be ignored because "people are dumb"
20:28 < jrmithdobbs> pes?
20:28 < jrmithdobbs> yes?
20:29 < petertodd> jrmithdobbs: yeah, all those points.
20:29 < jrmithdobbs> petertodd: just making sure i was understanding your point (and I agree)
20:29 < petertodd> Now if we're willing to accept that, then how do you force pools completely out of existance? I thik it was you adam who was talking about stealable proof-of-work for instance.
20:30 < adam3us> petertodd: yeah thats more intersting (must get off fixating on irritating user stupiity:)
20:30 < petertodd> Similarly, how can blockchains be structured such that p2pool-like varience reduction is a given?
20:30 < amiller> loosen the difficulty restriction
20:30 < amiller> let people choose their own difficulty in some way
20:30 < amiller> that way you can still maintain the overall security invariant
20:30 < petertodd> And, how can we make mining something that you don't need a bunch of setup time and other work to get started in?
20:31 < adam3us> petertodd: i think it was amiller who said it first (stealable PoW) except i thik he was talking reverse ... for hosted mining
20:31 < petertodd> amiller: well, is that diff per-block then or what?
20:31 < amiller> i was talking about both equally, i gave an abstraction where both pools and hosted mining are equally a security violation!
20:31 < petertodd> amiller: or can we split blocks up? how does consensus work?
20:31 < adam3us> amiller: actually the whole pool choses work packet for miner is just wrong thinkin
20:32 < petertodd> amiller: yeah, I'm not sure if I have a solution to hosted mining yet
20:32 < adam3us> amiller: the whole point of hashcash is the user choses their own work packet
20:32 < petertodd> adam3us: yet, just saying that doesn't help :)
20:32 < warren> Lots of the Litecoin users are pushing for a PoW change because they don't want the same thing to happen with ASIC's.
20:32 < petertodd> adam3us: getblocktemplate is the perfect example of just saying that, and look where that's gone
20:32 < jrmithdobbs> petertodd: the only straightforward solutions i can think of require things that don't actually exist
20:32 < amiller> so the block selection function is
20:32 < petertodd> warren: Good!
20:32 < amiller> choose the lbock with largest sum difficulty
20:32 < warren> They're quite naive, suggesting just increasing the scrypt parameters.
20:32 < amiller> that's invariant to difficulty choice
20:32 < jrmithdobbs> but i've not spent much time thinking about hosted mining, ha
20:32 < amiller> the problem with difficulty choice is one of PoW basically
20:33 < adam3us> petertodd: whats wrong with GBT?
20:33 < amiller> er
20:33 < amiller> Dos
20:33 < petertodd> warren: heh, they willling to put money towards researching ASIC-hardnesss
20:33 < petertodd> adam3us: there's no incentive for individual hashers to use it
20:33 < warren> If Litecoin is willing to go through the pain of a hardfork, it better be more interesting than bigger scrypt.
20:34 < petertodd> warren: agreed
20:34 < warren> And I think bigger scrypt is a bad idea, validation is already slow.
20:34 < amiller> you can reject someone's blocks, as part of the rational strategy space
20:34 < amiller> so that can include whether the sum difficulty is over tons of weak blocks or a few bonanza blocks with high diffiuclty
20:34 < adam3us> warren: coelho merkle hash PoW is better.  vitalik used it in dagger for ethereum.
20:34 < amiller> obviously the tons of weak blocks is a DoS
20:34 < petertodd> warren: heh, well, doing birthday-style momentum hash would be as temporarily asic-hard as any scrypt tweak, and with fast validation
20:34 < amiller> but we handle DoS on an ad hoc basis at the moment anyway.
20:34 < adam3us> warren: better in that it uses fiat-shamir to only have to spot check the answer, not repeat the work
20:35 < warren> petertodd: temporarily ...
20:35 < amiller> so how about this
20:35 < amiller> accept a range of difficulties
20:35 < petertodd> warren: sure, but at least the barrier to making an asic with that is fairly high - as I say, it gets you the same kind of barrier than an scrypt tweak would, but with less resoruce usage
20:35 < amiller> but not all the way to nothingness
20:35 < adam3us> petertodd: momentum is not too stupid.  quite TMTOable but other than that.
20:35 < warren> adam3us: <adam3us> maaku_: yes litecoin & ftc are currently not plausible to overtake  <----- huh?  ftc?
20:35 < petertodd> adam3us: define TMTO again?
20:35 < amiller> the bottom-out level is a miner policy
20:35 < amiller> minimum acceptable difficulty i mean
20:36 < warren> adam3us: only thing implausible about overtaking FTC is their centralized broadcast checkpoints
20:36 < petertodd> amiller: but difficulty is related to block interval, and you have to have long enough min block intervals so that consensus still works
20:36 < adam3us> warren: it was hypothetical comparison, nothing specific to ltc/ftc
20:36 < warren> adam3us: petertodd: economically the only way litecoin users would accept a PoW change is if the same miners were the beneficiaries (GPU owners). =(
20:36 < petertodd> adam3us: oh, right, Time Memory Tradeoff or whatever
20:37 < amiller> petertodd, okay so the basic way to handle that is to a) make everyone include stale blocks in some way, like GHOST already recommends and i babbled about on irc a year ago
20:37 < amiller> b) the more stale blocks you accumulate, the more penalty you apply to short spammy blocks
20:37 < petertodd> warren: birthday PoW might be GPU implementable actually
20:37 < petertodd> warren: cuckoo hashing seems possibly to be as well
20:37 < warren> adam3us: is Savitch's theorem relevant at all to this?
20:37 < adam3us> petertodd: TMTO is fine for warren's GPU lovers.  you ned that to run momentum on a gpu anyway
20:37 < amiller> the effect is that you eventually get enough of a bonus to mining at a hard difficulty, which causes the chain to stabilize
20:38 < petertodd> amiller: gah, I really am against this stale block crap - it gives advantages to those with fast network connections
20:38 < adam3us> warren: i am not sure if it is because momentum nearly works and has an extremely efficient verification (consuming no memory)
20:38 < amiller> they have an adavantage anyway
20:38 < petertodd> adam3us: no actually, I was looking at some papers suggesting that GPU's are actually reasonable good at implementing content addressable memories
20:39 < petertodd> adam3us: it's not a TMTO tradeoff in that case
20:39 < adam3us> petertodd: oh nice.
20:39 < petertodd> amiller: yes, but don't make it even bigger, which ghost does
20:40 < amiller> i'm advocating *allowing* it to get bigger for a much more important reason
20:40 < amiller> the only thing ghost claims you can do is marginally increasing the flux of transactions, which is meh
20:41 < amiller> i'm claiming the main benefit to this is getting user-selectable variance *within* the main mining game
20:41 < petertodd> amiller: wait, what getting bigger? orphan rate?
20:41 < amiller> no the advantage to dudes with better network equipment in data centers, ie the amount of data and latency dependence
20:42 < petertodd> amiller: nah, better ways to get user-selectable varience than screwing up those incentives
20:42 < amiller> like what
20:42 < petertodd> amiller: again, why are you assuming a monolithin blockchain?
20:43 < amiller> how else are you going to get user selectable variance
20:43 < petertodd> amiller: do per-tx PoW and figure out how to make that reasonable
20:43 < adam3us> amiller: above are you talking about p2pool?  pooled mining apis in general? variance you mean being able to pick an appropirate to miner pow work size?
20:43 < amiller> small players want to play at lower variance, so yes
20:44 < adam3us> amiller: just because actual low variance can be done via multiple sub-puzzles and redefining work to be the sum of the subpuzzles,however that breaks power-fairness of the PoW for btc style first past post race
20:44 < adam3us> amiller: so u mean low variance in terms of pool shares.
20:45 < petertodd> adam3us: ifthe sub-puzzles earn you money linearly, that doesn't break fairness
20:45 < amiller> it doesn't break power fairness, it does have a subtle security rpoblem related to that though
20:45 < petertodd> amiller: which is?
20:45 < amiller> attackers can revert larger history with *better than negligible chance* if they can increase the difficulty high enouhg
20:45 < warren> petertodd: perhaps it would be more palatable of a change if something like every other block were allowed to be scrypt or birthday.  but in any case none of that fixes the issue of centralization, if litecoin has a hardfork I want to tackle that.
20:45 < adam3us> amiller: well if we said you had to make a coelho merkle pow it would have a lot of progress so be power-unfair
20:46 < amiller> adam3us, that's an all or nothing puzzle
20:46 < amiller> adam3us, that's different than letting individuals get their own little reward for a subpart
20:46 < adam3us> amiller: right.  the prize is all-or-nothing.
20:47 < amiller> ok so make subdivisible puzzles where there rewards are also subdivisble in the same way
20:47 < petertodd> amiller: right, so devise schemes where we're not letting luck revert large history
20:47 < adam3us> amiller: ok that i think is interesting to explore.  (i tried a bit in the past also)
20:47 < amiller> petertodd, no that's fine as long as its not unbounded
20:47 < amiller> unbounded is a problem in the other direction too
20:47 < amiller> unboundedly small puzzles => DoS hazard as attacker floods network with small plausible weak blocks
20:47 < warren> adam3us: petertodd: how well researched is birthday against a worse break?
20:47 < adam3us> amiller: the other problem is you have reward and consensus and they are bound together
20:47 < amiller> unboundedly difficult puzzles => attacker has too good a chance of an attack with less power
20:47 < adam3us> warren: its pretty fundamentally hard
20:48 < adam3us> warren: just time memory trade offs
20:48 < amiller> adam3us, could you be a little more specific about what reward and consensus mean here
20:48 < warren> adam3us: are people already using TMTO to mine it?
20:48 < petertodd> amiller: in any case, I think my binary tree chains thing works for this, because you set it up with diff halved on each step down, and only let miners mine one path, keep separate diffs for each level, but also keep the reward the same horizontally so there's no economic incentives to let them get out of whack
20:48 < warren> scrypt GPU uses TMTO
20:48 < adam3us> warren: there was a thread on the protoshares / bitshare board where a guy was coding one.
20:49 < amiller> petertodd, i don't know what you are talking about, MMR? MMR for blocks?
20:49 < adam3us> warren: he had an example implementation and got the tmto working, but i dont know if he yet coded it for the gpu
20:49 < petertodd> amiller: no, I mean, strucure your blockchain as a binary tree of "blocks"
20:49 < petertodd> amiller: still linear in the time axis
20:50 < adam3us> amiller: reward = 25btc/block, consensus = everyone agreeing on transaction order and validation (over time)
20:50 < petertodd> amiller: point with this, is that you can have PoW per tx, and sum up work simply by the fact that the upper levels of the tree get that lucky less often, yet have higher difficulty
20:50 < petertodd> amiller: related is I suspect such a structure can do better scalability
20:50 < amiller> ok so make the reward proportional to block
20:51 < amiller> fees behave same way as before
20:51 < amiller> consensus = everyone agrees on transaction order same as before...
20:51 < petertodd> amiller: yeah
20:51 < amiller> proportional to difficulty in a block*
20:51 < adam3us> adam3us: but for consensus security there maybe an incentive security tie relating to reward...
20:51 < petertodd> amiller: now I *also* think you can probably structure this so that miners don't have to keep up with the whole chain, only doing subsets, but that's not necessarily directly related to the per-tx PoW aspect of it
20:52 < adam3us> amiller: oh i get you.  allow a consensus to be built up from frctional blocks
20:53 < petertodd> adam3us: yup, and the fraction could be as little as a single tx
20:53 < petertodd> adam3us: (obviously it's likely the concept will end up with some notion of work/byte)
20:53 < adam3us> amiller: like you could be 1.5-confirmed.  plausible but creates longer chain/complexity, maybe orphan risk, bandwidth usage
20:54 < petertodd> adam3us: yet, if you combine it with a scalability solution w/ sharding, per-node bandwidth can be less
20:54 < amiller> maybe the GHOST guys want to work on this
20:54 < warren> <petertodd> warren: heh, well, doing birthday-style momentum hash would be as temporarily asic-hard as any scrypt tweak, and with fast validation
20:54 < warren> To what degree would this be merely kicking the can down the road?
20:54 < petertodd> amiller: heh, well *I* want to work on this
20:55 < petertodd> warren: good question, probably tens of millions down the road, in terms of ASIC development cost
20:55 < amiller> well it basically forces a bunch of other sore issues
20:55 < amiller> like how to make fees match resources consumed
20:55 < warren> tens of millions of dollars?  that's nothing
20:55 < petertodd> warren: the scary thing is like any ASIC-hard-but-not-hard-enough scheme the first ASIC to be built is winner take all
20:55 < amiller> i think having parameters to restrict the bounds on either end is important
20:55 < petertodd> warren: sha256 ASICs are hundreds of thousands
20:55 < adam3us> petertodd: well if basic compression (not sending data twice) was implemented a block may cost less bw
20:55 < warren> petertodd: oh, tens of millions factor, not dollars?
20:56 < petertodd> warren: no, I'm saying my gut feeling is that a successful ASIC for such a beast would be tens of millions in dev costs
20:56 < adam3us> warren: i think $ in both cases
20:56 < warren> ok, then that isn't a worthwhile change
20:56 < petertodd> warren: but, what that's really saying is this is something that we need a real hardware person to analyse
20:57 < petertodd> warren: also momentum has interesting stuff: e.g. commodity content addressable memory *is* available because network routiers and the liek use it
20:57 < adam3us> amiller: btw i also thought of ghost a while back :) (saw you mentioned u did above)
20:58 < petertodd> warren: if you could get the community to put up a few thousand, you could probably get a decent bit of research+report on how viable it is
20:58 < warren> who is qualified to analyze it?
20:58 < petertodd> warren: it's the kind of thing MSC should be thinking about too
20:58 < petertodd> warren: good question - some kind of digital electronics/computer engineering person
20:58 < warren> huh? MSC has PoW?
20:58 < adam3us> amiller: in my case i was like hmm this creates compexity not enuf of a win, but they picked out its lower block interval support which i wasnt focusing on
20:58 < petertodd> warren: I've got the contacts to find a person for that
20:59 < petertodd> warren: not yet, but that falsl into things MSC should look into
20:59 < petertodd> warren: note that Ethereum does and it's a MSC competitor/substrate
20:59 < warren> If MSC is on Bitcoin's network, I don't see how it needs its own PoW
20:59 < warren> what is Ethereum?
20:59 < adam3us> warren: oh boy
21:00 < petertodd> warren: a bit part of why I was hired was to determine what the options are there...
21:00 < petertodd> adam3us: lol
21:00 < warren> (I've been busy lately.)
21:00 < petertodd> warren: "TURING COMPLETE CRYPTO CURRENCY INVESTMENT OPPORTUNITY BUY BUY BUY!"
21:00 < adam3us> warren: http://ethereum.org/ethereum.html
21:00 < warren> who made this?
21:00 < adam3us> warren: vitalik
21:01 < warren> a month ago he was all pro-primecoin
21:01 < adam3us> warren: with support of some good marketing folks
21:01 < petertodd> warren: vitalik is smart, but not wise...
21:01 < adam3us> warren: prime coin is a crock (IMO)
21:01 < adam3us> warren: i persuaded him that coelho was better ;)
21:01 < warren> sorry, what is coelho?
21:01 < adam3us> warren: hence he made dagger (linke from the above)
21:01 < petertodd> I was at a talk by him on ethereum and there was a moment kinda halfway through where he really jumped the shark so to speak
21:02 < adam3us> warren: merkle hash PoW with a fiat-shamir trick to reduce the memory for verify to like 4log(n) or such
21:03 < petertodd> adam3us: ugh, dagger is used *so* poorly in ethereum
21:03 < adam3us> warren: it crazy stuff because the script language is like able to do almost anything.  the implications are unknowable
21:04 < adam3us> petertodd: critique specific?
21:04 < petertodd> adam3us: the huge advantage with a fiat-shamir trick pow is that you can make the pow depend on block data, with dagger doesn't do
21:04 < adam3us> warren: virus script that like takes all coins?  probably not actually. but its openended and people may have fun with it
21:05 < petertodd> adam3us: meanwhile that kind of PoW is still rather parallelizable, including in an asic
21:05 < adam3us> petertodd: ah yes he dropped that bit.  he was talking about data tho & i mentioned he could use that feature
21:05 < adam3us> petertodd: (separately proof of storage or something for some other reason... )
21:05 < petertodd> adam3us: ugh, so he knows that you can do that? fuck
21:05 < petertodd> adam3us: the whole writeup on the ethereum site is just full of hand-wavey numbers too
21:05 < adam3us> petertodd: well he does now.  i am not sure it occurred to him at the time he wrote dagger
21:07 < petertodd> adam3us: anyway, the whole idea that memory requirements somehow make something ASIC hard by themselves is very wrong
21:07 < adam3us> petertodd: well it is somewhat memory hard with the params he has and thte sequence of calcs hmm i wonder ou cant keep a cache and skip list and get most of it without memory can you?
21:07 < warren> is dagger fast to verify?
21:07 < petertodd> warren: yeah
21:07 < adam3us> warren: faster than scrypt for the memory used, but slower than momentum.  however momentum is more TMTOable
21:08 < petertodd> adam3us: well, you make an asic that's physical strucutre is a tree for instance
21:08 < adam3us> warren: i wouldnt say fast but less slow.
21:08 < adam3us> warren: i think he aims to use the faster verify to demand more memory per instance however, rather than to make faster wall-clock verify
21:08 < adam3us> warren: u could use it otherwise...
21:09 < adam3us> petertodd: i meant even in software!  gotta re-read it (didnt occur to e before for some reason)
21:09 < petertodd> adam3us: kindsa reminds me: so one problem I had in coming up with a asic-hard "hash all the data"-style pow was that crypto-primatives like hash functions tend to be pretty slow compared to the bandwidth of main memory
21:10 < petertodd> adam3us: so the question is then what's the *weakest* crypto-primative you can get away with and still be secure - like, could you have the lowest parts of a dagger-style tree only do a single sha256 round?
21:10 < adam3us> amiller: this fractional block seems interesting, but you probably have to use ghost, due to block interval creating orphans, and put a sanity limit like you said.
21:10 < warren> petertodd: so wait, where would MSC use PoW?
21:10 < petertodd> adam3us: where going up the tree enough rounds have been done to be pre-image secure?
21:11 < warren> sorry, I'll be back later, meeting in 30 minutes I need to prepare for
21:11 < petertodd> warren: it'd use it to implement a ethereum layer
21:11 < petertodd> warren: I mean, implement ethereum-style consensus system, as an example
21:11 < amiller> adam3us, sure, it's kind of a dauting engineer effort which is why i've shied away from it
21:11 < adam3us> petertodd: that might not be a bad idea. tree-evaled sha256 rounds
21:11 < amiller> adam3us, but i hope at this point it's at least clear what sort of benefit this can get you
21:11 < amiller> not faster transactions or something trivial like that, but the ability to have user-selected difficulty which means the whole need for pools goes away
21:12 < petertodd> adam3us: yeah, hell, maybe even something as simple as XOR can be used in some cases for lower parts of the tree?
21:13 < petertodd> adam3us: cuckoo PoW could be an example there too: maybe each round of your cuckoo path can be just a single hash round and you can still get away with it given reversing a round may be *sufficiently* hard that just fetching the appropriate bit of memory is easier
21:15 < petertodd> adam3us: though that could backfire too because I suspect an optimal cuckoo implementation is a grid of small memory cells and routing logic to efficiently pass around in-progress solutions without using long, power-hungry wires
21:15 < adam3us> petertodd: i think scrypt has a faster hash to fill memory at one stage no?
21:16 < adam3us> petertodd: there were some earlyer PoW that aimed to stress memory latency by wobber et al.  unfortunately they all got broken :)
21:16 < petertodd> adam3us: yeah, that's why it uses salsa20
21:16 < petertodd> adam3us: for consensus pow I think trying to stress latency is hopeless
21:17 < petertodd> adam3us: though for timelock crypto it's perfectly reasonable
21:17 < adam3us> petertodd: why? its another form of parallelizable work...
21:18 < petertodd> adam3us: I'm talking about serial-parallel hash chain schemes
21:18 < petertodd> adam3us: in that case that memory latency leads itself to high parallelism is an *advantage* by making it cheaper to make the timelock
21:20 < petertodd> e.g. prepare x GB worth of lookup table, have n parallel queries going to the lookup table using some scheme using up all available bandwidth, then use the encrypted intermediate steps trick to deparallelize it
21:20 < adam3us> warren: u now in theory sha256 asics are more efficient in the way jtimon was arguing about earlier.  it concentrates the reward, but it maybe uses less electricity as a result
21:20 < petertodd> now you have a timelock that was reasonable cheap to make, yet the speed of sequentially cracking it is very directly related to memory latency, and mem latency sucks
21:21 < adam3us> petertodd: he he the first memory (latency) hard paper sent 16MB of random data in the example executable to make it non compactible
21:21 < petertodd> adam3us: sent? ?
21:21 < adam3us> petertodd: they linked it into the exe
21:21 < petertodd> adam3us: ah, I get it
21:22 < petertodd> adam3us: yeah, that's an interesting question: you really want a nothing-up-my-sleeve source of non-compactable random data!
21:22 < adam3us> petertodd: we've got one :) the block chain
21:22 < petertodd> adam3us: interesting problem to get bulk nothing-up-my-sleeve numbers - good opportunity for being overely cute
21:22 < petertodd> I was gonna say...
21:23 < petertodd> though even then you'd probably want to encrypt the blockchain with a CBC cipher to properly randomize it
21:23 < adam3us> petertodd: relatedly i proposed on CFRG using the block chain to proof NUMS / uncooked Elliptic curve paramter generation
21:23 < petertodd> ha nice
21:23 < adam3us> petertodd: i think its actually much better than the alternatives and the current state of the art which is quite gamable
21:24 < petertodd> adam3us: what's the state of the art?
21:24 < adam3us> petertodd: that soeone makes up a nice story about how they didnt cheat, like they publish the generation algorithm, code, and then feed it a seed like pi or a quote and say see "tada we couldnt have cheated"
21:25 < adam3us> petertodd: except there are 100s of bits of choices hidden in there..
21:25 < adam3us> petertodd: which means the choices could've been ground (doh!)
21:25 < petertodd> adam3us: oh right
21:25 < petertodd> adam3us: well don't they usually pick the *first* bits of pi?
21:26 < adam3us> petertodd: yes but i mean the code itself, the endian choice, the order the options are considered etc
21:26 < adam3us> petertodd: http://www.ietf.org/mail-archive/web/cfrg/current/msg04019.html
21:26 < adam3us> petertodd: (its quite short and bitcoin amusing)
21:26 < petertodd> adam3us: sure, but not that many bits there...
21:27 < adam3us> petertodd: i reckon you could find quite a few if you tried  see you are selecting curves on lot of complex rules, so which rule you reject first, that affects the choice
21:27 < petertodd> adam3us: ah, yeah I'll admit using the blockchain to prove you didn't try the whole process twice is nice
21:27 < adam3us> petertodd: many arbitrary decisions = grindability
21:28 < petertodd> adam3us: though don't make it double sha256, do it timelock crypto style so that to brute-force select would take longer than a block interval :P
21:28 < adam3us> petertodd: the certicom guy was saying hash like nasdaq closing prices, but hten after the fact its not as convincing.  blockchain is like a transferable irrefutable self contained proof!
21:28 < petertodd> yup
21:29 < adam3us> petertodd: i like it :) i mean its actually a useful improvement
21:30 < petertodd> adam3us: I think I posted that on the cryptography mailing list, or if not that my "add together n previous blockhashes" idea that averages them all together
21:31 < petertodd> timelock works really well in this case because you don't care how long it takes to verify the process
21:33 < petertodd> adam3us: might be interesting to do some timelock crypto competitions with the memory-latency-hard technique - encrypt a private key of course and first to decrypt gets to spend it
21:33 < adam3us> petertodd: oh yeah i think i remember that post now you mention it.. maybe it stuck in my subconscious
21:33 < petertodd> adam3us: be nice to get some lower-bounds there
21:33 < petertodd> adam3us: I'm pretty sure there's nothing with better latency for large amounts of ram out there than commodity hardware
21:33 < adam3us> petertodd: out comes the watercooled monster box :)
21:34 < petertodd> adam3us: yup
21:34 < petertodd> adam3us: which reminds me: one of the hard things about all this asic-hard stuff is PoW doesn't need to be reliable, while even the worse consumer hardware is fairly reliable
21:34 < adam3us> petertodd: my cpu is good (4.8ghz hex core) but i didnt splash for fancy ram
21:34 < petertodd> adam3us: that costs you speed
21:35 < adam3us> petertodd: exactly, yes.  (reliability argument) i think one of the asic hw people commented on that
21:35 < petertodd> with a big enough bounty it could be a good way to test the "single round of foo hash" idea
21:35 < petertodd> adam3us: butterfly labs for one implements that
21:35 < petertodd> adam3us: though we *are* lucky that overclocking is still popular
21:38 < adam3us> petertodd: oc is cost effective.  that 6-core sandybridge is faster than i think just about any single socket xeon for 3x the price (or worse if you go for dual socket costs)
21:39 < adam3us> petertodd: ghz*core speed assuming parallelizable tasks.
21:39 < petertodd> heh, it'd be hilarious if all our efforts at ASIC-hard PoW just leads to more hardware designed for overclockers :P
--- Log closed Fri Jan 17 00:00:09 2014