--- Log opened Wed Jul 24 00:00:18 2013
00:29 < amiller> hrm, hrm, just how strong is SPV anyway
00:29 < amiller> it's actually really secure
00:29 < petertodd> define "really"
00:30 < amiller> by the ordinary bitcoin assumptions, 51% etc etc, the problem with SPV isn't that a client might get duped or double spent
00:30 < amiller> the bigger problem is that "mining" as an SPV client is irresponsible and a public hazard, which could ruin the 51%
00:30 < amiller> the bigger problem is that "mining" as an SPV client is irresponsible and a public hazard, which could ruin the 51
00:30 < amiller> (er up arrow mistake)
00:31 < amiller> if 51% of miners do full validation and not just SPV, then the point is SPV is safe for everyone else
00:31 < petertodd> so lets say I accept transactions with one confirmation, and you've figured out what node I'm using, how secure is SPV for me in terms of cost to attack me?
00:31 < amiller> one confirmation doesn't count
00:31 < petertodd> why?
00:31 < amiller> it's still 6 or whatever, you have to do a risk calculation
00:31 < petertodd> why is it 6?
00:31 < petertodd> what not 5? or 7?
00:31 < petertodd> or 144?
00:31 < amiller> i carried on a thread once trying to analyze this
00:31 < amiller> 6 is just a social norm
00:32 < petertodd> did you analyze it in terms of probabiity, or cost?
00:32 < amiller> but really you could treat it as a risk management problem
00:32 < amiller> both
00:32 < amiller> cost is basically measured in time
00:32 < petertodd> no, cost is measured in money
00:32 < amiller> the longer you wait, the more of a hassle it is, and the more likely it's not suitable
00:32 < petertodd> lol, "hassle" has nothing to do with attacks
00:32 < petertodd> be precise, how much money does it cost you to attack me, and under what assumptions?
00:33 < amiller> petertodd, the only real interesting thing i came up with is that it isn't even the cost of attacking *you*
00:33 < amiller> it's more about the likelihood of getting swept up in an attack aimed at someone else
00:33 < petertodd> ah, you're getting closer to understanding this...
00:33 < petertodd> so what happens to this cost stuff if the attacker is attacking n targets at once?
00:33 < amiller> my basic model is an attacker with a budget and a time window
00:34 < amiller> i let the attacker have infinite hash power, but not an infinite amount of energy
00:34 < petertodd> how many targets does this attacker have?
00:34 < amiller> the target is some fraction of all the double spend opportunities in whatever time window they're successful in mining an "attack fork"
00:34 < petertodd> right, so your attacker can pay $x/second worth of electricity to get y hashes/second
00:35 < amiller> the attacker can purchase B hashes and he gets them all at once
00:35 < petertodd> heh, you've even more optimistic than I'm talking about, but go on
00:35 < amiller> so fix the network's hash rate, and the attacker's budget B. now the attacker has to pick a time window and a probability of success
00:36 < amiller> one thing i like to consider (i think someone else has talked about this recently) is a doomsday attack where someone makes a credible threat that they're going to reverse 24 hours of blockchain history
00:36 < amiller> beeginning on Jan 1 or something like that
00:36 < amiller> everyone knows (or believes) in advance that doublespends will be possible during this time
00:37 < amiller> (maybe there's some anonymous dropbox where you are supposed to spend your doublespend transactions)
00:37 < amiller> the point of this thought experiment is that the attack might not even need to be skillfully coordinated
00:37 < Luke-Jr> amiller: that'd be a difficult situation to double-spend in
00:37 < amiller> if you had an attack fork, maybe you can just get everyone to doublespend each other
00:37 < petertodd> hang on, go back a second, so how are you calculating return for the attacker against my SPV example?
00:38 < petertodd> what specifically is the attacker doing for that matter?
00:38 < amiller> petertodd, ok ok so i went on a tangent to describe the enormous attack that gets everyone to double spend everything
00:38 < petertodd> remember, I'm an SPV client
00:38 < amiller> the more realistic one i guess is that the point is an attacker pays for and mines an attack fork, and then tries to do some big double spending at that time
00:39 < amiller> petertodd, SPV or not, the point is you go find all the merchants you can
00:39 < petertodd> again, I'm an SPV client, why bother double-spending me at all?
00:39 < amiller> that are willing to make big irreovacalbe actions after some number of blocks
00:39 < petertodd> why not make a block that meets difficulty, and is filled with transactions that are fake?
00:39 < amiller> where that number of blocks is less than what you can mine with your attack budget!
00:40 < amiller> petertodd, the point is, if there's a merchant that lets you drive off with a ferrari after 6 blocks, and you are able to in a timely fashion produce 7 blocks before everyone else makes 6, then you can win a ferrarri
00:41 < petertodd> you're making a lot of assumptions
00:41 < petertodd> I can be much more clever than just trying to double-spend
00:41 < amiller> what else would you do
00:41 < amiller> what else would you need to do
00:41 < amiller> you could double spend money you don't even have
00:41 < petertodd> as I said, I can make blocks that are filled with completely invalid transactions creating money out of thin air
00:41 < petertodd> SPV clients can't tell the difference
00:41 < amiller> sure, good point
00:41 < amiller> that... definitely decreases the cost of an attack
00:42 < petertodd> indeed
00:42 < amiller> especially since if the attack fails in the ordinary double spend case you'd have a lot more to lose.
00:42 < petertodd> doesn't take much to sybil the network, after all, I might have other uses for that capability like trying to figure out who is making what transactions
00:43 < amiller> still, if you can achieve anything against this SPV client, you could also double spend the ordinary clients
00:43 < amiller> and double-spend is still a serious attack
00:43 < amiller> the real havoc is if SPV clients mine.
00:44 < petertodd> the thing is, against an SPV client I don't even need the money, and can launch my attack against a huge number of targets at once, so even if there's a tiny chance of success for any one target I win overall
00:44 < petertodd> (again, goes back to sybiling the network)
00:44 < petertodd> I don't need a 100% sybil
00:45 < amiller> petertodd, it's still very expensive for you to make an attack fork...
00:45 < amiller> a successful attack is more profitable if there are lots of SPV merchants, yeah
00:45 < petertodd> it is *right now*, it might not be in the future as fees become more important, and we don't know
00:46 < petertodd> heck, I could probably pull all this off in a real-life scenario, by, say, controlling the wireless network at a "satoshi circle" event and MITMing everyones android phone
00:47 < petertodd> "Gee, confirmations sure are taking awhile today aren't they?"
00:47 < amiller> it's quiet, too quiet.
00:47 < petertodd> Play it carefully and I can make it look like I lost money in the attack too so it's not obvious who actually made it happen.
00:48 < petertodd> In this scenario 10% of the hashing power would probably be enough for a real-life attack.
00:48 < petertodd> Heck, 0% given people accept zero-conf...
00:48 < amiller> yes
00:48 < amiller> so!
00:48 < amiller> lets say you're going to do a risk analysis
00:48 < amiller> lets say you're about to exchange 1 btc for cash
00:48 < amiller> how long should you wait?
00:48 < amiller> even if you're a full client
00:49 < petertodd> The best way, is for me to check their government issued photo ID and take a picture of it so I can report the counter-party to the police.
00:49 < amiller> heh, so we get as far as we can with the crypto and let government registries pick up the slack :p
00:50 < amiller> i'm not comfortable with protocols for which i don't have a model (not that i have a satisfactory one for bitcoin, which definitely makes me uncomfortable)
00:50 < petertodd> Heck, I sold someone a Bitcoin back when they were over $200 in person - I didn't have a bitcoin on my phone, so they gave me the $200, I gave them my business card, and I sent them the Bitcoin a few hours later.
00:50 < amiller> petertodd, so a -10 confirmation transaction :p
00:51 < petertodd> Absolutely
00:51 < petertodd> Heck, about a -50 confirmation transaction.
00:51 < amiller> so even if you know them
00:51 < amiller> like you said
00:51 < amiller> you should make it so that they can't blame it on someone else
00:51 < amiller> like if they send you a transaction that they only received 1 block agin
00:51 < amiller> ago
00:51 < petertodd> They didn't know me at all or anyone else in the group, but they did know it appeared a bunch of people recognized me.
00:52 < amiller> petertodd, maybe think of it this way
00:52 < amiller> suppose you're a bitcoin business
00:52 < amiller> you might want bitcoin business insurance!
00:52 < petertodd> Point is, people tend to overestimate SPV security, because they think in terms of "an attacker is trying to attack *me*" which is dead wrong.
00:52 < amiller> how would an insurance company decide what to quote you for insurance against fork-attack double-spends?
00:52 < amiller> a risk manager for a bitcoin business would want to develop a policy for how many confirmations to wait before doing something irrevocable
00:52 < petertodd> First they'd call up myself and jdillon and ask us how replace-by-fee is going...
00:53 < petertodd> (0.25% hashing power jdillon figured, at least a month ago)
00:53 < amiller> if you don't have any transactions in flight and a bunch of noobs get double spent after 2-confirmation transactions, then it doesn't really effect you
00:53 < amiller> affect*
00:54 < petertodd> Frankly I think the best way is to arrange things such that you can't lose an unacceptable amount in one go, and continuously, and automatically, watch for fraud, triggering behavioral changes when you see it.
00:54 < petertodd> This isn't like the weather where the underlying mechanisms are well understood,
00:55 < amiller> yeah, and we still fall for the old "natural disaster" attack often enoguh
00:55 < petertodd> When jdillon and I were initially promoting replace-by-fee, we contacted a number of zero-conf accepting merchants, and nearly everyone followed that exact line of thinking and almost without exception the merchants said they weren't worried about replace-by-fee at all.
00:55 < petertodd> (that's before jdillon realized the scorched earth strategy can even make it fairly safe)
00:56 < gmaxwell> amiller would like the scorched earth strategy point if he hasn't heard it.
00:57 < amiller> i don't think i've heard it
00:57 < amiller> in any case this still supports my point
00:57 < petertodd> https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189
00:57 < amiller> SPV is bad for *everyone else* to use
00:57 < amiller> but it isn't unsafe for an individual to use
00:57 < petertodd> fourth paragraph
00:58 < amiller> it's a social cost / public good problem
00:58 < amiller> not an individual security problem
00:58 < petertodd> agreed on that point
00:58 < amiller> like voting
00:58 < petertodd> especially when we're talking about tiny sums
00:58 < petertodd> applies to general network scalability too, which itself is a security issue
00:59 < amiller> yeah, i'm all for that.
01:00 < petertodd> Note that scorched earth is subject to most of the technical risks that the current defacto zero-conf is - differing ideas of what is a valid tx - although those risks are lessoned because we only need to be pretty sure a really high fee tx propagates well, and that's obviously not a DoS attack.
01:00 < amiller> it's what i assume is part of the "rational bitcoin client"
01:00 < petertodd> Yeah, bit of hand-waving there because you don't get paid to relay transations of course, but so long as wel keep full/partial nodes cheap we're ok there.
01:01 < amiller> yeah and fees dont' make terribly much sense overall anyway yet, but it's a step in the right direction
01:01 < jgarzik> That's the $10,000 prize:  figure out how to compensate people for being full nodes
01:02 < jgarzik> Something that cannot be *for the most part* gamed, a la click bots
01:02 < amiller> jgarzik, yes, move to a Proof-of-Retrievability based puzzle rather than empty hashes
01:03 < petertodd> Well, the logical extension of scorched earth is to make fees part of the *consensus* algorithm: IE burn money instead of burning electricity. This gets your "infinite mining capacity" in real life, almost, which means a 51% attacker needs to spend more than the entire value of the currency. (roughly speaking)
01:03 < petertodd> Problem is, systems like that aren't SPV compatible unless you're clever about it...
01:04 < amiller> petertodd, do you have an idea how you can make it so you have to expend the cost *just to try*?
01:04 < petertodd> They're also disturbingly close to proof-of-stake...
01:04 < petertodd> amiller: Fraud proofs.
01:04 < petertodd> But that only works with the jam-proof-network assumption, and depends on that assumption very heavily.
01:04 < amiller> so you're money is deleted if anyone provides evidence that you used the same money twice?
01:04 < amiller> yeah
01:04 < amiller> your
01:04 < amiller> *
01:05 < petertodd> jgarzik: Very easy to do if we're willing to add extra data to transactions and do probabalistic payments.
01:05 < petertodd> amiller: Yeah, and your fee sacrifice is still sacrificed if someone proves your block was invalid.
01:06 < amiller> petertodd, do you imagine that could ever be money-sacrifice all the way down?
01:06 < amiller> that cpu burning isn't even necessary as a bootstrap step?
01:06 < petertodd> amiller: You get into the nothing at stake problem... at some point *something* has to be costly in terms of energy.
01:06 < amiller> my intuition is that it's not but i haven't made any progress in clarifying what that means
01:08 < petertodd> Non-interactive proofs can work, but they tend to depend on computational limits...
01:08 < petertodd> It may be that the issue boils down to how do you do initial coin distribution fairly.
01:11 < amiller> so i meant to lead into this new topic i want to ramble about....  SPV security is a key point in composition for bitcoin (i.e., multiple chains, and smart coins)
01:11 < amiller> the idea is you can have a heterogeneous network where some people do full validation, and other people just do SPV validation
01:12 < amiller> i am working right now on a "Bitcoin extension" project that lets you pay for outsourced storage
01:13 < amiller> by Bitcoin extension i mean that i am just pretending i can tweak the transaction scripts however i like to define smart contracts and assign value to them
01:14 < petertodd> remember we *can* soft-fork to add all the opcodes we want
01:14 < amiller> so the idea is i write a script that defines a proof-of-retrievability "verification" routine, and i attach some money to it to be paid out every so often
01:14 < amiller> now there is a public bounty on answering proofs-of-retrievability, which means storing my data!
01:14 < petertodd> ha, lovely
01:14 < petertodd> problem is, how many copies?
01:15 < amiller> right! so that's where it gets interesting
01:15 < petertodd> so nLockTime these txs
01:15 < petertodd> or better yet OP_BLOCKHEIGHT them
01:15 < amiller> i have to do some weird sorts of economic modeling here, but it is likely that because of economies of scale
01:15 < petertodd> (so you can't double-spend the txout)
01:15 < amiller> the most cost effective way to participate in my challenge is just to pay some server farm to do the storing for you
01:16 < petertodd> yeah
01:16 < amiller> bitcoin makes it pretty easy to enter into a mining-for-payment contract
01:16 < petertodd> one issue: how do you incentivize retrieval?
01:16 < amiller> basically you just do something like reencode the puzzle
01:16 < amiller> and you pay them when they prove they're working at least on valid 'shares' that would benefit your public key
01:16 < amiller> so my solution to that is to change the proof of work so it's not just a hash, but a signature
01:16 < amiller> in other words, each time you scratch of a ticket, you have to use your private key
01:17 < amiller> this would make it much more difficult just to outsource mining
01:17 < petertodd> ah I see
01:17 < petertodd> yeah, I noticed that issue too with proof-of-stake stuff - allowing for separate stake proof and spend proof keys is a bad thing
01:18 < amiller> i'm having a really hard time defining that intuition any more clearly though
01:18 < amiller> it seems to relte to program obfuscation
01:18 < petertodd> unfortunate, but it has to be done
01:18 < amiller> there are results for general outsourcing of private programs
01:18 < amiller> but they are definitely more expensive
01:19 < petertodd> hmm... go back to your concrete use-cases though, I'm not sure you have to do anything fancy for them
01:19 < amiller> so i'm at this point moving on and just saying, assume i can make a proof-of-work based on signatures such that it's infeasible to outsource, then i can assume somehow that individuals who participate won't just hire the central amortized server
01:19 < amiller> so the next question is what you asked
01:19 < amiller> how to incentivze the actual retreival
01:19 < petertodd> right
01:19 < amiller> and i have no idea
01:19 < petertodd> how big is the data?
01:19 < amiller> just because someone collects the reward by proving they *have* my data doesn't mean they're going to transfer it to me on demand
01:20 < amiller> petertodd, well so far we're considering like storing the library of congress
01:20 < petertodd> it's easy to just make a tx that requires providing the data itself to spend it
01:20 < amiller> it doesn't need to be public data
01:20 < amiller> but it's fun to think of it that way as a start
01:20 < petertodd> encryption makes public data private data :)
01:20 < amiller> i want my random strings stored, everywhere, and i'll pay good btc for it!
01:21 < amiller> it's not porn, it's just /dev/urandom's greatest hits vols. 15-22
01:22 < amiller> so yeah, how many copies do you want and what are you willing to pay for it
01:22 < amiller> i don't know how to express that.
01:22 < petertodd> Actually, this is pretty easy: use a  non-interactive proof to determine the counter-party actually posesses the data, and have them give it to you encrypted, then hand over the encryption key as part of the scriptSig to prove they can spend the reward transaction.
01:22 < gmaxwell> well, if you wait long enough your data will show up in a storage proof. :P
01:22 < amiller> right, extractability :)
01:22 < gmaxwell> like delay line memory.
01:23 < amiller> (although i might have to get the whole thing and not just a block of my choice at a time)
01:23 < amiller> so one thing i've been thinking about
01:23 < amiller> is that in the real world the way things like this are done is by involving some exclusivity
01:23 < petertodd> gmaxwell: You mean Indiiana Jones style secure government warehouse memory?
01:23 < amiller> like i have a call for proposals that is announced to the public, then i anonymously select the winner
01:24 < amiller> but then the winner and i have an exclusive arrangement
01:24 < amiller> so they don't have to keep competing
01:24 < amiller> this has some advantages and some disadvantages but really several options should be possible
01:24 < amiller> anyway the part i wanted to mention, that relates to SPV security, is this
01:25 < amiller> it would probably be super expensive if i was trying to pay the whole bitcoin network to be ready to validate my custom PoR proofs
01:25 < petertodd> aside: you can use probabalistic payments with the "data hand over" protocol to pay to get data.
01:25 < amiller> petertodd, that's a good idea.
01:26 < petertodd> Makes is cheap to validate them too, amortized.
01:26 < amiller> anyway so it's hard (Without PCP) to fully check the por proof with cryptographic soundness
01:26 < amiller> what's a lot easier is to make an economic argument about work
01:26 < amiller> that if thousands of PoR's are computed
01:26 < petertodd> por==proof-of-reception?
01:26 < petertodd> or proof-of-retainment?
01:26 < amiller> proof of retreival
01:27 < petertodd> IE, por means I prove I can retreive some data?
01:27 < amiller> it's basically just like, select a dozen blocks at random and prove you can fetch them and hash them with something
01:27 < petertodd> Yeah, and you don't need PCP at all for that.
01:28 < petertodd> Heck, you could do it with the current scripting language I think had we not disabled the cool opcodes...
01:28 < petertodd> (oh, you'd need OP_BLOCKHASH)
01:28 < amiller> you do sort of need pcp
01:28 < petertodd> why?
01:28 < petertodd> I'm not computing anything
01:28 < amiller> it's the same thing we talked about at some previous point
01:28 < amiller> where if you want to check some sequential thing
01:28 < amiller> the way to do it efficiently is just to check a small sample
01:29 < amiller> but then there could be a small number of incorrect pieces that you wouldn't have super great chance of detecting
01:29 < amiller> PCP is basically about amplifying those errors such that the small sample catches them anyway
01:29 < petertodd> So what? Store the data in the first place with sufficient error correction.
01:30 < petertodd> Same solution, but applied in a way that's simple rather than black magic.
01:30 < amiller> i need to have a sequential proof though
01:30 < amiller> like
01:30 < amiller> at least some number like k iterations
01:31 < amiller> the reason is that in the "puzzle solving" setting, unlike the ordinary interaction setting,
01:31 < amiller> if you draw a nonce that says "go fetch block X5" and X5 happens to be a block that you are skipming out on by not storing
01:31 < amiller> you can just skip that challenge and go on to the next
01:31 < amiller> you don't have to worry about this in the client server setting because the server has to answer all the client's challenges
01:31 < petertodd> No you don't: if I sample, say, 64 totally random samples of the data I have a 50:50 chance of getting away with fraud if I fail to store roughly 1% of the data. So store the data in the first palce with an error-correction-code that can handle >1% losses.
01:32 < amiller> the way around this is to make the 64 random sampels *sequential*
01:32 < petertodd> That makes things worse, not better.
01:33 < amiller> no because it's rpetty cheap to reroll and ask for a new choice of 64
01:33 < petertodd> If they are sequential I can fail to store more of the data by leaving out larger chunks.
01:33 < amiller> sorry not sequential liek that
01:33 < amiller> i mean
01:33 < amiller> you have to do the first one
01:33 < amiller> take the hash of that data you jsut fetched
01:33 < amiller> use that to compute your next challenge
01:33 < amiller> and so on, 64 times
01:34 < amiller> rather than getting to look at all 64 indexes at the beginning to decide if you want to respond to this challenge or ignore it and ask for a new one
01:34 < petertodd> Ah, but who says it has to be cheap? This is a txout script, it can work by first getting the prevblockhash, using that to select the subset, and if you can provide that proof, you get to spend it. Obviously miners are most likely to be able to actually get the tx mined.
01:34 < amiller> that works just as well i guess
01:34 < petertodd> You only get one roll per block, so if you are a miner you're incentive is to have the data handy to try to put the corresponding txout in your block.
01:34 < amiller> anyway, still, validating 64 chunks of data?
01:35 < amiller> that might not be too expensive
01:35 < petertodd> It's a trade-off between # of txouts you use to pay people vs. txout size vs. chance your data won't actually get stored.
01:36 < amiller> right
01:36 < petertodd> 64 is very conservative, even just proving one is probably fine
01:36 < amiller> but, this is my new thought for tonight....
01:36 < amiller> SPV suggests an additional way
01:36 < amiller> maybe not everyone has to validate the whole secure PoR
01:36 < petertodd> Although also, multiple proofs in one tx can be more space efficient as the merkle paths share state
01:36 < amiller> for disbursing payment
01:36 < amiller> it may just be enough that you have to do the same amount of work
01:36 < amiller> with a moderate chance of failure
01:37 < petertodd> (merkleized ASTs would be ideal for this you know...)
01:37 < petertodd> yeah, plenty of trade-offs
01:38 < petertodd> the interesting thing is so how many ops do we need to enable/add to make this happen? I'm pretty sure it's just the string manipulation stuff + op_prevblockhash + op_blockheight
01:38 < amiller> good question
01:39 < amiller> (i still don't like the one-try-per-block idea as much as having it be self-selected, but lets assume either case for the sake of this question)
01:40 < amiller> i could do almost the whole thing with just string manipulation and a hash
01:40 < amiller> blockheight or cumulative difficult probably is important yeah
01:40 < petertodd> yeah, you need that PRNG
01:40 < amiller> especially if there's like a time quality to this
01:42 < petertodd> yeah, and that time quality is really useful
01:42 < amiller> so suppose i wanted to use this
01:42 < petertodd> like, I might want to spend a few years in a cave, and come back and stil have my data
01:42 < amiller> yeah
01:42 < amiller> so suppose you preallocate the funds for it
01:42 < amiller> and determine how fast they get spent
01:42 < amiller> it's like setting the puzzle difficulty
01:42 < amiller> do i have a jackpot that rolls over or something
01:43 < petertodd> the txouts act like jackpots kinda, and with op_blockheight their jackpots that unlock
01:43 < petertodd> so make them frequent enough that the future value isn't discounted too much
01:45 < amiller> so how to people decide to participate in this
01:45 < amiller> it's extra work
01:45 < amiller> and it's potentially competitive
01:45 < petertodd> indeed
01:45 < petertodd> well, write good software so it's turnkey :)
01:45 < amiller> i am willing to assume things that like perhaps people have intelligent mining clients that know about many currencies and opprtunities and basically select some portfolio of the best work to engage in
01:46 < petertodd> yeah
01:46 < petertodd> if it's automatic the bar can be relatively low
01:46 < amiller> but what makes a puzzle competitivef
01:46 < amiller> or a good deal
01:46 < amiller> i'm starting to think that being able to win some form of exclusivity might be important
01:46 < petertodd> NO
01:46 < amiller> no?
01:47 < petertodd> you want the competition, so that if any given player drops out, there will be backups
01:47 < amiller> yeah
01:47 < petertodd> point is, make the software easy enough that people run it even when the return isn't very high
01:47 < petertodd> the logic should be "Hey! I can make money with this spare harddrive space!"
01:47 < amiller> that's true but not good enough for my standards
01:48 < amiller> because if that's successful then my competition will be other people who are vying for the same storage space!
01:48 < petertodd> it's a decentralized system, you're not going to get better with software
01:48 < petertodd> yes
01:48 < petertodd> whomever can provide the space the cheapest
01:48 < amiller> no i mean
01:48 < amiller> competition among other puzzle-contract-creators
01:48 < amiller> other people trying to purchase storage
01:48 < amiller> how do i make my tx-contract the most attractive deal
01:49 < petertodd> no, this isn't a zero-sum-game
01:49 < amiller> obviously i can pay more money
01:49 < amiller> that sweetens the deal
01:49 < petertodd> the storage providers will look at the sum of potential earnings, and buy enough storage to take advantage.
01:49 < petertodd> yes, you can pay more to make it more likely the providers will bother.
01:50 < petertodd> (the real issue: who knows what the btc/GiB ratio will be)
01:50 < amiller> i think it's going to turn out to be even more of a challenge when defining what the retrieval costs are supposd to be
01:50 < amiller> i really like this one extreme example, Amazon glacire
01:51 < amiller> https://aws.amazon.com/glacier/
01:51 < petertodd> retrieval costs don't need to be defined, that ones actually a bidding process you realize
01:51 < petertodd> I've got ~300GiB there
01:52 < petertodd> big spender I know
01:52 < amiller> have you ever retrieved it
01:52 < petertodd> not all of it
01:52 < amiller> heh, do you ever probe it with PoR's effectively
01:52 < petertodd> I know the fees are crazy if you want it fast
01:52 < petertodd> lol
01:53 < petertodd> I rely on others to do that for me :P
01:58 < amiller> so
01:58 < amiller> in the case of bitcoin, you rely on mining nodes to do full validation
01:59 < amiller> an individual SPV client may only care about checking the total amount of work, which basically makes it expensive to overwhelm with effort, whether it's valid data or not
02:00 < amiller> for a complicated transaction of mine i think i should only expect the whole global network to do something like SPV style validation before deciding to release my funds
02:00 < amiller> although i would probably be interested in doing the more complete validation
02:00 < amiller> or i dunno hiring a smaller number of people to do this validation at lower cost, but not globally
02:00 < amiller> do i get anything by having a larger network do cursory SPV validation
02:00 < amiller> vs only having a small network do full validation?
02:01 < amiller> with merge mining, there is no validation
02:01 < amiller> from the big network to the smaller one i mean
02:03 < amiller> i think the important thing about SPV validation is that work that passes SPV can't also be repurposed to achieve anything else
02:03 < petertodd> why have all that complexity? why not focus on ways to make the transactions small as much as possible?
02:03 < petertodd> only do fancy stuff when you get desparate, and that fancy stuff can happen in a different chain dedicated to it with correct incentives, releasing funds via oracle or something
02:04 < petertodd> look how for the data storage example the proofs actually aren't all that bad
02:05 < amiller> oracles are just another fancy name for TTP
02:05 < amiller> in any case...
02:05 < amiller> well the fancy stuff happening in a dedicated chain
02:05 < amiller> correct incentives.. what do you mean?
02:06 < amiller> that's kind of what i have in mind
02:06 < petertodd> who knows?
02:06 < amiller> that's why this is a compositionality thing
02:06 < amiller> how can i use the Big Network's safety and stable money, as an incentive in my celebration-of-random-strings altchain
02:06 < petertodd> now, what I want you do to, is write down a quick summary of how op_blockhash and op_blockheight helps you in this goal, so we can get an idea of the uses for new opcodes and start figuring out what is worth implementing
02:07 < petertodd> because you have Yet Another Example of a cool and useful thing we can do
02:07 < amiller> i want to be able to define SPV validation for another chain!
02:08 < amiller> i'll need hashes for consuming merkle tree proofs
02:08 < amiller> and... really none of that requires anything else i guess
02:08 < petertodd> Ok, so write up an example script.
02:08 < amiller> hm
02:08 < amiller> Ok.
02:08 < petertodd> Sounds like you just need OP_CAT, OP_SUBSTR and what not.
02:09 < petertodd> See, I've got a soft-forkable mechanism in mind where we can gradualy enable more stuff as we prove we haven't screwed up.
02:09 < petertodd> And I'm thinking MAST support should be #1
02:10 < amiller> interesting
02:11 < petertodd> MAST is actually pretty simple too: just make OP_IF and OP_ELSE take a digest, rather than opcodes, if the branch isn't executed, and use that digest in the calculation of the tree
02:11 < petertodd> It'll look kinda like P2SH really
02:12 < petertodd> If bitcoin isn't interested, worth asking litecoin.
02:13 < amiller> what about breaking a computation into parts
02:13 < amiller> so it could be spread over multiple tx
02:13 < amiller> that's unnecssary complexity nvm
02:13 < petertodd> That would be complex, and incompatible with how Bitcoin scripting usually works.
02:13 < petertodd> KISS
02:14 < petertodd> *Another* thing I want to do, like soon, is add "debugging" support to scripts to trace the state they take, which is similar code.
02:15 < petertodd> example: http://webbtc.com/script/31d3fb6b4af93525e04e9d97690cffdd292ca554791cfadd34af76ecbb9bdf29:0
02:15 < amiller> hm
02:15 < amiller> i could probably just model bitcoin's stack language in ocaml and use my compiler hack directly as a reference design
02:15 < petertodd> that's using bitcoin-ruby, which is broken - very much worth adding this to bitcoin itself for debugging/pedalogical reasons
02:16 < petertodd> *pedagogical
02:16 < amiller> that's slick, thanks for link
02:16 < petertodd> heck, testing too: make hashes of those execution traces and store them in the unittests
02:16 < petertodd> frankly if anything changes, it's almost certainely a bug
11:59 < jgarzik> petertodd, amiller: anybody given any thought to identity (SINs) + file sharing?  Trying to figure out if a decentralized Amazon S3 could ever be possible
11:59 < jgarzik> i.e. where data hosting entities can come and go, and be compensated for their work.  users can come and go, and pay for storage.
12:00 < jgarzik> data hosting has two layers, as zooko and Tahoe-LAFS well know, low level storage and upper level accounting.
12:00 < jgarzik> accounting/indexing
12:04  * jgarzik always thought of Tahoe-LAFS as cumbersome to build but doable -- but the HARD part is figuring out economic/game theory incentives to make such a system self-supporting
12:04 < amiller> mojonation was supposed to be that
12:04 < amiller> tahoe-lafs is a much reduced scale
12:04 < amiller> so hm.
12:05 < amiller> my observation though is if you have accounting that works, you probably don't even need SINs...
12:11 < jgarzik> possibly true
12:11 < jgarzik> I was thinking that SINs form a nexus around which you can build a positive reputation
12:13 < jgarzik> users need to provably pay for their download.  providers need to provably get paid for providing a download.  difficult if not impossible without proxying through third party verification
12:13 < jgarzik> (or so it seems to me)
12:18 < jgarzik> and these might be semi-trusted proxies, that audit each others' work and build a reputation
12:19 < jgarzik> perhaps users and providers follow a protocol that sends a request to A and B, yet provably expects the response to be delivered by C
12:20 < jgarzik> that gives other providers an awareness of requests going through the system, setting expectations for delivery by C
12:50 < jgarzik> switching topics,
12:50 < jgarzik> petertodd, still not totally happy with anyone-can-spend
12:51 < jgarzik> petertodd, lacking a bitcoind mod, the rational behavior is to send two transactions, the required anyone-can-spend and also a new tx spending that
12:51 < jgarzik> certainly the announce gives others the /chance/ to spend
12:52 < jgarzik> but in the initial stages of any such system, the identities will be cost-free
15:30 < petertodd> jgarzik: Did you see the discusstion between amiller and myself about proving you have some data as a way of incentivising storage?
15:30 < petertodd> jgarzik: anyone-can-spend *only* works if it's timelocked in any case, so with announce-commit it's actually three transactions.
15:31 < petertodd> jgarzik: Adding auto-spend support to the mempool in bitcoin upstream is easy - I wouldn't get hung up on that.
15:34 < petertodd> jgarzik: People already have huge wallets watching for coins being spent to tens of thousands of addresses they've done dictionaries for re: brainwallets.
15:36 < petertodd> jgarzik: For instance "jgarzik"=1KCvSPxjaJdVQtzP15bJgBXXDbrBxCNhj7, and "petertodd"=16VpZwEfw2PCwf4dZEBNeXpKgFPdbiUnf, and a 50mBTC payment to both got spent within about a second.
15:37 < petertodd> jgarzik: Provided spending a anyone-can-spend is standard, I don't think we have an issue at all.
15:39 < petertodd> Reminds me: we should consider a transaction input standard in AreInputsStandard() if a empty scriptSig, or scriptSig=OP_TRUE, is able to spend it in any case.
15:56 < petertodd> Also, that's a rational for anyone-can-spend too IMO: you don't need to be a miner to have an incentive to setup the infrastructure to claim it.
15:57 < petertodd> (especially with an anyone-can-spend based on OP_CHECKMULTISIG where it's already a standard tx)
16:09 < jgarzik> petertodd, I'm just concerned about initial bootstrapping.  After the system is running, it's fine.
16:11 < petertodd> Well, if anyone can spend is useful from a technical point of view, then why not use the OP_CHECKMULTISIG version?
16:11 < petertodd> Also, add scriptPubKey=<digest> to your OP_RETURN <data> pull-req.
16:12 < petertodd> (with <digest>!=0)
16:34 < petertodd> Keep in mind that for something like IRC, where a heck of a lot of proofs might need to be stored, you really want to keep the proof size small for the sacrifice. Eventually anyone-can-spend will need as little as a SHA256 midstate + <digest> + value + nLockTime and the merkle path. It's even better if you allow people to use the coinbase version, and proof-of-work coinbase version. (latter where you mine a share that would have been worth xBTC)
17:54 < midnightmagic> petertodd: zooko et al were doing a lot of work in that regard not so long ago.
17:55 < midnightmagic> i'm sad warner isn't idling in freenode anymore.
18:39 < petertodd> midnightmagic: what work exactly?
--- Log closed Thu Jul 25 00:00:21 2013