| 00:00:06 | sipa: | but right now, only very low bandwidth links or very low latency ones likely benefit from more complex propagation protocols |
| 00:00:37 | jaekwon: | what's the mean latency today for propagating an average sized block? |
| 00:00:45 | sipa: | slow |
| 00:00:55 | sipa: | but much is things that could be improved in software |
| 00:00:58 | phantomcircuit: | jaekwon, depends on who found the block |
| 00:01:11 | phantomcircuit: | some mining pools are better connected than others |
| 00:01:24 | jaekwon: | ah. |
| 00:01:39 | phantomcircuit: | thus my comment about blindly forwarding blocks to the entire available network |
| 00:01:39 | sipa: | i havebhard about 1 minute propagation times, but afaik tjat was with 0.7 still |
| 00:02:14 | phantomcircuit: | sipa, to get 99.999% propagation takes a pretty long time |
| 00:02:46 | phantomcircuit: | there are enough nodes out there on high bandwidth links with slow disks that the verify -> store -> forward cycle is actually pretty significant |
| 00:03:09 | sipa: | we really need forward before storing on disk :) |
| 00:03:22 | phantomcircuit: | think: all those people trying to "help" the network by spinning up a VPS running bitcoind |
| 00:03:30 | jaekwon: | interesting. and, for new blocks, is the whole block transferred at once, or is it receive-block -> request inv of transaction hashes in block -> request individual transactions of block? |
| 00:03:37 | sipa: | whole block |
| 00:03:46 | jaekwon: | thank you. |
| 00:03:48 | sipa: | which on decent links is certainly faster |
| 00:04:19 | phantomcircuit: | sipa, yeah i have a small relay which uses a whitelist, if it receives a message from anything on the whitelist it broadcasts it to as many peers as it can find without verifying or anything |
| 00:04:36 | sipa: | sounds smart |
| 00:04:37 | phantomcircuit: | actually it pushes an inv and then the block immediately without waiting for getdata also |
| 00:04:43 | jaekwon: | for what it's worth, libswift seems to perform really well for flash swarms, which is the case for new blocks. might make block propagation faster. |
| 00:04:46 | phantomcircuit: | because lol fuck people with spv clients |
| 00:05:07 | phantomcircuit: | jaekwon, it's not a bandwidth issue for the most part |
| 00:05:24 | phantomcircuit: | block propogation times are tied almost entirely to the multiple round trips it takes |
| 00:05:46 | phantomcircuit: | consider that the effective maximum latency between nodes is 500ms (the connect() timeout is 500ms iirc) |
| 00:05:49 | sipa: | jaekwon: bitcoin relays blocks only after validating them |
| 00:05:58 | phantomcircuit: | so to go 3 hops you're looking at |
| 00:06:14 | sipa: | no, 5000ms |
| 00:06:20 | phantomcircuit: | sipa, oh was it changed? |
| 00:06:27 | phantomcircuit: | it was 500ms when i wrote the patch :P |
| 00:06:28 | sipa: | like in 0.5 |
| 00:06:30 | sipa: | oh |
| 00:06:34 | sipa: | maybe it changed since |
| 00:06:48 | sipa: | but 0.5 can't work... no tor link would function |
| 00:06:51 | phantomcircuit: | i changed it to 500ms when it was switched to using select |
| 00:06:56 | phantomcircuit: | before that the timeout was 120 seconds |
| 00:07:09 | kanzure: | phantomcircuit, is the whitelist a default feature in bitcoind? |
| 00:07:16 | sipa: | no |
| 00:07:18 | phantomcircuit: | kanzure, this isn't bitcoind |
| 00:07:29 | phantomcircuit: | bitcoind would cry under the load this thing gets |
| 00:07:46 | sipa: | #botcoin-dev |
| 00:07:48 | kanzure: | does bitcoind eventually blacklist peers that relay wrong things too often? |
| 00:08:01 | kanzure: | the reason i ask is because i could imagine attacks about relaying everything |
| 00:08:19 | phantomcircuit: | kanzure, i dont think it does any meaningful blacklisting of peers at all actually |
| 00:08:28 | phantomcircuit: | afaict the DoS system does very little |
| 00:08:33 | phantomcircuit: | which is probably good |
| 00:08:35 | sipa: | #bitcoin-dev |
| 00:08:47 | phantomcircuit: | oh alright |
| 00:29:13 | justanotheruser: | gmaxwell: what means do you address hashrate instability with? |
| 00:51:14 | gmaxwell: | justanotheruser: you don't? if the system is healthy the hashrate should not be very unstable. Factors of 2x don't really harm anything much. |
| 00:51:44 | gmaxwell: | Though one possibility would be to actually have faster adaptation but use a different metric for confirmation than number of blocks. |
| 00:52:11 | gmaxwell: | but ::shrugs:: it's already common for people to have unjustifyable insecure practices wrt confirmation. |
| 00:55:03 | justanotheruser: | gmaxwell: I don't what? |
| 00:55:28 | gmaxwell: | 17:29 < justanotheruser> gmaxwell: what means do you address hashrate instability with? |
| 00:55:51 | justanotheruser: | I don't address hashrate instability? |
| 01:00:29 | jaekwon: | he means, you don't do it. |
| 01:00:45 | jaekwon: | er, no need to do it. i think :) |
| 01:01:35 | gmaxwell: | Right. If your hashrate is unstable you have worse problems than slow blocks. |
| 01:02:27 | gmaxwell: | I think its not worth improving usibility of a system not enough people care about if the expense is harming security in the case people actually do care. |
| 01:02:39 | justanotheruser: | ohh, the question mark confused me. |
| 01:06:16 | jaekwon: | i wonder, in a state of world war, or less worse, the major intercontinental fibers might become disconnected… but i suppose there's still radio & satellites. |
| 01:06:42 | gmaxwell: | jaekwon: I think a libswift parallel transport would be interesting, but it doesn't solve the interesting problems for block relay, as they're mostly latency mediated... also attack resistance is important. But it would be neat to see more parallel protocols regardless. |
| 01:07:22 | gmaxwell: | I've sketched out some of the interesting things that could be done by a protocol that was savvy of bitcoin internals: https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding |
| 01:07:53 | jaekwon: | ah cool |
| 01:08:18 | gmaxwell: | jaekwon: yea, in theory bitcoin over HF should work fine, I wasn't able to find anyone to help try it out back in 2011 when I had a reasonable antenna farm. |
| 01:08:46 | jcorgan: | gmaxwell: didn't you identify some fountain code like protocol that didn't run afoul of patents? |
| 01:09:12 | gmaxwell: | Yes, LDPC block codes. |
| 01:09:33 | jcorgan: | heh, the very next sentence :) |
| 01:09:34 | gmaxwell: | they aren't infinite rate, but they'd be fine for this. |
| 01:11:03 | gmaxwell: | it may also be pretty easy to avoid the raptor code patents, but I've not looked into it. |
| 01:11:34 | gmaxwell: | I'm generally fond of fountain codes because the encoder implementation is so trivial. |
| 01:12:03 | jcorgan: | hmm, it might be fun to play with that LDPC codec you reference on top of our packet stuff in GNU Radio |
| 01:13:05 | gmaxwell: | it's mostly targeted around an packet-erasure channel, for radio use you'd probably want to still have a lower level code right at the modem level. |
| 01:13:53 | jcorgan: | yes, of course |
| 01:14:09 | jcorgan: | but as a concatenated FEC "top" half |
| 01:14:19 | gmaxwell: | Right. |
| 01:14:58 | gmaxwell: | It would probably be pretty awesome for implementing a reliable multicast in a mesh network. E.g. where you don't know in advance which nodes can hear which nodes this instant. |
| 01:20:06 | jcorgan: | i was nerd sniped by fountain codes a year or so ago, but never got the time to pursue much experimentation. |
| 01:41:56 | justanotheruser: | Why or why not would Kademlia be a good network topology for bitcoin? |
| 01:42:03 | justanotheruser: | Sorry if this belongs in -dev |
| 01:44:00 | gmaxwell: | it absolutely does not belong in -dev |
| 01:46:42 | gmaxwell: | you can basically take virtually all work connected with distributed hash tables and drop it in the trash, short of the work doen by CJD or freenet virtually none of it has a shred of attack resistance. They also address a differenet problem that a consensus system has— they provide random access, when we want people to access the same data (consensus system, after all) |
| 01:47:48 | gmaxwell: | (and CJD and freenet only gain a measure of security by requiring that the users have a social graph, and that the social graph obeys certian properties) |
| 01:49:08 | gmaxwell: | If you do have a social graph, you can just apply it to the bitcoin flooding network— addnode your friends and don't accept txn or mine unless some threshold of them are up, with very low complexity. .. since in a broadcast network you don't need routing. |
| 01:50:43 | [nsh]: | [nsh] has left #bitcoin-wizards |
| 01:54:11 | justanotheruser: | gmaxwell: is bitcoins network topology still the best when you want a public broadcast channel, but don't need consensus (eg. bitmessage) |
| 01:56:01 | justanotheruser: | Sorry if this belongs in #bitcoin then :P |
| 01:57:06 | gmaxwell: | It's an attack resistant broadcast channel that doesn't require preexisting trust. I know of no better, and a _lot_ worse. Bitmessage may not require cosnesus but if you can partition the network you can deanonymize people. |
| 01:58:01 | gmaxwell: | though without reencryption mixes or the like bitmessage is probably paper thin against a true network attacker. |
| 01:58:12 | justanotheruser: | gmaxwell: well partitioning the network isn't trivial is it? |
| 01:58:51 | justanotheruser: | also, is bitcoins network topology the first of it's kind? |
| 01:58:53 | gmaxwell: | it's trivial for someone who controls the network. It's also trivial in some topologies for random sybil attackers, though not bitcoin's. |
| 01:58:56 | justanotheruser: | Is there a name for it? |
| 01:59:19 | gmaxwell: | it's just a randomly wired flooding network. Most people are not interested in flooding. |
| 02:00:13 | gmaxwell: | Bitmessage theoretically provides perfect secrecy for recivers (well not, because their broken design requires recievers to transmit to announce their pubkeys), but the privacy for sending is very poor in it. |
| 02:00:15 | justanotheruser: | were there any common programs that used flooding before bitcoin? |
| 02:01:09 | gmaxwell: | no. Sometimes some messages (e.g. routing) are flooded in other protocols... usually flooding means an instant dos attack, but POW and transaction fees prevent that. |
| 02:01:27 | gmaxwell: | (or at least limit it) |
| 02:02:15 | justanotheruser: | that makes sense. So there pretty much couldn't have been any secure p2p networks that used flooding before hashcash and I'm guessing even those would have been easy to attack with GPUs. |
| 02:03:19 | jcorgan: | gmaxwell: there is also the fact that each node does extensive analysis on received items before relaying, which tends to limit the propagation of "bad stuff" |
| 02:03:23 | gmaxwell: | maybe, I mean, whats the benefit in attacking? |
| 02:03:50 | justanotheruser: | I guess that leads me to another question. Is a "stake token" scheme in a decentralized program using flooding scalable? It seems like organizing all those stake tokens would be a nightmare. |
| 02:04:02 | gmaxwell: | the protection only needs to be strong enough to make attacking unattractive. |
| 02:04:15 | gmaxwell: | justanotheruser: well thats what we use to prevent flooding of transactions. |
| 02:04:21 | gmaxwell: | Spendable coins are 'stake tokens'. |
| 02:05:08 | gmaxwell: | and pow and tx fees are 'resource expendature' |
| 02:05:09 | justanotheruser: | gmaxwell: I mean without making unnecessary transactions. You could make a tx every time, but that would just add more data every fullnode would have to hold forever. |
| 02:07:44 | gmaxwell: | huh? I can't follow what you're thinking. |
| 02:08:09 | gmaxwell: | Nowhere did I suggest that you had to, I'm just pointing out that we're able to use these things to apparently good effect. |
| 02:08:21 | gmaxwell: | This doesn't imply that other ways of using these things can't be done. |
| 02:08:27 | justanotheruser: | gmaxwell: Oh, i see |
| 02:08:53 | justanotheruser: | I just see making a tx for your PoS as bad a using OP_RETURN for your proof of burn |
| 02:09:21 | gmaxwell: | yea so? don't do silly things. |
| 02:09:24 | justanotheruser: | unless you are using the PoS to broadcast a monetary transaction that full nodes are running to process |
| 02:09:42 | gmaxwell: | if you don't need a consensus all you need is anti-replay. |
| 02:09:55 | gmaxwell: | so that someone can't just infinitely reuse the same resource. |
| 02:10:11 | justanotheruser: | yeah, and that seems like it would be difficult. |
| 02:10:17 | gmaxwell: | so you make a freeking hash table of already used resources. this doesn't reuqire a lot of thought. |
| 02:10:18 | justanotheruser: | or atleast expensive |
| 02:11:21 | justanotheruser: | sorry. This isn't as intuitive to me as it is to you. |
| 02:11:24 | gmaxwell: | how is it expensive? some resource can be used once per unit time, you remember 16 bytes or whatever to identify its reuse. |
| 02:11:30 | gmaxwell: | drop repeats. |
| 02:11:55 | gmaxwell: | if you can't handle storing 16 bytes per message for some finite time then your resource wasn't limited enough. |
| 02:12:20 | gmaxwell: | the storage could even be probablistic, since it doesn't need to be consistent. |
| 02:12:23 | justanotheruser: | hmm... that does seem simple. Are there any ways this is vulnerable? |
| 02:14:25 | gmaxwell: | it can be parameterized in ways that make it vulnerable. |
| 02:14:38 | gmaxwell: | (by not making the resource scarce enough) |
| 02:14:45 | justanotheruser: | Makes sense. |
| 02:15:08 | gmaxwell: | or implemented in a way that makes it vulnerable, e.g. by using a probablistic filter and banning peers that give you things you don't like. |
| 02:15:22 | gmaxwell: | (and thus banning good peers who's filters were just too leaky) |
| 03:49:57 | sendak.freenode.net: | topic is: This channel is not about Bitcoin today | "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi." |
| 03:49:57 | sendak.freenode.net: | Users on #bitcoin-wizards: andytoshi-logbot eristisk george_p TheSeven Vitalik MoALTz hearn SoftwareMechanic jgarzik shesek [nsh] justusranvier nikitab Dizzle samson_ shinybro_ zenojis c0rw1n justanotheruser cajg edulix quickcoin gavinandresen jaekwon spinza nanotube Luke-Jr dansmith_btc roconnor p15 realazthat dsnrk posita Quanttek melvster HM ryan-c tromp lianj emsid tempnick1371711 ebfull justanotheruser1 FRCJoe maaku waxwing [Derek] [Tristan] lnovy Kretchfoop |
| 03:49:57 | sendak.freenode.net: | Users on #bitcoin-wizards: DoctorBTC john2 Emcy Logicwax helo a5m0 eizh digitalmagus nickler Krellan mr_burdell davidlatapie Sangheili mappum dgenr8 jchp espes__ prepost dexX7 tacotime go1111111 alferz tromp_ Hunger- stonecoldpat LarsLarsen qwertyoruiop bobke nsh pajarillo burcin ewust Eliel pigeons Cory jcorgan d34th wumpus ageis forrestv asoltys crescendo coyo Alanius sipa gmaxwell Anduck K1773R Dyaheon- kanzure jaromil zibbo hno mmozeiko Mikalv kiddouk michagogo |
| 03:49:57 | sendak.freenode.net: | Users on #bitcoin-wizards: amiller stephenreed so kinlo Graet artifexd stqism gribble mumu warren harrow Fistful_of_Coins coryfields [\\\] flammit weex EasyAt BlueMatt poggy rs0 phantomcircuit quackgyver lenticulis mhanne lechuga_ petertodd Apocalyptic heakins roasbeef comboy LaptopZZ_ keus midnightmagic @ChanServ epscy iddo copumpkin sl01 BCB Muis UukGoblin optimator otoburb |
| 10:00:14 | kdomanski__: | kdomanski__ is now known as kdomanski |
| 12:29:58 | fanquake: | fanquake has left #bitcoin-wizards |
| 13:12:58 | jgarzik: | jgarzik is now known as home_jg |
| 17:56:03 | wallet421: | wallet421 is now known as wallet42 |
| 17:58:04 | kanzure: | from pmetzger's cryptography mailing list: "We can achieve a robust notary infrastructure that is proof against defection for considerably less money. Let there be 32 independent notary log maintainers who maintain a Harber-Stornetta style hash chain log (i.e. what is used in Certificate Transparency). Each notary has very limited defection opportunities and any defection would be quickly noticed." |
| 17:58:12 | kanzure: | trivially vulnerable to sybil and collusion? |
| 18:04:35 | gmaxwell: | kanzure: Works fine if the notarys are fixed as system parameters (prevents sybil) and if you assume they won't collude. |
| 18:05:41 | gmaxwell: | What was Perry comparing to? (the 'less money')? |
| 18:06:22 | gmaxwell: | E.g. if you were going to compare to the CA infrastructure then the '32 independent notary log maintainers' would be a step forward. |
| 18:07:27 | gmaxwell: | since 32 system parameters all-of-which-must-be-compromised is way better than 500 any-of-which-must. |
| 18:07:33 | Apocalyptic: | definitely |
| 18:08:05 | gmaxwell: | * gmaxwell looks for the post |
| 18:08:44 | gmaxwell: | oh the nist stuff. |
| 18:09:29 | gmaxwell: | ah that wasn't a pmetzger post. |
| 18:38:37 | coke0: | just read up on crypto note, why is bytecoin so completely obscure compared to the likes of darkcoin which don't seem to have serious features? |
| 18:41:38 | tacotime: | coke0, well, it has a lot more privacy. |
| 18:41:56 | tacotime: | mandatory stealth addressing and denomination, and input obfuscation from ring signature use. |
| 18:42:41 | tacotime: | and ring signature double-spending prevention from the use of keyimages derived from private keys. |
| 18:43:08 | coke0: | dark does? |
| 18:43:14 | tacotime: | haha, no. |
| 18:43:20 | coke0: | I thought it was only using miners as mixers? |
| 18:43:22 | coke0: | ah right |
| 18:43:25 | tacotime: | cryptonote does |
| 18:43:29 | coke0: | so the puzzle remains |
| 18:43:30 | tacotime: | eg monero, bytecoin |
| 18:43:34 | coke0: | yeah |
| 18:43:52 | tacotime: | drk has rotating centralized coinjoin nodes |
| 18:43:52 | coke0: | why are people even talking about darkcoin? |
| 18:44:26 | coke0: | ring signatures seem vastly superior |
| 18:45:10 | tacotime: | no clue, but cryptonote is the first thing that's caught my attention in terms of privacy in a while. after seeing it implemented it seems like a fairly obvious use of ring signatures for privacy too, it's kind of neat. |
| 18:46:14 | coke0: | and crypto is more mature than snarks or other zkp |
| 18:46:34 | tacotime: | yeah, ring signature schemes have been around for a while. |
| 18:46:51 | coke0: | have the core devs expressed any intent in implementing in? seems like a soft fork |
| 18:47:28 | tacotime: | it's more of a hard fork afaik, unless you're using suprablockchain data like mastercoin/counterparty. |
| 18:47:37 | sipa: | you'd need new opcodes in the scripting language |
| 18:47:46 | tacotime: | it's using a different signature scheme than bitcoin. |
| 18:47:47 | tacotime: | yeah |
| 18:47:51 | sipa: | which is technically doable with a softfork, by using an op_eval like structure |
| 18:48:41 | gmaxwell: | It's softfork-able, though there are scaling implications, it's unprunable. (all strong privacy systems have this issue) |
| 18:48:47 | gmaxwell: | it's easy to implement, at least. |
| 18:48:54 | tacotime: | yeah. |
| 18:49:27 | tacotime: | cryptonote prevents dust from accumulating in the blockchain by adding mandatory large fees to dust outputs, too. |
| 18:50:12 | tacotime: | or, well, the wallet adds them, i should look and see if there after dust rules in the consensus code. |
| 18:50:34 | tacotime: | (the fee code it came with is pretty weird) |
| 18:50:41 | gmaxwell: | tacotime: yea, thats kinda lame however— fees are free to miners, and 'large' depends on external-to-the-system econimcs. |
| 18:51:22 | tacotime: | yeah, we're still trying to figure out how to retool fees in monero, it doesn't even do per-kb fees atm. |
| 18:52:22 | tacotime: | but i mean -- we don't even have a db implementation, first things first i guess. but cryptonote is still a neat proof of concept i think. |
| 18:52:32 | gmaxwell: | I think I pissed off smooth because I commented negatively on monero apparently discussing hard fork protocol changes in secret. |
| 18:52:57 | tacotime: | hard fork protocol changes to monero? |
| 18:53:42 | gmaxwell: | smooth said that the broken block size control was being worked on, I asked where the discussion was... he said in secret and cited the extreme altcoin competition. |
| 18:54:16 | tacotime: | oh, yeah, he was in favour of me not speaking about it in public, but someone started attacking the chain and i kind of had to. |
| 18:54:34 | gmaxwell: | ah, I wasn't aware there was an attack. |
| 18:54:42 | gmaxwell: | (I was just aware that the design was broken) |
| 18:54:51 | gmaxwell: | It sounded like he thought I was attacking it, doofus. |
| 18:55:08 | tacotime: | someone has been attacking the quazarcoin chain for a long time. http://qcn.cryptostats.org/charts/reward |
| 18:55:17 | tacotime: | not sure why they didn't update their code. |
| 18:55:37 | coke0: | what's the block size control problem? |
| 18:56:12 | tacotime: | coke0, https://bitcointalk.org/index.php?topic=583449.msg6963085#msg6963085 |
| 18:56:47 | gmaxwell: | coke0: the bytecoin-things have no blocksize limit really, just a median operation over the prior blocks and a requirement if you build a block greater than some threshold over the median that you burn fees. |
| 18:56:57 | gmaxwell: | I wasn't aware of the mining logic bug. |
| 18:57:37 | gmaxwell: | But the whole thing is broken in the long run, since it's perfectly possible to pay fees out of band (e.g. just give each miner a mutant of the transaction with an output to them), and then there is no limit at all. |
| 18:57:44 | coke0: | is the attack to drive miners out of the market by forcing a lot of tx? |
| 18:57:45 | gmaxwell: | makes it pretty easy to bloat the crap out of it. |
| 18:58:08 | tacotime: | mutant of the tx? |
| 18:58:30 | tacotime: | coke0, yeah, attack is to just spam the chain until reward dies |
| 18:58:44 | coke0: | I see |
| 18:58:49 | tacotime: | i wanted to hardfork to a max block size of 200 kb instead of the weird penalty thing |
| 18:58:59 | gmaxwell: | yea, I'd advise that. |
| 18:59:07 | coke0: | well better mining code would just solve that no? |
| 18:59:22 | coke0: | just maximize reward+fee? |
| 18:59:24 | gmaxwell: | it would solve that short term attack, it wouldn't solve the design being wrongheaded. |
| 18:59:39 | coke0: | why is it wrongheaded? |
| 19:00:23 | gmaxwell: | coke0: I explained above. In the long run (e.g. once subsidy is low, which isn't that long in monero) miners have no limit. You could give them free txn and pay them not via fees but via outputs. |
| 19:01:11 | gmaxwell: | so miners wouldn't have to give up anything to build blocks over the median, the weird quadratic penality thing is just complexity for no solid benefit. |
| 19:01:17 | coke0: | so you can pay a miner to make a giant block and that spams the system |
| 19:01:23 | coke0: | I see |
| 19:01:36 | tacotime: | yeah i'll propose it as the 4th improvement proposal i guess. |
| 19:01:38 | gmaxwell: | not just spams up the system, but also drives other validators and miners out of business potentially. |
| 19:01:57 | coke0: | yeah the trick would be to make the miner receive a fixed amount |
| 19:02:14 | coke0: | and then *pay* depending on block size |
| 19:02:38 | tacotime: | 2nd is to max coinbase maturity to 24 h instead of 1 h, 3rd is to fix reward when inflation hits ~1% per annum to try to avoid a dogecoin like "our reward is too low to secure the blockchain" problem. |
| 19:02:47 | coke0: | so reward = C - exp( b. Size ) |
| 19:03:08 | gmaxwell: | maybe the security model is to 'trust miners' to not bloat the system to death... I dunno how you pay for mining in the long term... but if so, simpler to just do the median thing without the penality. |
| 19:03:17 | coke0: | tacotime: that's a generic problem with pow |
| 19:03:45 | coke0: | you need constant wasteful inflation, tx fees can drop arbitrarily low |
| 19:03:52 | gmaxwell: | I don't agree. I mean, it's just a problem if all the value is speculation rather than use. |
| 19:04:12 | tacotime: | i didn't design monero so mostly i just have to deal with the ramifications of weird-ass design decisions. |
| 19:04:14 | coke0: | no |
| 19:04:36 | gmaxwell: | coke0: bad incentives. basically you have people who are conserving network resources by not transacting unnecessarily subsidizing people who use them, if you have non-trivial inflation. |
| 19:04:45 | tacotime: | Well, I prefer that there is a small but significant redistribution of wealth based on mining that is not just fees. But that's an economic thing. |
| 19:05:02 | coke0: | it's not going to be small if the economy is large |
| 19:05:08 | gmaxwell: | it's not just economic, its incentives. |
| 19:05:16 | coke0: | basically waste = O( market cap) |
| 19:05:41 | gmaxwell: | (not that some small amount of inflation might not be bad, but I know of no way to promise that it's small other than making it zero) |
| 19:06:22 | gmaxwell: | doubly so in a ring signature system since you don't have any idea what the size of the active pool of money is. |
| 19:06:54 | tacotime: | i'm not sure i totally follow the incentives issue. are you saying that you enforce transacting on-chain when there is no block reward? |
| 19:07:52 | coke0: | yeah you can't enforce on chain transactions |
| 19:07:58 | gmaxwell: | tacotime: I'm saying that when inflation pays for security instead of fees you can look at it as people who are conservative with their tx volume being taxed to subsidize those who aren't. |
| 19:08:09 | coke0: | sure so say 10% inflation |
| 19:08:34 | gmaxwell: | coke0: you can't just make a parameter in the system that is x% inflation, since you don't know what the real currency supply is. |
| 19:08:56 | coke0: | it means the cost of attacking for a day |
| 19:09:01 | gmaxwell: | e.g. 10m coins may exist, but really 5m are lost. You think you asked for 10% but you really got 20%. |
| 19:09:07 | coke0: | is 1/7300 of the money supply |
| 19:09:42 | gmaxwell: | coke0: I'm not following you. |
| 19:10:22 | coke0: | 1/7660 actually |
| 19:10:30 | coke0: | OK say you have 10% inflation |
| 19:10:45 | tacotime: | gmaxwell, i guess i don't see that as a bad thing, as long as there is assurance of security. |
| 19:10:50 | coke0: | now look at the mining reward that gets you over one day |
| 19:10:54 | coke0: | divide by 2 |
| 19:11:08 | coke0: | that gives you the cost of a 51% |
| 19:11:13 | gmaxwell: | tacotime: perhaps, but there isn't any way to control the amount of inflation. |
| 19:11:20 | coke0: | now you might say, it's about the hardware |
| 19:11:50 | coke0: | so say mining hardware returns 5% on investment a year |
| 19:11:56 | gmaxwell: | tacotime: and too much of it would be certantly awful. |
| 19:12:39 | coke0: | a rig may cost about 20 years of reward |
| 19:12:57 | tacotime: | gmaxwell, well, i suppose, but i guess if you set it low enough i think it'll still be lucrative in comparison to the capriciousness of fiat. |
| 19:13:14 | coke0: | hum so with 10% inflation, 51% costs in hardware the market cap |
| 19:13:18 | coke0: | that's not too bad |
| 19:13:42 | coke0: | but holy shit, the waste |
| 19:13:58 | gmaxwell: | tacotime: I don't think there is any amount that is guarenteed to be safe. :( It's a gamble with what the actual unmeasurable money supply in the future is. :( |
| 19:17:25 | tacotime: | well, i suppose you could demurrage --> mining reward too. but i feel like that'd be a difficult thing to get people to agree on too. |
| 19:17:49 | tacotime: | is that even any more ideal? |
| 19:17:59 | gmaxwell: | tacotime: it's basically the same economically. |
| 19:18:09 | tacotime: | yeah. |
| 19:18:14 | gmaxwell: | Also a lot messier in terms of implementation for accounting/applications. |
| 19:18:29 | tacotime: | right :) |
| 19:19:26 | tacotime: | i just still really worry as to whether or not fees will be sufficient in the long run to secure the blockchain. |
| 19:20:00 | tacotime: | i guess transaction volume is public, you could try estimate the total money supply based on transaction volume of the last year. |
| 19:20:40 | maaku: | absolutely not the same thing but you can debate that on #freicoin if you will |
| 19:21:05 | maaku: | (only the same thing under spherical cow assumptions) |
| 19:21:06 | tacotime: | ...could be catastrophic if someone like satoshi suddenly decided to dump, though. |
| 19:23:16 | maaku: | tacotime: freicoin was one of the first alts, maybe only namecoin is older, conceptually. but we delayed launch for 1.5 years because we were trying to solve that problem -- estimating velocity and interest rates from block chain data |
| 19:23:39 | maaku: | ultimately I became personally convinced that it is not possible, although a mathmatical proof of such still eludes me |
| 19:23:46 | tacotime: | maaku, what were your conclusions? do you have data somewhere? |
| 19:24:50 | maaku: | it's spread all over the freicoin forums in the "Initial Proposals" section, and irc logs |
| 19:25:06 | FRCJoe: | there's lot of good reading over there ;) |
| 19:25:12 | tacotime: | okay, i'll check it out. |
| 19:25:46 | maaku: | we tried all sorts of stuff from simplying looking at transaction data (easily faked), to fidelity bonds backing an interest rate market (sorta like synthetic assets, and similarly vulnerable to manipulation by whales) |
| 19:27:03 | tacotime: | right, makes sense. |
| 19:27:31 | maaku: | i have very analagous feelings as I do about proof of stake - for each objection it is easy to come up with a "fix" that counters the objection but opens up some other hole |
| 19:28:18 | maaku: | as I said, it was a rabbit hole we wasted 1.5 years on before throwing in the towel (frc's demurrage rate is fixed), although without the satisfaction of a neat proof of impossibility |
| 19:29:14 | tacotime: | ah, another problem for me to go insane looking at. :p hmm. |
| 19:33:31 | coke0: | velocity is ill defined to begin with |
| 19:34:13 | coke0: | you can't get anything meaningful from transaction activity when so much can be meaningless back and forth or so much can happen off chain |
| 19:34:58 | coke0: | what you *can* do with a blockchain is put a cap on the whole interest rate curve |
| 19:35:11 | gmaxwell: | maaku: beertoken and weeds were both older than namecoin. :P |
| 19:35:18 | coke0: | by allowing coins to be converted into coupon paying bonds |
| 19:36:16 | coke0: | ur, I mean a floor |
| 19:37:31 | gmaxwell: | I think if we had timelock encryption and a way to make mining jamming proof you could achieve controlled interest by having the system perform a bond auction. |
| 19:37:48 | home_jg: | home_jg is now known as jgarzik |
| 19:38:01 | coke0: | no need to make it an auction, make it a normal transaction |
| 19:38:05 | gmaxwell: | e.g. you don't fix the interest rate, you fix the bond duration, and let people bid against each other for interest rates to lock up coins. |
| 19:38:24 | gmaxwell: | coke0: it needs to be an auction if you want to guarentee that the system doesn't get too far out of wack. |
| 19:38:44 | coke0: | you know you can make perpetuities with fixed duration? |
| 19:39:02 | coke0: | with a geometrically decreasing coupon rate |
| 19:39:27 | coke0: | very elegant, would solve a lot of liquidity issues in the treasury market |
| 19:39:41 | gmaxwell: | I don't see how that helps with acheving controlled inflation in a cryptocurrency, however. |
| 19:39:58 | coke0: | not inflation |
| 19:40:08 | coke0: | it controls the interest rate curve |
| 19:40:22 | gmaxwell: | right, so I was taking about something somewhat different. |
| 19:40:29 | coke0: | if you start out with enough of these bonds in the market |
| 19:40:48 | coke0: | and they have a fixed exchange rate to the main coin |
| 19:41:03 | coke0: | you get a fixed interest rate curve |
| 19:41:33 | coke0: | of course you can run into runaway inflation |
| 19:41:49 | coke0: | and you will unless your curve is flat |
| 19:43:17 | coke0: | why would you want controlled inflation to begin with? |
| 19:49:27 | maaku: | gmaxwell: we looked at that (i mentioned it above) - the problem is that like a synthetic asset, a whale could set the interest rate to whatever he wants , presumably to profit off derivatives |
| 19:50:32 | maaku: | it would help achieve controlled inflation if your goal was 0% real interest rates, as freicoin's is, then having a bond market to establish actual basic interest rates is useul |
| 19:51:23 | coke0: | you mean nominal |
| 19:51:33 | coke0: | real interest rate isn't going to be 0 |
| 19:53:38 | maaku: | yes sorry |
| 19:53:55 | coke0: | in general manipulation of the money supply to affect credit markets is a bad idea. Some nominal inflation for psychological reasons may be valuable, but beyond that it's unlikely to do what you want it to do |
| 19:54:16 | maaku: | coke0: i'd be happy to debate that on #freicoin |
| 19:54:39 | coke0: | maybe some other time, I should be working but gladly :p |
| 20:39:00 | sl01: | petertodd: so did maidsafe lure you in to their blackmagic with their 6 million $ ? |
| 20:39:43 | Apocalyptic: | * Apocalyptic grabs some popcorn |
| 20:41:03 | justanotheruser: | sl01: is he their cheif scientist now or something? |
| 20:42:20 | sl01: | justanotheruser: no he said he was meeting with them like a week ago... |
| 20:42:55 | sl01: | i assume they offered to shower him with money |
| 20:45:01 | Apocalyptic: | hard to refuse such an offer I guess |
| 20:46:12 | sl01: | i'm just hoping he vetted them somewhat and can share |
| 20:47:45 | gmaxwell: | petertodd has been meeting with * lately, thus so quiet here. |
| 20:47:50 | gmaxwell: | I wouldn't suggest reading anything into it. |
| 20:48:19 | petertodd: | I'll meet with anyone who pays my flights/time and is located in an area which is unlikely to get me killed |
| 20:48:25 | petertodd: | speaking of, literally just got back |
| 20:49:15 | petertodd: | gmaxwell: I wound up visiting six counties and giving something like four or five interviews |
| 20:51:54 | sl01: | petertodd: so no technical insight on maidsafe was gained that you can share? |
| 20:53:01 | petertodd: | sl01: gained plenty of insight; will do a writeup in the next few days |
| 20:53:16 | sl01: | sweet you're awesome |
| 21:00:22 | Anduck: | Anduck is now known as [nicks] |
| 21:00:29 | [nicks]: | [nicks] is now known as Anduck |
| 21:09:56 | jgarzik: | petertodd, the MK/RT was cute. He's so excitable. |
| 21:15:09 | petertodd: | jgarzik: yeah, and I think it's hilarious that some people thought I was the most boring guy they've interviewed |
| 21:15:20 | diesel_: | diesel_ is now known as Dizzle |
| 21:19:38 | jgarzik: | gmaxwell, heh, Chief Scientist of * |
| 21:21:28 | petertodd: | jgarzik: Finance 2.0 Checklist: Step 1: Hire Peter Todd as Chief {Scientist|Architect|Naysayer} |
| 21:24:13 | jgarzik: | hehehe |
| 21:28:33 | petertodd: | speaking of, remember that just because I'm giving advice to a project doesn't mean I think they have a chance in hell of suceeding - even prior to Bitcoin almost every job I've had has been a startup, and nearly every single one has failed; any sane investor would steer clear of anything I consider interesting and exciting enough to want to work at /end public notice |
| 21:30:31 | sipa: | well, "interesting" and "profitable" are hardly correlated |
| 21:31:00 | petertodd: | sipa: indeed, and "sane" investors rarely make it big :) |
| 21:32:06 | sipa: | you have to aim for the stars |
| 21:32:07 | petertodd: | there's gotta be a bias in the investing markets - particularly venture capital type stuff - for interesting over actually profitable |
| 21:32:12 | sipa: | (and likely fail) |
| 21:33:06 | Eliel: | people are dreamers. It's easy to grab more than you can chew. |
| 21:35:34 | sipa: | i believe most "sane" investors are very aware of the fact that their endeavours are very high risk |
| 21:44:37 | sipa: | wow. |
| 21:45:17 | sipa: | a perl script i wrote years ago to create udf volumes that are cross-os usable (using a very nifty partition table hack!), was put on github by someone |
| 21:45:54 | sipa: | someone else actually filed an issue, saying that he should credit the original author |
| 21:53:52 | tacotime: | gmaxwell: What are your thoughts about removing penalty for blocksize but allowing the network to only accept blocks at 2*median size, and capping median size at 100 kb (--> max block size 200kb)? I figured that maybe this would enable the network to progressively increase the blocksize. |
| 21:55:02 | tacotime: | I wasn't sure if there's any benefit to it, though. |
| 21:56:13 | tacotime: | Aside from maybe preventing sudden spam attacks of 200 kb blocks (but I really need to fix the fees code to prevent that). |
| 21:56:51 | sipa: | it would mean miners can game the rules |
| 21:57:06 | sipa: | by artificially adding transactions to increase the median |
| 21:57:48 | tacotime: | Yeah. I'm not sure there's really any benefit at all to adaptive block sizing. |
| 21:58:32 | coke0: | tacotime, why not charge miners a linear fee for block size? |
| 21:58:33 | sipa: | so, imho, you can divide the network (of full nodes) into two groups |
| 21:58:55 | sipa: | miners and users (and some people may be both) |
| 21:59:06 | sipa: | the first have an incentive to get as much subsidy and fee as possible |
| 21:59:15 | sipa: | the second have an incentive to keep the system usable |
| 22:00:02 | sipa: | the second group is the one that sets they rules (implictly, by running the software that implements it, and assigning value to the tokens represented by it) |
| 22:00:15 | phantomcircuit: | [20:47:45] petertodd has been meeting with * lately, thus so quiet here. |
| 22:00:22 | phantomcircuit: | he's been kidnapped by darkcoin supporters |
| 22:00:28 | sipa: | the first group is in fact a client to the second: they try to produce blocks that satisfy the requirements set by the users |
| 22:01:07 | sipa: | the block limit is what keeps the set of users intact |
| 22:02:03 | sipa: | if you see it as voting (which is wrong, there is no majority or anything relevant here, only economic weight), running software that allows the block size to grow beyond what you yourself are able to cheaply enough validate, is voting yourself out of the electorate |
| 22:02:40 | sipa: | bottom line: the block size limit should be exactly what users (full nodes, with an incentive to validate that nobody is cheating) are willing to accept |
| 22:02:59 | sipa: | and i don't think miners should have any privileged position in setting that value |
| 22:03:14 | tacotime: | okay. |
| 22:03:29 | sipa: | wow |
| 22:03:42 | sipa: | i'm repeating a argument i've tried many times over, while half drunk |
| 22:03:43 | gmaxwell: | tacotime: I would strongly suggest against making it a median of actual sizes, if you want to give miners explicit control over the size you should just let them express the limit they want. But as sipa is pointing out, its far from clear that letting miners control the size is good. |
| 22:04:52 | gmaxwell: | Since a majority of miners can always force the size smaller (by orphaning blocks) perhaps it is prudent to have an explicit mechenism to coordinate that... but that alone doesn't prevent bad outcome like miners driving non-miners out of the business of validating. |
| 22:04:52 | tacotime: | sipa, it's okay, sorry to have you have to repeat it. |
| 22:05:52 | gmaxwell: | (the reason I suggest against actual sizes is that it just encourages inefficient gamesmanship.— they can stuff transactions into blocks, do bother making them do so) |
| 22:06:27 | tacotime: | Right, that makes sense. Yeah, I had figured the same thing when thinking about it recently, they control the contents, so... |
| 22:08:26 | gmaxwell: | Petertodd and jdillion had an interesting POS-ish notion but might be too complex to be worth implementing. |
| 22:09:13 | tacotime: | There a reference on the forum or somewhere? |
| 22:11:01 | gmaxwell: | It went (after some refineminet) something like: take the transactions in the last block, pick one pubkey from it based on the hash of the prior block and coins days destroyed, that pubkey is permitted to produce a signature over the last block header that indicates that they think the blocksize should increase. Note that you can't force them to produce the message before putting their tx in the block, since must sign the header. |
| 22:11:16 | gmaxwell: | harder to do coins-days-destroyed in an anonymous coin though! :) |
| 22:12:14 | tacotime: | right, haha. |
| 22:13:20 | gmaxwell: | in any case, since the 'votes' can only go in the miners interest (assumiming the miners are just trying to bloat and not DOS) there is no way they can really gain advantage via censoring, short of demanding people turn over their private keys to get txn included. |
| 22:14:37 | gmaxwell: | ultimately that may be futile though in that the 'stake' parties might too happily hand control over the coin to a single entity, — just because you have a lot of coin at the moment doesn't mean you're not shortsighted. |
| 22:14:45 | tacotime: | well, i guess, unless the voters demand smaller blocks. |
| 22:14:48 | tacotime: | yeah. |
| 22:15:44 | gmaxwell: | well the notion is that it would fall absent the votes (towards a baseline, e.g. 90% of some windowed median, with some threshold) |
| 22:16:47 | tacotime: | ah, i see. and i guess, collusion could be an issue here too, if the miners and the large holders interact prior to the miner mining blocks. |
| 22:17:10 | gmaxwell: | Right, collusion can't be directly guarenteed in this case, however. |
| 22:17:21 | gmaxwell: | E.g. I can't give you my vote in advance. |
| 22:17:26 | tacotime: | yeah, true. |
| 22:17:32 | gmaxwell: | I can't delegate my vote without risking you stealing my coins. |
| 22:18:35 | gmaxwell: | but the miner could still attack, e.g. require people to make a deposit to get their txn mined and refuse to return it unless they vote. |
| 22:19:17 | gmaxwell: | but at that point the users all fork the network and add a hard cap if they really dislike where things are going, at least all that stuff would make the misconduct explicit. |
| 22:19:55 | gmaxwell: | the other problem is that anyone using a hosted wallet is effectively delegating their votes, and alas— hosted wallets may well be aligned with bloating the network into centeralization. |
| 22:20:02 | phantomcircuit: | gmaxwell, this all has to do with regulating the block size? |
| 22:20:25 | gmaxwell: | phantomcircuit: yea, bytecoin&friends do a cute thing that is sadly broken. |
| 22:20:30 | tacotime: | pos seems to complicate everything. :) |
| 22:21:26 | phantomcircuit: | gmaxwell, seems like something you could experiment with by hard forking bitcoin and rebranding |
| 22:21:29 | tacotime: | for some cryptonote thought it was a good idea to make everything adaptive, not sure why exactly. |
| 22:21:35 | phantomcircuit: | (im surprised nobody has done an altcoin that way) |
| 22:21:52 | gmaxwell: | you have to actually have users to care about the blocksize. |
| 22:22:26 | phantomcircuit: | gmaxwell, sure, and forking from bitcoin means you instantly have tons of potential users |
| 22:22:43 | phantomcircuit: | the hard part is getting people to share private keys between the two systems |
| 22:22:49 | phantomcircuit: | (i wouldn't) |
| 22:23:29 | gmaxwell: | tacotime: because they were trying to be smart. Which is good, but their work didn't have enough review. |
| 22:24:03 | gmaxwell: | or maybe they made it trivially vulnerable for fun. |
| 22:24:33 | gmaxwell: | I've certantly joked that if I made an altcoin I'd through in a bunch of bad ideas, because why not? :P |
| 22:25:13 | pigeons: | i knew gmaxwell made cryptonote! |
| 22:25:37 | tacotime: | heh. the block reward and difficulty adjustment algos seem okay so far. |
| 22:26:14 | tacotime: | there's a lot of stuff with mc2 where i get kind of, "hm, not sure that will totally work, but i guess let's try it and see what happens." |
| 22:26:30 | tacotime: | that's kind of the point for an altcoin in my mind, though, as a playground for ideas. |
| 23:22:28 | Luke-Jr: | phantomcircuit: hardforking from Bitcoin doesn't get you users, just a premine with Bitcoin users rewarded |
| 23:37:22 | phantomcircuit: | [23:22:28] phantomcircuit: hardforking from Bitcoin doesn't get you users, just a premine with Bitcoin users rewarded |
| 23:37:59 | phantomcircuit: | that's correct |
| 23:44:13 | phantomcircuit: | nom nom wifi on the plane |