| 00:42:24 | cpacia: | cpacia has left #bitcoin-wizards |
| 00:50:20 | omni: | omni is now known as Guest73638 |
| 02:26:18 | SDCDev: | SDCDev is now known as pistoff |
| 02:26:33 | pistoff: | pistoff is now known as pistdov_ |
| 02:27:03 | pistdov_: | pistdov_ is now known as Nomster |
| 04:23:34 | petertodd: | gmaxwell: re: prob payments, writeup? I know people who have use-cases for this |
| 04:24:30 | petertodd: | gmaxwell: also, re: sign-to-contract (https://bitcointalk.org/index.php?topic=893898.msg9861102#msg9861102) has anyone implemented this/reviewed the crypto? |
| 04:30:59 | bramc: | probabilistic payments should be implementable with the oakland lottery trick |
| 04:31:34 | petertodd: | bramc: that soo doesn't turn up any useful google results :) |
| 04:32:10 | bramc: | petertodd, https://eprint.iacr.org/2013/784.pdf |
| 04:34:17 | bramc: | Basically I can gift you a utxo if you can guess the length of a preimage correctly |
| 04:35:10 | bramc: | It might be a few minutes of arrow-drawing to make it so that everything works out correctly and there are literally no transactions committed in the event where you lose |
| 04:35:24 | petertodd: | bramc: oh, that's the guys who did that magic scriptPubKey that actually did something useful with OP_SIZE... |
| 04:35:58 | gmaxwell: | petertodd: no writeup yet. It's much better IMO than the OP_SIZE trick. |
| 04:36:17 | bramc: | gmaxwell, What's the other trick? |
| 04:36:31 | gmaxwell: | as far as sign to contract. New revelation, so not extensively reviewed yet. Though the security argument is basically that of pay to contract. |
| 04:37:25 | petertodd: | gmaxwell: cool, sign to contract is highly useful for implementing uncensorable embedded consensus schemes conveniently |
| 04:38:22 | bramc: | What is 'sign to contract'? |
| 04:38:29 | gmaxwell: | Yes, I'm excited about it. I think it's finally a scheme where I'd feel happy implementing timestamping as a standard feature in bitcoin-qt. e.g. queue of hashes, whenever you transact it commits to the queue as a side effect of a signature and writes out the proof. |
| 04:38:31 | petertodd: | bramc: make a signature commit to hash |
| 04:39:04 | bramc: | I'm not following |
| 04:39:38 | petertodd: | bramc: so, I want to make a sig, such that it depends on H(msg), such that I can't pretend it depended on H(msg') instead |
| 04:39:50 | gmaxwell: | bramc: I can, as a side effect of a signature, prove some data existed as of a particular time and that it was asscoiated with the transaction. |
| 04:40:14 | petertodd: | bramc: see "Use committed encryption keys for anti-censorship" at the bottom of this: https://github.com/petertodd/uniquebits |
| 04:41:31 | petertodd: | bramc: which incidentally mostly solves adam back's issues with doing hidden encrypted transactions re: miners censoring the revealing of them, as the revealing of those encryption keys can be done lazily (he may have already come up with this - that was a long discussion) |
| 04:41:43 | gmaxwell: | bramc: or see the appendix a in the sidechains whitepaper for a scheme performing such a commitment with the payment pubkey rather than the signature. |
| 04:42:26 | gmaxwell: | petertodd: kinda we always knew it could be revealed later, there just wasn't a way to guarentee that parties ever heard it (unless you go with the 'all the history rides with the payment channel' approach) |
| 04:42:48 | petertodd: | gmaxwell: which is of course what I'm actually implementing |
| 04:42:58 | gmaxwell: | I figured. |
| 04:43:09 | bramc: | How can that be used for probabilistic payment? |
| 04:43:20 | bramc: | I had a crazy idea today |
| 04:43:22 | petertodd: | gmaxwell: (though truncated history based on trusted validator - can swap out miner signature equally well) |
| 04:43:23 | gmaxwell: | there were two seperate questions, PP and sign to contract. |
| 04:43:45 | gmaxwell: | petertodd: yes, reissuance effectively. |
| 04:43:50 | petertodd: | gmaxwell: yup |
| 04:44:04 | petertodd: | gmaxwell: which hilariously looks almost identical to a blockchain... |
| 04:44:11 | gmaxwell: | (though I still think thats only of moderate value, ... have the issuer keep the whole ledger :) ) |
| 04:44:34 | gmaxwell: | (I mean the general model of using a blockchain like system when there exist a party that could safely reissue) |
| 04:44:51 | gmaxwell: | but opinions differ and I respect that, I'm not actually sure how little value I think it is. |
| 04:44:53 | petertodd: | gmaxwell: merkle sum everything for trust/fraud-proofing of course |
| 04:45:17 | gmaxwell: | sure sure, though you can make recepit producing purely centeralized systems too. |
| 04:45:22 | bramc: | Would it be possible to cram an IP address into the signature for a coin, and then have client machines use SPV to find the latest thing that coin's been paid to and extract the IP address from the signature, to make a censorship-resistant form of DNS lookup? |
| 04:45:32 | petertodd: | gmaxwell: meh, whatever, issuers demand this stuff and doing the whole nine yards of it gives them operational flexibility |
| 04:45:50 | bramc: | On pay to contract: I see how you can use it as a hack around op_size, but isn't it not supported by current bitcoin opcodes? |
| 04:46:26 | gmaxwell: | bramc: spv in the bitcoin model can't be used for output lookups like that, though it's possible to have a commitment over a search tree that can be. What you're describing sounds like namecoin (or rather what namecoin should be) |
| 04:47:27 | gmaxwell: | petertodd: yea, I wasn't trying to debate it in any case; as I said, I accept opinions differ. My views on that subject are only strong enough that I feel compelled to mention "blockchains are not pixie dust" whenever it comes up. :) |
| 04:48:09 | gmaxwell: | Maybe you have some idea at the number of people I've encountered in the last couple months who want to use blockchains for applications which make _no_ sense to me, which they only can justify with a bunch of handwaving. :) |
| 04:48:16 | petertodd: | gmaxwell: sounds like you haven't seen any of my recent talks... I spend half my professional life saying that |
| 04:48:49 | moa: | hand-waving?? |
| 04:48:52 | gmaxwell: | I knoe you do, audience wasn't you there. It's just automatic now. :P #include (gah, we've become the new "DHT") |
| 04:49:18 | gmaxwell: | moa: you're not familar with the term? Whats your native language? |
| 04:49:42 | moa: | sign language lol |
| 04:49:47 | bramc: | gmaxwell, This seems like the sort of thing where you would specifically NOT want to start a separate currency, I don't understand what you mean by 'commitment over a search tree' though |
| 04:50:10 | gmaxwell: | moa: haha! well that term might be vaguely insulting then! sorry about that. |
| 04:50:17 | moa: | jk |
| 04:50:59 | gmaxwell: | (I was going to see if google translate would translate the idiom, I assume all languages have an idiom for this. It just means a deflecting answer, "maybe this, maybe that. Oh look aliens!") |
| 04:51:30 | moa: | yeah i'm more than familiar ... usually in an academic context |
| 04:53:09 | gmaxwell: | bramc: yea namecoin is an example of the sillyness of a new currency for everything. It needs some ratelimiting token to prevent flooding though. A normal hash tree can only prove membership. In bitcoin SPV the hashtree shows that a block included a transaction. What you cannot prove (in bitcoin today) is that the very next block didn't spend that output and move the name to a new IP; except |
| 04:53:15 | gmaxwell: | by revealing the whole block. |
| 04:54:45 | gmaxwell: | But any query on any data structure can be converted to an authenticated query with complexity related to the number of bits the non-authenticated version read. E.g. you can see a normal hash tree as creating an authenicated version of an array lookup. |
| 04:55:18 | gmaxwell: | You could alternatively make a authenicated version of a map (e.g. an authenticated red-black tree), that can support looking up a key and proving the result of the lookup. |
| 04:56:51 | gmaxwell: | which is actually what you need for this application, I wrote about it some way back here: https://bitcointalk.org/index.php?topic=21995.0 ... though the terminology there is kind of odd because that was before we understood these ideas in the more general sense that we understand them now. |
| 04:58:31 | petertodd: | "hearn: For Namecoin this is likely not a big problem. You can just download a signed snapshot of the database from the same place you downloaded the software. |
| 04:58:34 | petertodd: | " <- lol |
| 04:59:12 | gmaxwell: | Yea, ... well at least we know that Mike wasn't corrupted by secret agents after Bitcoin became popular. :) |
| 04:59:14 | petertodd: | re, "the compelxity related" - out of curiosity is that an actual proven statement, or guesswork |
| 04:59:24 | petertodd: | gmaxwell: time machines |
| 04:59:31 | Guest73638: | namecoin? why wouldn't you want to put a name resolution system onto a blockchain? |
| 04:59:52 | petertodd: | Guest73638: human reasons - people *want* there to be centralized legal systems to audicate disputes |
| 04:59:56 | kanzure: | petertodd: did you reply to the factom email (aka did i miss that)? |
| 05:00:21 | gmaxwell: | petertodd: it's proven, I mean, amiller actually implemented some haskell magic code that lets you write an inductive expression of your algorithim (e.g. recursive) and it makes an authenticated query out of it. |
| 05:00:27 | Guest73638: | petertodd: that's not a sufficient reason *here*, given you can say the same for money. |
| 05:00:41 | kanzure: | petertodd: (i was alarmed by their "Any fork in publication is obvious as it would require different Bitcoin addresses to be used" statement...) |
| 05:00:57 | gmaxwell: | kanzure: well you can make a blockchain system that supports that, and even makes the lines of trust clear. |
| 05:01:14 | petertodd: | kanzure: oh, yeah, I saw that today - want to write up a proper reply given I'm going to be basically saying they're business model is silly |
| 05:01:23 | kanzure: | petertodd: fair enough |
| 05:01:31 | gmaxwell: | kanzure: though the consistency requirements for names is perhaps somewhat lower than e.g. a currency. Because no one ever merges names, and names are inherently not fungible. |
| 05:01:35 | kanzure: | gmaxwell: hm? it sounds like they can just be using multiple addresses already, and you woulnd't be able to detect that |
| 05:01:41 | kanzure: | oh, i am not talking about names |
| 05:01:45 | kanzure: | you have wires crossed |
| 05:01:59 | gmaxwell: | sorry thought you were responding to Guest73638 |
| 05:01:59 | petertodd: | Guest73638: well *here* we can just use the secure and globally unique legs of zooko's triangle... |
| 05:02:15 | kanzure: | hehe |
| 05:02:46 | bramc: | gmaxwell, so is the problem that you can't spv asking 'what happened to to coin X'? |
| 05:03:03 | gmaxwell: | anyways, anyone thinking of out namecoining namecoin should have read https://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks_less (actually I should update that to include the pairing crypto p2sh^2 proofs) |
| 05:03:39 | bramc: | Or is it that you can't get proof of that record of what happened to it? |
| 05:03:42 | gmaxwell: | bramc: not in bitcoin today. Its conceptually simple to support that, it just requires additional commitments. For bitcoin it's only of moderate importance, for namecoin it's quite critical. |
| 05:03:46 | Guest73638: | well let's just be honest and admit that we're boohooing namecoin because it detracts from Bitcoin. |
| 05:03:55 | Guest73638: | not that i have a problem with it. |
| 05:04:04 | gmaxwell: | bramc: I can prove to you something happened to it, but I can't prove to you nothing happened to it. Which means I can lie and say nothing happened. |
| 05:04:12 | gmaxwell: | Guest73638: wtf? |
| 05:04:34 | Guest73638: | oh sorry, i thought that was the case. |
| 05:04:40 | petertodd: | Guest73638: wtf? |
| 05:04:41 | kanzure: | why did you think that |
| 05:04:50 | bramc: | gmaxwell, there's a real question as to whether that sort of attack matters |
| 05:04:59 | Guest73638: | because i don't see a reason why namecoin shouldn't be on a blockchain. |
| 05:05:01 | bramc: | You could also just not answer the question at all |
| 05:05:07 | moa: | namecoin's merge-mining example is a useful contribution |
| 05:05:11 | Guest73638: | i mean, a name resolution system. |
| 05:05:11 | kanzure: | Guest73638: that's not what i asked |
| 05:05:35 | Guest73638: | sorry, what are you asking |
| 05:05:36 | kanzure: | Guest73638: i asked why did you think "well let's just be honest and admit that we're boohooing namecoin because it detracts from Bitcoin" |
| 05:05:36 | petertodd: | Guest73638: point is, the very *idea* of namecoin isn't somehting that has much chance of getting adopted - like I say, people *don't like* decentralized first-come-first-serve naming systems |
| 05:06:04 | gmaxwell: | Guest73638: I suspect I've made more technical proposals that would _improve_ namecoin than anyone else, going back years. It's development was largely abandoned, and left in a completely insecure state. If you want me to start "boohooing" I'd be glad to, but thats not what anyone was doing. Right now namecoin _cannot_ support a secure lite mode resolver, resolving names requires having the hu |
| 05:06:10 | gmaxwell: | ge child porn filled blockchain locally, or trusting someone. This is stilly, fixing it isn't technically hard. I understand there is some active development now, so maybe they'll fix some of these things soon. (could even be in progress for all I know) |
| 05:06:15 | petertodd: | Guest73638: we think they do, but in reality businesses and average people don't because you can't use the legal system to "make things right" - nothing to do with tech |
| 05:06:22 | gmaxwell: | And yea, namecoin has made a useful contribution to the space for sure. |
| 05:06:53 | gmaxwell: | s/stilly/silly/ :) |
| 05:06:56 | Guest73638: | petertodd: but they like decentralized steal-it-if-you-can systems? // kanzure: oh i just thought that was the case, because that's the only reason i can really think of for knocking namecoin per se, for Bitcoin devs. |
| 05:07:33 | petertodd: | Guest73638: no, they like centralized "let the legal system adjudicate" systems, which we've seen over and over again |
| 05:07:57 | gmaxwell: | Guest73638: If that was your response to the _very explicit_ statements about factual technical limitations of the system that anyone redoing it should improve then you have no business in this channel. |
| 05:09:30 | kanzure: | was the sign-to-contract an attempt at preventing private key related bits when signing? |
| 05:09:34 | gmaxwell: | (I am indeed guilty of being unfairly negative about some things sometimes, but I'll be damned if I'm going to tolerate someone making that kind of accusation about a basic, factual, technical discussion) |
| 05:09:55 | Guest73638: | gmaxwell: well, i'm trying to resolve this statement you made: "bramc: yea namecoin is an example of the sillyness of a new currency for everything." |
| 05:09:57 | kanzure: | (you are so far in the clear that it's hilarious) |
| 05:10:14 | Guest73638: | i'm not making any accusation of technical discussion, just wondering what you meant by the above. |
| 05:10:18 | gmaxwell: | kanzure: the purpose of sign to contract is just to get a commitment into a transaction 'for free', no censorship risk, no space added. After working with it some I realized it also created a degree of sidechannel supression. |
| 05:10:38 | kanzure: | ah okay |
| 05:12:13 | gmaxwell: | Guest73638: naming is a useful service. Just like washing cars is a useful service. My local car wash didn't establish a new currency for their business when they opened up, and if they did they likely wouldn't be successful... it's just overhead, and creates risks. bramc expressed the view that it seems odd to create a whole new system and currency for a functionality that could be accomplish |
| 05:12:15 | petertodd: | kanzure: note how sign-to-contract and nSequence share some commonalities in terms of what part of the transaction is signing what, and what you can do with that |
| 05:12:15 | kanzure: | as fr the other thing, there's no good reason to think that a key-value store needs a currency |
| 05:12:19 | gmaxwell: | ed without a new currency and I agree. |
| 05:13:16 | bramc: | gmaxwell, I would assume/hope that anybody creating a new cryptocurrency from scratch would make the root of a merkle tree of all unspent coins be included in each block. This is possibly hopelessly naive of me... |
| 05:13:31 | petertodd: | bramc: that's like, 500 lines of code, ugh |
| 05:13:41 | petertodd: | bramc: brb, gonna find some cute animal pics |
| 05:13:41 | kanzure: | dozens of lines |
| 05:13:51 | petertodd: | kanzure: ok, dozens + unittests ;) |
| 05:14:24 | gmaxwell: | bramc: yea basically no one has. Also, its more code than you might think if you need it to support arbritary lookups. It also makes the datastructure more normative, so you don't want to be too sloppy about it. |
| 05:15:16 | petertodd: | gmaxwell: note that you can make the rules be that you check validity of it only if it's included, which allows you to later soft-fork out the (U)TXO commitment-like thing |
| 05:15:38 | bramc: | gmaxwell, I'm thinking there should be a way of canonically going from the blockchain to the merkle tree, to keep the number of funky edge cases under control |
| 05:16:07 | gmaxwell: | petertodd: yea but so long as it can be included you have to track its state so you can validate it and enforce that rule, so if keeping track of it is costly, that may not be good. |
| 05:17:01 | petertodd: | gmaxwell: ah, but see, when you soft-fork it out you can ditch all that stuff - you get the best of both worlds by ensuring there's no real disadvantage to the commitment as you have to calculate it anyway, yet you can uprade it later |
| 05:17:13 | gmaxwell: | bramc: yes, well depends on the tree structure used. For example a normal red/black tree changes its geometry depending on the order data was inserted... wherease a partricia trie does not, it's just a determinstic function of the data. lots of little details to worry about in a commited data structure. |
| 05:17:20 | petertodd: | gmaxwell: *no real disadvantage to including the commitment in your blocks |
| 05:17:23 | bramc: | I'm of split mind right now about whether new block chains should worry about scaling from the get go. I'm convinced that it's a good idea to put a hard limit on volume at the beginning the way bitcoin has, so it's really a question of whether possible eventual scaling problems should can in principle be solved via raising a limit or doing some reorg. Either is a hard fork... |
| 05:17:33 | gmaxwell: | petertodd: oh by preventing the old one? I suppose thats true indeed. |
| 05:17:43 | petertodd: | gmaxwell: exactly, and that process can go on forever |
| 05:17:43 | Guest73638: | how about a merkle tree for unspent coins, but not based on UXTO but based on account balances with incrementing account sequence numbers? |
| 05:17:59 | petertodd: | bramc: we don't know how to scale blockchains yet |
| 05:18:29 | petertodd: | bramc: closest thing we have to answering that question is jdillon's proof-of-stake voting scheme, and that's a crazy political hack (though clever) |
| 05:18:30 | gmaxwell: | Guest73638: the sequence number approach results in unprunable data to prevent replay.. also forcing people into consistent accounts breaks the only privacy story bitcoin has. |
| 05:19:01 | Guest73638: | how is it unprunable? and you wouldn't be forcing them, you could choose to spend all coins all the time. |
| 05:19:26 | petertodd: | bramc: my guess is treechains can scale *non-validating* blockchains, but that's a very, very specific approach and looks nothing like blockchains as we know them |
| 05:19:38 | gmaxwell: | (god knows why people use bitcoin as it is today; it's almost unbelievable that people would use a system where your landlord or a mugger can see your income, or where your competition can see your prices and sales volumes... but I guess this is less of an issue because so much of the activity is just speculation) |
| 05:19:40 | bramc: | petertodd, You'd basically have to enable sharding, which is something which can be planned for but there might be some immediate costs for possible far off benefits |
| 05:19:59 | gmaxwell: | Guest73638: because you can not forget any previously used sequence number ever, if you're to prevent replay. |
| 05:19:59 | bramc: | petertodd, What do you mean by 'non-validating'? |
| 05:20:29 | petertodd: | bramc: sharding is an old idea - I may have actually been one of the first people to propose it actually - and it has some ugly failure modes when parts of the system lie |
| 05:20:51 | petertodd: | bramc: somewhere on bitcointalk is my "ring-of-blockchains" thought experiment |
| 05:21:26 | petertodd: | bramc: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html |
| 05:22:34 | Guest73638: | gmaxwell: interesting. though if you require the inclusion of the latest-ish block hash, and always keep some blocks unpruned, would work just as well. |
| 05:22:54 | bramc: | petertodd, Yes, sharding has obvious problems, hence my being convinced that just putting a flat limit is a perfectly fine thing to do to begin with |
| 05:23:37 | bramc: | Currently bitcoin is doing about 1 transaction/second, it has a hard limit at around 40 transactions/second, not anywhere close to being a problem right now |
| 05:23:56 | petertodd: | bramc: 7tx/second you mean? (and that's a kinda bs estimate) |
| 05:24:00 | Guest73638: | sharding seems fine if you get away from 2 way pegging, perhaps even more desirable to have currencies by geographic region and let the market handle the rest. |
| 05:24:18 | petertodd: | Guest73638: splitting up chains reduces security |
| 05:24:30 | Guest73638: | petertodd: oh right, proof-of-work-land. |
| 05:24:49 | bramc: | petertodd, A thing I read the other day said 110k/day |
| 05:25:00 | bramc: | At some point I'll start gathering some data on this directly myself |
| 05:25:33 | petertodd: | bramc: https://en.bitcoin.it/wiki/Maximum_transaction_rate |
| 05:26:26 | petertodd: | bramc: I wrote that, though it doesn't take into account things like multisig |
| 05:26:29 | moa: | it's in the 80-90k/day currently |
| 05:26:33 | gmaxwell: | Guest73638: has nothing to do with proof of work, though your comment suggest you might benefit from reading some of the little papers on the actual properties a DMMS system needs to meet to be useful (the asic faq and proof of stake papers on bitcoin.ninja). |
| 05:27:13 | petertodd: | Guest73638: splitting up chains even in the proof-of-stake model reduces security |
| 05:27:22 | petertodd: | Guest73638: (to the extent you can say it has any at all) |
| 05:27:33 | bramc: | Guest73638, Why would one care about geographic localities? |
| 05:28:32 | Guest73638: | bramc: because monetary policy is a political issue, and bitcoin's scheme is but one kind. |
| 05:29:21 | bramc: | bitcoin specifically gives no flexibility whatsoever to 'monetary' policy |
| 05:29:34 | Guest73638: | petertodd: not true. you can have security guarantees that cross chain boundaries. |
| 05:29:51 | Guest73638: | bramc: exactly my point. |
| 05:30:03 | moa: | mmm, what does 'policy' even mean in that context I wonder? |
| 05:30:36 | moa: | like what is the monetary policy of copper |
| 05:30:47 | Guest73638: | moa: maybe you want a local government that experiments with some mixture of minimum guaranteed income. maybe taxes are integrated. whatever. |
| 05:31:06 | moa: | oh |
| 05:31:17 | Guest73638: | moa: maybe people become dissatisfied with the distribution of the coins, regardless of the merits of its implementation. |
| 05:31:19 | moa: | sounds convoluted and unworkable |
| 05:31:34 | Guest73638: | moa: a human condition |
| 05:31:59 | moa: | probably best left at the door of a technological discussion forum then |
| 05:32:05 | Guest73638: | bramc: also it'd be nice to have a coin that works just fine even in the face of an internet split |
| 05:32:34 | Luke-Jr: | Guest73638: what you describe is inherently centralised, and has no need for a decentralised consensus system |
| 05:32:54 | Luke-Jr: | you can implement it more efficiently just by having the local government run a money server |
| 05:32:58 | Luke-Jr: | like paypal or such |
| 05:33:03 | Guest73638: | luke-jr: how so? it's inherently decentralized, to let people choose or rotate their own system. |
| 05:33:10 | Guest73638: | luke-jr: oh |
| 05:33:14 | petertodd: | Guest73638: off-topic for #wizards... |
| 05:33:26 | Guest73638: | luke-jr: well you can't start a new government if the current one won't let you start one. |
| 05:33:37 | Guest73638: | petertodd: i was answering the question about motivations for multiple blockchains. |
| 05:33:43 | Luke-Jr: | Guest73638: s/government/central bank/ |
| 05:33:55 | Guest73638: | government need not be centralized. |
| 05:34:13 | Luke-Jr: | you can't enumerate people with a decentralised system |
| 05:34:33 | Luke-Jr: | Guest73638: centralised government works better |
| 05:34:44 | petertodd: | Guest73638: monetary policy isn't strictly coupled to the blockchain anyway, as people can easily choose to use tokens embedded within it with any policy they desire |
| 05:35:18 | Guest73638: | i gotta run. thanks for the talk. |
| 05:35:20 | Luke-Jr: | actually, what would a "non-centralised government" even mean? I can't make sense of it.. |
| 05:35:29 | Guest73638: | :) |
| 05:35:30 | moa: | agoraphobia? |
| 05:35:53 | Guest73638: | dodophobia |
| 05:43:22 | bramc: | petertodd, How much is that improved if regular transactions use scriptkeys just for the hash compression? |
| 05:44:16 | petertodd: | bramc: I accounted fo rthat I think |
| 05:44:36 | petertodd: | bramc: I'm even assuming everyone combines their tx's together with coinjoin |
| 05:45:04 | bramc: | And it's still 322 bytes/transaction? |
| 05:46:00 | petertodd: | bramc: I guess so? do the math yourself :) |
| 05:46:10 | op_mul: | "< gmaxwell> (god knows why people use bitcoin as it is today" the numbers and letters in the address make it confusing. people honestly believe that using Bitcoin they are anonymous, or at least private. when neither is actually true on any level. |
| 05:46:33 | bramc: | I don't know all the numbers, but if a hash is 256 bits, that's 32 bytes, with two inputs and two outputs that's 128 bytes |
| 05:46:40 | petertodd: | op_mul: lets not get too optimistic about Bitcoin's transparency... even just plausible deniability is pretty good |
| 05:46:54 | petertodd: | bramc: wut? |
| 05:47:50 | bramc: | Oh wait those have to be actual signatures on the inputs, 'scuse me |
| 05:47:58 | op_mul: | petertodd: most people don't have that, though. transactions are often painfully obvious due to dust merging. |
| 05:48:25 | op_mul: | bramc: they could be smaller if we used EC pubkey recovery in transactions, like we do for signed messages. or if the encoding was slightly saner. |
| 05:48:57 | petertodd: | op_mul: the amount of third-party records you need to get to deanonymize people isn't trivial at all |
| 05:49:06 | op_mul: | (signatures are needlessly encoded, burning like 6 bytes per signature) |
| 05:49:35 | op_mul: | oh and people still use uncompressed pubkeys, which makes transactions huge. |
| 05:50:46 | op_mul: | petertodd: tyake changetip for example. I can identify almost all of their deposits due to them making the cold storage address public and static. I don't need any private data to be able to work out what goes in and out of their system. there's no plausible deniability there. |
| 05:51:27 | petertodd: | op_mul: sigh... try figuring out which *user* that was related too - it's very non-trivial for your average investigator |
| 05:53:10 | op_mul: | petertodd: any task is hard if you assume buffoonery. |
| 05:56:44 | op_mul: | and really, it isn't even that hard. address reuse means that half the time you have a direct person > person link in a transaction. |
| 05:58:02 | bramc: | Even if all the encoding issues were improved, it would probably still be like a 2x improvement |
| 05:58:36 | petertodd: | op_mul: it's not a matter of buffoonery, it's a matter of not having access to the data |
| 05:58:45 | bramc: | op_mul, a reasonable argument can be made that change should always be kept as change until it hits an aggregator like changetip, who should aggregate all they can at once |
| 06:00:54 | op_mul: | bramc: we can't even get wallet developers to use change addresses, let alone do anything interesting. heck, it takes them losing a quarter of a million USD to stop using random EC nonces. |
| 06:02:39 | bramc: | What do you mean by 'change addresses'? |
| 06:02:56 | bramc: | Do wallets mostly just reuse their public keys a lot? |
| 06:03:29 | op_mul: | when you make a transaction you end up with change. that gets sent to a new address. wallets shouldn't ever be reusing addresses, but they do because wallet developers are lazy and inept. |
| 06:04:54 | bramc: | That is, unfortunately, unsurprising |
| 06:05:46 | op_mul: | one of the biggest ones recently lost 800 BTC due to them first of all using a RNG to make their EC nonces, and then breaking the RNG so it only had 8 bits of entropy. |
| 06:06:16 | bramc: | Aren't you supposed to use the hash of the utxo as the nonce? |
| 06:07:05 | op_mul: | most certainly not. non-random RFC6979 nonces come from the hash of the message and the private key. if it was the hash of the output it was spending, anybody could recover the private key. |
| 06:07:26 | bramc: | Ah, that makes sense |
| 06:08:08 | bramc: | I tried to explain to the libressl developers that mixing private keys into your RNG source is a good idea. They were having none of it, claiming it was 'insecure' without justification |
| 06:09:21 | op_mul: | you get some nice features from not having an RNG at all too. you have have multiple pieces of software sign the same transaction and then compare them to verify they are not leaking information maliciously. |
| 06:10:16 | adam3us: | so bramc is your interest to catchup with bitcoin or to start a bramcoin, just curious :) if you dont mind us asking you a question in return! |
| 06:10:53 | bramc: | adam3us, I'm not announcing anything right now, people are drawing not unreasonable inferences though |
| 06:11:24 | adam3us: | bramc can you give an example of a not unreasonable inference (i am a bit behind on wizarsd backscroll) |
| 06:11:53 | bramc: | There's been some more off the path discussion in ##altcoin-dev where I was talking about how to mix together cuckoo and nonoutsourcable proofs of work |
| 06:13:16 | adam3us: | so you know, i went through the hmm people seem to know who I am, i could start an altcoin and probably make some pump & dump $ on it, for all of about 15seconds and then i was thinking, no thats antisocial, evil and selfish - its more sensible to work on improving bitcoin. hence arriving at encrypted values, and interest in sidechains. |
| 06:14:39 | moa: | and possibly more personally beneficial in the long term ... |
| 06:14:40 | adam3us: | bramc: just trying to nudge you through the right exit to that funnel so we dont get another "silver to bitcoins gold" moment (litecoin ref if you werent around for that one). a) its unlikely to over take bitcoin whatever it is - making it an unethical pyramid; and b) you shouldnt try because if you did it would be destructive of the very concept |
| 06:15:11 | bramc: | I'm not interesting in a pump and dump of an altcoin, but I have a lot of interesting in what the problems in bitcoin really are and how they might be improved. Almost all the really interesting stuff has to do with decentralizing mining (cuckoo, nonoutsourcable proofs of work, enforced wait times) |
| 06:15:43 | op_mul: | " enforced wait times" sounds impossible. |
| 06:15:58 | bramc: | op_mul, Oh but it isn't |
| 06:16:33 | bramc: | op_mul, https://eprint.iacr.org/2011/553.pdf |
| 06:16:41 | op_mul: | unless you have proof of wait up your sleeve |
| 06:16:44 | adam3us: | bramc: so my view is if there is a problem, its very interesting to work on solutions, and then integrate with bitcoin. if the improvement is marginal however dont be surprised if its not-worth changing. something has to be a significant improvement to take the risk at core. sidechains hopefully will allow more experimentation and you could indirectly experiment with pow in a sidechain off a sidechain. |
| 06:16:57 | bramc: | op_mul, that link gives a way of making a proof of wait, and it can be improved on |
| 06:18:02 | adam3us: | bramc: frankly i am personally going to be a little less interested to help you learn about bitcoin and common blockchain fallacies if you're going to turn around and do the #1 fallacy and make yet-another-altcoin. there are 1200 or so. the world really doesnt need another one. |
| 06:18:23 | bramc: | adam3us, Like I said I'm still investigating and not announcing anything right now |
| 06:18:33 | op_mul: | bramc: without having to deal with 28 pages of dense math. how does it get around the sybil problem? |
| 06:19:12 | adam3us: | bramc: yes bram but is that code for i am working on alt coin but i'm not going to say it or people wont give me 100s of hours of free strategic advice. then i'm going to go off and do the anti-social thing. |
| 06:19:14 | bramc: | I won't make another coin unless there's a compelling reason why the same functionality couldn't be crammed into bitcoin. If I do start serious plans to do so I'll give you the opportunity to convince me that I should do it on a sidechain instead |
| 06:19:23 | bramc: | Starting with sidechains shipping |
| 06:19:37 | adam3us: | bramc: well ok, thats good. |
| 06:20:39 | bramc: | adam3us, I might directly contribute stuff to bitcoin unrelated to my grander plans, at the moment I'm planning on looking into collaborative generation of ecdsa signatures for coinswap |
| 06:21:25 | bramc: | There aren't all that many things I consider interesting enough to actually work on, but that one seems useful |
| 06:22:01 | gwillen: | win 1043 |
| 06:22:08 | adam3us: | bramc my interest started in a similar direction, to see if there is anything i could do to improve or help with crypto or another set of eyes. (my conclusion actually is bitcoin is barely improvable, seems mostly optimised out once you digest the fallacies). |
| 06:22:22 | bramc: | op_mul, It has to do with its overall API, it's completely non-interactive. Given hash X, I can generate a proof that I performed a series of sequential operations after X was generated, and have a proof of that which you can verify quickly |
| 06:23:17 | op_mul: | bramc: not really proof that you're doing nothing though, isn't that just like peter todds timelock, forcing highly non-concurrent computation? |
| 06:23:18 | adam3us: | bramc: when i realised that its quite hard to make significant changes to bitcoin due to consensus fork risk, i started looking at sidechains. if you get bored you could look at that - seems to me to be the most promising avenue to enable more rapid innovation on blockchains without the pyramids inherent in altcoins. |
| 06:23:22 | bramc: | adam3us, So far I've gotten through figuring out that trying to improve transaction close times and scaling aren't actually worth banging one's head against |
| 06:24:18 | bramc: | op_mul, If the block chain requires proofs of sequential work between blocks, that's time when everybody just has to sit around and wait |
| 06:25:01 | bramc: | adam3us, I've gotten quite the earful about sidechains on here, I still have many questions though and am waiting for more concrete proposals to even consider actually doing anything with them |
| 06:25:13 | adam3us: | bramc: ie first create a framework for extensions, then go make interesting extensions. if the extension framework doesnt exist (last year) or is in progress and is complex (now) seems like the most useful place for someone smart enough to make a non-fallacy-repeat contribution would be to basically muck-in, help-out and work with the community. |
| 06:25:39 | adam3us: | bramc: i think its all hanging out there no? the paper, bitcoin-dev post etc. |
| 06:25:55 | op_mul: | bramc: sounds like a reason for me to get into liquid nitrogen CPU cooling. |
| 06:26:16 | bramc: | adam3us, I found the paper hard to read through (I suck at reading papers) but most of my basic questions have been answered |
| 06:27:28 | adam3us: | btw to be clear i consider asic-hard to be yet another fallacy. no offence to tromp but that is not the #1 interesting technical problem in blockchains, not even #10. |
| 06:27:48 | bramc: | op_mul, feel free, it's an interesting experiment to see how well it works. There's no direct payoff to running an honesty server beyond possibly getting more mining time for yourself if you get to it first. Having multiple people who do that just results in the overall work factor going up and they cancel each other out |
| 06:28:42 | bramc: | We might have different definitions of 'interesting' |
| 06:28:49 | op_mul: | quite |
| 06:29:28 | op_mul: | I'm used to working with things in tens of megahertz, not trying to get gigahertz out of a CPU with extreme cooling. |
| 06:29:38 | bramc: | Nobody's asked about how to fix the problem that you only have one measure of whether things are too easy or too hard, time, and there are now two different work factors to adjust for |
| 06:30:58 | bramc: | Trying to combine nonoutsourcability and time gaps is proving to make quite the frankensteinian monster, I'm not entirely sure it can be done well |
| 06:31:52 | adam3us: | bramc: interesting as in achieves something new or significantly better for bitcoin functionality, decentralisation or security. if the pow is good enough, and evidence is that it is. changing it to scrypt is worse, changing it to blake2 makes no difference, x11 etc marginally worse. where worse is slower verification, needless added complexity or higher vulnerability to asic optimisation; usefull better being hugely, massiv |
| 06:32:38 | op_mul: | adam3us: you got snipped at the end there. ended with massive. |
| 06:32:53 | bramc: | adam3us, I view limiting the amount of senseless destruction which goes into mining as a good thing |
| 06:32:56 | adam3us: | usefull better being hugely, massively harder for asic optimisation and bitcoin centralisation at breaking point. |
| 06:33:16 | adam3us: | bramc: its not senseless. its an economic necessity. thats an economic fallacy. |
| 06:34:22 | bramc: | adam3us, There's plenty of hardware sitting around depreciating all the time. If the costs of mining were adjusted to be primarily hardware depreciation then the amount of new investment in mining would go down, and it would be relying primarily on sunk costs |
| 06:34:24 | adam3us: | bramc: if coins have a production cost below their value, rational economic actors will spend up to the market value chasing it. if thats via politics, buying or bribing stake holders (pos) etc |
| 06:35:19 | adam3us: | bramc: i dont think my arguments change. its economic fundamental of commodity pricing. |
| 06:35:45 | adam3us: | szabo wrote about it, and paul sztorc. |
| 06:36:17 | bramc: | adam3us, I have in fact worked through this. If actors are basically proving that they already wasted some money on depreciating hardware, then they aren't going to incur much new costs because the depreciating hardware has already happened |
| 06:37:13 | op_mul: | proof of work is more about the power cost than the hardware cost. |
| 06:37:40 | adam3us: | bramc: so then their depreciating hardware isnt costing them anything new. there has to be a separable mining dedicated cost on either hardware or power. obviously something will shift. eg price of used hardware will rise, or people will make asics for whatever it is. to think hardware cant win over software is pure fallacy. |
| 06:37:41 | op_mul: | any ASIC you can buy today will use more power than it's own outright cost in a matter of days. |
| 06:38:00 | omni: | omni is now known as Guest35159 |
| 06:38:19 | Guest35159: | There's a good way to definitively solve the non-prunability of sequence numbered accounts. |
| 06:38:21 | bramc: | op_mul, the interesting question is how to change that. Cuckoo and proofs of time shift things quite a bit |
| 06:38:58 | bramc: | I don't think that the power thing happens in a matter of days, last numbers I saw the power and hardware costs of miners are roughly on par with each other |
| 06:39:44 | adam3us: | bramc: if the cost is the same, and necessarily so, and already work just fine, why is it interesting to engage in creating something different. different isnt better its just different. unless you can persuade bitcoin to change, via rational argument its a dead duck. you could maybe do it on a sidechain via a pow-adaptor sidechain, but still if its no advantage why bother. |
| 06:39:47 | bramc: | adam3us, There's a *lot* of depreciating hardware out there, far more than the amount of bitcoin specific hardware |
| 06:40:23 | op_mul: | the value of the hardware is next to meaningless though |
| 06:40:28 | op_mul: | it's all about the running costs. |
| 06:40:47 | adam3us: | bramc: so what. it still uses power, and economic systems are dynamic. the price of used hardware will rise. and anyway within 6-12mo of it being relevant an asic will arise which will decimate it. |
| 06:40:52 | bramc: | adam3us, the political reason is to shift power away from the miners is that they're highly centralized, while people who already have depreciating hardware are highly decentralized |
| 06:41:38 | bramc: | I'm not so sure that an asic can decimate cuckoo. And putting in time gaps hurts it via depreciation quite a lot. |
| 06:41:49 | adam3us: | bramc: decentralisation is something that is interesting, yes. but i dont think you can imagine depreciating hardware can compete against asics. |
| 06:42:25 | bramc: | adam3us, Well if your argument is whether the project can succeed that's a different question |
| 06:43:15 | adam3us: | bramc: gmaxwell gave some refs to custom memory research a while back. this is non-adversarial thinking by software people who dont know about hardware. we feel smart because we know software. there are people with 20 years experience and near genius iq working in hardware. we know squat about hw optimisation and our pronouncements about asic hardness would make them chortle. |
| 06:44:41 | adam3us: | bramc: an important design criteria for a pow is that its optimal asic implementation should be simple, and the non-optimal trivial with a smooth scaling in between. cuckoo fails that and it matters. that can easily make cuckoo net worse for asic in the same way scrypt was. |
| 06:44:47 | petertodd: | adam3us: +1 I had that exact same conversation with actual hardware people |
| 06:45:16 | bramc: | adam3us, Could be, but I'm unconvinced and think the experiment is worth running |
| 06:46:31 | bramc: | scrypt is a particularly bad choice of proof of work. It's a password hashing function, those are hard to verify by design |
| 06:46:33 | phantomcircuit: | any ASIC you can buy today will use more power than it's own outright cost in a matter of days. |
| 06:46:34 | phantomcircuit: | nah |
| 06:46:34 | roidster: | roidster is now known as Guest35090 |
| 06:47:00 | op_mul: | phantomcircuit: realised after I said it. weeks, probably. lets call it hyperbole and I forget I said it. |
| 06:47:16 | adam3us: | bramc: you probably want to find a real hw wizard before you put time or money into it. |
| 06:47:21 | phantomcircuit: | op_mul, ~ 30 days |
| 06:47:42 | bramc: | adam3us, I know a real hardware wizard who I spoke to about stuff before, I haven't run cuckoo by him yet, most certainly will |
| 06:47:49 | adam3us: | and expect if you make bramcoin or cuckoocoin on the sales pitch of it, rather than a sidechain experiment similar ridicule to litecoin. |
| 06:48:08 | adam3us: | bramc: would be interested in the hw feedback! |
| 06:48:15 | bramc: | He told me a funny thing about litecoin - people are spending more on designing fabs for litecoin than the litecoin total rewards are |
| 06:48:43 | phantomcircuit: | that seems unlikely |
| 06:48:46 | phantomcircuit: | it costs millions |
| 06:48:49 | adam3us: | bramc: yes. btw what i was saying about litecoin fail i guess you heard the story but it was a like quadruple fail. |
| 06:49:13 | bramc: | I don't know full details about litecoin mining, just that one story |
| 06:49:41 | op_mul: | sick of GPU mining? mine Litecoin, it's CPU only! |
| 06:49:44 | adam3us: | bramc: first it was claimed to be gpu-hard, then (surprise!) someone made a gpu version that was 10x faster decimating break even on cpu. then it was claimed asic hard, and eventually someone made an asic again decimating gpu |
| 06:50:10 | op_mul: | adam3us: hello, trivial tomato. |
| 06:51:13 | adam3us: | bramc: it also had other false claims. decentralised because of those claims. well no those claims are false. when people figured it out they demanded litecoin change pow, leading to a whole-coin design fork. but charlie lee managed to hold it togehter and say it would break the social contract even tho litecoin self-admittedly failed all of its claimed design criteria. |
| 06:51:16 | bramc: | The hardware expert I spoke to told me that the thing you really want to do is force the asic to use a huge amount of the dye, and that scrypt basically isn't using enough memory |
| 06:51:32 | phantomcircuit: | bramc, die |
| 06:51:33 | phantomcircuit: | :P |
| 06:52:16 | adam3us: | there's another issue. there is an argument that sha256 tends to overheat so you have whitespace or underclock etc for a given process. scrypto and memory-hard things dont have that problem so gain a bigger advantage over gpus. |
| 06:52:41 | bramc: | That prompted me to come up with my password hashing scheme, which I think is a good thing for password hashing but then I realized that password hashing is a bad fit for proofs of work |
| 06:52:42 | adam3us: | gmaxwell extrapolates from the scrypt asic empirical evidence of this in action. |
| 06:53:16 | bramc: | Here's the post on password hashing. Very interesting in feedback although I don't think it's of much use for cryptocurrencies: http://bramcohen.com/2014/11/18/a-mode-for-password-hashing |
| 06:53:43 | moa: | an evolution algorithm for mining might be asic hard but not sure what that would look like |
| 06:54:16 | adam3us: | scrypt keeps giving: it has smaller block intervals, leading to higher orphan rate (slight), plus propagation delay leads to more bandwidth/low latency centralisation. the asic is more complex and took longer to design - if someone cared they could centralise litecoin withit instead of selling those asics. |
| 06:55:41 | adam3us: | bramc: basically designing cryptocurrencies is hard. to boot there is a non-trivial likelihood that litecoin was an outright scam. the guy who actually designed it (charlie lee did nothing, he just forked someone elses code).. artForz with tenebrix knew extremely well the design criteria for gpu efficiency |
| 06:55:52 | bramc: | My password hashing scheme does a great job of being better than scrypt. Unfortunately to really run it requiring the amount of memory you'd like would require verification times to be uncomfortably high. Unless you made it use one round of AES instead of a full AES at a time. Maybe that would be a good idea. |
| 06:56:43 | adam3us: | artForz coded i think the first gpu implementation of sha256 mining? and/or the first fpga sha256 miner. so the fact that it turned out to be gpu easy, probably implies he was mining it like crazy as a plausibbly deniable hidden premine. charlie lees complicity or dupe status is unknown if one takes that story. |
| 06:56:59 | fluffypony: | well Tenebrix was relaunched as Fairbrix without artForz' premine |
| 06:57:01 | phantomcircuit: | adam3us, i dont think that actually happens in practice |
| 06:57:08 | bramc: | Also it's blindingly obvious how to implement my password hashing scheme, so there wouldn't be any big advantage to spending more money on designing a better asic |
| 06:57:52 | adam3us: | bramc: better asic can mean novel memory architecture, cell design or grinding other aspects of the pow. |
| 06:58:28 | fluffypony: | better ASIC can mean more power efficiency |
| 06:58:41 | phantomcircuit: | in practice you should always use the full die area then under clock/volt until you hit the thermal/power limits |
| 06:59:03 | adam3us: | the software implementation is obvious probably (tho take a look at bytecoin's fail with momentum hash which he also thought was clever and simple) that one failed to bloom filters to make a compact but unreliable virtual ram to fit into gpu cache. |
| 06:59:09 | bramc: | adam3us, I highly recommend reading through my password hashing scheme, it's a fun construction, and surprisingly simple, there's hardly anything which can be done do it. |
| 06:59:26 | op_mul: | phantomcircuit: ha, thought for a second you meant use a whole wafer suface as one die. imagine soldering that package :) |
| 06:59:50 | bramc: | phantomcircuit, Yeah the hardware person I spoke to said it's all about blowing the die area |
| 07:00:05 | adam3us: | phantomcircuit: "dont think that happens in practice" sorry lost in threading.. what happens? asic whitespace? |
| 07:00:36 | bramc: | Or should I say, dYe area :-) |
| 07:02:01 | bramc: | fluffypony, I've asked people what operations are likely to be best for ratio of power usage between general purpose CPUs and custom ASICs. Nobody wants to venture a guess, or maybe they figure it's hopeless |
| 07:02:48 | adam3us: | btw about the economic argument that low cost mining being a fallacy, recommend this analysis by economist Paul Szroc http://www.truthcoin.info/blog/pow-and-mining/ it cuts right through the reasoning and gives the intuition nicely. at least i found it illuminating :) |
| 07:03:50 | phantomcircuit: | adam3us, in practice i dont think anybody has significant whitespace on their die |
| 07:03:56 | adam3us: | bramc: optimized asics i think it matters to what degree. custom optimisation by someone who can think laterally is different than running it through normal process. |
| 07:04:17 | adam3us: | phantomcircuit: i guess it comes down to then underclock/undervolt vs typical for the process density? |
| 07:04:26 | bramc: | adam3us, I understand the argument, but have the counter with the sunk cost depreciation argument. I clearly will need to have a very comprehensive argument in favor of this if I decide to try to convince people to play along though. |
| 07:04:30 | phantomcircuit: | you can get the same thermal effects with better performance by dropping the clock/voltage |
| 07:05:11 | phantomcircuit: | and well i have 80 watt chips which are aircooled just fine |
| 07:05:23 | adam3us: | phantomcircuit: ie if you took the transistors in a 5bil transistor ivybridge or whatever and replaced them all with optimized sha256 circuits eg out of spondoolies or whatever then the thing would heat fail instantly. |
| 07:05:34 | phantomcircuit: | oh |
| 07:05:40 | phantomcircuit: | yeah for sure |
| 07:05:53 | fluffypony: | the CryptoNote PoW (CryptoNite) cheats the system by favouring AES-NI instructions, so in theory a CryptoNite ASIC would outstrip a CPU but only by a limited margin, which could quite possibly make it cost-prohibitive to produce |
| 07:06:11 | fluffypony: | Dave Andersen's theorising on it: "Note that GPUs *do* outperform CPUs, of course -- it's just that it's only a factor of two or three. Which is pretty remarkable. And an ASIC will likely outperform a GPU, but I'm guessing it will be in the ~5x better range, not huge." |
| 07:06:22 | phantomcircuit: | but to be fair there are people decapping 4970k chips to get better thermal contacts... |
| 07:06:42 | bramc: | fluffypony, Yeah the other thing to do is to rely heavily on AES on the grounds that it's already well optimized. I suggested that for password hashing... |
| 07:07:12 | adam3us: | phantomcircuit: so i think you're right it should be articulated that the point is the toggle rate average is insanely high in mining vs cpus and tolerance to error rates is maybe 6 orders of magnitudes higher. |
| 07:08:28 | bramc: | Yes error rates can be vastly higher, I think that doesn't allow for all that much overclocking though |
| 07:09:12 | petertodd: | bramc: with custom ASICs it does - very different silicon strategies for high-error vs. low-error |
| 07:09:32 | petertodd: | bramc: and what's worse, and since so little silicon can tolerate high error rates, we don't know all of those stateies yet |
| 07:09:46 | bramc: | petertodd, Okay, outside my field |
| 07:10:21 | bramc: | although, umm, actually my password hashing scheme would obliterate anything which ran with high error rates |
| 07:10:40 | bramc: | Maybe that thing isn't as bad as I though, I hate it being expensive to verify though. |
| 07:11:01 | phantomcircuit: | adam3us, well and i suspect you can build scrypt miners without memory by repeating the prng steps |
| 07:11:17 | petertodd: | bramc: you think it would :) don't be so sure - high error rate can also mean low reliability, which can be the right tradeoff too - doesn't just mean high average error rate |
| 07:11:34 | adam3us: | phantomcircuit: yes. i was presuming the asic does that a little. i tried asking them what balance they did between recompute vs store but didnt get an answer |
| 07:11:41 | gmaxwell: | petertodd: there is a TMTO in scrypt available though it's fairly modest and has a high computational cost. Doesn't look like the existant hardware is using it from what I can tell. |
| 07:11:50 | gmaxwell: | er that was phantomcircuit directe.d |
| 07:11:56 | phantomcircuit: | petertodd, indeed if you ask fabs about ultra low voltage operation, you will get a blank stare |
| 07:12:21 | bramc: | adam3us, A funny thing about mining is that the amount invested in mining appears to be consistently *more* than the payouts |
| 07:12:42 | petertodd: | bramc: don't make the mistake of assuming payouts == value :) |
| 07:13:19 | midnightmagic: | artforz wrote the first public opencl dsha core. mrb_ wrote the first cal/il raw assembly version. artforz improved on that efficiency by a non-trivial amount, and then went straight to fpga and sasic well before it was a glimmer in anyone else's eye. |
| 07:13:19 | adam3us: | i think the problem is this is such an unusual optimization area, and the normal chips are so optimised for their case that we dont even know how many orders of improvement for mining are lurking. very few hw people even of hw experts have the expertise to create new optimizations at manual gate layout and clockless design etc. |
| 07:13:50 | op_mul: | gmaxwell: I always expected the hardware would. even GPU miners did. |
| 07:14:42 | phantomcircuit: | adam3us, if you say clockless design you'll 100% get blank stares (or laughs) |
| 07:15:14 | gmaxwell: | op_mul: pipeline issues and a glut of free alu and a lack of memory random access make it more interesting on gpus. |
| 07:15:22 | midnightmagic: | bramc: the amount of profit currently requires an inside edge: people who can do their own chips, or have early, manufacturer/subsidised access to the hardware. Like KnC for example. Their customers bootstrapped and subsidized their own mining, and didn't even know it. |
| 07:15:37 | bramc: | phantomcircuit, There is at least one truly clockless general purpose CPU on the market now, it's used as an embedded chip, for low power |
| 07:15:42 | midnightmagic: | bramc: but, for those people, it *is* and *has always been* profitable. |
| 07:16:21 | adam3us: | bramc: so am i right in reading your pbkdf as optimised for the cache hierarchy of cpus? seems logical though you could expect on the hostile side asic's mirroring and improving latencies perhaps & mixing in the advantages of the error rate in the design and having no extraneous circuitry. |
| 07:16:25 | bramc: | midnightmagic, I suppose if you're selling mining rigs to suckers and do some mining with them before shipping, that might be profitable |
| 07:16:39 | gmaxwell: | Ex-coworker of mine previously worked on the octasic dsps, which were fully clockless async logic. |
| 07:16:47 | phantomcircuit: | bramc, interesting |
| 07:16:49 | midnightmagic: | bramc: Even if you don't, the profit margin of the retail/oem rates ends up subsidizing your own datacentres. |
| 07:17:13 | op_mul: | bramc: in the case of KNC, their customers funded their chips and PCBs. the stuff they shipped to customers still had all the sockets and hardware that was designed to go in KNCs farm. |
| 07:17:23 | midnightmagic: | (In the case of the scammers who want the public to fund their leapfrog..) |
| 07:18:24 | bramc: | adam3us, Yeah the whole idea is to force lots and lots of unpredictable memory lookups |
| 07:18:35 | phantomcircuit: | op_mul, people understood that risk and part of the purchase price included a guarantee from knc that they would never mine themselves |
| 07:18:37 | phantomcircuit: | so much for that |
| 07:18:44 | bramc: | And to make the amount of memory used roughly proportional to the time spent |
| 07:18:56 | adam3us: | bramc: right. and so do other designs. but your twist is that you do that at two levels to target the actual cpu memory architecture of cache & main memory. |
| 07:19:37 | bramc: | adam3us, What do you mean by 'at two levels'? My design does a better job than the others of making the lookups non-predictive by having them be data-dependent |
| 07:19:44 | adam3us: | bramc: which seems like a worthwhile change. btw on kdf's did you see my new idea to have a safely delegatable kdf? via blinding |
| 07:19:48 | midnightmagic: | (just for clarification, when I say artforz wrote the first public opencl impl, I just mean he let other people know about it, and convinced most people he did in fact have it.) |
| 07:20:13 | adam3us: | bramc: i mean if i read it correctly your design has two arrays: one assumed to fit in main memory and one assumed to fit in cache. |
| 07:21:11 | adam3us: | midnightmagic: you know there was a guy who had an opencl hashcash implementation. he used it to vanity mine a huge hashcash stamp for amusement. i think it'd have been worth $100k if he focussed on bitcoin. i guess he wasnt aware of it at the time. |
| 07:21:34 | bramc: | adam3us, My design has two data structures, one of which is way too big to fit in cache and one of which can basically fit in registers. The reason for that second, instead of having it be implicit in a certain part of main memory being 'active', is some highly technical stuff having to do with what's necessary to make the operations be reversible |
| 07:22:28 | midnightmagic: | adam3us: there's a whole community of optimizers in the hpc space who specialize either in opencl cores, or cuda cores, or assembly on standardized hardware. it would have been very amusing if that guy turned out to br mrb_ or artforz. |
| 07:23:14 | bramc: | One thing which may contribute to overinvestment in mining is optics - people run numbers and figure they can make money buying certain things at current hash rates, then by the time they make/acquire the equipment the hash rates have gone up, because of course a lot of other people did the exact same calculations... |
| 07:23:21 | adam3us: | ok. well anyway it seems logical to me in as far as i also engaged in asic hardness thought experiment back in like 1997 :) that one would if exploring that direction make use of the characteristics of the hw. cache line width, cache sizes, macro instructions (eg fp, aes ni) the execution logic (eg a pow that is a crng set of x86 cpu instructions) etc |
| 07:23:57 | adam3us: | and then i decided screw that, not worth the complexity. kiss etc. |
| 07:24:07 | op_mul: | adam3us: oh that's easy. new intel CPUs will have SHA256 instructions, why not make a PoW based on that! |
| 07:24:24 | phantomcircuit: | haha |
| 07:24:39 | bramc: | adam3us, My thought is that the thing which is already optimized well is AES (or maybe a single round of AES) and I wanted to make a construction which was as general as possible. It turns out that if you just start mashing in data-dependent lookups you open yourself up to all sorts of attacks unless you do the feistel trick of making everything reversible, which proved to be nontrivial |
| 07:25:23 | adam3us: | also i'd have looked pretty silly if i did that as hw characteristics shifted since 1997 :) eg main memory sizes then are cache sizes now etc. |
| 07:26:19 | phantomcircuit: | bramc, it's easy enough to use aes as a hash function |
| 07:26:29 | adam3us: | bramc: ok so your point is more on non-tmto than targetted at cpu memory architecture. i misread. |
| 07:26:47 | phantomcircuit: | im actually kind of surprised that nobody has don an aes-in pow alt |
| 07:26:53 | phantomcircuit: | im gonna be rich! |
| 07:26:54 | bramc: | Yeah the idea is to force the existence of 'real' memory |
| 07:27:02 | phantomcircuit: | * phantomcircuit runs off to build such a monstrosety |
| 07:27:30 | op_mul: | phantomcircuit: I have no idea if that's sarcasm or not |
| 07:27:53 | phantomcircuit: | the first part no genuine surprise the second part |
| 07:27:54 | phantomcircuit: | maybe |
| 07:27:59 | phantomcircuit: | i'll never tell |
| 07:28:27 | op_mul: | well. anyway there is a AES-NI based PoW. |
| 07:30:08 | fluffypony: | the only downside to it is the relatively expensive verification |
| 07:30:23 | fluffypony: | which is a topic that increasingly comes up when discussing the various PoW algorithsm |
| 07:30:27 | fluffypony: | *algorithms |
| 07:32:41 | phantomcircuit: | op_mul, i think they all try to be memory hard |
| 07:32:51 | phantomcircuit: | which i suspect is a mistake |
| 07:33:03 | bramc: | fluffypony, Yes that's the problem, I like my kdf as a PoW except for the awful verification time |
| 07:33:06 | op_mul: | yep. |
| 07:33:17 | fluffypony: | phantomcircuit: agreed |
| 07:33:34 | bramc: | phantomcircuit, Why do you think that's a mistake? |
| 07:33:35 | adam3us: | hmm altcoin pump & dump gets to court… finally i knew existing laws covered pump & dump pyramid scams! (sorry off topic) http://www.coindesk.com/florida-group-faces-fraud-charges-alleged-altcoin-pump-dump/ |
| 07:33:35 | fluffypony: | being memory hard is barely a stumbling block for an ASIC developer |
| 07:33:48 | fluffypony: | adam3us: was about time too |
| 07:34:12 | bramc: | fluffypony, The idea is that if it requires 'enough' memory you're better off using 'real' memory |
| 07:34:42 | phantomcircuit: | bramc, because ultimately it doesn't work and you've built something where the cpu -> gpu -> asic jumps are even larger |
| 07:35:20 | bramc: | adam3us, There are extremely specific things about what claims might get you in legal trouble when making a cryptocurrency (as you might guess, I'm familiar with these sorts of issues) |
| 07:36:00 | bramc: | phantomcircuit, Why are the jumps larger? |
| 07:36:36 | phantomcircuit: | because someone like me can put large SRAM cache onto the asic |
| 07:36:59 | adam3us: | bramc: my view (speaking of cryptocurrency only) is that while smarter people might skirt the spirit of the law, and avoid legal problems, the ethical challenges are real and should be discouraged and frowned upon. |
| 07:37:50 | adam3us: | bramc: by loose analogy that most bankers avoided jail, didnt make the mortgage fraud inherent in the subprime mortgage crisis any less of a scam with no doubt large amounts of profiteering criminal intent. |
| 07:38:06 | bramc: | I'm now convinced I need to talk to the hardware expert I know again and run everything by him. That's likely to be an extended conversation |
| 07:38:28 | midnightmagic: | adam3us: that's a neat blog article. :) |
| 07:38:55 | bramc: | adam3us, To be clear, I think most of wall street was unambiguously on the wrong side of the law. They just get special treatment because they own the government. |
| 07:38:58 | adam3us: | midnightmagic: paul sztorc - yeah i love it. asked bluematt to add it to bitcoin.ninja must-read list |
| 07:39:15 | phantomcircuit: | what is it about florida... |
| 07:39:51 | adam3us: | bramc: the problem is i think also that there are hw experts and then there are actual adversarial thinking, hw geniuses. the latter is harder to find. sort of like talking to a php programmer vs a gpu asm programmer or something. |
| 07:40:09 | adam3us: | bramc: its hard for us to even distinguish reliably because its not our field. |
| 07:40:35 | bramc: | adam3us, And yes of course I'm very familiar with all the ethical issues and take them seriously. I do promise that if I decide to do an altcoin I'll give you every opportunity to convince me that it can and should be done as a sidechain instead. |
| 07:40:37 | adam3us: | or maybe a closer analogy your average "i can do that" vs an actual cryptographer |
| 07:42:24 | bramc: | adam3us, I believe this contact of mine is actually quite good, but I haven't even run my kdf and cuckoo past him yet, so my direct feedback from any real hardware person at all is nil. I know what he told me before, which was of necessity somewhat general and vague. His feedback was great for coming up with my kdf though. |
| 07:43:12 | fluffypony: | midnightmagic: agreeda |
| 07:43:37 | bramc: | for what it's worth, this person ran over numbers on bitcoin mining with a friend of mine and it came out at very close to break even, so at least his numbers running seems to agree with emperical experience |
| 07:43:55 | fluffypony: | "Is The 2.0-Dev-Community Lazy Or Just Illiterate?" lol |
| 07:46:15 | phantomcircuit: | bramc, if you adjust the inputs a little the numbers change rapidly |
| 07:46:16 | bramc: | The upshot of all this discussion is that I'm still researching PoW-related stuff and I still think the experiment of trying to bust asics may be worth running, given sufficient compelling gizmos |
| 07:46:35 | midnightmagic: | powered by "investors" who want to own the future. the open-source nature of the core product obviates that as a long-term strategy. there's a reason why Linux won. |
| 07:47:17 | phantomcircuit: | it's cool name? |
| 07:47:31 | midnightmagic: | s/cool/unpronounceable/ |
| 07:47:40 | midnightmagic: | Hastu... |
| 07:47:42 | midnightmagic: | * midnightmagic explodes |
| 07:55:45 | bramc: | I came up with the idea of doing PoW using the 4sum problem. Unfortunately custom sorting chips work very well. |
| 08:21:45 | adam3us: | bramc: another kdf (secure delegatable) you might find interesting https://bitcointalk.org/index.php?topic=311000.0 as it allows much larger kdf parameters if people are willing to pay a fraction of a cent to gpu miners to do the work. |
| 08:22:42 | adam3us: | which is a new idea for kdfs. there's now someone on the kdf competition who has reinvented a similar idea. both using rivest-wagner time-lock puzzle mechanism as the underlying. |
| 08:23:05 | adam3us: | thomas pornin's variant is called makwa https://password-hashing.net/submissions/specs/Makwa-v0.pdf |
| 08:25:44 | bramc: | adam3us, Thanks, I've added those to my list of stuff to go over |
| 08:26:18 | bramc: | It seems to take an average of two days to knock something off my list of stuff to go over. Unfortunately I've been adding a new thing about once every two days. |
| 08:36:08 | lclc_bnc: | lclc_bnc is now known as lclc |
| 09:05:13 | sinisalo.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
| 09:05:13 | sinisalo.freenode.net: | Users on #bitcoin-wizards: andy-logbot CoinMuncher jb55_ coiner mkarrer_ bosma_ vmatekole grau bitbumper HaltingState NewLiberty austinhill damethos Guest35090 Guest35159 paveljanik ryanxcharles op_mul thrasher` RoboTeddy hashtagg_ adam3us TheSeven atgreen` Iriez hashtag_ woah nullbyte Dr-G2 tlrobinson nuke1989 Shiftos shesek moa gues luny NikolaiToryzin c0rw1n [\\\] heath Guest3112 Luke-Jr jgarzik Aquent Emcy_ prodatalab SubCreative Starduster d1ggy davejh69 waxwing |
| 09:05:13 | sinisalo.freenode.net: | Users on #bitcoin-wizards: grandmaster go1111111 Graet_ Transisto copumpkin pi07r koshii bbrittain huseby Baz___ spinza DoctorBTC Graftec BananaLotus dansmith_btc Apocalyptic phantomcircuit EasyAt tromp PRab_ isis espes___ jbenet null_radix hollandais midnightmagic Muis BlueMatt ebfull grishnakh__ starsoccer gavinandresen postpre OneFixt danneu catcow TD-Linux ryan-c roasbeef amiller smooth optimator_ mmozeiko Alanius epscy kobud dgenr8 JonTitor Hunger- MRL-Relay |
| 09:05:13 | sinisalo.freenode.net: | Users on #bitcoin-wizards: fluffypony mr_burdell samson_ btc__ CryptOprah mappum kanzure warren Krellan nanotube fenn otoburb LarsLarsen coutts bobke jchp nsh_ asoltys_ sl01_ K1773R nickler_ a5m0 PaulCapestany @ChanServ Meeh wumpus comboy btcdrak ahmed_ lnovy tdlfbx eordano nsh gribble gwillen Nightwolf Anduck Dyaheon cfields digitalmagus8 stonecoldpat gmaxwell pigeons andytoshi lechuga_ artifexd hguux_ michagogo kumavis warptangent Fistful_of_Coins HM2 paperbot maaku |
| 09:05:13 | sinisalo.freenode.net: | Users on #bitcoin-wizards: Cory Guest38445 coryfields iddo kinlo azariah yoleaux Logicwax berndj lclc s1w Eliel_ sneak harrigan sipa AdrianG livegnik burcin wizkid057 tromp_ poggy Taek throughnothing petertodd crescendo so [d__d] BigBitz jaromil helo Keefe phedny BrainOverfl0w harrow |
| 09:29:57 | lclc: | lclc is now known as lclc_bnc |
| 10:00:59 | lclc_bnc: | lclc_bnc is now known as lclc |
| 12:36:47 | lclc: | lclc is now known as lclc_bnc |
| 12:38:03 | lclc_bnc: | lclc_bnc is now known as lclc |
| 12:38:36 | lclc: | lclc is now known as lclc_bnc |
| 13:55:32 | wallet42: | wallet42 is now known as Guest25226 |
| 13:55:32 | wallet421: | wallet421 is now known as wallet42 |
| 15:37:14 | Guyver2: | Guyver2 has left #bitcoin-wizards |
| 16:11:25 | huseby: | huseby is now known as husebyAFK |
| 17:22:12 | lclc_bnc: | lclc_bnc is now known as lclc |
| 17:54:27 | devrando1: | devrando1 is now known as devrandom |
| 17:56:26 | devrando1: | devrando1 is now known as devrandom |
| 18:10:27 | bramc: | It turns out I was half wrong about hardware depreciation. While it's possible to favor depreciating hardware over custom built hardware, the amount spent in total will be the same. The problem is that there's too much depreciating hardware out there, and as long as the amount of electricity which can potentially be used across *all* that hardware is greater than the value of the mining rewards, that amount will get used |
| 18:10:27 | bramc: | up |
| 18:12:24 | bramc: | That said, it might be possible to favor depreciating hardware over custom hardware, but the potential for making something green isn't great. The best way to make cryptocurrencies be green is to lower mining rewards, and any new cryptocurrency is of course increasing mining rewards by making another pool of them |
| 18:13:25 | sipa: | in an equilibrium with globally constant prices, the mining reward is equal to hardware + electricity costs |
| 18:14:12 | sipa: | and also directly related to the security of the system (if miners get more from subsidy (+ fees) than by attacking, you can assume they won't) |
| 18:14:51 | sipa: | and assuming the security level is sort-of a choice made by the users of the system, you can't really set it at the start in the rules |
| 18:14:59 | sipa: | as the exchange rate remains a free-floating parameter |
| 18:15:39 | sipa: | hmm, never realized that this reasoning leads to an odd [lower subsidy] -> [high exchange rate] relation |
| 18:15:52 | sipa: | which is probably not true in practice |
| 18:16:40 | bramc: | sipa, I expect bitcoin prices to spike after the next time mining rewards halve, which will be in early 2016 |
| 18:16:54 | sipa: | bramc: approximately nothing happened the previous time |
| 18:17:13 | sipa: | (which is not to say you're wrong, but i wouldn't bet on it myself) |
| 18:17:16 | bramc: | sipa, There was a lot less pro mining going on last time. I could of course be wrong. |
| 18:17:26 | bramc: | Not sure I'll bet on it either :-) |
| 18:17:40 | sipa: | well if you do, now may be the time to buy :D |
| 18:18:07 | bramc: | No, there's way too much volatility in bitcoin for it to make sense to buy now based on a movement expected a year from now |
| 18:18:31 | sipa: | fair enough; i was only joking |
| 18:19:20 | bramc: | The price of bitcoin dropping is good for the environment |
| 18:19:30 | sipa: | and bad for its security :) |
| 18:19:46 | bramc: | although the relation may not be very immediate and linear because of all the sunk costs into hardware |
| 18:21:31 | bramc: | That said, all this stuff I've been working out is very interesting and worth publishing regardless |
| 18:22:41 | fluffypony: | sipa: why bad for tis security? |
| 18:22:46 | fluffypony: | *its |
| 18:23:09 | bramc: | Nobody seems curious about my super cute idea of how to adjust work difficulty when you're mixing both proofs of time and proofs of work |
| 18:23:25 | sipa: | what is proof of time? |
| 18:23:38 | fluffypony: | sipa: Proof of DeLorean |
| 18:23:52 | sipa: | * sipa gets his Mr. Fusion |
| 18:24:06 | bramc: | A proof of time is an operation which has to be done sequentially, and where a short proof results in the end which is much quicker to verify than to re-do the entire set of work |
| 18:24:33 | sipa: | non-parallellizable proof-of-work, basically? |
| 18:25:14 | bramc: | If you make them alternate with proofs of work in a block chain you can force everything to sit around doing nothing a substantial fraction of the time, which disadvantages custom hardware because it gets killed by depreciation vs. hardware which was already acquired for other reasons and is sitting around depreciating |
| 18:25:16 | sipa: | fluffypony: what if i tried to send a 1G dollar transaction in bitcoin? |
| 18:25:41 | fluffypony: | * fluffypony blanks out |
| 18:25:42 | fluffypony: | 1G? |
| 18:25:54 | sipa: | 1 billion |
| 18:25:59 | fluffypony: | oh |
| 18:26:02 | fluffypony: | good point |
| 18:27:12 | bramc: | sipa, Yes exactly, non-parallelizable |
| 18:27:51 | sipa: | bramc: can you keep that progress-free? |
| 18:28:42 | bramc: | define 'progress-free' |
| 18:29:05 | bramc: | It's possible to make a proof of time be dependent on an external value and non-interactive |
| 18:29:56 | bramc: | It isn't at all obvious that this is possible. This paper gives a construction, which I've figured out some big improvements on: https://eprint.iacr.org/2011/553.pdf |
| 18:31:49 | bramc: | So if by 'progress-free', you mean that it has to be started from scratch after each block, then yes that's totally doable, although there's some fun crypto involved |
| 18:34:04 | bramc: | Maybe the issue isn't that people aren't curious about my idea but that I haven't clearly explained the problem |
| 18:36:12 | gmaxwell: | bramc: what you're talking about is very much the opposite of progress free (in something progress free, a faster party doesn't have a disproportiate advantage. Non-progress free is like a race, the fastest always wins). But I think it's not really applicable for your goal, which indeed you haven't explained there. |
| 18:37:36 | sipa: | while progress-free is a lottery |
| 18:37:59 | bramc: | gmaxwell, Okay then it's totally progress-full, the idea being that almost everybody has about the same max clock speed, so a handful of ridiculously overclocked honesty servers will do that proofs of time while everybody else sits around and waits for it. |
| 18:38:30 | sipa: | you turn it into a fastest-sequential-hardware-always-wins |
| 18:38:32 | bramc: | I call them 'honesty' servers because there's no direct reward for finding the proofs of time. It can give you a bit of a jump on mining though, as long as someone else isn't playing the same game better |
| 18:38:33 | sipa: | basically |
| 18:38:51 | nsh: | i'm not sure anyone is able to prove clock-cycles-dedicated-to-P for any problem |
| 18:38:53 | bramc: | sipa, Yes exactly, and the differences there tend to be small, and the protocol is design so there isn't actually a reward for that step |
| 18:40:05 | bramc: | nsh, The paper I just linked does, and it's possible to improve on that one quite a bit. It doesn't involve any particularly complicated crypto, just hashing used in a clever way |
| 18:41:09 | gmaxwell: | bramc: does it do anything at all then? e.g. if you are not rewarded in the protocol for doing it, but it does something, can you just do it evily and actually get a reward? |
| 18:41:11 | bramc: | So my idea is that the block chain should alternate between proofs of work (blocks) and proofs of time, and each one refers to the previous one, so it's enforced that time was spent between mining operations |
| 18:41:32 | AdrianG: | hm. |
| 18:41:47 | gmaxwell: | For example, no one pays you for it normally. But someone wants to go mine a fork and to do that they need it done, so why not just abandon the honest network and go mine the fork where your costly sequential hardware will get paid for? |
| 18:41:48 | bramc: | gmaxwell, If you set up a superoverclocked setup you can start mining the next block before everybody else does |
| 18:42:02 | nsh: | * nsh reads linked paper :) |
| 18:42:57 | gmaxwell: | bramc: that goal sounds like its a non-trivial centeralization advantage even if it does what you want, then? |
| 18:43:14 | bramc: | gmaxwell, You're hinting at the really interesting question: How should the work difficulty of the proofs of time and proofs of work be adjusted if you want to maintain a specific ratio between them regardless of the current scale of each? |
| 18:43:47 | nsh: | consideration of scale: good -- tweaking: bad |
| 18:43:58 | bramc: | gmaxwell, it winds up having some centralization in an interesting way. There are a handful of overclocked honesty servers who publish their time proofs to keep the others from getting an advantage |
| 18:44:17 | bramc: | nsh, not sure what you mean |
| 18:44:56 | nsh: | you don't want a strong-dependence on (human) fine-tuning |
| 18:45:19 | nsh: | and network-level adaptation has a pretty limited remit at the moment |
| 18:46:41 | bramc: | gmaxwell, Hopefully even the extremely overclocked honesty servers aren't really much faster than the handful of slower people running honesty servers just in case, and you can't get too aggressive about how much of the time is spent in proofs of time vs proofs of work or an overclocker has too much potential advantage, maybe 2:1 is reasonable |
| 18:47:00 | bramc: | nsh, bitcoin's work adjustment works just fine |
| 18:47:02 | nsh: | bramc, are you improvements to the depth-robust DAG-based sequential hashes public? |
| 18:47:16 | bramc: | nsh, no not public yet |
| 18:47:21 | nsh: | bramc, that's because it does one very limited thing where getting it wrong just minorly inconveniences people |
| 18:47:23 | nsh: | :) |
| 18:47:38 | bramc: | And it isn't exactly a DAG any more. I found another tirck :-) |
| 18:47:45 | nsh: | neat |
| 18:47:46 | pigeons: | trust me, i'm an honesty server |
| 18:48:29 | nsh: | (by getting it wrong i mean over- or underadjustice-adjusting a little, not failing to prevent hashpower attacks) |
| 18:48:36 | nsh: | *unmangle |
| 18:49:35 | bramc: | nsh, Yes the interesting question is how you handle having two different types of work and trying to maintain an appropriate ratio between them, and this is where I have an interesting/crazy idea |
| 18:51:28 | nsh: | (also quite a few factors make the recalculation of target consensuable: based on public information, limited leeway to skew the adjustment by lying about timestamps, everyone can verify it was performed soundly, it's as trivial as it can be with the desired control properties) |
| 18:51:51 | bramc: | Yes that's the problem: You don't want to rely on timestamps |
| 18:52:27 | bramc: | The only timestamping you have any confidence in is the difference across reset intervals |
| 18:53:03 | nsh: | what's a reset, sorry? |
| 18:53:36 | bramc: | When the difficulty of mining operations is changed, I'm not sure what that's called |
| 18:54:00 | nsh: | retarget, i guess |
| 18:54:15 | gmaxwell: | retargeting, yep. |
| 18:54:19 | nsh: | but yeah, that is the network-level tick |
| 18:54:55 | nsh: | (blocks can be considered elastic subdivisions between ticks, i suppose...) |
| 18:55:27 | bramc: | Right, so you have exactly one thing you can rely on for retargeting, which is the amount of time spent over an interval, because anyone getting a block chain can look at the time and compare the total rewards given in the chain to the total rewards which should have been handed out by now and reject if it they're too much (technically it doesn't do exactly that, but this is the essence of what is happening) |
| 18:57:23 | nsh: | (the bitcoin network is statistically measuring energy-expended as a proxy of time based on a measuring of power) |
| 18:57:49 | nsh: | (which works out to be roughly equivalent to measuring time, but not in the same way as you're considering proof-of-time through sequential hashing) |
| 18:58:13 | bramc: | Right, you have an apple-to-peanuts problem with proofs of time vs. proofs of work |
| 18:58:21 | nsh: | * nsh nods |
| 19:00:13 | bramc: | So here's my crazy idea: Instead of having two work factors, one for each, you have a single composite work factor which is a combination of the two where the fastest way for everybody to collectively mine is to maintain the intended ratio |
| 19:01:59 | bramc: | Now mining operations and proofs of time are paired together, where a mining operation isn't considered to be successful until the proof of time after it has hit the appropriate threshold |
| 19:03:23 | nsh: | and the ratio would retarget globally at some interval based on a function of the network sums of each rates over the prior interval? |
| 19:03:43 | bramc: | The exact formula you use depends on the ratio you're trying to enforce. The key observation for coming up with the formula is that both proofs of work and proofs of time have the property that you can do twice as much in twice as much time, and that you want the formula to be scale free, meaning regardless of the current scale twice as much time will result in double the value |
| 19:03:57 | bramc: | No the ratio is set, it doesn't move |
| 19:04:10 | nsh: | then what truth does it encode? |
| 19:04:24 | bramc: | You have to decide beforehand that, for example, you want there to be twice as much time spent in proofs of time as proofs of work |
| 19:05:19 | bramc: | And that ratio will be enforced by the formula, at least if people are mining as efficiently as they possibly can |
| 19:05:49 | nsh: | it would surprise me (moderately) if there was a platonic constant that represented some eternal truth about the relationship between parallelizable and sequential work independent of today's contingent stage of human electronic technological sophistication |
| 19:06:10 | nsh: | but there could be a sweet spot, i guess |
| 19:06:43 | nsh: | or does the ratio reflect something else? |
| 19:06:47 | nsh: | * nsh is probably missing things |
| 19:07:19 | bramc: | Not sure what you mean. The nature of time isn't going to change any time soon. What's being enforced is that the system spends six minutes in proof of time, then three in proof of work, then six in time, then three in work, etc. |
| 19:08:38 | nsh: | you can't prove an alternating sequence between things where only one is inherently sequential |
| 19:08:45 | nsh: | (i claim) |
| 19:09:03 | nsh: | you can prove state dependency though |
| 19:09:26 | kanzure: | "nature of time isn't going to change any time" i get it |
| 19:10:06 | bramc: | Still not sure what you mean. The blockchain format itself is fairly straightforward, and can in fact prove what's claimed, at least in terms of the *number* of sequential steps which happened, the nuance is in how much *time* they took |
| 19:10:36 | nsh: | right |
| 19:10:48 | bramc: | It isn't terribly obvious that it's possible to make proofs of time which work this way, but for the sake of current discussion I'd like to just assume it is because that's a very long tangent |
| 19:12:11 | bramc: | So here's my idea: Let's say that we want to spend an equal amount of time in both. There's a single work factor which needs to be met for a proof of work and its following proof of time to be valid. The formula is (W*T)^(1/2) |
| 19:12:12 | nsh: | so it's kind of lock-step march arrangement? the PoW worker must wait for the (cryptographically-verifiably) correct answer from PoT / seq.hashing worker to get some value that it can grind? |
| 19:12:19 | nsh: | and then vice versa? |
| 19:12:26 | bramc: | Yes exactly, it's alternating |
| 19:12:59 | nsh: | right, i had similar ideas for maintaining (granular) progress-freeness while being tied to some relatively-arbitrary "useful" ancillary calculation |
| 19:13:15 | nsh: | proving sequential operation being a particular case of useful |
| 19:15:17 | bramc: | The way that formula works out is that when someone is doing a proof of work they have to decide what work factor they're shooting for before they start, and they'll naturally be incented to set the amount of work they're shooting for be the one which will make the rewards happen as soon as possible |
| 19:15:38 | nsh: | so with the left foot you're sacrificing progress-freeness and decentralization, but the right foot you're clawing it back |
| 19:15:49 | nsh: | the optimum ratio is like ensuring your left leg and right leg are the same length |
| 19:16:01 | nsh: | it's naturally incentivized |
| 19:16:10 | bramc: | Yes you can view it that way |
| 19:17:22 | nsh: | i still think it's not going to be constant enough, but it might not matter badly |
| 19:17:33 | bramc: | It's also possible to set other ratios, for example if you want to spend twice as much time in time as work you can use (W*T^2)^(1/3) |
| 19:19:20 | nsh: | has to be the case that the baton being passed between the two types of work -- the state-information each requires to resume -- is tied to that node, and can't be networked |
| 19:19:32 | nsh: | otherwise i think you can game it |
| 19:19:59 | nsh: | (tied to previous work done by that node) |
| 19:20:18 | nsh: | markelwhatever |
| 19:20:24 | bramc: | Each proof directly references the previous one by hash, so the primitives being used enforce that |
| 19:20:35 | nsh: | * nsh nods |
| 19:20:46 | bramc: | It's a good idea to force proofs of work to declare what they're shooting for up front though |
| 19:21:09 | bramc: | Or maybe not. I need to think about that one |
| 19:21:11 | nsh: | well, it must be validatable by any full node |
| 19:21:42 | bramc: | Yeah, validation is easy (well, assuming the proof of work thing is done right, which isn't trivial but is doable) |
| 19:22:06 | bramc: | Unfortunately the proofs of time are a bit big, like 100k-150k |
| 19:22:21 | bramc: | I meant 'the proof of time thing is done right' not 'the proof of work thing is done right' |
| 19:22:24 | nsh: | * nsh nods |
| 19:22:25 | lclc: | lclc is now known as lclc_bnc |
| 19:22:59 | bramc: | They can in principle be made much smaller using zero knowledge proofs, but that's impractical at current computation scale |
| 19:23:04 | nsh: | poly(n). polylog(N). for verifying mahmoody's construction |
| 19:24:27 | bramc: | I've got it down to log(n)*log(n) |
| 19:24:43 | bramc: | That is, log(n) for the construction, log(n) for the number of samples you do |
| 19:25:02 | nsh: | neat |
| 19:26:01 | bramc: | I now have a list of papers I need to write. I feel like I should enroll in a PhD program. |
| 19:26:45 | nsh: | * nsh smiles |
| 19:27:56 | bramc: | And I still have a huge pile of things to work through and need to figure out what I'm actually going to build |
| 20:24:34 | tdlfbx: | Can anyone suggest any use case for allowing the pubkeys in a multisig address to occur in different orders (for the same set of pubkeys)? e.g. allowing different addresses for the same set of keys. |
| 20:25:35 | sipa: | not really, but i also don't see much use case for enforcing an order |
| 20:25:50 | sipa: | the spenders need to know the exact redeemscript anyway |
| 20:25:50 | tdlfbx: | reducing confusion. |
| 20:26:20 | sipa: | yeah, i understand, it means you can reconstruct the redeemscript from just the involved public keys |
| 20:26:25 | tdlfbx: | Just to specify a standard, for software interoperability. |
| 20:26:35 | sipa: | but public keys are not generally something that is transferred independently anyway |
| 20:26:37 | gmaxwell: | tdlfbx: you can reduce confusion with standards instead of enforcement though. :) |
| 20:26:49 | sipa: | i'm sure that's what he's proposing |
| 20:26:53 | tdlfbx: | gmaxwell: I agree. I'm thinking of writing a BIP. |
| 20:27:01 | belcher: | order them in ascending order? |
| 20:27:12 | gmaxwell: | belcher: which ascending order? there are several. |
| 20:27:13 | tdlfbx: | I'm unsure whether enforcing it in future transactions is necessary or useful. |
| 20:27:16 | sipa: | i'm not opposed but i think it is 1) way to late and 2) not really useful |
| 20:27:37 | tdlfbx: | sipa: why is it way too late? As long as existing transactions aren't invalidated... |
| 20:27:41 | sipa: | also, #bitcoin-dev |
| 20:27:47 | sipa: | tdlfbx: why would anyone adopt it? |
| 20:27:56 | gmaxwell: | tdlfbx: it would be useful to do in the context of anything that proposes an encoding for sending around data, at least. |
| 20:27:59 | tdlfbx: | Every time I ask any question in any channel, someone tries to send me to a different channel. |
| 20:28:15 | sipa: | well you're talking about bitcoin, this channel isn't |
| 20:29:21 | tdlfbx: | Why would anyone adopt it? If two software vendors/projects want to both do multisig, and be compatible with each other, give them a BIP to point to to decide this. |
| 20:31:10 | gmaxwell: | tdlfbx: compatible in which respect though? e.g. what messages would be communicated between them where an incompatiblity might arise? |
| 20:31:20 | gmaxwell: | (and why wouldn't that message specify an ordering if it was helpful there?) |
| 20:32:02 | bramc: | Is there a string order comparator which can be used in redeemscripts? |
| 20:32:30 | tdlfbx: | gmaxwell: It could. This is trivial to solve really. But different implementors will make different choices. |
| 20:32:40 | sipa: | please |
| 20:55:44 | bramc: | How much of a problem is dust really? Do wallets in the wild wind up getting filled with dust? |
| 20:56:47 | fluffypony: | yes |
| 20:57:00 | fluffypony: | if you're pool mining with a smallish piece of hardware, of course |
| 20:58:32 | bramc: | How small does the dust tend to be compared to the size of the account? 1%? .1%? |
| 20:59:22 | Luke-Jr: | fluffypony: pools tend to offer minimum payouts to avoid that |
| 21:00:01 | fluffypony: | Luke-Jr: sure, so it depends on what you define as dust |
| 21:00:20 | fluffypony: | and you're a piss-poor reference point for that, given your history. |
| 21:00:33 | Luke-Jr: | lolwut, are you trolling? |
| 21:00:48 | fluffypony: | Luke-Jr: no off-topic, plx. |
| 21:00:53 | Luke-Jr: | … |
| 21:04:45 | bramc: | When wallets pay out, do they always hand out one utxo or do they sometimes hand over a bunch of utxos whole to avoid extra linking? |
| 21:06:07 | Luke-Jr: | bramc: Bitcoin Core always does one, but multiple may become more common in the future |
| 21:06:26 | Luke-Jr: | it's been discussed, at least - not sure if any other wallet is implementing it yet |
| 21:06:40 | Luke-Jr: | since each UTXO needs its own address, it only really works with things like stealth addresses |
| 21:06:56 | sipa: | Luke-Jr: i have an email from satoshi from 2011 in which he suggests doing that :) |
| 21:07:13 | bramc: | multiple seems like a good idea, no need to go shmearing the history of everybody else you've done business with across the block chain |
| 21:07:15 | belcher: | satoshi was still around in 2011 ? |
| 21:07:21 | sipa: | belcher: not publicly |
| 21:07:36 | belcher: | i know, last post around 2010 |
| 21:07:40 | sipa: | it was early 2011 |
| 21:10:45 | bramc: | not sure what you mean by 'stealth addresses'. Obviously you need to send multiple utxos to different recipient keys or there's no point |
| 21:11:52 | sipa: | stealth addresses are a sort of static address that lets the sender derive the actual key at sending time, and attaches data to the transaction to make it recoverable by the receiver |
| 21:12:13 | sipa: | so every transaction on the chain pays to a different key, even though the identifier used was the same |
| 21:13:47 | Muis: | Monero does something very similar as stealth adresses |
| 21:18:03 | bramc: | Are these explained in bip32 or is that something else? |
| 21:21:30 | fluffypony: | Muis: kinda...we have two public keys, and the "destination" for an output is computed from both of those pubkeys + some random data |
| 21:24:53 | Muis: | bramc: http://sx.dyne.org/stealth.html |
| 21:25:49 | bramc: | Thanks Muis |
| 21:26:20 | fluffypony: | (computed by P = Hs(rA)G+B, where P = one-time public key / destination, Hs = a hashing function, r = a random r ∈ [1,l- |
| 21:48:15 | AdrianG: | is anyone interested in analyzing bitcoin's incentive structure? |
| 21:49:21 | tdlfbx: | AdrianG: people talk about little else. |
| 21:49:36 | AdrianG: | i dont see that. |
| 21:49:52 | tdlfbx: | stick around. ;-) |
| 21:50:59 | AdrianG: | bramc: why do you expect 2016 halvening will have any serious impact on btc market cap at all? |
| 21:51:29 | AdrianG: | only because instead of 3.6k, we'll have 1.8k new coins entering markets daily? |
| 21:51:34 | bramc: | AdrianG, If miners are selling their coins as they get them the supply of coins available will immediately tank |
| 21:51:45 | bramc: | Yep |
| 21:51:56 | AdrianG: | bramc: everyone knows when it'll happen, it's going to be priced in well before it actually happens. |
| 21:52:16 | AdrianG: | exchange volumes are way higher than 3.6k. |
| 21:52:33 | AdrianG: | this makes sense in theory, I don't know how applicable this is in practice. |
| 21:52:34 | bramc: | AdrianG, Maybe. We shall see. there's enough uncertainty that it's hard for the market to prepare |
| 21:52:47 | AdrianG: | for now, it is too far away, yes. |
| 21:53:04 | bramc: | It's also possible that the price will rise in advance expecting a spike and then drop right after when the spike doesn't happen |
| 21:53:11 | AdrianG: | but think of it in a different way. if btc market cap goes to 100+ billions, it'll cost 6.5 billion/year to secure the network after 2016 |
| 21:53:22 | AdrianG: | 6.5 bn/year. thats seriously high costs. |
| 21:54:42 | bramc: | AdrianG, Yes that's the sucky thing about cryptocurrencies |
| 21:55:13 | AdrianG: | I think that's a very serious hurdle. |
| 21:56:30 | tdlfbx: | How much do we spend on banks now though? |
| 21:57:07 | AdrianG: | tdlfbx: for sure inflation and the "banking" cartel end up costing more. |
| 21:57:17 | AdrianG: | but nobody percieves those costs as actual "costs" |
| 21:57:35 | tdlfbx: | And the bankers love that. |
| 21:57:49 | AdrianG: | i know an argentinian who was screwed out of his retirement nest egg by the arg. govt |
| 21:57:58 | AdrianG: | he went as far as immigrating to another state, starting a new life |
| 21:58:07 | AdrianG: | and now guess what, he keeps voting for bigger govts. |
| 21:58:27 | AdrianG: | tdlfbx: of course they love it, its the best scam on earth. |
| 21:58:45 | AdrianG: | however, this doesnt resolve the economic issues the blockchain will run into if it grows. |
| 21:59:48 | AdrianG: | the technology can easily be resolved, even if it requires terabytes of storage and lots of 24/7 bandwidth. I'm not sure how economics are going to be solved, if at all, I don't think anyone will seriously consider altering reward schedules. |
| 21:59:59 | tdlfbx: | PoW is like democracy. It's the best of a bad lot. Yes it's expensive. But there's no alternative. |
| 22:00:24 | AdrianG: | on the other hand, coins sold by miners offer constant liquidity. |
| 22:00:29 | AdrianG: | so its not like its a total negative. |
| 22:01:06 | bramc: | I don't mean to be one of those people, but could we not have this discussion on this channel? |
| 22:02:02 | AdrianG: | the cost considerations? |
| 22:03:51 | bramc: | AdrianG, the political angle. Technical discussions of the implications of cost structure I'm happy to engage in |
| 22:04:07 | AdrianG: | i dont care much for political talk either. |
| 22:04:10 | AdrianG: | but anyway. |
| 22:04:41 | AdrianG: | at that size of blockchain, costs to secure it will pretty much equal operating income of the UK's National Grid PLC |
| 22:05:26 | bramc: | The hard limit on transaction volume is likely to be a big problem long before then |
| 22:05:39 | AdrianG: | thats a technical problem, and can be solved, i think |
| 22:06:05 | bramc: | It isn't a terribly simple thing to solve |
| 22:06:39 | AdrianG: | ofc not, but it can be solved. |
| 22:07:07 | bramc: | It's also possible that more utxos might get to be 'in circulation' at larger scale, and the price would go down correspondingly. The vast majority have never been spent. |
| 22:07:24 | AdrianG: | bramc: i think thats whats happening at the moment |
| 22:08:27 | bramc: | It's quite likely that someone, maybe, I dunno, the winklevoss twins, is buying up coins whenever the price drops too much to prevent a fast selloff, but they might have run out of cash |
| 22:08:48 | AdrianG: | tbh, at that size, thats M1 money supply of smaller states, like finland and singapore |
| 22:09:25 | bramc: | It isn't clear how much real commerce is happening via bitcoin right now. It's possible that the overwhelming majority is still speculation. |
| 22:09:44 | AdrianG: | most certainly it is specs. |
| 22:10:18 | bramc: | As a general rule an unfounded asset can go down just as quickly as it went up |
| 22:10:20 | AdrianG: | btc is basically a foreign currency. even if you'd have blockchain based, idk, yuans |
| 22:10:34 | AdrianG: | why would anyone use them in the US? exchange costs/volatility alone would be a major issue. |
| 22:11:01 | bramc: | If you want expedient money transfers. They actually cost less than western union. |
| 22:11:29 | AdrianG: | cross-border - yes, its great |
| 22:11:40 | AdrianG: | which is where i expect to gain traction first |
| 22:11:51 | AdrianG: | it already did, in some ways. |
| 22:12:10 | bramc: | Of course, there's nothing stopping the traditional banking system from getting its shit together and offering a similar service, which wouldn't be a bad thing |
| 22:13:31 | AdrianG: | http://en.wikipedia.org/wiki/Fortum |
| 22:14:03 | AdrianG: | so basically yes, bitcoin mining will have to become a large utility corp to support marketcaps of that size |
| 22:14:59 | AdrianG: | do you think its actually feasible? |
| 22:15:19 | bramc: | Probably not, but I'm just working on interesting engineering problems |
| 22:15:31 | AdrianG: | which? |
| 22:16:31 | bramc: | And honestly, my attitude towards people 'investing' in bitcoin by buying it is caveat emptor |
| 22:17:00 | bramc: | AdrianG, There's been a whole long list of interesting technical discussions about bitcoin I've been having on here, still not sure what I'm going to build though |
| 22:17:50 | AdrianG: | are PoS/hybrid/etc sidechains possible theoretically? |
| 22:20:39 | bramc: | In principle scaling issues could be addressed with sidechains. It isn't a slam dunk though. |
| 22:21:47 | AdrianG: | yes, but can they be using anything else besides PoW |
| 22:22:02 | AdrianG: | ? |
| 22:22:41 | bramc: | Someone else needs to explain all the details of how microtransactions can be enabled via sidechains. I remain skeptical. |
| 22:23:52 | AdrianG: | with microtransactions its the 1st time sign up thats the cause of friction |
| 22:24:20 | bramc: | It isn't the case that mining has to be a particular fraction of transaction volume by the way. All that has to happen is that it's more profitable to take mining rewards and transaction fees than to engage in fraudulent double-spending. It's rather hard to do fraudulent double-spending, and if it starts getting dicey then the likely result is that people will just have to wait longer for transactions to clear |
| 22:24:44 | bramc: | because what matters is the total amount of work which has passed since your transaction went through, so waiting longer works well. |
| 22:25:01 | AdrianG: | bramc: do you really think microtxns need to be secured by the entire network |
| 22:25:14 | bramc: | There are a lot of problems with microtransactions. The biggest one being blowing the transaction rate limit. |
| 22:25:31 | bramc: | the output of a microtransaction needs to be redeemable, that's where the problems come in |
| 22:25:33 | AdrianG: | even securing $4 starbuck coffees sounds absurd |
| 22:26:43 | bramc: | Well buying at point of sale has the problem that it takes half an hour for a transaction to clear |
| 22:27:13 | AdrianG: | exactly, so its a non-starter |
| 22:27:19 | AdrianG: | they are going to be centralized, like changetip or something |
| 22:27:36 | bramc: | or VISA :-P |
| 22:29:10 | bramc: | sidechains could possibly have shorter clearing times, but getting under 30 seconds presents some deep engineering challenges |
| 22:30:29 | AdrianG: | ive heard someone proposing multisig txns for those scenarios |
| 22:30:55 | AdrianG: | with one of them being basically a bank of sorts, like coinbase cosigns your transactions, etc |
| 22:33:34 | instagibbs: | GA.it is exactly such an arrangement. 2-of-2, GA.it promises not to double-spend. |
| 22:37:09 | AdrianG: | ? |
| 22:37:17 | AdrianG: | GA? |
| 22:38:41 | instagibbs: | GreenAddress.it (GA.it) |
| 22:38:45 | instagibbs: | sorry it's a long name |
| 22:39:59 | instagibbs: | hub-spoke style micropayment channels make even more sense. Similar limited trust model, most activity "off-chain" |
| 23:00:44 | wallet421: | wallet421 is now known as wallet42 |