| 00:00:06 | adam3us: | maaku_: "3 people to donate <$1000" i a not sure what this says about the crypto currency market. seems like so far its telling us that scamcoins and crazy but high PR things get the most money. if the market keeps voting that way an the money is used accordingly (ie nothing good morphs out of bad money) ... hmm depressing |
| 00:00:19 | jtimon: | maaku_ adam3us re not the end of the worl: specially if litecoin was MM |
| 00:00:51 | adam3us: | jtimon: but its different PoW |
| 00:01:00 | maaku_: | adam3us: yeah, depressing :( |
| 00:01:20 | jtimon: | yeah, I mean assuming it was a SHA256 improvement instead of a scrypt one |
| 00:01:30 | adam3us: | petertodd: do something good with msc money to restore our faith in humanity :) please! |
| 00:01:45 | killerstorm: | people regularly ask me how to buy colored coins, I have a hard time telling them that it's impossible :). they do this much research before "investing"... |
| 00:01:57 | petertodd: | adam3us: don't worry, going to vegas with my first paycheck to find some strippers |
| 00:02:11 | maaku_: | pics or it didn't happen |
| 00:02:12 | petertodd: | killerstorm: lol |
| 00:02:22 | jtimon: | re: 1M usd destruction it would be funny if the guy said "it was a joke" |
| 00:02:33 | petertodd: | jtimon: the guy is anonymous |
| 00:02:47 | maaku_: | killerstorm: that sounds like every investor conversation Jorge and I have had (save one, maybe something will come of that) |
| 00:02:55 | jtimon: | petertodd does it make it less funny? |
| 00:03:04 | petertodd: | jtimon: it makes it more plausible |
| 00:03:11 | petertodd: | jtimon: well, more likely |
| 00:03:13 | maaku_: | he sure as hell is going to stay anonymous now |
| 00:03:16 | adam3us: | petertodd: did someone look at the code of xcp? it claims to actually have stuff working? |
| 00:03:59 | maaku_: | adam3us: honestly the crypto currency investment market reminds me of Lemmings |
| 00:04:02 | petertodd: | adam3us: I did, not much too it |
| 00:04:49 | killerstorm: | BTW is anybody interested in reviewing design/implementation of colored coin client (NGCCC aka ChromaWallet)? We don't have people who are familiar with bitcoin clients in our team, I just want to confirm we aren't doing something stupid... |
| 00:04:53 | adam3us: | maaku_: i think there is a lot of dumb money. people who got lucky with various mining/buying things and are not considering it real money |
| 00:05:07 | warren: | adam3us: maaku_: I'm open to diverging more from bitcoin. it just isn't clear what are the good ideas at the moment. |
| 00:05:07 | killerstorm: | We can probably allocate some bounty for it (review). |
| 00:05:34 | warren: | adam3us: maaku_: meanwhile litecoin has mainly been useful in discovering bugs that are in bitcoin |
| 00:06:03 | adam3us: | warren: could try zerocash but integrated in the way zerocoin was planned if you like being a canary |
| 00:06:21 | warren: | adam3us: the original zerocoin? |
| 00:06:28 | maaku_: | adam3us: unfortunately that pool of dumb money will eventually empty itself on mostly useless projects :( |
| 00:06:38 | maaku_: | there's some other interesting ones out there |
| 00:06:52 | adam3us: | warren: well u recall that it was a trustless mix attached to the block chain |
| 00:06:56 | maaku_: | but quality of the project seems to be inversely proportional with funds received |
| 00:06:59 | jrmithdobbs: | maaku_: nah that's not the sad part |
| 00:07:01 | warren: | adam3us: I'm actually very interested in P2SH^2 and something like p2pool in the standard client |
| 00:07:23 | warren: | adam3us: I don't like data storage in the blockchain and mining centralization is a long-term existential threat. |
| 00:07:33 | killerstorm: | Oh, BTW, is anybody working on cryptocurrency which uses something other than ECDSA? |
| 00:07:41 | adam3us: | warren: whereas now that bitcoin said "nah too heavy" with zerocash which is actually light enuf to be sensible, they're taken the msg that they will create an alt instead. |
| 00:07:48 | maaku_: | warren: be careful the trapdoor in zerocash though... not ready for prime time imho |
| 00:07:55 | jrmithdobbs: | maaku_: the sad part is that it's self fullfilling and there doesn't seem to be a way to break the chain, it's like people actually actively attempt to invest in the worst ideas in the space because they think they have intuition for the system they're buying into when they really have no fucking clue what's going on |
| 00:07:57 | warren: | maaku_: I'm aware |
| 00:08:09 | maaku_: | killerstorm: we're eventually going to add schnorr and laport signatures |
| 00:08:22 | jrmithdobbs: | maaku_: but maybe i'm just jaded :) |
| 00:08:22 | adam3us: | killerstorm: gmaxwell investigated using EdDSA as a bitchoin |
| 00:09:11 | adam3us: | killerstorm: new sigtype which is schnorr and so has some nice features (compact k of n sig, blind sig) |
| 00:09:26 | jtimon: | maaku_ lol lemmings |
| 00:09:40 | warren: | Is the latest thoughts on P2SH^2 written anywhere? |
| 00:09:42 | warren: | I lost my IRC logs. |
| 00:09:46 | adam3us: | maaku_ warren: yes the setup time trapdoor is a problem someone has to be trusted to delete it |
| 00:09:57 | justanotheruser: | maaku_: I think it's already been implemented, it's just not public |
| 00:10:20 | killerstorm: | maaku_: I think it would be interesting to implement optional upgrade-to-lamport. I.e. script references both ECDSA pubkey and Lamport pubkey, normally only ECDSA pubkey is used, but optionally if ECDSA is broken :), one can use Lamport pubkey without revealing ECDSA pubkey |
| 00:10:34 | adam3us: | warren: if you dislike centralization and have not much SPV clients? you could consider committed-tx experiments |
| 00:10:56 | petertodd: | warren: I can send you my logs |
| 00:11:33 | maaku_: | killerstorm: that would be perfectly doable using multisig |
| 00:11:37 | warren: | adam3us: regarding zerocash, even if it is efficient in terms of blockchain bloat, I am concerned about the regulatory implications. The current situation with bitcoin less-private-than-case-even-with-coinjoin might strike a good balance of needed transactional privacy with the need to prevent unfettered criminal uses. |
| 00:11:38 | adam3us: | warren: i agree mining centralization is bad. committed-tx is an attempt to have user polic choice even with quite high centralization by denying miners information with which to make policy on |
| 00:12:01 | warren: | less-private-than-cash |
| 00:12:07 | adam3us: | warren: yeah the risk is not lost on me. hence "if you want to be a (regulatory) canary" |
| 00:12:11 | maaku_: | you'd accomplish this by sighash extension, so the signature itself specifies which scheme is used (of course it would have to match the pubkey) |
| 00:12:43 | petertodd: | adam3us, warren: committed txin may be even more interesting along those lines |
| 00:12:44 | warren: | adam3us: mastercoin is asking to be a regulatory canary |
| 00:13:14 | warren: | adam3us: I think centralization should be a top priority, it is an existential threat. |
| 00:13:40 | maaku_: | killerstorm: lamport sigs are big ... even in a post-quantum world i think we'd still use elliptic curves |
| 00:14:08 | warren: | centralization is *THE* existential threat |
| 00:14:12 | petertodd: | warren: +1 |
| 00:14:13 | adam3us: | warren: btw i think its not as clear cut as all that. you can make different privacy tradeoffs by choice. zerocash is a building block as much as ecdsa. you could have fungible coins with new "wallet addresses" that have a similar payment level linking as today. |
| 00:15:01 | adam3us: | warren: sign me up no that call too "centralization = existential threat" |
| 00:15:03 | warren: | petertodd: I'd like logs covering all the recent P2SH^2 discussion |
| 00:15:38 | adam3us: | warren: which i think is a quite interesting tradeoff. no more private than current, but fully fungible. (coinvalidation falls on its face) |
| 00:16:05 | warren: | is zerocash's design published? |
| 00:16:33 | maaku_: | warren: no |
| 00:16:37 | adam3us: | warren: ie current privacy at payment level, but fungible/anonymous at coin level. so if you trade a bad actor you ask them to reimburse you but you cant freeze the coin |
| 00:16:44 | petertodd: | warren: sent |
| 00:17:30 | adam3us: | warren: gmaxwell knows more about it (zerocash) |
| 00:18:09 | adam3us: | warren: also there was a podcast recording of matthew green talk on it at real world crypto conf, can google for |
| 00:18:13 | killerstorm: | maaku_: I think the idea is to have something as a backup IF shit hits the fan. E.g. if ECDSA vulnerability is discovered, people can use Lamport signatures temporarily, and then hard-fork upgrades cryptocurrency to something small and safe. |
| 00:19:17 | adam3us: | warren: you could always build holes to plug it into, then wait for zerocash to release their code & link in the library |
| 00:19:21 | warren: | IMHO, I rather focus entirely on the centralization existential threat. |
| 00:19:52 | warren: | That's uncontroversial. |
| 00:19:54 | adam3us: | warren: ok. see if u can do something with committed tx. |
| 00:20:20 | adam3us: | warren: are you willing to complicate SPV model to do it? |
| 00:20:28 | petertodd: | killerstorm: you realize that lamport sigs are implementable easily in even bitcoin's original scripting system right? |
| 00:20:40 | petertodd: | killerstorm: not possible now that op_cat is disabled, but it doesn't take much |
| 00:21:03 | killerstorm: | Well, how do you hide ECDSA pubkey? |
| 00:21:05 | Luke-Jr: | meh, "disabled" really means "removed" in this context :/ |
| 00:21:09 | warren: | adam3us: it depends, need to read all the current thinking on committed tx. is this written down anywhere? |
| 00:21:23 | petertodd: | Luke-Jr: yup |
| 00:21:24 | warren: | adam3us: I really dislike the current way SPV is done. |
| 00:21:25 | jrmithdobbs: | petertodd: ya well the disabled ops have enough to implement salsa/chacha too (inefficiently and insecurely) |
| 00:21:28 | jrmithdobbs: | heh |
| 00:22:00 | petertodd: | jrmithdobbs: well, scripts are limited to 10,000 opcodes so... probably not, lamport however is practical within the limits (modulo disabled ops) |
| 00:22:17 | petertodd: | warren: what do you want changed re: SPV? |
| 00:22:18 | adam3us: | warren: sort of but not really cleanly bct thread https://bitcointalk.org/index.php?topic=206303.0 ask if it doesnt make sense |
| 00:22:28 | jrmithdobbs: | petertodd: i think that's still true for at *least* chacha with the real limits |
| 00:22:40 | killerstorm: | Ok I guess it isn't hard to hide it... |
| 00:22:52 | jrmithdobbs: | petertodd: not that anyone should do so, ever |
| 00:22:58 | maaku_: | warren: anti-centralization is uncontrovertial. some of the side effects of relevant proposals are worrisome on the other hand |
| 00:23:14 | petertodd: | killerstorm: "can implement lamport" is probably a good minimum test for whether or not your scripting system is general enough! |
| 00:23:22 | maaku_: | there's no clear cut path forward which decentralizes the network without tradeoffs |
| 00:23:34 | warren: | petertodd: 1) easy to MITM 2) easy to determine which keys you have 3) no way of doing authenticated peerings 4) expensive to the server |
| 00:24:43 | petertodd: | warren: right 1) committed (U)TXO 2) all the lessons in my blockchain privacy paper 3) add SSL or SSL-alike 4) prefix-filters w/ appropriate indexes |
| 00:25:00 | warren: | maaku_: multiple competing scalable p2pool-like things with a trustless accumulators and more GBT pools would be low hanging fruit |
| 00:25:07 | petertodd: | warren: electrum actually is reasonably close to solving all that, modulo committed indexes |
| 00:25:19 | warren: | petertodd: yeah |
| 00:25:37 | adam3us: | petertodd, warren: prefix have worse privacy properties than bloom. |
| 00:25:42 | petertodd: | warren: problem is we have to make it *more* profitable to mine with p2pool/decentralized, and that's going to require changing economics |
| 00:25:43 | maaku_: | petertodd: well, Thomas is waiting on me for the indices |
| 00:25:46 | maaku_: | * maaku_ gets back to work |
| 00:25:49 | petertodd: | adam3us: depends on your attack model |
| 00:26:13 | petertodd: | adam3us: again, did you read my paper? :P I strongly think in practice with real users prefix has better real-world privacy |
| 00:26:16 | adam3us: | petertodd: broadcast vulnerable info is like worse because it can be analysed later by anyone, vs sent to one random node |
| 00:26:23 | adam3us: | petertodd: i did, i just disagree. |
| 00:26:32 | petertodd: | adam3us: well, least you read it finally, ha |
| 00:26:47 | warren: | petertodd: the lower orphan rate should help. currently the too-many-txo's in coinbase is a problem. |
| 00:26:59 | adam3us: | petertodd: yeah i skimmed it before also. as i recall gmaxwell has the same view as me on that risk. |
| 00:27:00 | warren: | petertodd: the trustless accumulator should help that |
| 00:27:13 | petertodd: | adam3us: problem is bloom naturally leads to a situation where people broadcast the *exact* contents of their wallets over and over again to random peers, and that's just nasty |
| 00:27:37 | petertodd: | adam3us: android wallet has 1 in 16k specificity for a reason - users want fast syncs |
| 00:27:55 | petertodd: | adam3us: that could really kill coinjoin the moment attackers start running SPV nodes to collect wallet data |
| 00:28:36 | petertodd: | warren: no it won't - it still requires all the expense of running a full node |
| 00:29:14 | adam3us: | petertodd: they are both non ideal solutions. it is considered in privacy that you should pick a random node and stick to it. if its going to analyse you it already did. if you explore random nodes eventualy you'll find a hostile one. tor doesnt do this yet either, but theyre planning to fix it. |
| 00:29:16 | petertodd: | adam3us: anyway, prefix *queries* are a categorically better model than bloom filters from the point of view of lookup privacy |
| 00:29:54 | adam3us: | petertodd: that might be. also electrum is like central/trusted type of solution right? |
| 00:30:00 | petertodd: | adam3us: now forcing your txouts to match prefixes may or may not be the right approach, but only prefix queries lets you distribute the load, and thus query specificity leak, accross multiple nodes |
| 00:30:25 | petertodd: | adam3us: electrum is not different from bloom SPV in principle |
| 00:30:38 | petertodd: | adam3us: in practice maybe more secure in some models because there are fewer electrum servers |
| 00:30:46 | petertodd: | adam3us: and their operators are better known |
| 00:30:58 | adam3us: | petertodd: but in practice, i thought electrum have a few central servers |
| 00:31:22 | petertodd: | adam3us: meh, picking random nodes and sticking to them isn't very feasible without a "small number of nodes run by volunteers" model |
| 00:31:28 | adam3us: | petertodd: yes if u trust electrum. the other model as said above, pick a random node and try to stick to it. |
| 00:31:30 | petertodd: | adam3us: and even in that model you're better off with prefix queries |
| 00:31:40 | petertodd: | adam3us: electrum *is* the pick a random node and stick to it mdoel |
| 00:32:32 | adam3us: | petertodd: well its electrum advertising them selves as a trustworthy node. sometimes that is a flag to say dont trust them. |
| 00:32:50 | petertodd: | adam3us: anyway, my prefix solution may leave some statistical data in the chain, but it has the enormous advantage that it doesn't fail hard the moment an attacker does a sybil attack. it also doesn't give that attacker a reason to do that sybil attack |
| 00:33:18 | petertodd: | adam3us: note how prefixes gives you decent security even *if* you're connected to the nsa |
| 00:33:22 | warren: | We could just forget about SPV, finish ultraprune and stop worrying about this. |
| 00:33:23 | adam3us: | petertodd: if u use prefix with one-use addresses t seems ok no? no need for explicit prefix |
| 00:33:24 | petertodd: | adam3us: (prefixes + addr grinding) |
| 00:34:06 | petertodd: | adam3us: no! unless your addresses in your wallet are clustered around a prefix, for a given amount of bandwidth you have to have very specific prefixes and thus are leaking a heck of a lot of data |
| 00:34:11 | CodeShark: | what's the prefix solution? using the first few bytes of a pubkey or script hash rather than a bloom filter? |
| 00:34:20 | petertodd: | warren: ultraprune doesn't help with bandwidth |
| 00:34:42 | petertodd: | CodeShark: yeah, there's two parts to it, first for queries you can always query by prefix |
| 00:34:59 | adam3us: | petertodd: could be block range constrained + closeness metric to tune like bloom |
| 00:35:08 | petertodd: | CodeShark: secondly you can always force your addresses in your wallet to *all* be clustered around soem prefix, which means you only have to do a single query |
| 00:35:41 | petertodd: | CodeShark: the beauty of the latter is even if you're querying the NSA for blockchain data they learn very little about what's in your wallet, the disadvantage is you leak *some* stat information to the blockchain permanently |
| 00:35:49 | adam3us: | petertodd: yeah but then you're back to broadcasting anon-set reducing info to the block chain for the stats analysis guys to party on. |
| 00:36:09 | petertodd: | CodeShark: I argue leaking some all the time is much better than leaking your exact wallet contents the moment you manage to connect to the NSA |
| 00:36:44 | petertodd: | adam3us: the types of people who have the resources to do stats analysis have the resources to just run 50% of the available nodes to connect too |
| 00:36:52 | adam3us: | petertodd: if you query the NSA with a prefix, they learn the anon-set you are in. just info o help triangulate you no? |
| 00:37:20 | adam3us: | petertodd: eh no? academics do it for like 3rd year project |
| 00:37:22 | petertodd: | adam3us: I mean, shit, I was running about 10% of all public nodes for a few hours to test an attack |
| 00:37:48 | petertodd: | adam3us: yeah, all they learn about is the prefix, and then the stats leaks stops |
| 00:37:49 | adam3us: | petertodd: oh ok, u mean on the low side, gotcha |
| 00:38:12 | petertodd: | adam3us: vs. without prefixed addresses *in reality* users set very specific prefix/bloom filters, and then you leak very specific contents of your wallet |
| 00:38:18 | adam3us: | petertodd: but a bloom filter with some decent params can do that also no? |
| 00:38:33 | petertodd: | adam3us: yeah, from the point of view of "clustered wallet addresses" bloom and prefix are identical |
| 00:38:39 | CodeShark: | petertodd: right now with BIP0032, you can have at most 2^31 different keys from a particular master seed - so say you use k bit prefix - that reduces the number of keys to 2^(31 - k), no? |
| 00:38:48 | adam3us: | petertodd: so say TD fixed improved the params |
| 00:38:48 | petertodd: | adam3us: if you're not clustering wallet addrs, bloom and prefix are identical, it's just the latter is way more scalable |
| 00:39:10 | jtimon: | petertodd is there any reason why you can't use several prefixes in your wallet? more bandwith but more privacy |
| 00:39:11 | jtimon: | ? |
| 00:39:12 | petertodd: | CodeShark: well BIP32 has problems there |
| 00:39:22 | petertodd: | adam3us: it's impossible to fit the params, it's a specificity/bandwidth tradeoff |
| 00:39:31 | petertodd: | adam3us: s/fit/fix/ |
| 00:39:47 | jtimon: | say, use 3 prefixes, n instead of 1 |
| 00:39:48 | petertodd: | adam3us: if you think params has anything to do with it you didn't understand my paper... |
| 00:39:55 | adam3us: | petertodd: bloom/prefix similar with no addr clustering... yes. |
| 00:39:57 | CodeShark: | perhaps we should expand the BIP0032 child index to 64 bits :) |
| 00:40:16 | petertodd: | jtimon: more prefixes *of the same length* just means you're using more bandwidth |
| 00:40:26 | petertodd: | jtimon: remember this is a bandwidth/anonymity set tradeoff |
| 00:40:32 | adam3us: | petertodd: you claimed the default params were too specific, so make them les so, while still tolerable bw. |
| 00:40:46 | petertodd: | adam3us: the reason why they are so specific is because users aren't tolerating more bandwidth |
| 00:40:48 | jtimon: | petertodd yes, my point is you can make the tradeoff configurable |
| 00:40:57 | petertodd: | jtimon: yes, and you can do that with prefix clustering too |
| 00:40:58 | CodeShark: | petertodd: I'm also thinking about how deterministic m-of-n script chains could work with this prefix model |
| 00:41:09 | adam3us: | petertodd: well more importantly u also said as i recall there was no feature to change the params |
| 00:41:10 | jtimon: | yes, yes, with prefixes |
| 00:41:33 | petertodd: | jtimon: the fundemental problem is that if you don't cluster all your addresses in one prefix or bloom index, then naturally you have to have fairly specific filters, which overtime become more specific and let you be attacked |
| 00:42:02 | petertodd: | adam3us: in the library and wallets no, but the bloom filter specification does let you change the params easily by making the filter smaller |
| 00:42:07 | petertodd: | adam3us: smaller filter == less specific |
| 00:42:28 | CodeShark: | there is in my library :) |
| 00:42:40 | petertodd: | CodeShark: good |
| 00:42:49 | jtimon: | but with prefixes, can't you just ask for more info than you need? |
| 00:42:58 | petertodd: | jtimon: that's the whole point of prefixes! |
| 00:43:00 | jtimon: | I know, more bandwidth |
| 00:43:21 | petertodd: | jtimon: gah, have you read that paper of mine? |
| 00:43:48 | jtimon: | my point is I don't see the bad side, with prefixes you can have the best privacy of them all at the cost of bandwith |
| 00:44:08 | petertodd: | jtimon: ah, well, that's why I'm pushing the idea :) sounds like we're in agreement |
| 00:44:11 | jtimon: | sorry, no |
| 00:44:40 | petertodd: | jtimon: you should, because everyone loves debating this without actually reading the damn thing and why I think it's worth making these tradeoffs |
| 00:44:56 | petertodd: | jtimon: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03612.html |
| 00:45:38 | petertodd: | I mean, hell, it's paragraph three where I outline that my threat model is an attacker controlling a reasonable number of the nodes you're SPV client is going to connect too... which is a *very* reasonable attack model. |
| 00:46:02 | petertodd: | Again, saying this because I've actually done this personally by throwing some cash at Amazon EC2 |
| 00:46:04 | jtimon: | yes, I don't understand adam's objections, yet I don't know what's the alternative, but yes, as said earlier to adam you shouldn't bother much explaining me this because I haven't read steakth addresses yet, really my fault for trying to follow again, sorry |
| 00:46:17 | petertodd: | jtimon: thanks |
| 00:47:03 | CodeShark: | jtimon: there's so much stuff going on in this space right now you'd be excused for not reading absolutely everything :) |
| 00:47:20 | adam3us: | petertodd: btw backing up a bit time-lock and stego, i dont think consensus is affected by unavailibility of the key, and the key can be encrypted for the recipeint and stored in the block chain |
| 00:47:39 | petertodd: | adam3us: no, the recipient is the public |
| 00:47:43 | adam3us: | petertodd: so then its simple matter if people do not reveal the key, they cant respend |
| 00:47:55 | petertodd: | adam3us: that's got nothing to do with it |
| 00:48:18 | CodeShark: | the recipient's key is already a hash of a pubkey |
| 00:48:25 | adam3us: | petertodd: yes for your other use case. but then make it available from all nodes (its validatable against the ciphertext) |
| 00:48:55 | petertodd: | adam3us: the problem is that miners who know a tx is part of some consensus scheme may want to censor the tx and not mine it, yet the tx data *must* be guaranteed to be made public to everyone for a consensus scheme to work, thus, use timelock to force miners to either delay *all* transactions, or give up trying to censor |
| 00:48:58 | jtimon: | CodeShark yes, that's why I was "passing on stealth addresses for now", as a filter, but then I shouldn't try to follow the discussions about it intervening in them |
| 00:49:15 | petertodd: | adam3us: there is no way to prove publication unless you can guarantee that the data can be decrypted |
| 00:50:11 | CodeShark: | whether or not keys are encrypted has no effect on privacy as long as the keys (encrypted or not) can be associated with a wallet |
| 00:50:18 | adam3us: | petertodd: i guess you are assuming a network where 90% of miners and nodes hate msc spam and want to kill it ;) so then you cant rely even on relaying and it maybe difficult to find a node with the key? |
| 00:50:31 | petertodd: | adam3us: consider a key:value(s) consensus system: if it's just encrypted, I could hold onto the key, then release it after the fact, changing the consensus suddenly |
| 00:51:11 | petertodd: | adam3us: that's the whole fucking point of it: how to make an embedded consensus system that's uncensorable unless miners implement whitelists |
| 00:51:43 | petertodd: | adam3us: of course I'm assuming that - if I wasn't it wouldn't be much of a result |
| 00:52:20 | petertodd: | adam3us: I mean, hell we've got an existance proof that if only some miners hate you you can still get your tx's mined... |
| 00:53:25 | adam3us: | petertodd: ok then; it a bit slow tho time-lock. maybe you can find a subnet of msc-relaying nodes |
| 00:54:42 | petertodd: | adam3us: well sure, but that's not unlike making the block time longer - perfectly acceptable for a lot of applications |
| 00:55:12 | petertodd: | adam3us: I'm not claiming mastercoin should go and implement it right now - I'm pointing out that they could |
| 00:56:37 | adam3us: | petertodd: yep. i have some more stego end-game ideas. still holding them back :) |
| 00:56:56 | adam3us: | petertodd: meaning i dont disagree the steganographer wins. in the en game |
| 00:57:14 | petertodd: | adam3us: meh, do everyone some good and just publish them so people stop making shitty assumptions about scalability |
| 00:58:25 | adam3us: | petertodd: they are not so interesting, just silly things you could do if you had to (if bandwidth was no obstacle). you probably already thought of them. |
| 00:59:08 | petertodd: | adam3us: ah, well if they're less efficient don't bother |
| 01:00:03 | killerstorm: | killerstorm has left #bitcoin-wizards |
| 01:00:10 | petertodd: | adam3us: anyway, the interesting thing is how to make crypto-currencies where utxo bloat and so on doesn't matter, and I think we're close to solving that pretty thoroughly |
| 01:00:27 | adam3us: | petertodd: cant u get get consensus by time-stamping and using a separate msc-only network for the data? |
| 01:00:50 | petertodd: | adam3us: consensus isn't just time-stamping |
| 01:01:01 | petertodd: | adam3us: proof-of-publication matters, and it's really not trivial |
| 01:01:12 | petertodd: | adam3us: heck, maybe there is no general solution to it |
| 01:01:55 | adam3us: | petertodd: well i mean if you tolerate jamming. just have nodes stop if they cant obtain a full explanation of the time-stamp merkle tree. |
| 01:02:29 | petertodd: | adam3us: the point of proof-of-publication is to tolerate jamming you know... |
| 01:03:21 | adam3us: | petertodd: hmm so you want to send the (time-lock) encrypted msg in the chain because then its atomically delivered so either you get it or you dont. |
| 01:03:24 | petertodd: | adam3us: frankly I think many in the bitcoin community are letting their desire to keep data out of the chain blind them to how fucking hard it is to make these things secure |
| 01:03:47 | adam3us: | petertodd: stego wins. i know it :) |
| 01:04:17 | adam3us: | petertodd: even if you have to use like morse code in the lsbit! |
| 01:04:31 | petertodd: | adam3us: it's not about "stego winning" - it's that people keep pushing MM and similar schemes not because it's better for the consensus system in question, but because it's better for bitcoin |
| 01:05:02 | petertodd: | adam3us: and whenever those consensus schemes take that advice, we bitcoin devs fool ourselves |
| 01:05:49 | adam3us: | petertodd: oh diff meaning. ok well given the scalability limitations, absent a robust scalability fix, as you said sharding seems better. so a MM chain is a crude form of sharding. if security is important buy some kncminers to tip the balance. or work on educating users to not use big pools etc. |
| 01:05:59 | petertodd: | adam3us: and you know, unless you honestly look at the incentives and attacks possible, you're not going to come up with MM schemes that *actually* work |
| 01:06:09 | adam3us: | petertodd: sure. |
| 01:06:10 | petertodd: | "educatiing users" fuck off |
| 01:06:19 | petertodd: | we've got a system where you *earn more money* mining at a big pool |
| 01:06:27 | petertodd: | that's fundemental to how bitcoin works and isn't going to change |
| 01:06:40 | adam3us: | petertodd: there are other ways to "educate" users you know. that may require tor for the educators safety... |
| 01:07:08 | petertodd: | adam3us: all solutions that don't help *decentralized consensus systems* |
| 01:07:10 | adam3us: | petertodd: i wonder if any o fthem are selfish mining |
| 01:07:13 | maaku_: | petertodd: currently, you earn more money mining p2pool... |
| 01:07:29 | petertodd: | maaku_: not if you take your time into account for many miners... |
| 01:07:29 | adam3us: | maaku_: yes. this is very puzzling to me. |
| 01:07:49 | adam3us: | petertodd: but its just as easy to pick p2pool from the list |
| 01:08:14 | maaku_: | adam3us: you don't pick p2pool from a list, you run a local daemon |
| 01:08:16 | petertodd: | maaku_: like it or not we probably have to get to the point where pools *can't* exist, and simultaneously fix scalability |
| 01:08:21 | maaku_: | but i've found it to be very stable at least |
| 01:09:03 | adam3us: | maaku_: i htought one of the miners i tried seemed to support p2pool out of the box (if it ran a daemon itself maybe) |
| 01:09:18 | maaku_: | petertodd: i like getting rid of pools. i don't like the negative side effects i've seen come attached to such proposals |
| 01:09:29 | petertodd: | adam3us: did you have a full node? if not you weren't using p2pool |
| 01:09:41 | adam3us: | petertodd: i did yes |
| 01:09:43 | petertodd: | maaku_: meh, just means you have to keep working on the proposals |
| 01:09:58 | maaku_: | adam3us: that'd be great if it does, but it probably just connected to a public p2pool node |
| 01:10:18 | maaku_: | which is really no different than a centralized pool as far as this conversation is concerned |
| 01:10:19 | petertodd: | maaku_: don't think I'm saying I have a perfect solution yet, I'm just saying we're incredibly naive in this community thinking stuff like p2pool is much of a fix |
| 01:10:48 | petertodd: | heh, heck, adam not knowing exactly what his hashing power was doing is a great example of why this is hard... |
| 01:10:52 | adam3us: | warren: maybe in your p2pool fixing budget you could try get a shiny nice UX GPU / ASIC scrypt/hashcash miner that bundles p2pool and makes it the default |
| 01:11:24 | petertodd: | adam3us: meh, that shiney p2pool bundle is an easy thing that people are already working on for free |
| 01:11:44 | warren: | adam3us: p2pool requires high CPU and disk i/o performance to be efficient =( |
| 01:11:47 | adam3us: | petertodd: i think the UX might be the key though. if someones doing it for fre fine |
| 01:12:27 | maaku_: | warren adam3us: really all you need to do is bundle up a py2exe virtual environment for p2pool with gitian builds of bitcoind and bfgminer |
| 01:12:34 | petertodd: | warren: I set my p2pool node to mine very small blocks for that reason |
| 01:12:46 | maaku_: | let bfgminer --p2pool set up the services |
| 01:12:57 | petertodd: | warren: I think it's set to like 0.01BTC/KB fee or something |
| 01:13:03 | warren: | adam3us: I don't have a p2pool fixing budget, I just made large donations out of pocket to the only person working on the problem to give him more incentive. I'm not happy that the larger bitcoin community isn't taking the issue seriously, and I'm at my limit of what I'm willing to fund out of pocket. |
| 01:13:42 | petertodd: | warren: and you know, don' |
| 01:13:45 | warren: | adam3us: I paid about $30k out of pocket during 2013 to various people who helped upstream bitcoin or p2pool |
| 01:13:59 | petertodd: | warren: don't get me wrong, that was money well spent, it's just that in the wizards part of the community we should be working on better |
| 01:14:21 | petertodd: | warren: we're supposed to be thinking medium to long term here, fixing p2pool is short to medium |
| 01:14:51 | jrmithdobbs: | petertodd: but the p2pool thing highlights a real problem |
| 01:14:56 | warren: | adam3us: that money came from people who were concerned about litecoin dying entirely due to lack of developers. I don't expect future revenue potential to be anything like that special case. |
| 01:15:16 | jrmithdobbs: | petertodd: we have functional-enough-for-now technical solution to this, but (practically) noone using it |
| 01:15:51 | petertodd: | jrmithdobbs: yes, that's because it's a tech solution operating in a vacuume, not one that actually takes economics and incentives into account |
| 01:15:55 | warren: | petertodd: p2pool and eligius are attacking the low hanging fruit. I don't have the cycles or money to attack the long-term issues myself. |
| 01:16:15 | adam3us: | warren: i see. (re money situ/history). |
| 01:16:22 | jrmithdobbs: | petertodd: but there's noone (very few) willing to pay the people capable of the technical solutions and give them the context |
| 01:16:24 | petertodd: | warren: that's fine, I do for now |
| 01:16:25 | jrmithdobbs: | petertodd: how do we solve that? |
| 01:16:46 | adam3us: | warren: low hanging short term is good too. people are not even using what they could and yet we are concerned about that as a systemic risk. |
| 01:16:58 | petertodd: | jrmithdobbs: foundations tend to be good at that, but they aren't going to solve that if people don't even accept this stuff is a problem |
| 01:17:20 | jrmithdobbs: | petertodd: or when major players in said foundations deny it's a problem. |
| 01:17:29 | petertodd: | jrmithdobbs: I can hardly even convince people *here* that p2pool isn't a very good solution |
| 01:17:32 | petertodd: | jrmithdobbs: heh, that too |
| 01:17:38 | jrmithdobbs: | petertodd: that's not a solution, that's an admittence of failure, really |
| 01:17:39 | adam3us: | warren, petertodd: which says maybe boring things like user education, nicer UX, more bundling, advertisement are perhaps necessary strange as that seems to a tech mindset |
| 01:18:14 | warren: | adam3us: it's no secret that I've been planning a 501(c)(6) foundation that focuses on development, with issues like centralization as a top priority. A few big players are interested in funding it. I've been too busy with my own career to create it. |
| 01:18:23 | petertodd: | adam3us: I don't have a tech mindset remember... I know damn well boring stuff works in the short term, but I'm not foolish enough to think we aren't up against genuine economic perverse incentives |
| 01:19:24 | adam3us: | petertodd: agreed. but sometimes short-term stupid action gains its own momentum and defacto "way-it-works" that leads to development cementing the stupidity. so it maybe worth fixing these short-term what-users-are-doing when they coud do better issues |
| 01:20:46 | jrmithdobbs: | kinds are part of the types really |
| 01:20:50 | jrmithdobbs: | err wrong chan |
| 01:20:57 | petertodd: | adam3us: hence why I'm not against people improving p2pool; I'm against people who could use their talents to do even better spending their time on p2pool |
| 01:21:15 | warren: | adam3us: uncontroversial things for the new foundation to tackle: centralization, anti-DoS, anti-sybil, scalability, timestamping tech. I rather not prioritize regulatory canaries when there are plenty of uncontroversial existential threats. Others can work other issues. |
| 01:21:29 | petertodd: | adam3us: the people who can do that work can't do consensus system theory (and mostly vice-versa) |
| 01:22:31 | adam3us: | petertodd: yeah maybe it just pains me to sit around watching needless stupidity create short term network scale risks. like 40% miners (that can and did to double spend attacks) when there is no sane reason to do it. |
| 01:22:43 | warren: | Go ahead and call me chicken, after centralization is fixed. |
| 01:23:22 | adam3us: | warren: canaries are a special breed. seemingly matthew green has what it takes :) he claim's he's gonna make an alt out of zerocash. |
| 01:23:39 | petertodd: | adam3us: well like I said, for that issue you've got a hell of an uphill battle... we just to complain about hashers to point their hardware at ghash.io, but the reality is from their point of view there's nothing very stupid about it |
| 01:24:37 | adam3us: | petertodd: actually ghash doesnt charge fees i think. (like eligius and p2pool) otherwise often the big miners are charging like 5% and people are still using them over eligius or p2pool |
| 01:24:50 | warren: | ghash has other ways to make money (trading commissions...) |
| 01:24:59 | petertodd: | adam3us: I know, that's one of the reasons they're so big |
| 01:25:46 | warren: | If p2pool improved substantially, grew bigger and flexed its orphan advantage it might be able to compete. |
| 01:25:46 | adam3us: | petertodd: but i mean wtf why not put it up to 10% and see if they still stay there? do they even care about money? |
| 01:25:48 | petertodd: | adam3us: and 5% isn't much money - remember that when I talk about pools being "profitable" that includes non-monetary "compensation", as well as lower costs, and less perceived risk |
| 01:26:22 | petertodd: | adam3us: business risk is a funny thing - ghash.io has a perception to maintain |
| 01:26:27 | adam3us: | petertodd: u know there's one with 100% fee (aka it stopped paying out) and it still has significant TH |
| 01:26:35 | petertodd: | adam3us: equally, people's perception of value is often that higher cost == better |
| 01:27:04 | adam3us: | petertodd: i suspect its bigger == better thinking here. |
| 01:27:07 | petertodd: | adam3us: hey, if you look at that and say "WTF?!" rather than "yeah, I can see why" then you don't have the insights to understand this stuff |
| 01:27:13 | petertodd: | adam3us: yeah, well duh |
| 01:27:49 | adam3us: | petertodd: if u have no clue and someone forces you to make a too technical or arbitrary decision, you'll tend to follow what others are doing... |
| 01:27:53 | petertodd: | adam3us: that's why I said above you probably have to create tech where pools aren't just discouraged, but are actively disabled in various ways |
| 01:28:01 | petertodd: | adam3us: yup |
| 01:28:11 | petertodd: | adam3us: having to research the right way to do something is a huge cost |
| 01:28:19 | petertodd: | adam3us: heck, ahving to make choices at all is a huge cost |
| 01:28:49 | adam3us: | petertodd: but 5% eh. maybe a 50point font mining pool fee % & profit calculator in the miner sw |
| 01:28:53 | jrmithdobbs: | petertodd: you're trying to say that not only do you need to be able to recognize that "bigger == better" thinking but realize that a) it's not necessarily wrong and b) it's ingrained for a reason and isn't something that can be ignored because "people are dumb" |
| 01:28:57 | jrmithdobbs: | pes? |
| 01:28:58 | jrmithdobbs: | yes? |
| 01:29:11 | petertodd: | jrmithdobbs: yeah, all those points. |
| 01:29:39 | jrmithdobbs: | petertodd: just making sure i was understanding your point (and I agree) |
| 01:29:50 | petertodd: | Now if we're willing to accept that, then how do you force pools completely out of existance? I thik it was you adam who was talking about stealable proof-of-work for instance. |
| 01:30:22 | adam3us: | petertodd: yeah thats more intersting (must get off fixating on irritating user stupiity:) |
| 01:30:23 | petertodd: | Similarly, how can blockchains be structured such that p2pool-like varience reduction is a given? |
| 01:30:37 | amiller: | loosen the difficulty restriction |
| 01:30:42 | amiller: | let people choose their own difficulty in some way |
| 01:30:58 | amiller: | that way you can still maintain the overall security invariant |
| 01:30:59 | petertodd: | And, how can we make mining something that you don't need a bunch of setup time and other work to get started in? |
| 01:31:06 | adam3us: | petertodd: i think it was amiller who said it first (stealable PoW) except i thik he was talking reverse ... for hosted mining |
| 01:31:11 | petertodd: | amiller: well, is that diff per-block then or what? |
| 01:31:37 | amiller: | i was talking about both equally, i gave an abstraction where both pools and hosted mining are equally a security violation! |
| 01:31:49 | petertodd: | amiller: or can we split blocks up? how does consensus work? |
| 01:31:58 | adam3us: | amiller: actually the whole pool choses work packet for miner is just wrong thinkin |
| 01:32:01 | petertodd: | amiller: yeah, I'm not sure if I have a solution to hosted mining yet |
| 01:32:12 | adam3us: | amiller: the whole point of hashcash is the user choses their own work packet |
| 01:32:20 | petertodd: | adam3us: yet, just saying that doesn't help :) |
| 01:32:34 | warren: | Lots of the Litecoin users are pushing for a PoW change because they don't want the same thing to happen with ASIC's. |
| 01:32:38 | petertodd: | adam3us: getblocktemplate is the perfect example of just saying that, and look where that's gone |
| 01:32:43 | jrmithdobbs: | petertodd: the only straightforward solutions i can think of require things that don't actually exist |
| 01:32:44 | amiller: | so the block selection function is |
| 01:32:46 | petertodd: | warren: Good! |
| 01:32:48 | amiller: | choose the lbock with largest sum difficulty |
| 01:32:49 | warren: | They're quite naive, suggesting just increasing the scrypt parameters. |
| 01:32:51 | amiller: | that's invariant to difficulty choice |
| 01:32:55 | jrmithdobbs: | but i've not spent much time thinking about hosted mining, ha |
| 01:32:59 | amiller: | the problem with difficulty choice is one of PoW basically |
| 01:33:11 | adam3us: | petertodd: whats wrong with GBT? |
| 01:33:15 | amiller: | er |
| 01:33:16 | amiller: | Dos |
| 01:33:16 | petertodd: | warren: heh, they willling to put money towards researching ASIC-hardnesss |
| 01:33:27 | petertodd: | adam3us: there's no incentive for individual hashers to use it |
| 01:33:54 | warren: | If Litecoin is willing to go through the pain of a hardfork, it better be more interesting than bigger scrypt. |
| 01:34:00 | petertodd: | warren: agreed |
| 01:34:07 | warren: | And I think bigger scrypt is a bad idea, validation is already slow. |
| 01:34:19 | amiller: | you can reject someone's blocks, as part of the rational strategy space |
| 01:34:35 | amiller: | so that can include whether the sum difficulty is over tons of weak blocks or a few bonanza blocks with high diffiuclty |
| 01:34:39 | adam3us: | warren: coelho merkle hash PoW is better. vitalik used it in dagger for ethereum. |
| 01:34:40 | amiller: | obviously the tons of weak blocks is a DoS |
| 01:34:42 | petertodd: | warren: heh, well, doing birthday-style momentum hash would be as temporarily asic-hard as any scrypt tweak, and with fast validation |
| 01:34:47 | amiller: | but we handle DoS on an ad hoc basis at the moment anyway. |
| 01:35:00 | adam3us: | warren: better in that it uses fiat-shamir to only have to spot check the answer, not repeat the work |
| 01:35:01 | warren: | petertodd: temporarily ... |
| 01:35:15 | amiller: | so how about this |
| 01:35:17 | amiller: | accept a range of difficulties |
| 01:35:35 | petertodd: | warren: sure, but at least the barrier to making an asic with that is fairly high - as I say, it gets you the same kind of barrier than an scrypt tweak would, but with less resoruce usage |
| 01:35:35 | amiller: | but not all the way to nothingness |
| 01:35:36 | adam3us: | petertodd: momentum is not too stupid. quite TMTOable but other than that. |
| 01:35:47 | warren: | adam3us: maaku_: yes litecoin & ftc are currently not plausible to overtake <----- huh? ftc? |
| 01:35:48 | petertodd: | adam3us: define TMTO again? |
| 01:35:48 | amiller: | the bottom-out level is a miner policy |
| 01:35:59 | amiller: | minimum acceptable difficulty i mean |
| 01:36:00 | warren: | adam3us: only thing implausible about overtaking FTC is their centralized broadcast checkpoints |
| 01:36:23 | petertodd: | amiller: but difficulty is related to block interval, and you have to have long enough min block intervals so that consensus still works |
| 01:36:26 | adam3us: | warren: it was hypothetical comparison, nothing specific to ltc/ftc |
| 01:36:45 | warren: | adam3us: petertodd: economically the only way litecoin users would accept a PoW change is if the same miners were the beneficiaries (GPU owners). =( |
| 01:36:50 | petertodd: | adam3us: oh, right, Time Memory Tradeoff or whatever |
| 01:37:09 | amiller: | petertodd, okay so the basic way to handle that is to a) make everyone include stale blocks in some way, like GHOST already recommends and i babbled about on irc a year ago |
| 01:37:20 | amiller: | b) the more stale blocks you accumulate, the more penalty you apply to short spammy blocks |
| 01:37:24 | petertodd: | warren: birthday PoW might be GPU implementable actually |
| 01:37:39 | petertodd: | warren: cuckoo hashing seems possibly to be as well |
| 01:37:47 | warren: | adam3us: is Savitch's theorem relevant at all to this? |
| 01:37:47 | adam3us: | petertodd: TMTO is fine for warren's GPU lovers. you ned that to run momentum on a gpu anyway |
| 01:37:49 | amiller: | the effect is that you eventually get enough of a bonus to mining at a hard difficulty, which causes the chain to stabilize |
| 01:38:08 | petertodd: | amiller: gah, I really am against this stale block crap - it gives advantages to those with fast network connections |
| 01:38:18 | adam3us: | warren: i am not sure if it is because momentum nearly works and has an extremely efficient verification (consuming no memory) |
| 01:38:18 | amiller: | they have an adavantage anyway |
| 01:38:52 | petertodd: | adam3us: no actually, I was looking at some papers suggesting that GPU's are actually reasonable good at implementing content addressable memories |
| 01:39:01 | petertodd: | adam3us: it's not a TMTO tradeoff in that case |
| 01:39:11 | adam3us: | petertodd: oh nice. |
| 01:39:52 | petertodd: | amiller: yes, but don't make it even bigger, which ghost does |
| 01:40:33 | amiller: | i'm advocating *allowing* it to get bigger for a much more important reason |
| 01:40:46 | amiller: | the only thing ghost claims you can do is marginally increasing the flux of transactions, which is meh |
| 01:41:04 | amiller: | i'm claiming the main benefit to this is getting user-selectable variance *within* the main mining game |
| 01:41:07 | petertodd: | amiller: wait, what getting bigger? orphan rate? |
| 01:41:46 | amiller: | no the advantage to dudes with better network equipment in data centers, ie the amount of data and latency dependence |
| 01:42:44 | petertodd: | amiller: nah, better ways to get user-selectable varience than screwing up those incentives |
| 01:42:54 | amiller: | like what |
| 01:42:55 | petertodd: | amiller: again, why are you assuming a monolithin blockchain? |
| 01:43:00 | amiller: | how else are you going to get user selectable variance |
| 01:43:04 | petertodd: | amiller: do per-tx PoW and figure out how to make that reasonable |
| 01:43:05 | adam3us: | amiller: above are you talking about p2pool? pooled mining apis in general? variance you mean being able to pick an appropirate to miner pow work size? |
| 01:43:29 | amiller: | small players want to play at lower variance, so yes |
| 01:44:21 | adam3us: | amiller: just because actual low variance can be done via multiple sub-puzzles and redefining work to be the sum of the subpuzzles,however that breaks power-fairness of the PoW for btc style first past post race |
| 01:44:33 | roidster: | roidster is now known as Guest75297 |
| 01:44:58 | adam3us: | amiller: so u mean low variance in terms of pool shares. |
| 01:45:01 | petertodd: | adam3us: ifthe sub-puzzles earn you money linearly, that doesn't break fairness |
| 01:45:07 | amiller: | it doesn't break power fairness, it does have a subtle security rpoblem related to that though |
| 01:45:22 | petertodd: | amiller: which is? |
| 01:45:43 | amiller: | attackers can revert larger history with *better than negligible chance* if they can increase the difficulty high enouhg |
| 01:45:49 | warren: | petertodd: perhaps it would be more palatable of a change if something like every other block were allowed to be scrypt or birthday. but in any case none of that fixes the issue of centralization, if litecoin has a hardfork I want to tackle that. |
| 01:45:58 | adam3us: | amiller: well if we said you had to make a coelho merkle pow it would have a lot of progress so be power-unfair |
| 01:46:25 | amiller: | adam3us, that's an all or nothing puzzle |
| 01:46:39 | amiller: | adam3us, that's different than letting individuals get their own little reward for a subpart |
| 01:46:48 | adam3us: | amiller: right. the prize is all-or-nothing. |
| 01:47:03 | amiller: | ok so make subdivisible puzzles where there rewards are also subdivisble in the same way |
| 01:47:03 | petertodd: | amiller: right, so devise schemes where we're not letting luck revert large history |
| 01:47:04 | adam3us: | amiller: ok that i think is interesting to explore. (i tried a bit in the past also) |
| 01:47:14 | amiller: | petertodd, no that's fine as long as its not unbounded |
| 01:47:20 | amiller: | unbounded is a problem in the other direction too |
| 01:47:35 | amiller: | unboundedly small puzzles => DoS hazard as attacker floods network with small plausible weak blocks |
| 01:47:43 | warren: | adam3us: petertodd: how well researched is birthday against a worse break? |
| 01:47:44 | adam3us: | amiller: the other problem is you have reward and consensus and they are bound together |
| 01:47:50 | amiller: | unboundedly difficult puzzles => attacker has too good a chance of an attack with less power |
| 01:47:59 | adam3us: | warren: its pretty fundamentally hard |
| 01:48:13 | adam3us: | warren: just time memory trade offs |
| 01:48:31 | amiller: | adam3us, could you be a little more specific about what reward and consensus mean here |
| 01:48:35 | warren: | adam3us: are people already using TMTO to mine it? |
| 01:48:43 | petertodd: | amiller: in any case, I think my binary tree chains thing works for this, because you set it up with diff halved on each step down, and only let miners mine one path, keep separate diffs for each level, but also keep the reward the same horizontally so there's no economic incentives to let them get out of whack |
| 01:48:49 | warren: | scrypt GPU uses TMTO |
| 01:48:58 | adam3us: | warren: there was a thread on the protoshares / bitshare board where a guy was coding one. |
| 01:49:06 | amiller: | petertodd, i don't know what you are talking about, MMR? MMR for blocks? |
| 01:49:17 | adam3us: | warren: he had an example implementation and got the tmto working, but i dont know if he yet coded it for the gpu |
| 01:49:37 | petertodd: | amiller: no, I mean, strucure your blockchain as a binary tree of "blocks" |
| 01:49:46 | petertodd: | amiller: still linear in the time axis |
| 01:50:24 | adam3us: | amiller: reward = 25btc/block, consensus = everyone agreeing on transaction order and validation (over time) |
| 01:50:41 | petertodd: | amiller: point with this, is that you can have PoW per tx, and sum up work simply by the fact that the upper levels of the tree get that lucky less often, yet have higher difficulty |
| 01:50:50 | petertodd: | amiller: related is I suspect such a structure can do better scalability |
| 01:50:57 | amiller: | ok so make the reward proportional to block |
| 01:51:01 | amiller: | fees behave same way as before |
| 01:51:12 | amiller: | consensus = everyone agrees on transaction order same as before... |
| 01:51:26 | petertodd: | amiller: yeah |
| 01:51:42 | amiller: | proportional to difficulty in a block* |
| 01:51:42 | adam3us: | adam3us: but for consensus security there maybe an incentive security tie relating to reward... |
| 01:51:59 | petertodd: | amiller: now I *also* think you can probably structure this so that miners don't have to keep up with the whole chain, only doing subsets, but that's not necessarily directly related to the per-tx PoW aspect of it |
| 01:52:47 | adam3us: | amiller: oh i get you. allow a consensus to be built up from frctional blocks |
| 01:53:12 | petertodd: | adam3us: yup, and the fraction could be as little as a single tx |
| 01:53:36 | petertodd: | adam3us: (obviously it's likely the concept will end up with some notion of work/byte) |
| 01:53:37 | adam3us: | amiller: like you could be 1.5-confirmed. plausible but creates longer chain/complexity, maybe orphan risk, bandwidth usage |
| 01:54:00 | petertodd: | adam3us: yet, if you combine it with a scalability solution w/ sharding, per-node bandwidth can be less |
| 01:54:27 | amiller: | maybe the GHOST guys want to work on this |
| 01:54:31 | warren: | warren: heh, well, doing birthday-style momentum hash would be as temporarily asic-hard as any scrypt tweak, and with fast validation |
| 01:54:40 | warren: | To what degree would this be merely kicking the can down the road? |
| 01:54:41 | petertodd: | amiller: heh, well *I* want to work on this |
| 01:55:05 | petertodd: | warren: good question, probably tens of millions down the road, in terms of ASIC development cost |
| 01:55:06 | amiller: | well it basically forces a bunch of other sore issues |
| 01:55:10 | amiller: | like how to make fees match resources consumed |
| 01:55:22 | warren: | tens of millions of dollars? that's nothing |
| 01:55:26 | petertodd: | warren: the scary thing is like any ASIC-hard-but-not-hard-enough scheme the first ASIC to be built is winner take all |
| 01:55:31 | amiller: | i think having parameters to restrict the bounds on either end is important |
| 01:55:35 | petertodd: | warren: sha256 ASICs are hundreds of thousands |
| 01:55:36 | adam3us: | petertodd: well if basic compression (not sending data twice) was implemented a block may cost less bw |
| 01:55:57 | warren: | petertodd: oh, tens of millions factor, not dollars? |
| 01:56:21 | petertodd: | warren: no, I'm saying my gut feeling is that a successful ASIC for such a beast would be tens of millions in dev costs |
| 01:56:27 | adam3us: | warren: i think $ in both cases |
| 01:56:36 | warren: | ok, then that isn't a worthwhile change |
| 01:56:41 | petertodd: | warren: but, what that's really saying is this is something that we need a real hardware person to analyse |
| 01:57:24 | petertodd: | warren: also momentum has interesting stuff: e.g. commodity content addressable memory *is* available because network routiers and the liek use it |
| 01:57:35 | adam3us: | amiller: btw i also thought of ghost a while back :) (saw you mentioned u did above) |
| 01:58:12 | petertodd: | warren: if you could get the community to put up a few thousand, you could probably get a decent bit of research+report on how viable it is |
| 01:58:29 | warren: | who is qualified to analyze it? |
| 01:58:32 | petertodd: | warren: it's the kind of thing MSC should be thinking about too |
| 01:58:48 | petertodd: | warren: good question - some kind of digital electronics/computer engineering person |
| 01:58:50 | warren: | huh? MSC has PoW? |
| 01:58:55 | adam3us: | amiller: in my case i was like hmm this creates compexity not enuf of a win, but they picked out its lower block interval support which i wasnt focusing on |
| 01:58:57 | petertodd: | warren: I've got the contacts to find a person for that |
| 01:59:23 | petertodd: | warren: not yet, but that falsl into things MSC should look into |
| 01:59:36 | petertodd: | warren: note that Ethereum does and it's a MSC competitor/substrate |
| 01:59:43 | warren: | If MSC is on Bitcoin's network, I don't see how it needs its own PoW |
| 01:59:52 | warren: | what is Ethereum? |
| 01:59:59 | adam3us: | warren: oh boy |
| 02:00:02 | petertodd: | warren: a bit part of why I was hired was to determine what the options are there... |
| 02:00:06 | petertodd: | adam3us: lol |
| 02:00:13 | warren: | (I've been busy lately.) |
| 02:00:24 | petertodd: | warren: "TURING COMPLETE CRYPTO CURRENCY INVESTMENT OPPORTUNITY BUY BUY BUY!" |
| 02:00:27 | adam3us: | warren: http://ethereum.org/ethereum.html |
| 02:00:37 | warren: | who made this? |
| 02:00:42 | adam3us: | warren: vitalik |
| 02:01:04 | warren: | a month ago he was all pro-primecoin |
| 02:01:08 | adam3us: | warren: with support of some good marketing folks |
| 02:01:13 | petertodd: | warren: vitalik is smart, but not wise... |
| 02:01:22 | adam3us: | warren: prime coin is a crock (IMO) |
| 02:01:37 | adam3us: | warren: i persuaded him that coelho was better ;) |
| 02:01:48 | warren: | sorry, what is coelho? |
| 02:01:49 | adam3us: | warren: hence he made dagger (linke from the above) |
| 02:01:50 | petertodd: | I was at a talk by him on ethereum and there was a moment kinda halfway through where he really jumped the shark so to speak |
| 02:02:24 | adam3us: | warren: merkle hash PoW with a fiat-shamir trick to reduce the memory for verify to like 4log(n) or such |
| 02:03:25 | petertodd: | adam3us: ugh, dagger is used *so* poorly in ethereum |
| 02:03:42 | adam3us: | warren: it crazy stuff because the script language is like able to do almost anything. the implications are unknowable |
| 02:04:03 | adam3us: | petertodd: critique specific? |
| 02:04:32 | petertodd: | adam3us: the huge advantage with a fiat-shamir trick pow is that you can make the pow depend on block data, with dagger doesn't do |
| 02:04:45 | adam3us: | warren: virus script that like takes all coins? probably not actually. but its openended and people may have fun with it |
| 02:05:04 | petertodd: | adam3us: meanwhile that kind of PoW is still rather parallelizable, including in an asic |
| 02:05:09 | adam3us: | petertodd: ah yes he dropped that bit. he was talking about data tho & i mentioned he could use that feature |
| 02:05:26 | adam3us: | petertodd: (separately proof of storage or something for some other reason... ) |
| 02:05:31 | petertodd: | adam3us: ugh, so he knows that you can do that? fuck |
| 02:05:53 | petertodd: | adam3us: the whole writeup on the ethereum site is just full of hand-wavey numbers too |
| 02:05:57 | adam3us: | petertodd: well he does now. i am not sure it occurred to him at the time he wrote dagger |
| 02:07:11 | petertodd: | adam3us: anyway, the whole idea that memory requirements somehow make something ASIC hard by themselves is very wrong |
| 02:07:16 | adam3us: | petertodd: well it is somewhat memory hard with the params he has and thte sequence of calcs hmm i wonder ou cant keep a cache and skip list and get most of it without memory can you? |
| 02:07:21 | warren: | is dagger fast to verify? |
| 02:07:25 | petertodd: | warren: yeah |
| 02:07:53 | adam3us: | warren: faster than scrypt for the memory used, but slower than momentum. however momentum is more TMTOable |
| 02:08:02 | petertodd: | adam3us: well, you make an asic that's physical strucutre is a tree for instance |
| 02:08:06 | adam3us: | warren: i wouldnt say fast but less slow. |
| 02:08:42 | adam3us: | warren: i think he aims to use the faster verify to demand more memory per instance however, rather than to make faster wall-clock verify |
| 02:08:51 | adam3us: | warren: u could use it otherwise... |
| 02:09:35 | adam3us: | petertodd: i meant even in software! gotta re-read it (didnt occur to e before for some reason) |
| 02:09:57 | petertodd: | adam3us: kindsa reminds me: so one problem I had in coming up with a asic-hard "hash all the data"-style pow was that crypto-primatives like hash functions tend to be pretty slow compared to the bandwidth of main memory |
| 02:10:33 | petertodd: | adam3us: so the question is then what's the *weakest* crypto-primative you can get away with and still be secure - like, could you have the lowest parts of a dagger-style tree only do a single sha256 round? |
| 02:10:33 | adam3us: | amiller: this fractional block seems interesting, but you probably have to use ghost, due to block interval creating orphans, and put a sanity limit like you said. |
| 02:10:47 | warren: | petertodd: so wait, where would MSC use PoW? |
| 02:10:58 | petertodd: | adam3us: where going up the tree enough rounds have been done to be pre-image secure? |
| 02:11:05 | warren: | sorry, I'll be back later, meeting in 30 minutes I need to prepare for |
| 02:11:08 | petertodd: | warren: it'd use it to implement a ethereum layer |
| 02:11:21 | petertodd: | warren: I mean, implement ethereum-style consensus system, as an example |
| 02:11:25 | amiller: | adam3us, sure, it's kind of a dauting engineer effort which is why i've shied away from it |
| 02:11:29 | adam3us: | petertodd: that might not be a bad idea. tree-evaled sha256 rounds |
| 02:11:39 | amiller: | adam3us, but i hope at this point it's at least clear what sort of benefit this can get you |
| 02:11:53 | amiller: | not faster transactions or something trivial like that, but the ability to have user-selected difficulty which means the whole need for pools goes away |
| 02:12:03 | petertodd: | adam3us: yeah, hell, maybe even something as simple as XOR can be used in some cases for lower parts of the tree? |
| 02:13:16 | petertodd: | adam3us: cuckoo PoW could be an example there too: maybe each round of your cuckoo path can be just a single hash round and you can still get away with it given reversing a round may be *sufficiently* hard that just fetching the appropriate bit of memory is easier |
| 02:15:16 | petertodd: | adam3us: though that could backfire too because I suspect an optimal cuckoo implementation is a grid of small memory cells and routing logic to efficiently pass around in-progress solutions without using long, power-hungry wires |
| 02:15:44 | adam3us: | petertodd: i think scrypt has a faster hash to fill memory at one stage no? |
| 02:16:35 | adam3us: | petertodd: there were some earlyer PoW that aimed to stress memory latency by wobber et al. unfortunately they all got broken :) |
| 02:16:37 | petertodd: | adam3us: yeah, that's why it uses salsa20 |
| 02:16:54 | petertodd: | adam3us: for consensus pow I think trying to stress latency is hopeless |
| 02:17:06 | petertodd: | adam3us: though for timelock crypto it's perfectly reasonable |
| 02:17:39 | adam3us: | petertodd: why? its another form of parallelizable work... |
| 02:18:00 | petertodd: | adam3us: I'm talking about serial-parallel hash chain schemes |
| 02:18:33 | petertodd: | adam3us: in that case that memory latency leads itself to high parallelism is an *advantage* by making it cheaper to make the timelock |
| 02:20:01 | petertodd: | e.g. prepare x GB worth of lookup table, have n parallel queries going to the lookup table using some scheme using up all available bandwidth, then use the encrypted intermediate steps trick to deparallelize it |
| 02:20:02 | adam3us: | warren: u now in theory sha256 asics are more efficient in the way jtimon was arguing about earlier. it concentrates the reward, but it maybe uses less electricity as a result |
| 02:20:28 | petertodd: | now you have a timelock that was reasonable cheap to make, yet the speed of sequentially cracking it is very directly related to memory latency, and mem latency sucks |
| 02:21:05 | adam3us: | petertodd: he he the first memory (latency) hard paper sent 16MB of random data in the example executable to make it non compactible |
| 02:21:22 | petertodd: | adam3us: sent? ? |
| 02:21:38 | adam3us: | petertodd: they linked it into the exe |
| 02:21:44 | petertodd: | adam3us: ah, I get it |
| 02:22:10 | petertodd: | adam3us: yeah, that's an interesting question: you really want a nothing-up-my-sleeve source of non-compactable random data! |
| 02:22:30 | adam3us: | petertodd: we've got one :) the block chain |
| 02:22:32 | petertodd: | adam3us: interesting problem to get bulk nothing-up-my-sleeve numbers - good opportunity for being overely cute |
| 02:22:39 | petertodd: | I was gonna say... |
| 02:23:23 | petertodd: | though even then you'd probably want to encrypt the blockchain with a CBC cipher to properly randomize it |
| 02:23:23 | adam3us: | petertodd: relatedly i proposed on CFRG using the block chain to proof NUMS / uncooked Elliptic curve paramter generation |
| 02:23:29 | petertodd: | ha nice |
| 02:23:48 | adam3us: | petertodd: i think its actually much better than the alternatives and the current state of the art which is quite gamable |
| 02:24:02 | petertodd: | adam3us: what's the state of the art? |
| 02:24:51 | adam3us: | petertodd: that soeone makes up a nice story about how they didnt cheat, like they publish the generation algorithm, code, and then feed it a seed like pi or a quote and say see "tada we couldnt have cheated" |
| 02:25:04 | adam3us: | petertodd: except there are 100s of bits of choices hidden in there.. |
| 02:25:17 | adam3us: | petertodd: which means the choices could've been ground (doh!) |
| 02:25:30 | petertodd: | adam3us: oh right |
| 02:25:45 | petertodd: | adam3us: well don't they usually pick the *first* bits of pi? |
| 02:26:09 | adam3us: | petertodd: yes but i mean the code itself, the endian choice, the order the options are considered etc |
| 02:26:16 | adam3us: | petertodd: http://www.ietf.org/mail-archive/web/cfrg/current/msg04019.html |
| 02:26:27 | adam3us: | petertodd: (its quite short and bitcoin amusing) |
| 02:26:30 | petertodd: | adam3us: sure, but not that many bits there... |
| 02:27:10 | adam3us: | petertodd: i reckon you could find quite a few if you tried see you are selecting curves on lot of complex rules, so which rule you reject first, that affects the choice |
| 02:27:18 | petertodd: | adam3us: ah, yeah I'll admit using the blockchain to prove you didn't try the whole process twice is nice |
| 02:27:20 | adam3us: | petertodd: many arbitrary decisions = grindability |
| 02:28:23 | petertodd: | adam3us: though don't make it double sha256, do it timelock crypto style so that to brute-force select would take longer than a block interval :P |
| 02:28:23 | adam3us: | petertodd: the certicom guy was saying hash like nasdaq closing prices, but hten after the fact its not as convincing. blockchain is like a transferable irrefutable self contained proof! |
| 02:28:44 | petertodd: | yup |
| 02:29:10 | adam3us: | petertodd: i like it :) i mean its actually a useful improvement |
| 02:30:33 | petertodd: | adam3us: I think I posted that on the cryptography mailing list, or if not that my "add together n previous blockhashes" idea that averages them all together |
| 02:31:17 | petertodd: | timelock works really well in this case because you don't care how long it takes to verify the process |
| 02:33:20 | petertodd: | adam3us: might be interesting to do some timelock crypto competitions with the memory-latency-hard technique - encrypt a private key of course and first to decrypt gets to spend it |
| 02:33:22 | adam3us: | petertodd: oh yeah i think i remember that post now you mention it.. maybe it stuck in my subconscious |
| 02:33:29 | petertodd: | adam3us: be nice to get some lower-bounds there |
| 02:33:58 | petertodd: | adam3us: I'm pretty sure there's nothing with better latency for large amounts of ram out there than commodity hardware |
| 02:33:59 | adam3us: | petertodd: out comes the watercooled monster box :) |
| 02:34:07 | petertodd: | adam3us: yup |
| 02:34:34 | petertodd: | adam3us: which reminds me: one of the hard things about all this asic-hard stuff is PoW doesn't need to be reliable, while even the worse consumer hardware is fairly reliable |
| 02:34:37 | adam3us: | petertodd: my cpu is good (4.8ghz hex core) but i didnt splash for fancy ram |
| 02:34:38 | petertodd: | adam3us: that costs you speed |
| 02:35:11 | adam3us: | petertodd: exactly, yes. (reliability argument) i think one of the asic hw people commented on that |
| 02:35:16 | petertodd: | with a big enough bounty it could be a good way to test the "single round of foo hash" idea |
| 02:35:32 | petertodd: | adam3us: butterfly labs for one implements that |
| 02:35:46 | petertodd: | adam3us: though we *are* lucky that overclocking is still popular |
| 02:38:42 | adam3us: | petertodd: oc is cost effective. that 6-core sandybridge is faster than i think just about any single socket xeon for 3x the price (or worse if you go for dual socket costs) |
| 02:39:09 | adam3us: | petertodd: ghz*core speed assuming parallelizable tasks. |
| 02:39:53 | petertodd: | heh, it'd be hilarious if all our efforts at ASIC-hard PoW just leads to more hardware designed for overclockers :P |
| 03:29:59 | c0rw1n_: | c0rw1n_ is now known as c0rw|zZz |
| 04:24:57 | Netherweave: | Netherweave has left #bitcoin-wizards |
| 05:27:22 | Doge_Funnie: | Doge_Funnie has left #bitcoin-wizards |
| 06:09:35 | jarpiain: | jarpiain is now known as Guest81487 |
| 06:10:50 | maaku_: | petertodd: that wouldn't be a bad outcome |
| 06:11:15 | maaku_: | * maaku_ dreams of commodity supercomputers |
| 06:57:17 | CodeShark: | opinions? https://github.com/CodeShark/bitcoin/compare/coinparams_new |
| 07:21:23 | wumpus: | CodeShark: I'm ok with moving more chain-specific configuration (such as MoneyRange) to chainparams, but adding all those redundant hashing algorithms isn't going to make it into mainline imo |
| 07:21:44 | CodeShark: | right, I realize that - I was considering a plugin model |
| 07:22:35 | CodeShark: | scrypt.so, hash9.so, etc... |
| 07:23:00 | wumpus: | hmm I don't know |
| 07:23:31 | CodeShark: | or perhaps a compiletime flag to statically link to a particular hash function |
| 07:23:37 | wumpus: | I'm all for making the source more modular, and making it into libraries, but loadable libraries brings a lot of problems of their own |
| 07:24:11 | CodeShark: | what are your concerns? |
| 07:25:09 | wumpus: | security mainly, incompatibility, general so/dll hell |
| 07:25:37 | wumpus: | for now I'd more like a modular approach based on libraries (which can get statically linked into the end product) |
| 07:25:56 | CodeShark: | so then perhaps a way to specify a list of static modules to link at compiletime |
| 07:26:39 | wumpus: | or make it possible to install the bitcoin core as a library, so that actual implementations/daemons can compile and link against it |
| 07:27:38 | wumpus: | or other applications that may need the bitcoin consensus stuff for their own purposes |
| 07:28:15 | wumpus: | anyway, lots of options, but: no altcoin specific stuff in bitcoin/bitcoin please |
| 07:28:16 | CodeShark: | for other applications I'm thinking more of a service-oriented architecture, with a core engine providing runtime services to other processes |
| 07:29:06 | CodeShark: | yeah, the intention wasn't to merge the altcoin specific stuff in bitcoin/bitcoin |
| 07:29:18 | CodeShark: | just to expose the ability to customize the core engine |
| 07:29:37 | wumpus: | okay |
| 07:30:21 | CodeShark: | the inclusion of scrypt and hash9 in particular is a total hack at this point, just intended to test the basic idea |
| 07:34:19 | CodeShark: | I'm also thinking that rather than trying to parametrize things like block reward and retargetting rules it would be better to also use a statically linked module approach |
| 07:41:04 | wumpus: | let's move this to #bitcoin-dev |
| 08:51:45 | TD[gone]: | TD[gone] is now known as TD |
| 11:50:46 | c0rw|zZz: | c0rw|zZz is now known as c0rw1n |
| 13:13:32 | wallet42: | wallet42 is now known as Guest30378 |
| 13:13:32 | wallet421: | wallet421 is now known as wallet42 |
| 13:20:18 | adam3us: | amiller: when you're awake about fractional blocks, I am wondering if there is an incentive issue. if a 0.1 block collects .1 of fees and is easily orphanable by a powerful miner, what motive do they have to not selfishly orphan it to collect the other 10% of the fee. |
| 13:24:43 | TD: | TD is now known as TD[away] |
| 13:52:01 | jgarzik: | jgarzik is now known as home_jg |
| 14:39:01 | _ingsoc: | andytoshi: Where are the -wizards logs again? |
| 14:40:11 | andytoshi: | _ingsoc: http://download.wpsoftware.net/bitcoin/wizards/ |
| 14:41:17 | _ingsoc: | Ty. |
| 14:41:58 | michagogo|cloud: | (That really belongs in the topic... |
| 14:42:04 | andytoshi: | no worries, i'm afraid you'll have a lot to scroll through, the last three days have been obscenely busy on this channel |
| 14:42:05 | michagogo|cloud: | ) |
| 14:42:22 | michagogo|cloud: | michagogo|cloud has left #bitcoin-wizards |
| 17:26:12 | deadweasel: | deadweasel has left #bitcoin-wizards |
| 18:36:22 | gwern: | I believe we were discussing ethereum before? might be of interest: https://bitslog.wordpress.com/2014/01/17/ethereum-dagger-pow-is-flawed/ http://www.reddit.com/r/ethereum/comments/1vgqa7/ethereum_dagger_pow_function_is_flawed/ |
| 18:36:22 | maaku_: | maaku_ is now known as maaku |
| 18:36:42 | Ursium: | hi gwern, yes i saw that |
| 18:37:15 | Ursium: | i believe the founders are aware as i remember reading about this very issue a while back. |
| 18:39:18 | petertodd: | Ursium: that's not a very good analysis: sequential memory hardness isn't all it's cut up to be for real-world hardware designs |
| 18:40:05 | Ursium: | petertodd: i see! |
| 18:40:54 | petertodd: | Ursium: not to say his point is necessarily invalid, but what needs to be done is to get an *actual* hardware engineer on board rather than just a bunch of software people theorizing about what makes something asic hard |
| 18:41:24 | Ursium: | makes sense. Will be interesting to follow for sure |
| 18:42:17 | sipa: | (upcoming ad-hominem) the author suggesting x86 as script code doesn't inspire much confidence |
| 18:42:55 | petertodd: | sipa: +1 |
| 18:43:13 | maaku: | i think there's a valid technical point in that ad-hominem |
| 18:43:26 | Ursium: | sipa: i believe they suggest C-like scripting which converts back to a very limited set of opcodes - so only interactions with the blockchain etc. What do you guys think? |
| 18:43:50 | sipa: | maaku: yes, but it's irrelevant to the issue being discussed |
| 18:44:25 | maaku: | Ursium: see the logs for the past few days. we've had some interesting discussions about what you can do with a more powerful script |
| 18:44:29 | maaku: | mostly related to covenants |
| 18:44:30 | petertodd: | Ursium: the idea of extrospective scripts is a good one, how to implement them is another issue |
| 18:44:58 | maaku: | you would *not* want to do so using an ad-hoc CISC language, however |
| 18:45:18 | petertodd: | maaku: speaking of: you realize that for colored coins and many other covenants, you actually only need to look *backwards*, so they aren't really covenants and have no issues |
| 18:45:20 | maaku: | you'd need something amenable to static analysis (e.g. a strongly typed stack language) |
| 18:45:56 | petertodd: | maaku: or a single type :P |
| 18:46:04 | maaku: | petertodd: ? for CC you need to look at the outputs of the current transaction to avoid inflation |
| 18:46:26 | maaku: | well, functions/combinators are types... |
| 18:47:14 | maaku: | michagogo|cloud: I'm allowed to op, but not change the title for some reason. Is that a different permission? |
| 18:47:19 | petertodd: | maaku: NO! the magic CC script can be written such that it itself checks the transaction recursively, which means that all you have to do is check that the CC script would see the current "tip" transaction as valid one step back |
| 18:47:53 | maaku: | oh yes i see how that would work |
| 18:48:03 | maaku: | you lose SPV compatability though |
| 18:48:22 | petertodd: | maaku: no you don't! SPV compat is still there because you only need to check one step back to know the whole chain is valid |
| 18:48:47 | petertodd: | maaku: remember, the magic CC script can only exist in the scriptSig if the previous tx included the magic CC script in the scriptSig, all the way to the genesis condition |
| 18:48:50 | gwern: | huh. induction in real life. |
| 18:48:54 | petertodd: | gwern: yes |
| 18:49:31 | maaku: | only if the coins become unspendable if they were invalidly constructed |
| 18:50:05 | petertodd: | maaku: no, the coins are always spendable, but you can't spend them with a transaction scriptSig that matches the CC script checker |
| 18:50:22 | petertodd: | maaku: IE, you can get the coins back under all circumstances, you just can't make them colored fraudulently |
| 18:51:39 | maaku: | petertodd: ok, walk me through this. I create a transaction marking all the outputs as 'blue' with a CC script prefix |
| 18:51:50 | gmaxwell: | you make the script only allow you to assign it if it was used previously or if some birth criteria is met. |
| 18:52:03 | petertodd: | maaku: *no*, you make a transaction that in the scriptSig includes the CC validity script |
| 18:52:16 | gmaxwell: | E.g. this color coin scrpit can be applied if the parent txout is txid:vout or if the parent script had this script on it. |
| 18:52:28 | petertodd: | maaku: now, if you are the genesis tx, you have a separate code-path that checks a signature or that the txin is something specific or whatever |
| 18:52:39 | gmaxwell: | you use the first rule to give birth to the colored coin and then the rest can only be children of it. |
| 18:52:51 | petertodd: | gmaxwell: can only be children of it *or* not colored |
| 18:52:56 | gmaxwell: | or not colored, indeed. |
| 18:53:00 | gmaxwell: | don't want it to be viral. |
| 18:54:08 | petertodd: | yup |
| 18:54:15 | maaku: | ok how do you restrict which outputs are colored? |
| 18:54:46 | adam3us: | gwern, petertodd: i am not sure how important sequential memory hard is Lerner says "must not allow easy parallelization |
| 18:55:09 | petertodd: | maaku: the restriction is that you can't make the CC script execute unless the transaction only creates valid CC outputs |
| 18:55:23 | adam3us: | gwern, petertodd: however mining is inherently massively parallelizable by intent and necessity; what does it matter if its micro parallelizable as well as macro-parallelizable |
| 18:55:25 | petertodd: | maaku: but you can still spend the outputs, it just means the outputs aren't colored |
| 18:56:47 | petertodd: | adam3us: the difference is that micro-paralelization has different characteristics due to how memory works; the idea is that if you use some block of ram sequentially *at the scale of PoW mining hardware* that forces you to implement it in ways that looks like commodity hardware |
| 18:57:08 | maaku: | petertodd: so the outputs are still tagged? |
| 18:57:15 | petertodd: | adam3us: the problem is this isn't a hard-and-fast rule - it's not that his argument is invalid, just that he needs to analyze it much more carefully than that |
| 18:58:48 | petertodd: | maaku: well, one way to do it would be to rely on the txout index, so you might commit to what values spends of the various txouts are allowed to have in some merkle tree without actually evaluating the txout scriptPubKeys directly |
| 18:58:54 | adam3us: | petertodd: well if it was really sequentially accessed its cacheable and address calc pipelineable. seems more like scrypt's romix component with random access is more pausible. |
| 18:59:21 | maaku: | petertodd: btw, have you considered looking at how modern commodity hardware is difficient, and focusing on proof of work that would improve the situation if commoditized? |
| 18:59:22 | petertodd: | maaku: basically the scriptSig contains: |
| 19:00:03 | petertodd: | maaku: that's what SHA256 does, *if* ASIC mfg capacity is available, then a really simple PoW like sha256 is ideal because your startup costs to make a miner ASIC are low |
| 19:00:39 | petertodd: | adam3us: sequential != cachable |
| 19:00:50 | maaku: | petertodd: oh, i mean things like highly interconnected cores, greater memory bandwidth, etc. |
| 19:01:36 | petertodd: | adam3us: for real-world memory sequential is faster however, due to the fact that real-world ram talks to cpu's on a bank level, among many other considerations |
| 19:02:09 | adam3us: | maaku: i like the parallela chips. many risc cores on a chip. like a gpu but without the custom graphics stuff and without SIMD |
| 19:02:10 | petertodd: | maaku: well, see the problem with stuff like that is what is available as commodity changes over time; you have to target some architecture with a very high chance of existing in the future |
| 19:02:37 | maaku: | adam3us: like Cell and APU |
| 19:02:40 | adam3us: | petertodd: right. sequential access is faster on existing hardware because they optimie for it |
| 19:03:05 | petertodd: | adam3us: not so much because they optimize for it, but because it's the only possible way to build the hardware |
| 19:03:29 | petertodd: | adam3us: I mean, you could optimize for something else, but the limitations of silicon strongly suggest bank-accessed designs |
| 19:03:37 | maaku: | petertodd: no that's my point - you target something which you would like to become available, because it is beneficial for other purposes (e.g. those are things I would like for commodity supercomputers) |
| 19:03:58 | maaku: | or rather, things which are available now but in limited quantities |
| 19:04:02 | petertodd: | adam3us: similarly you need designs where the cpu<->mem interface happens in packets because high-speed parallel busses are impossible to make |
| 19:04:12 | maaku: | and let the market push industry further in that direction |
| 19:04:47 | petertodd: | maaku: oh, I see, yeah, but that's a very risky strategy that's just as likely to lead to some ASIC that's overly optimized and useless for any real-world thing |
| 19:05:26 | petertodd: | maaku: for instance, PoW mining can tolerate way higher error rates than almost any other application |
| 19:06:50 | adam3us: | maaku: so one hypothesis is to use halting problem logic to search for instruction sequences and what state they put some memory into or something like that of an open risc cpu design. if people want to make those fast thats a public good. however typically there is going tobe something that can be stripped to avanage to mae them faster/more energe efficient as miners.. but yes its an interesting direction. |
| 19:08:21 | adam3us: | maaku: basically the lesson i draw is a) hardware wins; b) a lot of software people dont now much about highly optimized custom hw design nor the limiting factors |
| 19:09:05 | petertodd: | adam3us: hence why I think we're a lot more likely to come up with PoW that is FPGA-soft rather than FPGA-hard |
| 19:11:09 | adam3us: | in some way of thinking re jtimon argument yesterday about energy efficiency, asic hashcash-sha256^2 could be argued to be more energy efficient than gpu-hard. so other than the centralization issues coming from hw manuf barrier to entry perhaps thats not so bad. (ie the more profitable mining is above investment the more likely it is to be energy efficient) |
| 19:11:39 | petertodd: | adam3us: meh, I like to beat on nature |
| 19:13:02 | adam3us: | the other obvious approach is to change the PoW periodically, or put dozens of building blocks into it and change the way they are connected to define new mining variants. have % of reward allocated to different PoW params, and adjust the difficulty of each param-set to match the % target. |
| 19:13:27 | jtimon: | adam3us I guess jgarzik just convinced me here http://www.coindesk.com/bitcoin-developer-jeff-garzik-on-altcoins-asics-and-bitcoin-usability/ |
| 19:13:27 | jtimon: | sorry afk for some time |
| 19:14:22 | petertodd: | jtimon: ugh... that's really ill-informed |
| 19:14:37 | petertodd: | jtimon: god-damn software engineers :p |
| 19:14:39 | adam3us: | u note how sergio lerner posted that mem hard pow with todays date. he seems to be a bit secretive and then reveal things when pushed. he still didnt reveal his claimed coin anonymity |
| 19:15:32 | petertodd: | adam3us: one thing that worries me about "change the pow constantly" schemes is they can turn the "ASIC-hard" problem into a secret *software* problem |
| 19:16:04 | petertodd: | adam3us: IE, if I'm a FPGA mfg and I put my experts onto the problem of making meta FPGA programming code to target the PoW most efficiently every day |
| 19:16:18 | petertodd: | adam3us: that industry has enough secrets that it'd be a winner-take-all situation potentially |
| 19:21:13 | jgarzik_: | jgarzik_ is now known as jgarzik |
| 19:21:38 | petertodd: | Oh, here's a nice proof-of-existence: suppose you have a scrypt-like sequential-hard PoW function. Now, they kinda suck because to verify them you need a ton of RAM and a lot of CPU power right? However, you can also make a SCIP/ZK-SNARK style proof of the pow solution and verify that instead. |
| 19:21:49 | petertodd: | Thus we know you can make sequential-hard PoW with fast verification. |
| 19:22:08 | petertodd: | Of course, there's the real-world problem where the SNARK proof-creation is a better PoW than the scrypt... :) |
| 19:22:32 | petertodd: | maaku: ^ though that might be a useful way to optimize SNARK proof-creation of course... |
| 19:22:48 | petertodd: | (I think gmaxwell? suggested basically that for SCIP stuff?) |
| 19:25:45 | adam3us: | petertodd: yes. my supposition would be the hw people would make fpgas with reconfigurable buses etc between the lumpy modules tht can be rewired the same as the sw. "hw wins" etc |
| 19:25:57 | gmaxwell: | though even though snark validation is fast it's still slower than SHA256 by a fair margin. (see vntinyram paper for state of the art numbers on the verification of the ggpr stuff... but anything else is not going to be much faster) |
| 19:26:23 | petertodd: | now the non-snark using version of that is easier to understand: fill up some ram with the function D[i] = H(D[i-1]), then do a merkle-tree over the ram and do samples to prove the transitions are honest, but the issue there is basically that the # of samples you pick relates very strongly to how parallelizable you can get away with without a high chance of getting caught out on fraud |
| 19:26:44 | petertodd: | gmaxwell: yeah, faster than scrypt though right? |
| 19:27:11 | gmaxwell: | dunno. scrypt as used in ltc is slow but it might just be compariable. |
| 19:27:41 | petertodd: | gmaxwell: yeah, anyway, the PoW validation slowness isn't a deal-breaker, just annoying |
| 19:27:57 | petertodd: | gmaxwell: bigger issue is that really ASIC-hard PoW's are a lot slower anduse a lot more ram than scrypt... |
| 19:28:02 | adam3us: | petertodd: i think the fiat-shamir transform can make the failure from skipping calc steps start to lose fast. this is what coelho merkle hash PoW introduced and dagger users even more links to reduce like 3% dow to < 1% |
| 19:28:10 | petertodd: | gmaxwell: (well, LTC-style scrypt params) |
| 19:29:18 | petertodd: | adam3us: yup, however what's nasty about it is if you start thinking about how fast actual hash primatives really are - a fair bit slower than main memory bandwidth right now |
| 19:30:10 | adam3us: | petertodd: indeed. i would help if people used a faster hash or the custom design u mentioned yesterday (hash rounds spread across the tree) |
| 19:31:20 | petertodd: | adam3us: yeah, also re: my "fraud == parallelism" argument, maybe you want the bottom of the tree to be fairly big chunks of memory being hashed anyway, which makes spreading a strong hash out make more sense |
| 19:31:30 | petertodd: | adam3us: like I was sayng above about how ram is banked anyway |
| 19:33:15 | petertodd: | adam3us: oh, and here's a consideration: you probably want to minimize the time and space of the merkle tree over the data being hashed, because if you don't you can optimize by making a better merkle hasher |
| 19:33:50 | gmaxwell: | petertodd: sequentiality to some extent prohibits being progress free, so unless the sequential part is very fast you are creating an advantage for faster miners. |
| 19:33:52 | petertodd: | For instance, notice how the # of nodes in a full binary tree is 2x the bottom layer, so you do need the bottom layer work cost to be >> making the tree |
| 19:34:37 | petertodd: | gmaxwell: well how fast is fast enough? I'd argue keep the PoW creation to < 1s or so and it's in line with latency assumptions anyway |
| 19:35:33 | gmaxwell: | I think it has to be a small fraction of latency in order to not matter. |
| 19:35:51 | gmaxwell: | keep in mind wrt the snark idea: snark _creation_ will always be much slower than execution |
| 19:36:10 | petertodd: | gmaxwell: I would have thought a small fraction of block interval - network latency is a similar impact to PoW latency |
| 19:36:26 | adam3us: | he watching the dexel/alpha indian peoples video on their coming 28nm script asic. did anyone figure out of their demo fpga version was a net win already? this should be fun to watch if they deliver |
| 19:36:29 | petertodd: | gmaxwell: oh, obviously if you do it snark-style you've gotta have the snark proof finish in < 1s - very difficult |
| 19:36:37 | petertodd: | gmaxwell: although maybe ok if the snakr is only for the sake of SPV |
| 19:36:42 | gmaxwell: | adam3us: the ltc fpgas were a power usage win. |
| 19:36:59 | gmaxwell: | petertodd: well in particular because you could do proofs of the whole sum rather than a single header. |
| 19:37:14 | petertodd: | gmaxwell: note how with all this stuff I'll bet you having a FPGA attached to some RAM would be a power win |
| 19:37:25 | petertodd: | gmaxwell: good point |
| 19:56:43 | adam3us: | gmaxwell: i believe that is correct. (progress freedom and ratio of minimum work unit on single core to block interval) |
| 20:00:31 | adam3us: | gmaxwell: it places a limit on how memory hard you can hope to be, which also relates to the fastest crypto hash that can drive the memory |
| 20:00:40 | Luke-Jr: | FPGAs were only a power win for Bitcoin as well |
| 20:01:02 | andytoshi: | petertodd: you don't need to have fast snarks if your block time is something like several hours |
| 20:01:22 | andytoshi: | that may be desirable anyway if you want an anonymous high-latency mechanism for getting txes to miners in the first place |
| 20:01:47 | petertodd: | andytoshi: true, although I suspect several hour block intervals have user-acceptance problems |
| 20:02:33 | andytoshi: | yeah, i really doubt such a system would be good for general use. but there are situations where several-day verification is ok (and it still beats visa :P), eg if there are long shipping or manufacturing times anyway |
| 20:05:10 | gmaxwell: | keep in mind that someday bitcoin might be several hour confirmations, if you can't count on the network to converge in one block anymore e.g. due to implementation inconsistencies, high latencies, bursty mining due to mining for fees, gnarly behavior from miners wrt "rational mining" that is willing to reorg if it's positive expectation |
| 20:05:26 | gmaxwell: | even with 10 minute blocks. |
| 20:13:29 | adam3us: | btw i was thinking part of the anti-litecoin fast confirmation argument maybe partly false. it can be claimed that well 12 lite coin confirms (30min) is weaker than 6 bitcoin ones (60mins). but consider your probability as a selfish miner of winning with p^24 << p^6. in fact even p^12 << p^6 etc. |
| 20:14:00 | Luke-Jr: | adam3us: consider the attacker doesn't need to worry about stale blocks also |
| 20:14:06 | Luke-Jr: | adam3us: there are a lot of factors involve |
| 20:14:09 | Luke-Jr: | d |
| 20:14:26 | Luke-Jr: | fast blocks = more hashes wasted by the legit miners |
| 20:14:41 | Luke-Jr: | scrypt = slower block propagation |
| 20:14:44 | adam3us: | Luke-Jr: oh yes (i said partly) the short block time is worse for orhans and igives well connected low latency miners more advantage |
| 20:14:53 | adam3us: | Luke-Jr: that too |
| 20:15:03 | Luke-Jr: | adam3us: right; there's advantages and disadvantages |
| 20:15:09 | Luke-Jr: | IMO they more or less balance out |
| 20:19:21 | adam3us: | i wonder what it does for selfish mining attack though. the ghost (hash in non-conflicting orphans) approach seemingly allows faster blocks becuase orphans are not wasted. so hypothetically ghost + bitcoin/sha256 mining + eg 2.5min intervals. and still 1hr confirmations . i wonder if the selfish miner loses in that circumstance |
| 21:25:03 | maaku: | maaku is now known as Guest32500 |
| 21:31:34 | Guest32500: | Guest32500 is now known as maaku |
| 21:54:52 | jtimon: | Luke-Jr I don't see the balance, Scrypt is neither "anti-ASIC" nor anti-GPU |
| 21:55:24 | jtimon: | what's the gain Scrypt has over SHA256 ? |
| 21:55:59 | phantomcircuit: | jtimon, nothing |
| 21:56:49 | sipa: | scrypt is certainly anti-gpu, if it'd use more than 128 KiB of RAM... |
| 21:56:55 | Luke-Jr: | jtimon: there is none, that's my point |
| 21:57:22 | sipa: | despite that, i'm very unconvinced that it has any advantages for bitcoin or similar systems |
| 21:57:24 | EasyAt: | scrypt ASICs will have a giant die size, no? |
| 21:57:47 | c0rw1n: | aq@gfa128KB ram desn't take much die space |
| 21:58:04 | sipa: | well the point would be to make the cost of the ASIC be dominated by fast memory |
| 21:58:10 | jtimon: | " IMO they more or less balance out" ok so this is just sarcasm? |
| 21:58:57 | Luke-Jr: | jtimon: no? we're talking about faster block times there, and how it doesn't make transactions any faster really. |
| 22:00:03 | jtimon: | Luke-Jr ok thans |
| 22:00:07 | jtimon: | thanks |
| 22:00:46 | jtimon: | sipa what's the point of "make the cost of the ASIC be dominated by fast memory" |
| 22:00:53 | jtimon: | ? |
| 22:01:24 | sipa: | not saying this is a good idea, just reasoning how you'd make an anti-asic pow |
| 22:01:36 | gmaxwell: | It's an attempt to reduce the gap between commodity hardware and specialized hardware. |
| 22:02:05 | sipa: | if the cost of the asic is dominated by memory, it's unlikely to provide much gain over state-of-the-art cpus connected to as much fast ram as you can find on the market |
| 22:02:14 | sipa: | as the cpu will not be the bottleneck |
| 22:02:25 | gmaxwell: | I think it's generally a poor idea for pow-consensus systems though. My reasoning is that at most you can probably do is get the gap down to 2:1 (or really probably more like 10:1), and even at 2:1 the commodity hardware will probably be completely excluded. |
| 22:02:45 | gmaxwell: | Vs in KDF usage getting the custom hardware advantage down to just 10:1 would be great. |
| 22:02:54 | sipa: | i think it's a great recipe if you want botnets |
| 22:03:28 | gmaxwell: | Well botnets too, if you don't pay for power because you're stealing it you don't mind that you're 10x less efficient than custom hardware. |
| 22:03:43 | jtimon: | I assume it also has to be anti-GPGPU, right? |
| 22:04:18 | sneak: | the nice thing about kdfs is that it's ok to use eleventy bazillion iterations too |
| 22:04:27 | sneak: | because most use-cases don't mind a 500msec wait |
| 22:04:48 | gmaxwell: | well KDFs want fast verification too, but a few hundred ms is okay usually. |
| 22:04:56 | sipa: | jtimon: unless GPUs would happen to have better memory bandwidth :) |
| 22:05:09 | gmaxwell: | They don't want generation / verification asymmetry, which we want for hashcash usage. |
| 22:06:23 | gmaxwell: | sipa: generally GPUs have had much better memory bandwidth than j-random-cpu. (though horrible memory latency relative to their clockrate) |
| 22:07:07 | jtimon: | sipa GPUs will have a better memory bandwith they're not only for graphics anymore, they're the present/near-future of supercomputing |
| 22:07:28 | jtimon: | and some problems have their bottlenecks in memory |
| 22:08:37 | gmaxwell: | jtimon: graphics work is generally memory throughput limited. |
| 22:11:38 | jtimon: | I'm just saying that GPU designers are not only optimizing for graphics, there's more problems being solved with other demands |
| 22:11:52 | jtimon: | GPUs architectures can change |
| 22:12:53 | jtimon: | maybe you're right and the GPGPU people won't ask for those constraints to be improved |
| 22:12:56 | gmaxwell: | jtimon: thats probably the same processor / coprocesor cycle that has gone on since the start of computing. Presumably GPUs will eventually go away and just be subsumed into cpus (or vice versa) |
| 22:13:56 | gwern: | the wheel of reincarnation |
| 22:14:39 | gmaxwell: | (e.g. how FPUs and stand alone short vector units became standard cpu features) |
| 22:14:58 | jtimon: | gmaxwell: interesting prediction, but you've said two options, so that's my point, we can't predict the future of hardware, what architecture are we anti-optimizing against? |
| 22:15:23 | sipa: | i'm not sure it matters |
| 22:15:27 | jtimon: | yeah gmaxwell xmm mmx |
| 22:15:32 | gmaxwell: | jtimon: we? I think it's all stupid regardless. :) |
| 22:16:07 | gmaxwell: | as I said, I don't think arch targeting can prevent there being at least a small constant improvement from dedicated implementations. Since mining is ~near perfect competition that small factor is enough to generally exclude the non-specialized stuff regardless. |
| 22:16:42 | gmaxwell: | And so simple circuits like SHA256 at least improve equality of access.. anyone can design a sha256 asic which is pretty competative, (well if not actually fabricate it themselves) |
| 22:17:03 | gmaxwell: | vs if you really did build something that required AMD scale engineering, then you'd much more likely have a hardware monopoly or near so. |
| 22:17:26 | gmaxwell: | simple fast circuits also have fast verification, which is very helpful too. |
| 22:18:21 | jtimon: | ok, so I see you have even more reasons than me against the "quest for the perfect mining function" |
| 22:19:32 | gmaxwell: | I think that like a lot of things in engineering you can only optimize so far and then its all just messy tradeoffs. |
| 22:19:57 | sipa: | heh, maybe we need an altcoin optimized for ASICs |
| 22:20:22 | gmaxwell: | DES POW. |
| 22:20:29 | sipa: | where the PoW function is has a trivial optimal circuit design |
| 22:20:33 | jtimon: | targeting GPU-friendly but ASIC-hard is specially odd for me since 1) as you said the later doesn't really exists 2) GPUs are already a market with concentrated production (the problem suppesedly solved by "hardness") |
| 22:20:51 | jtimon: | sipa there's one alt named ASICcoin |
| 22:21:13 | gmaxwell: | DES sboxes make for trivial combinitoric logic, it's much slower on current cpus/gpus than it is in direct hardware all other things equal. |
| 22:22:42 | gmaxwell: | the sha256 circuit is really straight forward already. You can get some gains by careful staging to equalize latencies... |
| 22:33:54 | andytoshi: | i have a crazy idea (involving nonexistant crypto) for a research pathway to a SNARK without forge-enabling keying material: http://download.wpsoftware.net/bitcoin/wizardry/public-fhe.pdf |
| 22:34:13 | andytoshi: | throwing it out here because there's probably something obviously dumb about it, and you guys are good at catching that stuff |
| 22:58:18 | gwern: | http://www.reddit.com/r/ethereum/comments/1vh94e/dagger_updates/ |
| 23:30:49 | jtimon: | how "computer hardware" is not "theoretical computer science"? |
| 23:32:38 | jtimon: | oh, not experts in hardware, I missread |