00:07:05ghtdak:ghtdak has left #bitcoin-wizards
01:46:01[\\\]:[\\\] is now known as assbot_sucks
01:46:46assbot_sucks:assbot_sucks is now known as [\\\]
01:50:22[\\\]:[\\\] is now known as assbot_sucks
01:51:57assbot_sucks:assbot_sucks is now known as [\\\]
03:48:53ghtdak:ghtdak has left #bitcoin-wizards
03:59:45maaku:maaku is now known as Guest56969
05:34:56jaekwon:i don't think you need consensus at all to store and transmit value.
05:40:30gmaxwell:you need anti-replay or people can be double spent. Consensus is a way to get anti-replay in a decenteralized system.
05:41:24jaekwon:anti-replay is necessary given a single coin.
05:41:50jaekwon:here's what i mean.
05:42:23jaekwon:Consider a large set of private entities that keep an internal ledger for users.
05:43:27jaekwon:Each entity has a single private key that signs blocks in its own blockchain. Each entity controls its own "coin".
05:44:17jaekwon:So you have a completely decentralized set of ledgers that aren't really connected in any way, except...
05:45:33jaekwon:If these separate ledgers are indirectly connected by trades, you can let the market decide the value of each entity.
05:45:34gmaxwell:I don't believe the word decentralized means what you think it means. :)
05:45:58gmaxwell:you also don't need a ledger. A sequence number and a signature of the current owner is enough.
05:46:12gmaxwell:(what do you care what the past owner of a coin was)
05:46:17jaekwon:Yes. I'm just painting the broad picture.
05:46:32jaekwon:Decentralized, as in, there isn't one coin.
05:46:51gmaxwell:It's still trustful, however.
05:47:05gmaxwell:I'd normally classify what you're calling that a federated system.
05:47:44gmaxwell:go see the coinwitness post, I describe that kind of system (where a centeralized party is tracking ownership of a particular coin) as one of the two offchain examples.
05:51:22jaekwon:It isn't simply based on trust.
05:53:09jaekwon:It is trustful, though. Yeah.
05:59:07jaekwon:It's not simply trust, and by that I mean this...
05:59:42jaekwon:It's based on the ability of an entity to act in a "good" manner, not double-spending, etc.
06:00:40jaekwon:Whether it be a black box, or a proof-of-work protected blockchain.
06:02:34jaekwon:The trick is in being able to pay Bob (who values, or trusts, entities E1, E2, and E3 in some weighted way) even if you don't hold any E1/E2/E3, with the help of the market.
06:07:02jaekwon:With Bitcoin, you still have to trust that a large portion of the miners won't behave irrationally, because (hopefully) they're incentivized to make the system useful.
06:07:44jaekwon:It's no different with a federation of centralized entities.
06:10:46jaekwon:You're not just trusting the entities either. You're also trusting the ability of market makers to predict the trustworthiness of each entity relative to each other.
06:10:59jaekwon:So, if you can trust a market, you can trust the market's value of each entity.
06:11:22gmaxwell:The problem with that is that security is a lemon market, everything looks great until its not but then its too late.
06:11:47gmaxwell:E1 is trustworthy, then someone shows up with an order and half the funds are seized.
06:12:06jaekwon:How do you mean?
06:13:47jaekwon:Someone shows up with what order? How are funds seized?
06:13:55gmaxwell:jaekwon: I'm not sure which part is ambigious to you. In general security is hard for markets to judge. Look at how many people have been defrauded in bitcoin-otc. People intentionally go and farm identies that behave very trustworthy, making trades and building reputations, and then poof. Sometimes they weren't even intentionally fradulent, they just make some massive uncorrectable mistake... regardless, past performance ...
06:14:02gmaxwell:... doesn't predict future results.
06:14:38gmaxwell:jaekwon: E.g. a court order, because of some regulatory snaft or other messy contractual dispute. "all these coins were previously stolen from me, please seize all of them so until we can sort them out"
06:14:44gmaxwell:s/snaft/snafu/
06:21:42jaekwon:What if the "coins" for E1 were conceptually, "shares" in E1, and E1's value is determined by the balance of its accounts on all the other E*'s?
06:22:25jaekwon:And when E1 is determined "dead" by E2, E2 releases the balance held by shareowners of E1 in proportion?
06:27:51jaekwon:You could use the market value of all the E* coins to determine the "health" of E1's account balance distribution across E*. Users should stay away from E1 if the dot product of its account balances in E* doesn't match the market values of E*
06:28:15jaekwon:If the distribution is healthy, then it doesn't matter that E1 goes down.
06:32:47kanzure:none of those statements seem to be related to security
06:40:59jaekwon:I'm thinking that there exists a protocol that can make the internal ledgers of federated nodes converge, given rational actors.
06:41:51jaekwon:such that even if major nodes go down, overall wealth distribution is preserved.
06:41:58jaekwon:not exactly, but enough.
13:38:45andytoshi:jaekwon: wtf is a "rational actor" in this system, how is your trust model any different from paypal's, why is there any disincentive (or difficulty, even) for foul play?
14:43:16ZoltanTokay:http://www.reddit.com/r/Bitcoin/comments/22utb0/mtgox_release_document_to_ask_for_refund/
14:43:31Apocalyptic:^ malware
14:47:15sipa:sipa has kicked ZoltanTokay from #bitcoin-wizards
15:33:26Guest56969:Guest56969 is now known as maaku
16:58:13zzyzx:zzyzx is now known as roidster
16:58:43roidster:roidster is now known as Guest81099
18:19:43fanquake:fanquake has left #bitcoin-wizards
18:57:42Guest81099:Guest81099 is now known as roidster
19:39:51c0rw1n:c0rw1n is now known as c0rw|dinner
19:58:16jaekwon:andytoshi: every entity has its own blockchain, signed by the entity. in the worst case it can only block a transaction, or double spend, but in either case it becomes known, as the blockchains are public.
19:58:39jaekwon:i don't have all the answers yet, so i'm sharing it here to bounce it.
19:59:03jaekwon:the point is, i don't think you need global consensus to achieve what we want.
19:59:35jaekwon:clearly centralized entities are capable of maintaining integrity with some value, given an incentive.
20:00:07jaekwon:and, even they their key gets compromised, i think the effects can be mitigated.
20:00:31jaekwon:and the more such entities there are, the more value this federated system would have.
20:01:34jaekwon:brb, let me paint a better framework
20:11:05c0rw|dinner:c0rw|dinner is now known as c0rw1n
20:11:17jaekwon:the difference with paypal is that, instead of of one paypal, there's a hundred or hundreds of thousands of paypals that all speak the same protocol, and everybody's balances are distributed unequally amongst them.
20:14:01jaekwon:the disincentive is that, should a conflicting block be signed by an entity E1, that information gets publicized by all the other entities (block123:hashxyz:signatureE0, block123:hashabc:signatureE0).
20:15:02jaekwon:all the users should at that point avoid using E1, so E1 can no longer earn fees, which was its incentive.
20:28:38jaekwon:each entity has not only an internal ledger for its own coins/shares, it also has assets in other entities.
20:30:39jaekwon:it's possible for a set of sybil entities to keep assets in each other, but i think you can at least calculate the different connected sets of entities.
21:24:42tromp_:was primecoin the first PoW not bsaed on hashcash?
22:13:41andytoshi:that is my recollection, though for months (years?) before there had been vague talk of scientifically useful PoW
22:27:15gmaxwell:is primecoin really not hashcash? [D[B[Bandytoshi: most ideas for a 'useful ' pow are still hashcash.. e.g. you just run the useful function inside the loop.
22:27:52gmaxwell:grr. lossy network, the first half shouldn't have been sent, yes, primecoin is not hashcash.
22:32:32andytoshi:you hash the block and then find a chain of primes using that hash as a seed — for greater clarity, by "not hashcash" we all mean "not finding the hash-preimage of some set"?
22:32:55andytoshi:so if it were looking for hashes which themselves encoded prime chains somehow, that would be hashcash?
22:33:41gmaxwell:I mostly think of hashcash as some function where you have data and invoke H(data||nonce) until the result is under some threshold.
22:34:11gmaxwell:and H() is hashlike, e.g. the result is uniform.
22:34:36gmaxwell:H(useful(H(data||nonce)) is hashlike, for example.
22:35:04gmaxwell:er H(data||useful(h(data||nonce))) for clarity
22:35:10andytoshi:ok, i would generalize that slightly to say "in some set" rather than "under some threshold". but i also think uniformity is essential, so it works the same
22:49:07andytoshi:so another way to get useful POW, which i'd still call hashcash, is usefulp(hash(data||nonce))
23:07:17jcorgan:has anyone calculated the lower bound of J/sha256^2
23:07:56gmaxwell:you dont have to mine using sha256^2.
23:08:22zzyzx:zzyzx is now known as roidster
23:08:29phantomcircuit:jcorgan, it's very very low
23:08:47phantomcircuit:but you can only get there is you run at ridiculously low frequencies
23:09:00roidster:roidster is now known as Guest29316
23:09:09gmaxwell:There may be ways to restate execution of the function (or perhaps n concurrent executions) such that the result is equal to sha256^2 with arbritary probablity but uses less energy than an any perfect implementation of sha256^2 can use.
23:11:31phantomcircuit:gmaxwell, darn, latest sp firmware is bad
23:11:53phantomcircuit:input_voltage < 130, limit power to 1100
23:11:54phantomcircuit::/
23:11:58phantomcircuit:except it's 230
23:15:10jcorgan:phantomcircuit: so J/hash grows supra-linearly with frequency? is that due to physics or due to some implementation decision?
23:15:29gmaxwell:amiller: I have this notion that that bloom+patricia datastructure suggests an authenticated data structure which is order invariant, always balanced, and update-composable like a plain patricia one but results in shorter proofs.
23:16:34jcorgan:i have not had enough coffee yet this morning to safely expose my brain to this channel
23:16:56phantomcircuit:jcorgan, physics
23:17:14gmaxwell:jcorgan: power is related to the voltage squared times frequency. And ususally voltage is related to frequency in that you need more drive voltage to get faster rise times, so effectively you have a cubic relationship between frequency and power.
23:17:36amiller:gmaxwell, hm, if so should fit within my generalised ads scheme nothing special about the merkell part
23:17:49jcorgan:oh, that, yeah, i'm familiar with. i thought there was some other thing involved.
23:18:05phantomcircuit:jcorgan, except on top of that you have issues with these chips of noise
23:18:47phantomcircuit:pushing hundreds of amps through them results in a ton of rf noise, which causes interference at lower frequencies
23:19:02phantomcircuit:iirc the hashfast chips basically dont work at all below 750MHz
23:19:06[\\\]:[\\\] is now known as imsaguy
23:19:41imsaguy:imsaguy is now known as [\\\]
23:21:03gmaxwell:(or rather you have some frequency threshold below which the frequency/power relationship should be linear, and above which it goes cubic)
23:21:16gmaxwell:phantomcircuit: thats all just design, not anything fundimental in general
23:24:29phantomcircuit:gmaxwell, right but i suspect building a chip that works at lower frequencies reliably would be more capital intensive
23:24:37c0rw1n:c0rw1n is now known as c0rw|sleep
23:25:26phantomcircuit:gmaxwell, btw did you ever get numbers on down clocking the ct boxes?
23:25:52gmaxwell:phantomcircuit: only to the extent that any additional design consideration at all is more expensive.
23:27:34phantomcircuit:gmaxwell, yeah that's my point :P
23:27:54amiller:andytoshi, here's how i describe the difference between hashcash and a useful function.... the problem is if usefulp(.) has some amortization shortcut
23:28:41amiller:suppose an attacker can generate h(x1), h(x2), h(x3)... h(xn), and determine which of those will have usefulp(x_i) = good in much less time than the cost of actualyl evaluating usefulp directly on each of them
23:49:30maaku:maaku is now known as Guest75548