--- Log opened Fri May 10 00:00:40 2013 02:29 < petertodd> new alt-coin: cacoin 02:30 < petertodd> the PoW function is to come up with a random number, and then your goal is to prove you posess, via a SSL certificate, a DNS name such that H(name) is closest to that number 02:31 < petertodd> (obvs the random number needs to be generated properly, a random beacon of some sort would be good, or a a protocol where the parties precommit to generate one) 02:31 < gmaxwell> closest-to pows are not very scalable... huge floods of traffic. 02:31 < petertodd> I'm sure that'll be the least of cacoin's problems :P 02:33 < petertodd> the other issue with closest too is it's way too easy to find someone was closer after the fact, causing a huge reorg 02:33 < gmaxwell> haha... "this coin is a member of the family HighExternalityCoins" 02:33 < petertodd> yeah, another nifty one would be to use TPM hardware signing keys 02:34 < petertodd> I especially like how you could construct the TPM hardware coin in a way to prove fraud on the part of the tpm hardware vendors 02:34 < petertodd> even if the hardware is not secure 05:35 < warren> sipa: to backport secp256k1 to 0.8.1 I need to redo those last four patches? 06:21 < warren> sipa: nm, figured it out 09:39 < zooko_> petertodd: are you familiar with Hal Finney's Reuable Proofs Of Work? 10:53 < amiller_> i don't like RPOW because it crucially relies on a central/global tpm 11:35 * zooko_ nods 12:21 < petertodd> zooko_: Who isn't in this crowd? :) 12:22 < petertodd> zooko_: amiller is quite correct, although when you have a reserve currency like Bitcoin handy, at least you can move value to and from it to switch tpm's and so on 12:39 < zooko_> Hm. 12:40 < zooko_> Do you know about Physically Unclonable Functions? 13:56 < zooko> Hello. 13:56 < zooko> PUFs 13:58 < amiller_> even pufs are still a poor choice for a global tpm 13:58 < amiller_> everyone concerned would have to agree that it was built correctly 13:59 < amiller_> like landing on the moon 13:59 < amiller_> a puf can't attest to the fact that it is a puf 14:39 < petertodd> amiller_: Indeed. That said, with some cleverness with fraud proofs and what not you can make a TPM manufacture have pretty strong incentives not to allow the TPM security to be cracked. I wouldn't trust it to buy a house, but to buy your morning coffee isn't a big deal. The hard part is making sure the damage from any one hacked TPM is limited. 14:40 < petertodd> I suspect that's what MintChip has planned with their mysterious "additional authentication" fields and what not in the protocol. 15:24 < zooko> I didn't mean to suggest a PUF for a global TPM. I don't even understand how that could work. 15:27 < zooko> Since midnightmagic just told me about a bitcoin theft (over on #tahoe-lafs, he told me about that), it reminds me of a wishlist item I have for future cryptocurrencies: 15:28 < zooko> I'd like to be able to emit spends from a wallet that has no information going into it, only out. 15:36 < gmaxwell> Frequently bad recommendation #123901319 15:37 < gmaxwell> Requires an entirely different architecture where you have persistant balances, reuse addresses, and don't identify the specific funds you're spending. And the last point has a bunch of surprising negative consequences when you work through the details. 15:39 < zooko> Haha. I found out why I didn't automatically rejoin this channel. I join #bitcon-wizards instead. 15:39 < zooko> gmaxwell: I'm not yet convinced that it is a bad idea. 15:40 < zooko> Also, I need to see that list! The other 123901318 are probably very interesting to me... 15:41 < BlueMatt> half of them include the term "DHT" 15:41 < zooko> Heh heh heh. 15:41 < gmaxwell> zooko: sorry, I'm busy atm or I'd find you the better of the several forum threads on it. 15:42 < zooko> gmaxwell: thanks anyway! I long since lost insight into the bitcointalk forum... :-/ 15:42 < zooko> I'm waiting for amiller to ask me what I was thinking of PUFs for, then... 15:42 < gmaxwell> But there are a whole bunch of screwed up corner cases like.... pay alice, pay bob, oops alice's payment didn't have enough fee and is not confirming fast enough, pay alice again with more fee. oops now alice got paid twice and you've ripped off bob. 15:42 * zooko nods. 15:43 < zooko> It makes a case that already exists: malicious or (rarely) accidental double-spending or other weirdness, into a more common case. 15:43 < zooko> Maybe there isn't any "other weirdness". 15:43 < gmaxwell> plus it requires address reuse, which undermines our privacy model. (perhaps seems less bad at the moment, but I expect we'll see existing reuse go down once BIP32 address chains are common, and once the payment protocol is deployed) 15:44 < zooko> Eh, that part could be worked-around. 15:44 < zooko> Yeah, in fact that can be totally eliminated. 15:44 < zooko> In a sufficiently unconstrained-by-compatibility cryptocurrency. 15:44 < gmaxwell> zooko: it makes transaction replacement into double spending. 15:44 < zooko> Err, wait, maybe I'm wrong... 15:44 < zooko> What's transaction replacement? 15:45 < gmaxwell> replacing a transaction with another one such that only one is allowed to survive. An intetional, consentual, harmless (e.g. pays the same parties, but pays them more or increases fees) doublespend. 15:45 < zooko> Hm. 15:46 < amiller_> zooko, indeed, what is it that you were thinking for PUFs and RPOW if not a giant central rpow server staypuft monster 15:46 < gmaxwell> and I mean what you want to do is actually not possible fundimentally, you need to know your balance to spend it.— if you don't you'll randomly doublespend your payments) I just assumed you meant knowing no more than your balance. 15:46 < zooko> gmaxwell: I don't think that's fundamentally true. 15:47 < zooko> I mean, you can *try* to spend it. 15:47 < zooko> You can emit a message that says "I, $PUBKEY_X, hereby transfer to $PUBKEY_Y 10 units. If I have any. Love, X." 15:47 < zooko> I think you are right that how the rest of world deals with that message could get complicated. 15:48 < zooko> And I think you already introduced me to some complications that I hadn't thought of, in the last few minutes. 15:48 < gmaxwell> zooko: yea, great, and when you do this and make multiple spends before one is confirmed (which you can't tell because you have no information) you'll potentially conflict earlier ones. You could have a sequence number, but then a byzantine network loses one of them and none none of your future payments work. 15:48 < gmaxwell> yea, I'm not saying it's impossible, but it has a lot of surprising negative tradeoffs. 15:49 < zooko> amiller_: I want off-line transaction. You and I meet on the dark side of the moon, and I give you something, and you can't communicate with anyone else, but you're satisfied that I've enriched you, so you give me a crate full of valuable ores and we part. 15:49 < zooko> gmaxwell: yeah. 15:49 < zooko> amiller_: but I hadn't thought through the threat of the PUF-manufacturer making duplicable/duplicate PUFs... 15:50 < gmaxwell> zooko: of course, if you're on the dark side of the moon, amiller can't tell if you're broke or not either (and if he knew you weren't he could tell you). :P hard to be satisified that you've been encriched through an IOU from a throwaway identity. :P 15:50 < zooko> Is that threat considered by the PUF literature? 15:50 < zooko> gmaxwell: sorry, I was starting a second stream of conversation there. 15:50 < amiller_> no the PUF threat model begins after the secure manufacturing process 15:50 < zooko> The "deaf and blind spender" is the one I was talking about with you, and the "what's the use of PUFs" was the dark side of the moon. 15:50 < zooko> amiller_: oh darn. 15:51 < amiller_> fwiw i think a rational wallet should attempt double spends autoamtically at all times 15:51 < zooko> amiller_: haha! Good point. 15:51 < amiller_> and insist on innocence blaming something something distributed keys etc for the discrepeancy 15:51 < zooko> ☺ 15:51 < zooko> I agree that would be a civic-minded thing to do. 15:52 < zooko> vulnerability to DoS, inefficient cheat-detection, these are like garbage cluttering up our fair city. 15:52 < zooko> Don't contribute to the worsening problem by refraining from attempting double-spends! 15:53 < zooko> amiller_: well, do you believe in a PUF that you can be sure the manufacturer of it didn't manufacture any duplicates? 15:53 < zooko> How about a program to make PUFs on your home 3D printer? 15:54 < amiller_> i believe in affordable PUFs yes and that they're probably awesome for small / subjective networks if not the big global ones 15:54 < amiller_> for example i construct a PUF and mail it to you 15:55 < zooko> I want to know that not only the person who handed me the PUF as we floated in the lee of the moon 15:55 < zooko> but also that nobody in history, can have generated an identical PUF. 15:55 < zooko> And it only has to be worth as much as a box of valuable ores. 15:56 < amiller_> ok so i print a few PUFs for you and your friends, now you and your friends go to mars and you can still safely transact using the PUFs, no communication back to me required 15:56 < amiller_> and when we synch up again after the long eclipse, we can still all trust those pufs 15:57 < amiller_> so yes i think pufs are swell (pun), it's just still a trusted-originator scenario 15:57 < zooko> I have the feeling you might know of a way to use PUFs for some kind of computation that I don't know of. 15:58 < zooko> So you make some PUFs for me and my friends. 15:58 < zooko> What is the "trust-origination" part? 15:58 < zooko> Is it that we can't be sure you didn't make duplicates, or retained the ability to do so? 15:58 < amiller_> you had to be sure i actually made a PUF 15:58 * zooko thinks. 15:59 < amiller_> suppose i make a PUF and a non-PUF at the exact same time 15:59 < amiller_> i give you one of them. 15:59 < amiller_> you cannot tell whether i gave you the puf or the non-puf 15:59 < amiller_> but if i gave you the non-puf then everything is totally insecure 15:59 < zooko> I see. 15:59 < zooko> Darn. 16:01 < warren> hmm, 0.8.1 -> 0.8.2 changes the minimum fee from 0.0005 to 0.0001? Users could upgrade to 0.8.2 quickly, but how do they know it is safe to begin using the lower fees? 16:06 < gmaxwell> warren: the new fees relay already, so its safe as soon a one large miner applies the new criteria. 16:07 < warren> So users can reduce fees, at the risk of delays, as usual. 16:08 < warren> I hope the dust relay protection makes a difference. IMHO ~5k satoshi's was too small a threshold. 16:08 < gmaxwell> it's also not a "minimum fee" gah. it's important to speak clearly about this. It is the base fee per kilobyte. 16:08 < warren> ah, sorry. 16:09 < gmaxwell> warren: any higher would have had SD paying people to attack the change. 16:09 < gmaxwell> (directly or indirectly) 16:10 < gmaxwell> (and also wouldn't have been so obviously harmless: you would have had to make a value judgement about SD's business practices) 16:10 < warren> I might have missed this, how does it handle if change would fall below that threshold? 16:11 < gmaxwell> same way it always has, converts it to fees. Keep in mind, we've long had that behavior. 16:12 < gmaxwell> because change <0.01 results in not qualifying as a free transaction, thus a fee of 0.0005 BTC. 16:12 < gmaxwell> so when your change was less than 0.0005 it instead turned it into fee. 16:12 < warren> ah 16:12 < warren> good 16:27 < warren> FYI on those silly alt coins. A few weeks ago "Feathercoin" started, clone of Litecoin, identical in every way except 200 subsidy per block instead of 50. It went straight onto multiple exchanges and began a massive bubble, at one point it was 5 x more profitable to mine FTC and sell for BTC than to mine BTC directly. Difficulty skyrocketed. For the past few days their difficulty has been stuck at this level, with more and more miners qu 16:27 < warren> itting the estimated time to target is getting longer every day. Now their dev is talking about hardforking for faster retargeting, like Terracoin's "innovation". 16:29 < warren> It's frightening to see how many miners jump on the latest bandwagon, over and over again. 16:30 < RedEmerald> agreed 16:30 < zooko> Oh hi there, RedEmerald. 16:30 < RedEmerald> howdy 16:33 < zooko> Happy to find out that Adam Back is going to bitcoin2013. 16:37 < RedEmerald> i wish i had the time for that 16:37 < RedEmerald> too many conventions planned for this year already 20:09 < amiller_> amiller_: and as has been said before, I think it's too big of an economic change to be anything but a non-starter in bitcoin. Perhaps we'll get an ECDSA break that lets us make old utxo unspendable... but who knows. 20:09 < amiller_> zooko, ^^ 20:10 < amiller_> i guess i understand the point about the big economic change thing but i'm not sure where to go from there 20:10 < amiller_> maybe just prepare the solution in case there's an ecdsa break like you said? 20:11 < amiller_> or consider it as a thing so we don't have to delete any old coins that are grandfathered in... 20:13 < amiller_> a good argument is that at some point the ad hoc solutions to inflating utxo will be worse than the parking meter approach which is straightforward and reasonable and *not demurrage* 20:21 < gmaxwell> even with a break, what evidence I'm seeing so far is that people still will oppose making old outputs unspendable. I don't know if this is just a sampling error from the lolbertarians in the bitcoin community or what. But I do think thats the best chance. 20:22 < gmaxwell> people were agressively calling the no-create-dust changes recently theft. 20:23 < amiller_> well right now they are expecting free rent forever and that's obviously an unsustainable business 20:23 < amiller_> unless they're squatters 20:24 < amiller_> i mean i know it's not you that disagrees with me here you're just explaining to me what the consensus seems to be 20:25 < gmaxwell> well, it's not clear how unsustainable it is.. the utxo set can't grow faster than the blockchain. Soooo under the current network rules .... 20:25 < gmaxwell> even if you ignore that, with current granularity, if we deny 0 value outputs, the maximum utxo size is about 45 PB which is clearly not infinite. 20:26 < gmaxwell> if you're a member of the church of infinite-exponential-improvement-of-technology 45 petabytes sometime in the far future sounds pretty good. 20:26 < gmaxwell> (but there is a reason I describe that as a religion...) 20:27 < RedEmerald> i dont think 45 PB is outside the realm of possibility for a home computer 20:28 < RedEmerald> theres some cool storage tech being worked on that makes for some really dense storage 20:30 < zooko> Hi, amiller_. 20:38 < zooko> Was the no-create-dust patch motivated by utxo storage being an unfunded externality? 20:39 < warren> zooko: that has been one of the motivations for months now. 20:41 < gmaxwell> there are a bunch of motivations, thats one of them but probably the least short term significant right now. 20:43 < warren> I did like the ideas of eventually expiring tiny uxto's if they fail to pay rent. 20:44 < zooko> gmaxwell: but, you're saying that motivation may be unfounded? 20:45 < zooko> I.e., a proliferation of utxos may be not too costly, even though it is an externality? 20:45 < gmaxwell> zooko: at what timescale? 20:45 < zooko> I guess that would imply that there is some limit on it, possibly just a natural limit on people *wanting* to make utxos? 20:45 < zooko> gmaxwell: well, I don't know. 20:45 < zooko> I thought you were saying maybe the current rules would be sustainable. 20:46 < gmaxwell> we have to worry about all timescales. ... if you assume continued acceleration of technology and us not allowing zero value txo, then its not an issue in a sufficiently long timescale because the number of possible non-zero value utxo is finite. 20:47 < gmaxwell> zooko: "There are levels of survival we are prepared to accept" ... right now it can grow about 50gbytes/year. 20:47 < zooko> Uh, what? 20:47 < zooko> Oh, if every satoshi is its own utxo. I see. 20:47 < gmaxwell> Right 21e14 utxo. 20:48 < gmaxwell> If the utxo set were already its maximum size, e.g. about 200gbytes... then I think its very likely bitcoin would fail: that kind of cost to run a full node would not be justified by usefulness and significance of bitcoin. 20:48 < zooko> Another way of putting that is that the problem of storage of utxos would eventually impose a limit on smaller-ganularity payments. 20:49 < zooko> What's 200 GB? If every satoshi were a utxo, then it would take only 200 GB to store it all? 20:49 < zooko> That sounds way too small. 20:49 < gmaxwell> Though 200gbytes isn't some horrible unattainable value... basically even if there is no long term problem (not clear!) there can still be a short term one with the system becoming costly to operate faster than it becomes valuable to use. 20:50 < gmaxwell> zooko: no, the chain can't grow faster than ~50gbytes/yr due to the maximum blocksize. So every satoshi couldn't be a seperate utxo yet. 20:51 < zooko> gmaxwell: ok. 20:51 < zooko> Thanks. 20:51 < zooko> Time for dinner with my kids, then hopefully I'll get back on IRC... --- Log closed Fri May 10 22:00:20 2013 --- Log opened Fri May 10 22:00:33 2013 --- Log closed Sat May 11 00:00:43 2013