00:00:06adam3us: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:19jtimon:maaku_ adam3us re not the end of the worl: specially if litecoin was MM
00:00:51adam3us:jtimon: but its different PoW
00:01:00maaku_:adam3us: yeah, depressing :(
00:01:20jtimon:yeah, I mean assuming it was a SHA256 improvement instead of a scrypt one
00:01:30adam3us:petertodd: do something good with msc money to restore our faith in humanity :) please!
00:01:45killerstorm: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:57petertodd:adam3us: don't worry, going to vegas with my first paycheck to find some strippers
00:02:11maaku_:pics or it didn't happen
00:02:12petertodd:killerstorm: lol
00:02:22jtimon:re: 1M usd destruction it would be funny if the guy said "it was a joke"
00:02:33petertodd:jtimon: the guy is anonymous
00:02:47maaku_:killerstorm: that sounds like every investor conversation Jorge and I have had (save one, maybe something will come of that)
00:02:55jtimon:petertodd does it make it less funny?
00:03:04petertodd:jtimon: it makes it more plausible
00:03:11petertodd:jtimon: well, more likely
00:03:13maaku_:he sure as hell is going to stay anonymous now
00:03:16adam3us:petertodd: did someone look at the code of xcp? it claims to actually have stuff working?
00:03:59maaku_:adam3us: honestly the crypto currency investment market reminds me of Lemmings
00:04:02petertodd:adam3us: I did, not much too it
00:04:49killerstorm: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:53adam3us: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:07warren: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:07killerstorm:We can probably allocate some bounty for it (review).
00:05:34warren:adam3us: maaku_: meanwhile litecoin has mainly been useful in discovering bugs that are in bitcoin
00:06:03adam3us:warren: could try zerocash but integrated in the way zerocoin was planned if you like being a canary
00:06:21warren:adam3us: the original zerocoin?
00:06:28maaku_:adam3us: unfortunately that pool of dumb money will eventually empty itself on mostly useless projects :(
00:06:38maaku_:there's some other interesting ones out there
00:06:52adam3us:warren: well u recall that it was a trustless mix attached to the block chain
00:06:56maaku_:but quality of the project seems to be inversely proportional with funds received
00:06:59jrmithdobbs:maaku_: nah that's not the sad part
00:07:01warren:adam3us: I'm actually very interested in P2SH^2 and something like p2pool in the standard client
00:07:23warren:adam3us: I don't like data storage in the blockchain and mining centralization is a long-term existential threat.
00:07:33killerstorm:Oh, BTW, is anybody working on cryptocurrency which uses something other than ECDSA?
00:07:41adam3us: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:48maaku_:warren: be careful the trapdoor in zerocash though... not ready for prime time imho
00:07:55jrmithdobbs: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:57warren:maaku_: I'm aware
00:08:09maaku_:killerstorm: we're eventually going to add schnorr and laport signatures
00:08:22jrmithdobbs:maaku_: but maybe i'm just jaded :)
00:08:22adam3us:killerstorm: gmaxwell investigated using EdDSA as a bitchoin
00:09:11adam3us:killerstorm: new sigtype which is schnorr and so has some nice features (compact k of n sig, blind sig)
00:09:26jtimon:maaku_ lol lemmings
00:09:40warren:Is the latest thoughts on P2SH^2 written anywhere?
00:09:42warren:I lost my IRC logs.
00:09:46adam3us:maaku_ warren: yes the setup time trapdoor is a problem someone has to be trusted to delete it
00:09:57justanotheruser:maaku_: I think it's already been implemented, it's just not public
00:10:20killerstorm: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:34adam3us:warren: if you dislike centralization and have not much SPV clients? you could consider committed-tx experiments
00:10:56petertodd:warren: I can send you my logs
00:11:33maaku_:killerstorm: that would be perfectly doable using multisig
00:11:37warren: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:38adam3us: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:07adam3us:warren: yeah the risk is not lost on me. hence "if you want to be a (regulatory) canary"
00:12:11maaku_: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:43petertodd:adam3us, warren: committed txin may be even more interesting along those lines
00:12:44warren:adam3us: mastercoin is asking to be a regulatory canary
00:13:14warren:adam3us: I think centralization should be a top priority, it is an existential threat.
00:13:40maaku_:killerstorm: lamport sigs are big ... even in a post-quantum world i think we'd still use elliptic curves
00:14:08warren:centralization is *THE* existential threat
00:14:12petertodd:warren: +1
00:14:13adam3us: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:01adam3us:warren: sign me up no that call too "centralization = existential threat"
00:15:03warren:petertodd: I'd like logs covering all the recent P2SH^2 discussion
00:15:38adam3us:warren: which i think is a quite interesting tradeoff. no more private than current, but fully fungible. (coinvalidation falls on its face)
00:16:05warren:is zerocash's design published?
00:16:33maaku_:warren: no
00:16:37adam3us: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:44petertodd:warren: sent
00:17:30adam3us:warren: gmaxwell knows more about it (zerocash)
00:18:09adam3us:warren: also there was a podcast recording of matthew green talk on it at real world crypto conf, can google for
00:18:13killerstorm: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:17adam3us:warren: you could always build holes to plug it into, then wait for zerocash to release their code & link in the library
00:19:21warren:IMHO, I rather focus entirely on the centralization existential threat.
00:19:52warren:That's uncontroversial.
00:19:54adam3us:warren: ok. see if u can do something with committed tx.
00:20:20adam3us:warren: are you willing to complicate SPV model to do it?
00:20:28petertodd:killerstorm: you realize that lamport sigs are implementable easily in even bitcoin's original scripting system right?
00:20:40petertodd:killerstorm: not possible now that op_cat is disabled, but it doesn't take much
00:21:03killerstorm:Well, how do you hide ECDSA pubkey?
00:21:05Luke-Jr:meh, "disabled" really means "removed" in this context :/
00:21:09warren:adam3us: it depends, need to read all the current thinking on committed tx. is this written down anywhere?
00:21:23petertodd:Luke-Jr: yup
00:21:24warren:adam3us: I really dislike the current way SPV is done.
00:21:25jrmithdobbs:petertodd: ya well the disabled ops have enough to implement salsa/chacha too (inefficiently and insecurely)
00:22:00petertodd:jrmithdobbs: well, scripts are limited to 10,000 opcodes so... probably not, lamport however is practical within the limits (modulo disabled ops)
00:22:17petertodd:warren: what do you want changed re: SPV?
00:22:18adam3us: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:28jrmithdobbs:petertodd: i think that's still true for at *least* chacha with the real limits
00:22:40killerstorm:Ok I guess it isn't hard to hide it...
00:22:52jrmithdobbs:petertodd: not that anyone should do so, ever
00:22:58maaku_:warren: anti-centralization is uncontrovertial. some of the side effects of relevant proposals are worrisome on the other hand
00:23:14petertodd:killerstorm: "can implement lamport" is probably a good minimum test for whether or not your scripting system is general enough!
00:23:22maaku_:there's no clear cut path forward which decentralizes the network without tradeoffs
00:23:34warren: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:43petertodd: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:00warren:maaku_: multiple competing scalable p2pool-like things with a trustless accumulators and more GBT pools would be low hanging fruit
00:25:07petertodd:warren: electrum actually is reasonably close to solving all that, modulo committed indexes
00:25:19warren:petertodd: yeah
00:25:37adam3us:petertodd, warren: prefix have worse privacy properties than bloom.
00:25:42petertodd: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:43maaku_:petertodd: well, Thomas is waiting on me for the indices
00:25:46maaku_:* maaku_ gets back to work
00:25:49petertodd:adam3us: depends on your attack model
00:26:13petertodd:adam3us: again, did you read my paper? :P I strongly think in practice with real users prefix has better real-world privacy
00:26:16adam3us:petertodd: broadcast vulnerable info is like worse because it can be analysed later by anyone, vs sent to one random node
00:26:23adam3us:petertodd: i did, i just disagree.
00:26:32petertodd:adam3us: well, least you read it finally, ha
00:26:47warren:petertodd: the lower orphan rate should help. currently the too-many-txo's in coinbase is a problem.
00:26:59adam3us:petertodd: yeah i skimmed it before also. as i recall gmaxwell has the same view as me on that risk.
00:27:00warren:petertodd: the trustless accumulator should help that
00:27:13petertodd: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:37petertodd:adam3us: android wallet has 1 in 16k specificity for a reason - users want fast syncs
00:27:55petertodd:adam3us: that could really kill coinjoin the moment attackers start running SPV nodes to collect wallet data
00:28:36petertodd:warren: no it won't - it still requires all the expense of running a full node
00:29:14adam3us: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:16petertodd:adam3us: anyway, prefix *queries* are a categorically better model than bloom filters from the point of view of lookup privacy
00:29:54adam3us:petertodd: that might be. also electrum is like central/trusted type of solution right?
00:30:00petertodd: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:25petertodd:adam3us: electrum is not different from bloom SPV in principle
00:30:38petertodd:adam3us: in practice maybe more secure in some models because there are fewer electrum servers
00:30:46petertodd:adam3us: and their operators are better known
00:30:58adam3us:petertodd: but in practice, i thought electrum have a few central servers
00:31:22petertodd: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:28adam3us:petertodd: yes if u trust electrum. the other model as said above, pick a random node and try to stick to it.
00:31:30petertodd:adam3us: and even in that model you're better off with prefix queries
00:31:40petertodd:adam3us: electrum *is* the pick a random node and stick to it mdoel
00:32:32adam3us:petertodd: well its electrum advertising them selves as a trustworthy node. sometimes that is a flag to say dont trust them.
00:32:50petertodd: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:18petertodd:adam3us: note how prefixes gives you decent security even *if* you're connected to the nsa
00:33:22warren:We could just forget about SPV, finish ultraprune and stop worrying about this.
00:33:23adam3us:petertodd: if u use prefix with one-use addresses t seems ok no? no need for explicit prefix
00:33:24petertodd:adam3us: (prefixes + addr grinding)
00:34:06petertodd: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:11CodeShark:what's the prefix solution? using the first few bytes of a pubkey or script hash rather than a bloom filter?
00:34:20petertodd:warren: ultraprune doesn't help with bandwidth
00:34:42petertodd:CodeShark: yeah, there's two parts to it, first for queries you can always query by prefix
00:34:59adam3us:petertodd: could be block range constrained + closeness metric to tune like bloom
00:35:08petertodd: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:41petertodd: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:49adam3us: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:09petertodd: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:44petertodd: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:52adam3us: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:20adam3us:petertodd: eh no? academics do it for like 3rd year project
00:37:22petertodd:adam3us: I mean, shit, I was running about 10% of all public nodes for a few hours to test an attack
00:37:48petertodd:adam3us: yeah, all they learn about is the prefix, and then the stats leaks stops
00:37:49adam3us:petertodd: oh ok, u mean on the low side, gotcha
00:38:12petertodd: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:18adam3us:petertodd: but a bloom filter with some decent params can do that also no?
00:38:33petertodd:adam3us: yeah, from the point of view of "clustered wallet addresses" bloom and prefix are identical
00:38:39CodeShark: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:48adam3us:petertodd: so say TD fixed improved the params
00:38:48petertodd:adam3us: if you're not clustering wallet addrs, bloom and prefix are identical, it's just the latter is way more scalable
00:39:10jtimon:petertodd is there any reason why you can't use several prefixes in your wallet? more bandwith but more privacy
00:39:12petertodd:CodeShark: well BIP32 has problems there
00:39:22petertodd:adam3us: it's impossible to fit the params, it's a specificity/bandwidth tradeoff
00:39:31petertodd:adam3us: s/fit/fix/
00:39:47jtimon:say, use 3 prefixes, n instead of 1
00:39:48petertodd:adam3us: if you think params has anything to do with it you didn't understand my paper...
00:39:55adam3us:petertodd: bloom/prefix similar with no addr clustering... yes.
00:39:57CodeShark:perhaps we should expand the BIP0032 child index to 64 bits :)
00:40:16petertodd:jtimon: more prefixes *of the same length* just means you're using more bandwidth
00:40:26petertodd:jtimon: remember this is a bandwidth/anonymity set tradeoff
00:40:32adam3us:petertodd: you claimed the default params were too specific, so make them les so, while still tolerable bw.
00:40:46petertodd:adam3us: the reason why they are so specific is because users aren't tolerating more bandwidth
00:40:48jtimon:petertodd yes, my point is you can make the tradeoff configurable
00:40:57petertodd:jtimon: yes, and you can do that with prefix clustering too
00:40:58CodeShark:petertodd: I'm also thinking about how deterministic m-of-n script chains could work with this prefix model
00:41:09adam3us:petertodd: well more importantly u also said as i recall there was no feature to change the params
00:41:10jtimon:yes, yes, with prefixes
00:41:33petertodd: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:02petertodd: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:07petertodd:adam3us: smaller filter == less specific
00:42:28CodeShark:there is in my library :)
00:42:40petertodd:CodeShark: good
00:42:49jtimon:but with prefixes, can't you just ask for more info than you need?
00:42:58petertodd:jtimon: that's the whole point of prefixes!
00:43:00jtimon:I know, more bandwidth
00:43:21petertodd:jtimon: gah, have you read that paper of mine?
00:43:48jtimon: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:08petertodd:jtimon: ah, well, that's why I'm pushing the idea :) sounds like we're in agreement
00:44:11jtimon:sorry, no
00:44:40petertodd: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:56petertodd:jtimon: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03612.html
00:45:38petertodd: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:02petertodd:Again, saying this because I've actually done this personally by throwing some cash at Amazon EC2
00:46:04jtimon: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:17petertodd:jtimon: thanks
00:47:03CodeShark:jtimon: there's so much stuff going on in this space right now you'd be excused for not reading absolutely everything :)
00:47:20adam3us: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:39petertodd:adam3us: no, the recipient is the public
00:47:43adam3us:petertodd: so then its simple matter if people do not reveal the key, they cant respend
00:47:55petertodd:adam3us: that's got nothing to do with it
00:48:18CodeShark:the recipient's key is already a hash of a pubkey
00:48:25adam3us:petertodd: yes for your other use case. but then make it available from all nodes (its validatable against the ciphertext)
00:48:55petertodd: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:58jtimon: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:15petertodd:adam3us: there is no way to prove publication unless you can guarantee that the data can be decrypted
00:50:11CodeShark: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:18adam3us: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:31petertodd: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:11petertodd: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:43petertodd:adam3us: of course I'm assuming that - if I wasn't it wouldn't be much of a result
00:52:20petertodd: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:25adam3us:petertodd: ok then; it a bit slow tho time-lock. maybe you can find a subnet of msc-relaying nodes
00:54:42petertodd:adam3us: well sure, but that's not unlike making the block time longer - perfectly acceptable for a lot of applications
00:55:12petertodd:adam3us: I'm not claiming mastercoin should go and implement it right now - I'm pointing out that they could
00:56:37adam3us:petertodd: yep. i have some more stego end-game ideas. still holding them back :)
00:56:56adam3us:petertodd: meaning i dont disagree the steganographer wins. in the en game
00:57:14petertodd:adam3us: meh, do everyone some good and just publish them so people stop making shitty assumptions about scalability
00:58:25adam3us: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:08petertodd:adam3us: ah, well if they're less efficient don't bother
01:00:03killerstorm:killerstorm has left #bitcoin-wizards
01:00:10petertodd: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:27adam3us:petertodd: cant u get get consensus by time-stamping and using a separate msc-only network for the data?
01:00:50petertodd:adam3us: consensus isn't just time-stamping
01:01:01petertodd:adam3us: proof-of-publication matters, and it's really not trivial
01:01:12petertodd:adam3us: heck, maybe there is no general solution to it
01:01:55adam3us: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:29petertodd:adam3us: the point of proof-of-publication is to tolerate jamming you know...
01:03:21adam3us: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:24petertodd: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:47adam3us:petertodd: stego wins. i know it :)
01:04:17adam3us:petertodd: even if you have to use like morse code in the lsbit!
01:04:31petertodd: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:02petertodd:adam3us: and whenever those consensus schemes take that advice, we bitcoin devs fool ourselves
01:05:49adam3us: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:59petertodd: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:09adam3us:petertodd: sure.
01:06:10petertodd:"educatiing users" fuck off
01:06:19petertodd:we've got a system where you *earn more money* mining at a big pool
01:06:27petertodd:that's fundemental to how bitcoin works and isn't going to change
01:06:40adam3us:petertodd: there are other ways to "educate" users you know. that may require tor for the educators safety...
01:07:08petertodd:adam3us: all solutions that don't help *decentralized consensus systems*
01:07:10adam3us:petertodd: i wonder if any o fthem are selfish mining
01:07:13maaku_:petertodd: currently, you earn more money mining p2pool...
01:07:29petertodd:maaku_: not if you take your time into account for many miners...
01:07:29adam3us:maaku_: yes. this is very puzzling to me.
01:07:49adam3us:petertodd: but its just as easy to pick p2pool from the list
01:08:14maaku_:adam3us: you don't pick p2pool from a list, you run a local daemon
01:08:16petertodd:maaku_: like it or not we probably have to get to the point where pools *can't* exist, and simultaneously fix scalability
01:08:21maaku_:but i've found it to be very stable at least
01:09:03adam3us: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:18maaku_: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:29petertodd:adam3us: did you have a full node? if not you weren't using p2pool
01:09:41adam3us:petertodd: i did yes
01:09:43petertodd:maaku_: meh, just means you have to keep working on the proposals
01:09:58maaku_:adam3us: that'd be great if it does, but it probably just connected to a public p2pool node
01:10:18maaku_:which is really no different than a centralized pool as far as this conversation is concerned
01:10:19petertodd: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:48petertodd:heh, heck, adam not knowing exactly what his hashing power was doing is a great example of why this is hard...
01:10:52adam3us: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:24petertodd:adam3us: meh, that shiney p2pool bundle is an easy thing that people are already working on for free
01:11:44warren:adam3us: p2pool requires high CPU and disk i/o performance to be efficient =(
01:11:47adam3us:petertodd: i think the UX might be the key though. if someones doing it for fre fine
01:12:27maaku_: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:34petertodd:warren: I set my p2pool node to mine very small blocks for that reason
01:12:46maaku_:let bfgminer --p2pool set up the services
01:12:57petertodd:warren: I think it's set to like 0.01BTC/KB fee or something
01:13:03warren: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:42petertodd:warren: and you know, don'
01:13:45warren:adam3us: I paid about $30k out of pocket during 2013 to various people who helped upstream bitcoin or p2pool
01:13:59petertodd: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:21petertodd:warren: we're supposed to be thinking medium to long term here, fixing p2pool is short to medium
01:14:51jrmithdobbs:petertodd: but the p2pool thing highlights a real problem
01:14:56warren: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:16jrmithdobbs:petertodd: we have functional-enough-for-now technical solution to this, but (practically) noone using it
01:15:51petertodd: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:55warren: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:15adam3us:warren: i see. (re money situ/history).
01:16:22jrmithdobbs:petertodd: but there's noone (very few) willing to pay the people capable of the technical solutions and give them the context
01:16:24petertodd:warren: that's fine, I do for now
01:16:25jrmithdobbs:petertodd: how do we solve that?
01:16:46adam3us: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:58petertodd: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:20jrmithdobbs:petertodd: or when major players in said foundations deny it's a problem.
01:17:29petertodd:jrmithdobbs: I can hardly even convince people *here* that p2pool isn't a very good solution
01:17:32petertodd:jrmithdobbs: heh, that too
01:17:38jrmithdobbs:petertodd: that's not a solution, that's an admittence of failure, really
01:17:39adam3us: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:14warren: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:23petertodd: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:24adam3us: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:46jrmithdobbs:kinds are part of the types really
01:20:50jrmithdobbs:err wrong chan
01:20:57petertodd: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:15warren: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:29petertodd:adam3us: the people who can do that work can't do consensus system theory (and mostly vice-versa)
01:22:31adam3us: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:43warren:Go ahead and call me chicken, after centralization is fixed.
01:23:22adam3us: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:39petertodd: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:37adam3us: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:50warren:ghash has other ways to make money (trading commissions...)
01:24:59petertodd:adam3us: I know, that's one of the reasons they're so big
01:25:46warren:If p2pool improved substantially, grew bigger and flexed its orphan advantage it might be able to compete.
01:25:46adam3us: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:48petertodd: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:22petertodd:adam3us: business risk is a funny thing - ghash.io has a perception to maintain
01:26:27adam3us:petertodd: u know there's one with 100% fee (aka it stopped paying out) and it still has significant TH
01:26:35petertodd:adam3us: equally, people's perception of value is often that higher cost == better
01:27:04adam3us:petertodd: i suspect its bigger == better thinking here.
01:27:07petertodd: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:13petertodd:adam3us: yeah, well duh
01:27:49adam3us: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:53petertodd: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:01petertodd:adam3us: yup
01:28:11petertodd:adam3us: having to research the right way to do something is a huge cost
01:28:19petertodd:adam3us: heck, ahving to make choices at all is a huge cost
01:28:49adam3us:petertodd: but 5% eh. maybe a 50point font mining pool fee % & profit calculator in the miner sw
01:28:53jrmithdobbs: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:29:11petertodd:jrmithdobbs: yeah, all those points.
01:29:39jrmithdobbs:petertodd: just making sure i was understanding your point (and I agree)
01:29:50petertodd: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:22adam3us:petertodd: yeah thats more intersting (must get off fixating on irritating user stupiity:)
01:30:23petertodd:Similarly, how can blockchains be structured such that p2pool-like varience reduction is a given?
01:30:37amiller:loosen the difficulty restriction
01:30:42amiller:let people choose their own difficulty in some way
01:30:58amiller:that way you can still maintain the overall security invariant
01:30:59petertodd: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:06adam3us:petertodd: i think it was amiller who said it first (stealable PoW) except i thik he was talking reverse ... for hosted mining
01:31:11petertodd:amiller: well, is that diff per-block then or what?
01:31:37amiller:i was talking about both equally, i gave an abstraction where both pools and hosted mining are equally a security violation!
01:31:49petertodd:amiller: or can we split blocks up? how does consensus work?
01:31:58adam3us:amiller: actually the whole pool choses work packet for miner is just wrong thinkin
01:32:01petertodd:amiller: yeah, I'm not sure if I have a solution to hosted mining yet
01:32:12adam3us:amiller: the whole point of hashcash is the user choses their own work packet
01:32:20petertodd:adam3us: yet, just saying that doesn't help :)
01:32:34warren: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:38petertodd:adam3us: getblocktemplate is the perfect example of just saying that, and look where that's gone
01:32:43jrmithdobbs:petertodd: the only straightforward solutions i can think of require things that don't actually exist
01:32:44amiller:so the block selection function is
01:32:46petertodd:warren: Good!
01:32:48amiller:choose the lbock with largest sum difficulty
01:32:49warren:They're quite naive, suggesting just increasing the scrypt parameters.
01:32:51amiller:that's invariant to difficulty choice
01:32:55jrmithdobbs:but i've not spent much time thinking about hosted mining, ha
01:32:59amiller:the problem with difficulty choice is one of PoW basically
01:33:11adam3us:petertodd: whats wrong with GBT?
01:33:16petertodd:warren: heh, they willling to put money towards researching ASIC-hardnesss
01:33:27petertodd:adam3us: there's no incentive for individual hashers to use it
01:33:54warren:If Litecoin is willing to go through the pain of a hardfork, it better be more interesting than bigger scrypt.
01:34:00petertodd:warren: agreed
01:34:07warren:And I think bigger scrypt is a bad idea, validation is already slow.
01:34:19amiller:you can reject someone's blocks, as part of the rational strategy space
01:34:35amiller:so that can include whether the sum difficulty is over tons of weak blocks or a few bonanza blocks with high diffiuclty
01:34:39adam3us:warren: coelho merkle hash PoW is better. vitalik used it in dagger for ethereum.
01:34:40amiller:obviously the tons of weak blocks is a DoS
01:34:42petertodd:warren: heh, well, doing birthday-style momentum hash would be as temporarily asic-hard as any scrypt tweak, and with fast validation
01:34:47amiller:but we handle DoS on an ad hoc basis at the moment anyway.
01:35:00adam3us:warren: better in that it uses fiat-shamir to only have to spot check the answer, not repeat the work
01:35:01warren:petertodd: temporarily ...
01:35:15amiller:so how about this
01:35:17amiller:accept a range of difficulties
01:35:35petertodd: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:35amiller:but not all the way to nothingness
01:35:36adam3us:petertodd: momentum is not too stupid. quite TMTOable but other than that.
01:35:47warren:adam3us: maaku_: yes litecoin & ftc are currently not plausible to overtake <----- huh? ftc?
01:35:48petertodd:adam3us: define TMTO again?
01:35:48amiller:the bottom-out level is a miner policy
01:35:59amiller:minimum acceptable difficulty i mean
01:36:00warren:adam3us: only thing implausible about overtaking FTC is their centralized broadcast checkpoints
01:36:23petertodd: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:26adam3us:warren: it was hypothetical comparison, nothing specific to ltc/ftc
01:36:45warren: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:50petertodd:adam3us: oh, right, Time Memory Tradeoff or whatever
01:37:09amiller: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:20amiller:b) the more stale blocks you accumulate, the more penalty you apply to short spammy blocks
01:37:24petertodd:warren: birthday PoW might be GPU implementable actually
01:37:39petertodd:warren: cuckoo hashing seems possibly to be as well
01:37:47warren:adam3us: is Savitch's theorem relevant at all to this?
01:37:47adam3us:petertodd: TMTO is fine for warren's GPU lovers. you ned that to run momentum on a gpu anyway
01:37:49amiller: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:08petertodd:amiller: gah, I really am against this stale block crap - it gives advantages to those with fast network connections
01:38:18adam3us:warren: i am not sure if it is because momentum nearly works and has an extremely efficient verification (consuming no memory)
01:38:18amiller:they have an adavantage anyway
01:38:52petertodd:adam3us: no actually, I was looking at some papers suggesting that GPU's are actually reasonable good at implementing content addressable memories
01:39:01petertodd:adam3us: it's not a TMTO tradeoff in that case
01:39:11adam3us:petertodd: oh nice.
01:39:52petertodd:amiller: yes, but don't make it even bigger, which ghost does
01:40:33amiller:i'm advocating *allowing* it to get bigger for a much more important reason
01:40:46amiller:the only thing ghost claims you can do is marginally increasing the flux of transactions, which is meh
01:41:04amiller:i'm claiming the main benefit to this is getting user-selectable variance *within* the main mining game
01:41:07petertodd:amiller: wait, what getting bigger? orphan rate?
01:41:46amiller:no the advantage to dudes with better network equipment in data centers, ie the amount of data and latency dependence
01:42:44petertodd:amiller: nah, better ways to get user-selectable varience than screwing up those incentives
01:42:54amiller:like what
01:42:55petertodd:amiller: again, why are you assuming a monolithin blockchain?
01:43:00amiller:how else are you going to get user selectable variance
01:43:04petertodd:amiller: do per-tx PoW and figure out how to make that reasonable
01:43:05adam3us: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:29amiller:small players want to play at lower variance, so yes
01:44:21adam3us: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:33roidster:roidster is now known as Guest75297
01:44:58adam3us:amiller: so u mean low variance in terms of pool shares.
01:45:01petertodd:adam3us: ifthe sub-puzzles earn you money linearly, that doesn't break fairness
01:45:07amiller:it doesn't break power fairness, it does have a subtle security rpoblem related to that though
01:45:22petertodd:amiller: which is?
01:45:43amiller:attackers can revert larger history with *better than negligible chance* if they can increase the difficulty high enouhg
01:45:49warren: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:58adam3us: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:25amiller:adam3us, that's an all or nothing puzzle
01:46:39amiller:adam3us, that's different than letting individuals get their own little reward for a subpart
01:46:48adam3us:amiller: right. the prize is all-or-nothing.
01:47:03amiller:ok so make subdivisible puzzles where there rewards are also subdivisble in the same way
01:47:03petertodd:amiller: right, so devise schemes where we're not letting luck revert large history
01:47:04adam3us:amiller: ok that i think is interesting to explore. (i tried a bit in the past also)
01:47:14amiller:petertodd, no that's fine as long as its not unbounded
01:47:20amiller:unbounded is a problem in the other direction too
01:47:35amiller:unboundedly small puzzles => DoS hazard as attacker floods network with small plausible weak blocks
01:47:43warren:adam3us: petertodd: how well researched is birthday against a worse break?
01:47:44adam3us:amiller: the other problem is you have reward and consensus and they are bound together
01:47:50amiller:unboundedly difficult puzzles => attacker has too good a chance of an attack with less power
01:47:59adam3us:warren: its pretty fundamentally hard
01:48:13adam3us:warren: just time memory trade offs
01:48:31amiller:adam3us, could you be a little more specific about what reward and consensus mean here
01:48:35warren:adam3us: are people already using TMTO to mine it?
01:48:43petertodd: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:49warren:scrypt GPU uses TMTO
01:48:58adam3us:warren: there was a thread on the protoshares / bitshare board where a guy was coding one.
01:49:06amiller:petertodd, i don't know what you are talking about, MMR? MMR for blocks?
01:49:17adam3us: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:37petertodd:amiller: no, I mean, strucure your blockchain as a binary tree of "blocks"
01:49:46petertodd:amiller: still linear in the time axis
01:50:24adam3us:amiller: reward = 25btc/block, consensus = everyone agreeing on transaction order and validation (over time)
01:50:41petertodd: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:50petertodd:amiller: related is I suspect such a structure can do better scalability
01:50:57amiller:ok so make the reward proportional to block
01:51:01amiller:fees behave same way as before
01:51:12amiller:consensus = everyone agrees on transaction order same as before...
01:51:26petertodd:amiller: yeah
01:51:42amiller:proportional to difficulty in a block*
01:51:42adam3us:adam3us: but for consensus security there maybe an incentive security tie relating to reward...
01:51:59petertodd: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:47adam3us:amiller: oh i get you. allow a consensus to be built up from frctional blocks
01:53:12petertodd:adam3us: yup, and the fraction could be as little as a single tx
01:53:36petertodd:adam3us: (obviously it's likely the concept will end up with some notion of work/byte)
01:53:37adam3us:amiller: like you could be 1.5-confirmed. plausible but creates longer chain/complexity, maybe orphan risk, bandwidth usage
01:54:00petertodd:adam3us: yet, if you combine it with a scalability solution w/ sharding, per-node bandwidth can be less
01:54:27amiller:maybe the GHOST guys want to work on this
01:54:31warren: warren: heh, well, doing birthday-style momentum hash would be as temporarily asic-hard as any scrypt tweak, and with fast validation
01:54:40warren:To what degree would this be merely kicking the can down the road?
01:54:41petertodd:amiller: heh, well *I* want to work on this
01:55:05petertodd:warren: good question, probably tens of millions down the road, in terms of ASIC development cost
01:55:06amiller:well it basically forces a bunch of other sore issues
01:55:10amiller:like how to make fees match resources consumed
01:55:22warren:tens of millions of dollars? that's nothing
01:55:26petertodd: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:31amiller:i think having parameters to restrict the bounds on either end is important
01:55:35petertodd:warren: sha256 ASICs are hundreds of thousands
01:55:36adam3us:petertodd: well if basic compression (not sending data twice) was implemented a block may cost less bw
01:55:57warren:petertodd: oh, tens of millions factor, not dollars?
01:56:21petertodd: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:27adam3us:warren: i think $ in both cases
01:56:36warren:ok, then that isn't a worthwhile change
01:56:41petertodd:warren: but, what that's really saying is this is something that we need a real hardware person to analyse
01:57:24petertodd:warren: also momentum has interesting stuff: e.g. commodity content addressable memory *is* available because network routiers and the liek use it
01:57:35adam3us:amiller: btw i also thought of ghost a while back :) (saw you mentioned u did above)
01:58:12petertodd: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:29warren:who is qualified to analyze it?
01:58:32petertodd:warren: it's the kind of thing MSC should be thinking about too
01:58:48petertodd:warren: good question - some kind of digital electronics/computer engineering person
01:58:50warren:huh? MSC has PoW?
01:58:55adam3us: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:57petertodd:warren: I've got the contacts to find a person for that
01:59:23petertodd:warren: not yet, but that falsl into things MSC should look into
01:59:36petertodd:warren: note that Ethereum does and it's a MSC competitor/substrate
01:59:43warren:If MSC is on Bitcoin's network, I don't see how it needs its own PoW
01:59:52warren:what is Ethereum?
01:59:59adam3us:warren: oh boy
02:00:02petertodd:warren: a bit part of why I was hired was to determine what the options are there...
02:00:06petertodd:adam3us: lol
02:00:13warren:(I've been busy lately.)
02:00:27adam3us:warren: http://ethereum.org/ethereum.html
02:00:37warren:who made this?
02:00:42adam3us:warren: vitalik
02:01:04warren:a month ago he was all pro-primecoin
02:01:08adam3us:warren: with support of some good marketing folks
02:01:13petertodd:warren: vitalik is smart, but not wise...
02:01:22adam3us:warren: prime coin is a crock (IMO)
02:01:37adam3us:warren: i persuaded him that coelho was better ;)
02:01:48warren:sorry, what is coelho?
02:01:49adam3us:warren: hence he made dagger (linke from the above)
02:01:50petertodd: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:24adam3us:warren: merkle hash PoW with a fiat-shamir trick to reduce the memory for verify to like 4log(n) or such
02:03:25petertodd:adam3us: ugh, dagger is used *so* poorly in ethereum
02:03:42adam3us:warren: it crazy stuff because the script language is like able to do almost anything. the implications are unknowable
02:04:03adam3us:petertodd: critique specific?
02:04:32petertodd: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:45adam3us:warren: virus script that like takes all coins? probably not actually. but its openended and people may have fun with it
02:05:04petertodd:adam3us: meanwhile that kind of PoW is still rather parallelizable, including in an asic
02:05:09adam3us:petertodd: ah yes he dropped that bit. he was talking about data tho & i mentioned he could use that feature
02:05:26adam3us:petertodd: (separately proof of storage or something for some other reason... )
02:05:31petertodd:adam3us: ugh, so he knows that you can do that? fuck
02:05:53petertodd:adam3us: the whole writeup on the ethereum site is just full of hand-wavey numbers too
02:05:57adam3us:petertodd: well he does now. i am not sure it occurred to him at the time he wrote dagger
02:07:11petertodd:adam3us: anyway, the whole idea that memory requirements somehow make something ASIC hard by themselves is very wrong
02:07:16adam3us: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:21warren:is dagger fast to verify?
02:07:25petertodd:warren: yeah
02:07:53adam3us:warren: faster than scrypt for the memory used, but slower than momentum. however momentum is more TMTOable
02:08:02petertodd:adam3us: well, you make an asic that's physical strucutre is a tree for instance
02:08:06adam3us:warren: i wouldnt say fast but less slow.
02:08:42adam3us: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:51adam3us:warren: u could use it otherwise...
02:09:35adam3us:petertodd: i meant even in software! gotta re-read it (didnt occur to e before for some reason)
02:09:57petertodd: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:33petertodd: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:33adam3us: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:47warren:petertodd: so wait, where would MSC use PoW?
02:10:58petertodd:adam3us: where going up the tree enough rounds have been done to be pre-image secure?
02:11:05warren:sorry, I'll be back later, meeting in 30 minutes I need to prepare for
02:11:08petertodd:warren: it'd use it to implement a ethereum layer
02:11:21petertodd:warren: I mean, implement ethereum-style consensus system, as an example
02:11:25amiller:adam3us, sure, it's kind of a dauting engineer effort which is why i've shied away from it
02:11:29adam3us:petertodd: that might not be a bad idea. tree-evaled sha256 rounds
02:11:39amiller:adam3us, but i hope at this point it's at least clear what sort of benefit this can get you
02:11:53amiller: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:03petertodd:adam3us: yeah, hell, maybe even something as simple as XOR can be used in some cases for lower parts of the tree?
02:13:16petertodd: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:16petertodd: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:44adam3us:petertodd: i think scrypt has a faster hash to fill memory at one stage no?
02:16:35adam3us:petertodd: there were some earlyer PoW that aimed to stress memory latency by wobber et al. unfortunately they all got broken :)
02:16:37petertodd:adam3us: yeah, that's why it uses salsa20
02:16:54petertodd:adam3us: for consensus pow I think trying to stress latency is hopeless
02:17:06petertodd:adam3us: though for timelock crypto it's perfectly reasonable
02:17:39adam3us:petertodd: why? its another form of parallelizable work...
02:18:00petertodd:adam3us: I'm talking about serial-parallel hash chain schemes
02:18:33petertodd: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:01petertodd: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:02adam3us: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:28petertodd: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:05adam3us: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:22petertodd:adam3us: sent? ?
02:21:38adam3us:petertodd: they linked it into the exe
02:21:44petertodd:adam3us: ah, I get it
02:22:10petertodd:adam3us: yeah, that's an interesting question: you really want a nothing-up-my-sleeve source of non-compactable random data!
02:22:30adam3us:petertodd: we've got one :) the block chain
02:22:32petertodd:adam3us: interesting problem to get bulk nothing-up-my-sleeve numbers - good opportunity for being overely cute
02:22:39petertodd:I was gonna say...
02:23:23petertodd:though even then you'd probably want to encrypt the blockchain with a CBC cipher to properly randomize it
02:23:23adam3us:petertodd: relatedly i proposed on CFRG using the block chain to proof NUMS / uncooked Elliptic curve paramter generation
02:23:29petertodd:ha nice
02:23:48adam3us:petertodd: i think its actually much better than the alternatives and the current state of the art which is quite gamable
02:24:02petertodd:adam3us: what's the state of the art?
02:24:51adam3us: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:04adam3us:petertodd: except there are 100s of bits of choices hidden in there..
02:25:17adam3us:petertodd: which means the choices could've been ground (doh!)
02:25:30petertodd:adam3us: oh right
02:25:45petertodd:adam3us: well don't they usually pick the *first* bits of pi?
02:26:09adam3us:petertodd: yes but i mean the code itself, the endian choice, the order the options are considered etc
02:26:16adam3us:petertodd: http://www.ietf.org/mail-archive/web/cfrg/current/msg04019.html
02:26:27adam3us:petertodd: (its quite short and bitcoin amusing)
02:26:30petertodd:adam3us: sure, but not that many bits there...
02:27:10adam3us: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:18petertodd:adam3us: ah, yeah I'll admit using the blockchain to prove you didn't try the whole process twice is nice
02:27:20adam3us:petertodd: many arbitrary decisions = grindability
02:28:23petertodd: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:23adam3us: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:29:10adam3us:petertodd: i like it :) i mean its actually a useful improvement
02:30:33petertodd: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:17petertodd:timelock works really well in this case because you don't care how long it takes to verify the process
02:33:20petertodd: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:22adam3us:petertodd: oh yeah i think i remember that post now you mention it.. maybe it stuck in my subconscious
02:33:29petertodd:adam3us: be nice to get some lower-bounds there
02:33:58petertodd:adam3us: I'm pretty sure there's nothing with better latency for large amounts of ram out there than commodity hardware
02:33:59adam3us:petertodd: out comes the watercooled monster box :)
02:34:07petertodd:adam3us: yup
02:34:34petertodd: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:37adam3us:petertodd: my cpu is good (4.8ghz hex core) but i didnt splash for fancy ram
02:34:38petertodd:adam3us: that costs you speed
02:35:11adam3us:petertodd: exactly, yes. (reliability argument) i think one of the asic hw people commented on that
02:35:16petertodd:with a big enough bounty it could be a good way to test the "single round of foo hash" idea
02:35:32petertodd:adam3us: butterfly labs for one implements that
02:35:46petertodd:adam3us: though we *are* lucky that overclocking is still popular
02:38:42adam3us: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:09adam3us:petertodd: ghz*core speed assuming parallelizable tasks.
02:39:53petertodd:heh, it'd be hilarious if all our efforts at ASIC-hard PoW just leads to more hardware designed for overclockers :P
03:29:59c0rw1n_:c0rw1n_ is now known as c0rw|zZz
04:24:57Netherweave:Netherweave has left #bitcoin-wizards
05:27:22Doge_Funnie:Doge_Funnie has left #bitcoin-wizards
06:09:35jarpiain:jarpiain is now known as Guest81487
06:10:50maaku_:petertodd: that wouldn't be a bad outcome
06:11:15maaku_:* maaku_ dreams of commodity supercomputers
06:57:17CodeShark:opinions? https://github.com/CodeShark/bitcoin/compare/coinparams_new
07:21:23wumpus: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:44CodeShark:right, I realize that - I was considering a plugin model
07:22:35CodeShark:scrypt.so, hash9.so, etc...
07:23:00wumpus:hmm I don't know
07:23:31CodeShark:or perhaps a compiletime flag to statically link to a particular hash function
07:23:37wumpus: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:11CodeShark:what are your concerns?
07:25:09wumpus:security mainly, incompatibility, general so/dll hell
07:25:37wumpus:for now I'd more like a modular approach based on libraries (which can get statically linked into the end product)
07:25:56CodeShark:so then perhaps a way to specify a list of static modules to link at compiletime
07:26:39wumpus: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:38wumpus:or other applications that may need the bitcoin consensus stuff for their own purposes
07:28:15wumpus:anyway, lots of options, but: no altcoin specific stuff in bitcoin/bitcoin please
07:28:16CodeShark:for other applications I'm thinking more of a service-oriented architecture, with a core engine providing runtime services to other processes
07:29:06CodeShark:yeah, the intention wasn't to merge the altcoin specific stuff in bitcoin/bitcoin
07:29:18CodeShark:just to expose the ability to customize the core engine
07:30:21CodeShark:the inclusion of scrypt and hash9 in particular is a total hack at this point, just intended to test the basic idea
07:34:19CodeShark: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:04wumpus:let's move this to #bitcoin-dev
08:51:45TD[gone]:TD[gone] is now known as TD
11:50:46c0rw|zZz:c0rw|zZz is now known as c0rw1n
13:13:32wallet42:wallet42 is now known as Guest30378
13:13:32wallet421:wallet421 is now known as wallet42
13:20:18adam3us: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:43TD:TD is now known as TD[away]
13:52:01jgarzik:jgarzik is now known as home_jg
14:39:01_ingsoc:andytoshi: Where are the -wizards logs again?
14:40:11andytoshi:_ingsoc: http://download.wpsoftware.net/bitcoin/wizards/
14:41:58michagogo|cloud:(That really belongs in the topic...
14:42:04andytoshi: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:22michagogo|cloud:michagogo|cloud has left #bitcoin-wizards
17:26:12deadweasel:deadweasel has left #bitcoin-wizards
18:36:22gwern: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:22maaku_:maaku_ is now known as maaku
18:36:42Ursium:hi gwern, yes i saw that
18:37:15Ursium:i believe the founders are aware as i remember reading about this very issue a while back.
18:39:18petertodd: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:05Ursium:petertodd: i see!
18:40:54petertodd: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:24Ursium:makes sense. Will be interesting to follow for sure
18:42:17sipa:(upcoming ad-hominem) the author suggesting x86 as script code doesn't inspire much confidence
18:42:55petertodd:sipa: +1
18:43:13maaku:i think there's a valid technical point in that ad-hominem
18:43:26Ursium: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:50sipa:maaku: yes, but it's irrelevant to the issue being discussed
18:44:25maaku: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:29maaku:mostly related to covenants
18:44:30petertodd:Ursium: the idea of extrospective scripts is a good one, how to implement them is another issue
18:44:58maaku:you would *not* want to do so using an ad-hoc CISC language, however
18:45:18petertodd: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:20maaku:you'd need something amenable to static analysis (e.g. a strongly typed stack language)
18:45:56petertodd:maaku: or a single type :P
18:46:04maaku:petertodd: ? for CC you need to look at the outputs of the current transaction to avoid inflation
18:46:26maaku:well, functions/combinators are types...
18:47:14maaku:michagogo|cloud: I'm allowed to op, but not change the title for some reason. Is that a different permission?
18:47:19petertodd: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:53maaku:oh yes i see how that would work
18:48:03maaku:you lose SPV compatability though
18:48:22petertodd: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:47petertodd: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:50gwern:huh. induction in real life.
18:48:54petertodd:gwern: yes
18:49:31maaku:only if the coins become unspendable if they were invalidly constructed
18:50:05petertodd: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:22petertodd:maaku: IE, you can get the coins back under all circumstances, you just can't make them colored fraudulently
18:51:39maaku:petertodd: ok, walk me through this. I create a transaction marking all the outputs as 'blue' with a CC script prefix
18:51:50gmaxwell:you make the script only allow you to assign it if it was used previously or if some birth criteria is met.
18:52:03petertodd:maaku: *no*, you make a transaction that in the scriptSig includes the CC validity script
18:52:16gmaxwell: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:28petertodd: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:39gmaxwell:you use the first rule to give birth to the colored coin and then the rest can only be children of it.
18:52:51petertodd:gmaxwell: can only be children of it *or* not colored
18:52:56gmaxwell:or not colored, indeed.
18:53:00gmaxwell:don't want it to be viral.
18:54:15maaku:ok how do you restrict which outputs are colored?
18:54:46adam3us:gwern, petertodd: i am not sure how important sequential memory hard is Lerner says "must not allow easy parallelization
18:55:09petertodd:maaku: the restriction is that you can't make the CC script execute unless the transaction only creates valid CC outputs
18:55:23adam3us: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:25petertodd:maaku: but you can still spend the outputs, it just means the outputs aren't colored
18:56:47petertodd: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:08maaku:petertodd: so the outputs are still tagged?
18:57:15petertodd: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:48petertodd: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:54adam3us: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:21maaku: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:22petertodd:maaku: basically the scriptSig contains:
19:00:03petertodd: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:39petertodd:adam3us: sequential != cachable
19:00:50maaku:petertodd: oh, i mean things like highly interconnected cores, greater memory bandwidth, etc.
19:01:36petertodd: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:09adam3us: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:10petertodd: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:37maaku:adam3us: like Cell and APU
19:02:40adam3us:petertodd: right. sequential access is faster on existing hardware because they optimie for it
19:03:05petertodd:adam3us: not so much because they optimize for it, but because it's the only possible way to build the hardware
19:03:29petertodd:adam3us: I mean, you could optimize for something else, but the limitations of silicon strongly suggest bank-accessed designs
19:03:37maaku: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:58maaku:or rather, things which are available now but in limited quantities
19:04:02petertodd:adam3us: similarly you need designs where the cpu<->mem interface happens in packets because high-speed parallel busses are impossible to make
19:04:12maaku:and let the market push industry further in that direction
19:04:47petertodd: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:26petertodd:maaku: for instance, PoW mining can tolerate way higher error rates than almost any other application
19:06:50adam3us: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:21adam3us: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:05petertodd: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:09adam3us: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:39petertodd:adam3us: meh, I like to beat on nature
19:13:02adam3us: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:27jtimon:adam3us I guess jgarzik just convinced me here http://www.coindesk.com/bitcoin-developer-jeff-garzik-on-altcoins-asics-and-bitcoin-usability/
19:13:27jtimon:sorry afk for some time
19:14:22petertodd:jtimon: ugh... that's really ill-informed
19:14:37petertodd:jtimon: god-damn software engineers :p
19:14:39adam3us: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:32petertodd: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:04petertodd: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:18petertodd:adam3us: that industry has enough secrets that it'd be a winner-take-all situation potentially
19:21:13jgarzik_:jgarzik_ is now known as jgarzik
19:21:38petertodd: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:49petertodd:Thus we know you can make sequential-hard PoW with fast verification.
19:22:08petertodd:Of course, there's the real-world problem where the SNARK proof-creation is a better PoW than the scrypt... :)
19:22:32petertodd:maaku: ^ though that might be a useful way to optimize SNARK proof-creation of course...
19:22:48petertodd:(I think gmaxwell? suggested basically that for SCIP stuff?)
19:25:45adam3us: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:57gmaxwell: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:23petertodd: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:44petertodd:gmaxwell: yeah, faster than scrypt though right?
19:27:11gmaxwell:dunno. scrypt as used in ltc is slow but it might just be compariable.
19:27:41petertodd:gmaxwell: yeah, anyway, the PoW validation slowness isn't a deal-breaker, just annoying
19:27:57petertodd:gmaxwell: bigger issue is that really ASIC-hard PoW's are a lot slower anduse a lot more ram than scrypt...
19:28:02adam3us: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:10petertodd:gmaxwell: (well, LTC-style scrypt params)
19:29:18petertodd: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:10adam3us: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:20petertodd: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:30petertodd:adam3us: like I was sayng above about how ram is banked anyway
19:33:15petertodd: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:50gmaxwell: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:52petertodd: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:37petertodd: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:33gmaxwell:I think it has to be a small fraction of latency in order to not matter.
19:35:51gmaxwell:keep in mind wrt the snark idea: snark _creation_ will always be much slower than execution
19:36:10petertodd:gmaxwell: I would have thought a small fraction of block interval - network latency is a similar impact to PoW latency
19:36:26adam3us: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:29petertodd:gmaxwell: oh, obviously if you do it snark-style you've gotta have the snark proof finish in < 1s - very difficult
19:36:37petertodd:gmaxwell: although maybe ok if the snakr is only for the sake of SPV
19:36:42gmaxwell:adam3us: the ltc fpgas were a power usage win.
19:36:59gmaxwell:petertodd: well in particular because you could do proofs of the whole sum rather than a single header.
19:37:14petertodd: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:25petertodd:gmaxwell: good point
19:56:43adam3us:gmaxwell: i believe that is correct. (progress freedom and ratio of minimum work unit on single core to block interval)
20:00:31adam3us: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:40Luke-Jr:FPGAs were only a power win for Bitcoin as well
20:01:02andytoshi:petertodd: you don't need to have fast snarks if your block time is something like several hours
20:01:22andytoshi:that may be desirable anyway if you want an anonymous high-latency mechanism for getting txes to miners in the first place
20:01:47petertodd:andytoshi: true, although I suspect several hour block intervals have user-acceptance problems
20:02:33andytoshi: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:10gmaxwell: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:26gmaxwell:even with 10 minute blocks.
20:13:29adam3us: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:00Luke-Jr:adam3us: consider the attacker doesn't need to worry about stale blocks also
20:14:06Luke-Jr:adam3us: there are a lot of factors involve
20:14:26Luke-Jr:fast blocks = more hashes wasted by the legit miners
20:14:41Luke-Jr:scrypt = slower block propagation
20:14:44adam3us: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:53adam3us:Luke-Jr: that too
20:15:03Luke-Jr:adam3us: right; there's advantages and disadvantages
20:15:09Luke-Jr:IMO they more or less balance out
20:19:21adam3us: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:03maaku:maaku is now known as Guest32500
21:31:34Guest32500:Guest32500 is now known as maaku
21:54:52jtimon:Luke-Jr I don't see the balance, Scrypt is neither "anti-ASIC" nor anti-GPU
21:55:24jtimon:what's the gain Scrypt has over SHA256 ?
21:55:59phantomcircuit:jtimon, nothing
21:56:49sipa:scrypt is certainly anti-gpu, if it'd use more than 128 KiB of RAM...
21:56:55Luke-Jr:jtimon: there is none, that's my point
21:57:22sipa:despite that, i'm very unconvinced that it has any advantages for bitcoin or similar systems
21:57:24EasyAt:scrypt ASICs will have a giant die size, no?
21:57:47c0rw1n:aq@gfa128KB ram desn't take much die space
21:58:04sipa:well the point would be to make the cost of the ASIC be dominated by fast memory
21:58:10jtimon:" IMO they more or less balance out" ok so this is just sarcasm?
21:58:57Luke-Jr:jtimon: no? we're talking about faster block times there, and how it doesn't make transactions any faster really.
22:00:03jtimon:Luke-Jr ok thans
22:00:46jtimon:sipa what's the point of "make the cost of the ASIC be dominated by fast memory"
22:01:24sipa:not saying this is a good idea, just reasoning how you'd make an anti-asic pow
22:01:36gmaxwell:It's an attempt to reduce the gap between commodity hardware and specialized hardware.
22:02:05sipa: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:14sipa:as the cpu will not be the bottleneck
22:02:25gmaxwell: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:45gmaxwell:Vs in KDF usage getting the custom hardware advantage down to just 10:1 would be great.
22:02:54sipa:i think it's a great recipe if you want botnets
22:03:28gmaxwell: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:43jtimon:I assume it also has to be anti-GPGPU, right?
22:04:18sneak:the nice thing about kdfs is that it's ok to use eleventy bazillion iterations too
22:04:27sneak:because most use-cases don't mind a 500msec wait
22:04:48gmaxwell:well KDFs want fast verification too, but a few hundred ms is okay usually.
22:04:56sipa:jtimon: unless GPUs would happen to have better memory bandwidth :)
22:05:09gmaxwell:They don't want generation / verification asymmetry, which we want for hashcash usage.
22:06:23gmaxwell:sipa: generally GPUs have had much better memory bandwidth than j-random-cpu. (though horrible memory latency relative to their clockrate)
22:07:07jtimon: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:28jtimon:and some problems have their bottlenecks in memory
22:08:37gmaxwell:jtimon: graphics work is generally memory throughput limited.
22:11:38jtimon:I'm just saying that GPU designers are not only optimizing for graphics, there's more problems being solved with other demands
22:11:52jtimon:GPUs architectures can change
22:12:53jtimon:maybe you're right and the GPGPU people won't ask for those constraints to be improved
22:12:56gmaxwell: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:56gwern:the wheel of reincarnation
22:14:39gmaxwell:(e.g. how FPUs and stand alone short vector units became standard cpu features)
22:14:58jtimon: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:23sipa:i'm not sure it matters
22:15:27jtimon:yeah gmaxwell xmm mmx
22:15:32gmaxwell:jtimon: we? I think it's all stupid regardless. :)
22:16:07gmaxwell: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:42gmaxwell: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:03gmaxwell: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:26gmaxwell:simple fast circuits also have fast verification, which is very helpful too.
22:18:21jtimon:ok, so I see you have even more reasons than me against the "quest for the perfect mining function"
22:19:32gmaxwell: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:57sipa:heh, maybe we need an altcoin optimized for ASICs
22:20:22gmaxwell:DES POW.
22:20:29sipa:where the PoW function is has a trivial optimal circuit design
22:20:33jtimon: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:51jtimon:sipa there's one alt named ASICcoin
22:21:13gmaxwell: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:42gmaxwell:the sha256 circuit is really straight forward already. You can get some gains by careful staging to equalize latencies...
22:33:54andytoshi: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:13andytoshi:throwing it out here because there's probably something obviously dumb about it, and you guys are good at catching that stuff
23:30:49jtimon:how "computer hardware" is not "theoretical computer science"?
23:32:38jtimon:oh, not experts in hardware, I missread