| 00:52:36 | home_jg: | home_jg is now known as jgarzik |
| 01:59:30 | wallet42: | wallet42 is now known as Guest49318 |
| 01:59:30 | wallet421: | wallet421 is now known as wallet42 |
| 02:56:35 | gmaxwell: | There was a puzzle in the MIT mystery hunt that some folks here would like solving. |
| 02:57:07 | gmaxwell: | oh. crud. I guess I can't post it until after the hunt is over, so forget the last line for three days. |
| 03:14:30 | roidster: | roidster is now known as Guest32414 |
| 04:38:44 | jcrubino: | is it possible to have an address that is both a valid litecoin and bitcoin address? |
| 04:50:44 | coryfields: | coryfields is now known as cfields |
| 05:02:08 | Taek42: | gmaxwell what do you do for a living? |
| 05:02:38 | phantomcircuit: | Taek42, he works at mozilla doing stuff and things |
| 05:36:25 | kyrio: | kyrio has left #bitcoin-wizards |
| 07:24:46 | justanotheruser: | jcrubino: no simply because of the fact that litecoins version number starts is L, not 1 |
| 07:38:45 | jcrubino: | justanotheruser: I have a testnet address that passes validation tests by both daemon clients |
| 07:39:40 | justanotheruser: | jcrubino: Hmm. I suppose if both daemons ignore the version it could be valid |
| 07:40:07 | brisque: | justanotheruser: I explained in #bitcoin-dev that you can use the same public keys, just the address reads differently. |
| 07:40:07 | jcrubino: | I chaes my tail in circles while unit testing over that |
| 07:40:13 | justanotheruser: | what character does the testnet address start with |
| 07:40:18 | brisque: | m or n |
| 07:40:28 | brisque: | ;;bc,wiki address prefixes |
| 07:40:29 | gribble: | https://en.bitcoin.it/wiki/List_of_address_prefixes | Dec 25, 2013 ... The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use. |
| 07:40:36 | justanotheruser: | brisque: I meant for litecoin |
| 07:40:44 | brisque: | does litecoin have a testnet? |
| 07:40:52 | jcrubino: | yes |
| 07:41:08 | justanotheruser: | brisque: yes, but I figured it would would be valid for the bitcoin daemon considering the daemon might consider the version number bad |
| 07:42:22 | brisque: | if the testnet prefix is the same it'll work with no problem |
| 07:42:29 | jcrubino: | assumming I change out the address prefix in bitcoind to the litecoin version what else needs to change to make it litecoind ? |
| 07:42:33 | justanotheruser: | jcrubino: ultimately you can have a public key hash that is valid for both bitcoin and litecoin. An address is just a conversion to base 58 with a version number |
| 07:42:48 | brisque: | jcrubino: mainly just the POW system and the logo. |
| 07:43:50 | jcrubino: | does a non mining daemon verify the pow or does it just relay ? |
| 07:45:03 | brisque: | ever node validates the POW of every block |
| 14:00:30 | wallet421: | wallet421 is now known as wallet42 |
| 16:38:30 | roidster: | roidster is now known as Guest57763 |
| 16:59:43 | spin123456: | spin123456 is now known as spinza |
| 18:21:56 | justanotheruser: | If it is possible to have a PoW that only has a maximum of like 5% improvement from CPU to ASIC, is that beneficial? |
| 18:27:11 | nsh: | justanotheruser, in general, no. |
| 18:31:08 | maaku: | justanotheruser: the best you could probably do is several multiples, maybe an order of magnitude |
| 18:46:15 | justanotheruser: | maaku: eh, I disagree. If the hashing function takes up a lot of code and uses many different RISC instructions, then you could use an ASIC, but it would might prohibitively expensive because you have to have so much circuitry to have the hash function implemented. |
| 18:46:27 | justanotheruser: | s/takes up a/uses a |
| 18:48:57 | nsh: | * nsh frowns |
| 19:03:42 | adam3us: | justanotheruser: the hashing function would have to be very dynamically dependent on the instructins, or it can be special cased; even then someone can make the minimal unrolled cpu strip out everything else and put that circuity down redundancy as many times as it will fit. i think inevitably almost, hw wins, by a decent margin |
| 19:06:45 | adam3us: | maybe another direction is a FPGA friendly design, and hope ASIC/FPGA advantage will narrow as a trend. |
| 19:06:51 | justanotheruser: | adam3us: Yeah dynamically dependent instructions would be better. If you made it use all instructions, and it involved storing data in the registers, etc wouldn't the ASICs essentially be effecient CPUs? |
| 19:07:30 | gmaxwell: | why does this pow wanking keep going on here? |
| 19:07:38 | gmaxwell: | I can't imagine a less interesting subject. |
| 19:07:48 | gmaxwell: | Does anyone here even care about it? |
| 19:07:56 | adam3us: | potentially. however its a bit of a weird cpu. it doesnt mind the input being a counter, and 99.99999% of the outputs are thrown away |
| 19:08:47 | justanotheruser: | adam3us: maybe the PoW could require all the outputs. |
| 19:09:00 | justanotheruser: | One problem I see with this is verification taking a long time |
| 19:09:15 | andytoshi: | gmaxwell: +1, guys we had a long long discussion about this yesterday and completely overwhelmed my ability to follow the entire -wizards scrollback |
| 19:09:42 | gmaxwell: | I just don't even understand why it's being discussed, since I don't think anyone here even thinks its actually all that important. |
| 19:10:07 | gmaxwell: | (though maybe my tolerance is limited because I'm only looking in here once/twice a day because I'm busy elsewhere right now) |
| 19:10:24 | justanotheruser: | gmaxwell: It seems one of your altcoin ideas linked in the topic involves a modified PoW |
| 19:10:43 | adam3us: | maybe we need a #bitcoin-pow-wankery ;) |
| 19:11:23 | gmaxwell: | justanotheruser: I specfically avoided this kind of BS on that list. All the 'modified pow' there were achieving some other purpose than architectural overoptimization. |
| 19:11:46 | adam3us: | justanotheruser: many of the alts sole 'hook' (aka fake argument for existence/sales pitch) is a different pow for "decentralization" |
| 19:12:04 | gmaxwell: | I think there is no end to what you can discuss in that space, and the arguements that its a useful tradeoff are very hard to make a clear argument for. |
| 19:12:25 | gmaxwell: | It's just the kind of superficial thing that people can discuss forever. e.g. "random POW generator" |
| 19:12:49 | justanotheruser: | adam3us: I agree it doesn't save electricity or anything like that. People just end up spending money on the hardware instead of the electricity. |
| 19:13:32 | adam3us: | justanotheruser: so at a high level, it would not have to be so slow to verify just because it depends on the dynamic execution of a randomly generated machine code I think |
| 19:13:59 | adam3us: | justanotheruser: seems to me asic-hardness ends up using more electricity typically |
| 19:15:15 | jtimon: | justanotheruser when your ASIC competitors are doing 4% profits, will you mine at -1%? |
| 19:16:20 | justanotheruser: | jtimon: ASICs probably wouldn't give them 4% profits because they would have to buy new hardware |
| 19:16:42 | adam3us: | but its probably more fruitful towards decentralization to try find ways to put diseconomies of scale into the protocol somehow or make bitcoin less vulnerable to 25/33/50% attack, selfish mining and policy/censorship with any level of centralization, then maybe we dont even care |
| 19:16:47 | justanotheruser: | The ops here seem to want us to change the topic though. |
| 19:16:59 | jtimon: | profits = gains after all costs, including capital costs |
| 19:17:52 | justanotheruser: | jtimon: I don't understand why you defined profits. It doesn't really change anything about what I said. |
| 19:18:36 | adam3us: | as i recall no one found a good answer to the 25/33% attack, and ghash is at 34% now coincidentally |
| 19:19:40 | justanotheruser: | adam3us: what's the 25/33% attack? Just them being able do a large reorg some of the time? |
| 19:19:52 | gmaxwell: | it's the argument that pow-wanking for foo-hardness is irrelevant becausing the perfect competition of mining will drive even marginally less efficient out of business. You can debate how much slop there is... but whever you decide it won't be a huge amount. |
| 19:20:41 | maaku: | why does this pow wanking keep going on here? I can't imagine a less interesting subject. <--- thank you :) |
| 19:21:56 | adam3us: | justanotheruser: selfish mining is the result that a pool with over 33% power can gain more than 33% of the wins/reward by intelligently delaying publication of the blocks it wins |
| 19:22:44 | justanotheruser: | adam3us: and with 25% you can do this too? |
| 19:22:45 | c0rw1n: | is there a pool that takes over 33% of the network regularly? |
| 19:22:47 | adam3us: | justanotheruser: the cost is someone might win while it does that, but the advantage is if it gets a length 2 private chain, it has an advantage that no one else knows the chain |
| 19:23:19 | adam3us: | c0rw1n: its been the case lots of the time, even right now ghash has 34% (i though they said publicly they had 40% recently) |
| 19:23:26 | gmaxwell: | it is sort of interesting that ghash has a lot of orphans, people had been assuming its because their hardware has severe latency problems, but that might not be the only issue. |
| 19:24:08 | adam3us: | justanotheruser: with 25% you can still get an advantage presuming you can succeed to race publication of other winners via good connectivity |
| 19:24:18 | jtimon: | gmaxwell are you suggesting that ghash selfmines and that's why it gets more orphans? |
| 19:24:33 | adam3us: | jtimon: its plausible that would be the side effect |
| 19:24:40 | justanotheruser: | adam3us: So what percentage of blocks can you get given you have N% of the network? Is there a formula? |
| 19:24:41 | c0rw1n: | i parsed it as "that, or they're doing something wrong with their connetivity" |
| 19:25:03 | c0rw1n: | justanotheruser yeah there is a formula. in involves the variance |
| 19:25:19 | gmaxwell: | jtimon: someone should crunch the data and see if it supports that theory. |
| 19:25:26 | adam3us: | justanotheruser: they have a graph in their paper, its not fully modeling some real-world effects, but its interesting and should work |
| 19:25:38 | justanotheruser: | link? |
| 19:25:57 | jtimon: | so you could as well call "selfish mining", "block relay time optimization" |
| 19:26:04 | gmaxwell: | I have noticed an increase in depth 2 orphaning, so if so I don't think they're doing it successfully. |
| 19:26:10 | jtimon: | how will that destroy bitcoin? |
| 19:26:17 | justanotheruser: | gmaxwell: Is it possible to determine that? Like would you have to look at their orphans vs their 2-in-a-row blocks? |
| 19:26:34 | adam3us: | justanotheruser: selfish-mining http://arxiv.org/pdf/1311.0243v2.pdf |
| 19:26:37 | justanotheruser: | thanks |
| 19:27:20 | jtimon: | I guess we would need to estimate their real block distribution latency to calculate the time they hold their blocks? |
| 19:27:48 | jtimon: | I don't know, network topology...too hard of a problem for me |
| 19:27:53 | gmaxwell: | justanotheruser: just stats on orphaning at varrious depths for different parties would be suggestive. (e.g. I think you'd get a higher rate of 1-orphan for the selfish miner and a higher rate of >1 orphan for all others than expected) |
| 19:29:24 | justanotheruser: | gmaxwell: So if there is one fork that has 3 orphans and the main chain has 4 GHash blocks in their place, that might suggest this attack is taking place? |
| 19:29:46 | gmaxwell: | Yes. |
| 19:29:49 | c0rw1n: | that may be a symptom if i got it right |
| 19:29:50 | jtimon: | would consecutive blocks for parties be significant? |
| 19:29:59 | gmaxwell: | jtimon: happens naturally. |
| 19:30:13 | jtimon: | I mean, count how many times they mine 2 in a row, 3 in a row, etc |
| 19:30:16 | gmaxwell: | more than you'd expect based on their hashrate would be interesting. |
| 19:30:33 | gmaxwell: | but the data is perhaps too undersampled to say with confidence. |
| 19:30:51 | gmaxwell: | long reorgs are more surprising. |
| 19:31:11 | adam3us: | gmaxwell: its hard to force the point, because they could hide their reward claims (change their reward address, announce via multiple IP#s) |
| 19:31:25 | gmaxwell: | sure though thats detectable for people mining on them. |
| 19:32:09 | adam3us: | gmaxwell: yeah but most users dont know when their home hosted asic wins so they are not auditing, and their individual chance to be the source of the winning block is very low |
| 19:32:58 | gmaxwell: | adam3us: you don't even have to see the winning block, since you can tell if you were working on the same transaction set as a specific wining block (e.g. differs only in extranonce) |
| 19:33:15 | jtimon: | undersampled data? mhmmhm, so maybe coblee's story is not as solid as I thought... ;p https://bitcointalk.org/index.php?topic=143659.0 |
| 19:33:36 | maaku: | hrm.. Luke-Jr it might be nice if bfgminer collected statistics on how often and for how long it sees work based on previous blocks that are not publicly known |
| 19:34:35 | c0rw1n: | *click* that's interesting |
| 19:34:37 | gmaxwell: | maaku: how would it know public? |
| 19:34:50 | c0rw1n: | it could blockchain the mining stats? |
| 19:35:02 | gmaxwell: | "blockchain the mining stats" |
| 19:35:03 | maaku: | gmaxwell: either from local bitcoind or by asking Eliguis |
| 19:35:04 | gmaxwell: | * gmaxwell zot |
| 19:35:14 | sipa: | c0rw1n: i hope you're kidding |
| 19:35:40 | sipa: | * sipa gets his hammer; c0rw1n looks like a nail |
| 19:35:58 | gmaxwell: | maaku: I guess it can poll all configured pools and log when their prevs are different. |
| 19:35:59 | c0rw1n: | 'k i'll shut up if i'm not this smart enough to talk :$ |
| 19:36:40 | gmaxwell: | maaku: It's odd that miners don't equal loadbalance pools almost at all, since that minimizes variance. |
| 19:36:49 | adam3us: | gmaxwell: well they could hide the most recent block by handing different blocks with same parent block (assuming GBT was not used) |
| 19:36:51 | gmaxwell: | but I guess thats because they count on pools for monitoring/stats (doh) |
| 19:37:30 | jtimon: | "assuming GBT was not used" |
| 19:38:18 | maaku: | adam3us: that's why you have the miners report, because the pool could just partition your selfish-miner-alert-system off and feed you old GBT replies |
| 19:40:57 | jtimon: | what makes more expensive for pools to mine gbt/p2pool, bandwidth ? |
| 19:41:00 | adam3us: | maaku: selfish pool spot checking in mining client. not a bad feature. |
| 19:42:43 | jtimon: | maaku I don't get it wouldn't you detect selfish mining on your pool with p2pool/gbt alone ? |
| 19:45:13 | jtimon: | in p2pool concretely, could the pool operator find the block without the rest of the pool noticing? |
| 19:46:44 | adam3us: | jtimon: isnt p2pool p2p so there is no (central) operator so everyone learns everything? |
| 19:47:37 | jtimon: | adam3us I don't know much about pooling in general, but I think that there's an operator who connects all the miners and can collect fees |
| 19:48:04 | gwern: | gwern has left #bitcoin-wizards |
| 19:49:00 | adam3us: | jtimon: usually but in the case of p2pool its more clever, its p2p and each per is directly paid out in proportion to their p2p broadcast share history in the coinbase transaction (i think) |
| 19:49:40 | gmaxwell: | adam3us: thats right. |
| 19:50:02 | gmaxwell: | there is no operator it just works like bitcoin itself does to get a payout consensus. |
| 19:54:15 | Meistarin: | Meistarin has left #bitcoin-wizards |
| 19:54:41 | jtimon: | so selfish mining is not possible with p2pool? what about gbt? |
| 20:08:46 | jtimon: | well, probably better here, maaku no answer from the concatenative people, no? |
| 20:09:14 | maaku: | no, not yet |
| 20:11:51 | maaku: | jtimon: I did email one concatenative researcher who was working on relevant stuff |
| 20:11:58 | maaku: | hopefully I'll hear back at least from him |
| 20:16:42 | nsh: | what's this in reference to, maaku/jtimon? |
| 20:18:09 | jtimon: | in relation to the latests merklized turing complete scripting language |
| 20:18:15 | jtimon: | discussions |
| 20:18:41 | nsh: | ah |
| 20:19:13 | maaku: | nsh: replacing bitcoin script with a turing-complete concatenative language a la Joy, Cat |
| 20:19:38 | jtimon: | maaku emailed a group inciting them to help us design it and become bitcoin scripting language experts, hehe |
| 20:20:00 | nsh: | * nsh has not read much about concatenative programming languages, if anything at all |
| 20:20:06 | jtimon: | also now in #concatenative but doesn't seem a very active channel |
| 20:20:19 | maaku: | nsh: well, bitcoin script is a concatenative language |
| 20:20:26 | maaku: | just not a very expressive one |
| 20:20:34 | nsh: | mm |
| 20:20:38 | maaku: | basically anything Forth-derived, like postscript |
| 20:20:49 | maaku: | stack based languages |
| 20:21:19 | jtimon: | nsh, maaku gave us these links the other day http://evincarofautumn.blogspot.com.es/2012/02/why-concatenative-programming-matters.html http://www.kevinalbrecht.com/code/joy-mirror/j01tut.html |
| 20:21:27 | nsh: | oh, thanks |
| 20:21:37 | nsh: | former already open in tab :) |
| 20:22:23 | jtimon: | hehe, still I have them in the tab too, only started reading the first one |
| 20:22:42 | maaku: | i like that the first link goes over arithmetic expressions ... it's honest :) |
| 20:24:17 | maaku: | f x y z = y^2 + x^2 - |y| = drop dup dup × swap abs rot3 dup × swap − + |
| 20:24:43 | maaku: | yuck... but as an intermediate "high level assembly" representation it has its advantages |
| 20:27:55 | sipa: | in ast: -(+(*($2,$2),*($3,$3)),abs($2)) |
| 21:00:33 | adam3us: | gmaxwell: btw speaking of mid-term asic-hard futility for any given algorithm (to any useful extent), which i agree as a prediction - seems vitalik is going for it anyway http://www.reddit.com/r/ethereum/comments/1vh94e/dagger_updates/ |
| 21:00:52 | adam3us: | gmaxwell: "We have made a preliminary decision that we likely will fund a contest, similar to that used to develop AES and SHA3, to determine the best ASIC-proof (ie. going beyond just "memory hard" as a heuristic) mining algorithm" |
| 21:03:44 | adam3us: | (this is a reaction to the criticism of vitalik's coelho merkle hash PoW based "dagger" PoW, by sergio lerner who in reaction i guess published his own previously unpublished sequential memory hard hash) |
| 21:05:26 | adam3us: | anyway back to bitcoin useful thoughts... amiller was proposing a few days ago to have variable difficulty blocks so that the confirmation could be eg 1.5 or 1.1, with a 1 conf followed by a 0.5 conf etc. i was thinking that is going to be vulnerable to incentive to-not-orphan issues |
| 21:06:08 | nsh: | what do fractional confirmations mean? |
| 21:06:53 | adam3us: | btw you can (and i did this in hashcash-1 (but not in hashcash-0)) indicate the share size intended simply by including the share size in the hash, and the actual share size = min(actual size,target size) |
| 21:07:23 | adam3us: | nsh: so it means you are allowed to submit eg a 1/2 difficulty PoW for a 1/2 reward (12.5 coins) |
| 21:07:42 | adam3us: | nsh: or a 1/100th difficulty. with the objective to make pools less critical for more people. |
| 21:08:03 | nsh: | hmmm |
| 21:09:10 | adam3us: | nsh: tends to mean the block chain gets spammed with lots of little-pows, the interblock interval will be much lower (and he proposed to use GHOST (hashing non conflicting orphans) to support 1min eg interval without orphan loss)) |
| 21:10:36 | nsh: | i'll take your word for it :) |
| 21:11:31 | adam3us: | amiller, nsh: but my more immediate issue was why would a pool with a reasonable chance of getting a full size reward (1-conf) bother to accept say 0.9 reward rather than just orphaning the 0.1 reward. maybe amiller can explain how he thought that would work when he's online |
| 21:12:47 | nsh: | * nsh nods |
| 21:12:48 | amiller: | well the same you build on other people's blocks rather than undermining them |
| 21:12:52 | amiller: | same reason* |
| 21:13:22 | amiller: | i mean, you can get the full size reward by building on the 0.1 block too |
| 21:13:31 | adam3us: | amiller: well in that case its because you are scared that someone will build on the other block and you'll get orphaned |
| 21:13:37 | amiller: | yes |
| 21:13:57 | adam3us: | amiller: oh i see, got it. no new incentive to orphan |
| 21:15:02 | sipa: | i'm not sure the discreteness of increments to the total work is irrelevant |
| 21:15:11 | adam3us: | amiller: you also said you thought you'd have to use GHOST if i recll |
| 21:15:37 | adam3us: | amiller: to combat the faster variable-sized block interval that may result |
| 21:15:47 | amiller: | sipa, the way i say it now is that it seems okay as long as there is a bound on the min difficulty and max diffiuclty |
| 21:16:26 | adam3us: | sipa: i think its utility is it reduces the need to pool. you can more likely direct mine. |
| 21:16:39 | amiller: | the problem with too low difficulty is DoS and waste, and the problem with max difficulty is that malicious-not-profit-motivated attackers can revert long amounts of history with nonneglible probability |
| 21:16:57 | amiller: | but it's okay if there are two parameters clamping this space... |
| 21:17:23 | amiller: | (i'm still trying to figure out how to prove something about the case where there are no bounds/parameters but i haven't gotten anywhere) |
| 21:17:24 | adam3us: | amiller: do you know how GHOST proposes reward works i the adopted non-conflicting orphans in a give block? |
| 21:17:33 | amiller: | ghost proposes no rewards i believe |
| 21:17:49 | amiller: | i think it might not hurt to just include the rewards |
| 21:17:59 | amiller: | i'm not sure thouhg. |
| 21:18:22 | adam3us: | amiller: i think there would need to be some incentive to adopt orphans? |
| 21:19:27 | amiller: | yeah, i don't have any good answer for how that should work |
| 21:19:37 | StAv2: | StAv2 has left #bitcoin-wizards |
| 21:23:25 | adam3us: | amiller: eg you get 10% of the reward on top of each orphan you adopt, or something like that. (Bearing in mind rate of reward distribution can be tuned to match current however its done) |
| 21:23:41 | maaku: | adam3us: what do you mean by adopt? GHOST doesn't have anything like that (or need it) |
| 21:24:17 | adam3us: | amiller: i thought ghost works by referencing multiple predecessors in a given block, so that the adopted orphans are considered in the weighting of which block is voted as correct |
| 21:24:19 | amiller: | i get nauseous everytime there appears to be another parameter to adjust to reward/discourage some behavior like orphan vs building |
| 21:24:48 | amiller: | if i can state what the desired behavior is supposed to be and what the options are the right approach is to solve for what is incentive compatible or something like that, but that never seems to work out :/ |
| 21:24:52 | nsh: | amiller, works for the standard model... |
| 21:25:01 | maaku: | adam3us: no, ghost is just a new algorithm for selecting best block, taking into account stale blocks you might have seen |
| 21:25:07 | adam3us: | amiller: yes. well in my own design exploration i always come back so far to the current design is best. i found something like ghost but decided its complex to limited benefit. |
| 21:25:18 | nsh: | all we need is like 30-60 finely-tweaked otherwise-inexplicable parameters |
| 21:25:27 | maaku: | adam3us: it's a local algorithm, not consensus based |
| 21:25:38 | adam3us: | maaku: oh, seems i misunderstood it! |
| 21:26:24 | sipa: | maaku: what do you mean by local? |
| 21:26:26 | nsh: | (then we "explain" it by resource to a anthropic blockchain landscape) |
| 21:26:28 | adam3us: | maaku: so which is the best block in ghost? |
| 21:26:30 | nsh: | *recourse |
| 21:26:57 | adam3us: | amiller: yeah i think game-theory and self-interest are security-fragile. |
| 21:27:14 | maaku: | adam3us: at each step, choose the branch with the most total work, including stales |
| 21:27:39 | amiller: | but, we now have a more specific guiding goal |
| 21:27:43 | sipa: | maaku: right, but that can change over time |
| 21:27:53 | amiller: | getting whatever people want or can get from p2pool within the main game itself.... |
| 21:28:34 | maaku: | sipa: yes, but with a stable outcome |
| 21:29:26 | adam3us: | maaku: wait but orphans arise because of simultaneous publication, so what does ghost mean, you switch to a later announced block if it is heavier? how is weight determined? |
| 21:29:45 | adam3us: | maaku: (I mean you switch to mining on) |
| 21:31:58 | maaku: | adam3us: start with the genesis block as best. sum the aggregate work built off of each branch you know of - including stales - and choose the one with most total work |
| 21:32:50 | maaku: | if two branches have the same weight, then you use some other factor (like say when you heard about it) |
| 21:33:06 | maaku: | but yes, maybe one has more stales and therefore more weight |
| 21:33:20 | maaku: | another way of saying this is choose the branch that you have more evidence of hashpower commitement to |
| 21:33:34 | maaku: | because, in the long run, it's the branch more likely to pull ahead |
| 21:33:35 | qwertyoruiop: | maaku: so basically, 51% easier. |
| 21:33:47 | maaku: | qwertyoruiop: ? |
| 21:34:09 | qwertyoruiop: | the biggest pool can have more luck at double spending |
| 21:34:36 | maaku: | qwertyoruiop: no. not unless they are already >50% |
| 21:35:16 | qwertyoruiop: | you'd be making it easier for < 50% attackers trying to doublespend. |
| 21:35:26 | maaku: | qwertyoruiop: no i'd be harder |
| 21:36:54 | maaku: | because if the attacker has <50%, then he would have less evidence of work on his chain |
| 21:37:07 | maaku: | so people *wouldn't* switch to it, even if he managed to pull ahead by getting lucky |
| 21:37:49 | adam3us: | maaku: so do you think its really true that this makes the orphans useful enough to count as productively used and so to support reducing the block interval to 1min (with higher orphan rates) as they propose? |
| 21:38:17 | maaku: | he'd have to surpass not just the linear work of the honest chain, but all the stales too |
| 21:38:29 | adam3us: | maaku: doesn the orphan still get no reward and so give advantge to better latency connected miners? |
| 21:38:41 | qwertyoruiop: | what would exactly the point of adopting orphans be? |
| 21:38:43 | maaku: | adam3us: stales not orphans, and there's no reason to decrease the interblock time |
| 21:39:12 | maaku: | it gets you no practical advantage with a *huge* hit to SPV users |
| 21:39:13 | adam3us: | maaku: well i know no need, but i thought that was one of their claimed reasons and advantages for the approach? |
| 21:39:28 | maaku: | they misunderstand the tradeoffs involved |
| 21:39:37 | maaku: | but yes, that is what they are proposing |
| 21:40:06 | adam3us: | qwertyoruiop: maaku is explaining there is no orphan adoption in ghost |
| 21:40:08 | maaku: | GHOST lets you approach closer to the limits of what given bandwidth and latency assumptions allow |
| 21:40:22 | maaku: | closer that stock bitcoin at least |
| 21:40:42 | adam3us: | maaku: but that seems to create centralization risks if there is no reward for stales |
| 21:40:51 | adam3us: | maaku: (latency centralization) |
| 21:41:34 | maaku: | adam3us: bitcoin protocol is not the place to correct that |
| 21:41:44 | maaku: | do something like p2pool does |
| 21:42:06 | maaku: | adam3us: GHOST lets us increase the block size more, or decrease the block interval lower |
| 21:42:35 | maaku: | they mistakenly advocate shorter block times when in fact larger block sizes are more likely |
| 21:43:25 | maaku: | so for a given centralization tradeoff let's say 100MB blocks is possible with stock bitcoin; GHOST will let us get to 120MB for that same tradeoff |
| 21:43:29 | maaku: | (i'm making up numbers) |
| 21:44:37 | maaku: | regarding reward, i don't know if p2pool actually does this now, but there's no reason it couldn't merge share chains |
| 21:44:40 | maaku: | (forrestv ^^) |
| 21:45:31 | justanotheruser: | So here is how I want to score how likely it is someone is being a "greedy miner". First measure how often 1,2,3... block orphans occur. Combined with the hashing power of a pool I should be able to calculate what the odds are that there are N+1 blocks replacing their competitors orphans N blocks. If the odds of it happening are 1/X, then they get X added to their score. Keeping track of a weekly score should be able to ind |
| 21:45:47 | justanotheruser: | s/Analiese/anomalies |
| 21:46:12 | adam3us: | maaku: "it gets you no practical advantage with a *huge* hit to SPV users" "they misunderstand the tradeoffs involved" what was that in relation to? |
| 21:46:17 | maaku: | justanotheruser: or, you could simply point a miner at their pool and see if they're building of non-public work |
| 21:46:41 | maaku: | adam3us: advocating smaller interblock times (bad) vs. increasing the block size (good) |
| 21:47:15 | maaku: | smaller interblock times get you nothing unless you can get under a second |
| 21:47:19 | maaku: | which is impossible |
| 21:47:33 | maaku: | so actually, we want the *largest* acceptable interblock time |
| 21:47:46 | maaku: | since that minimizes strain on SPV devices |
| 21:48:05 | justanotheruser: | maaku: wow, that is a lot easier |
| 21:48:33 | justanotheruser: | maaku: except they might be doing this attack using cex.io |
| 21:49:06 | adam3us: | maaku: strain in terms of keeping up withthe hash chain and/or number of bloom queries if they are constained to a block? |
| 21:49:40 | maaku: | justanotheruser: correct, hosted miners are far worse than pools |
| 21:50:49 | adam3us: | maaku: i mentioned last few days that i think multiple smaller blocks are statistically harder to 51% attack because p^12 << p^6 eg (if you have p=10% or whatever) and to do an n-confirmation attack you need a chain n blocks long, and so if block interval is lower, then you can get more security per time-interval (eg within 30mins say) |
| 21:51:52 | maaku: | adam3us: SPV nodes must download headers + merkle path + coinbase tx for every block. that alone is a large but manageable cost already |
| 21:52:06 | maaku: | plus they must perform a boom or prefix query for the contents of each block |
| 21:52:27 | sipa: | * sipa likes boom queries |
| 21:54:09 | adam3us: | adam3us: so actually i think shorter block intervals allow more short confirmations (in a given time interval) and so are more secure, per elapsed time, and or allow faster confirmation to a given assurance level |
| 21:54:53 | sipa: | adam3us: depends on whether your attack model is about someone buying hash power, or buying hashes |
| 21:54:55 | adam3us: | maaku: (i know that was refuted in terms of "litecoin more secure than bitcoin" but i am not saying 6-conf on each I am saying 24-conf on 2.5min block interval is more secure than 6-conf on 10min block interval) |
| 21:54:56 | sipa: | i think |
| 21:55:18 | maaku: | adam3us: yes, but how often are those few minutes really worth it? |
| 21:55:52 | adam3us: | maaku: (sorry meant "ltc faster..." not "ltc securer" as people said yes but weaker so not usefully faster) |
| 21:56:07 | maaku: | vs increasing bandwidth requirements for spv nodes by an order of magnitude - especially when these users are often on data-capped mobile plans |
| 21:56:24 | adam3us: | maaku: spv min feed bloat is bad, yes. |
| 21:57:42 | justanotheruser: | Any idea how much of ghash is cloud mining? |
| 21:57:45 | adam3us: | sipa: there would be less electricity used, and smaller reward interval, so if they were bought yes they would be economically weaker. alternatively in terms of you own some hash power then statistically stronger |
| 21:58:02 | maaku: | adam3us: actually it is generally true that you should compare confirmations, not work done |
| 21:58:11 | maaku: | at least in standard bitcoin |
| 21:58:29 | maaku: | and so long as you're not approaching bandwith/latency limits |
| 21:59:06 | adam3us: | maaku: yes that was in regards sipas comment "depends on whether your attack model is about someone buying hash power, or buying hashes" |
| 21:59:14 | sipa: | maaku: i've suggested using (total_work_at_tip - total_work_at_inclusion)/current_difficulty as measure for confirmations |
| 21:59:31 | sipa: | "PoW equivalent time" |
| 22:00:05 | adam3us: | maaku: you cant determine work done really. luck. if you meant that in a strict sense |
| 22:00:24 | michagogo|cloud: | ;;later tell andytoshi Heh, your cj client is impossible to use on unencrypted wallets |
| 22:00:24 | gribble: | The operation succeeded. |
| 22:01:28 | sipa: | unfortunately, the current PoW-equivalent confirmation time of the genesis block is around 50 days |
| 22:01:50 | adam3us: | maaku: maybe you meant compare ltc 6-conf to btc 6-conf (rather than compare ltc 24 to btc 6) |
| 22:03:08 | adam3us: | sipa: yes thats a fun fact, nice stat feels weak intuitively, but it still its a long way from a rogue network subset going off and rewriting history. |
| 22:03:41 | maaku: | michagogo|cloud: why? |
| 22:03:52 | michagogo|cloud: | Because it assumes there's a passphrase |
| 22:04:15 | maaku: | michagogo|cloud: ah |
| 22:04:16 | adam3us: | sipa: the formula is nice for long confirmations separated by difficulty adjustments |
| 22:04:34 | michagogo|cloud: | maaku: http://imgur.com/4RYgCpJ |
| 22:04:49 | maaku: | adam3us: i'm saying ltc 6-conf is equal to btc 6-conf in realistic attack scenarios |
| 22:05:13 | maaku: | e.g. a pool trying to win money from a zero-conf service |
| 22:06:35 | maaku: | if the question is "what's the probability of my fraud chain pulling ahead?" interblock time doesn't factor into that |
| 22:06:38 | sipa: | adam3us: http://bitcoin.sipa.be/powdays-50k.png |
| 22:06:57 | adam3us: | sipa: yeah i know, i saw it, very nice :) |
| 22:09:26 | maaku: | sipa: it's an interesting measure, but it doesn't really factor into real attack analysis now does it? |
| 22:10:03 | maaku: | i should say, it's relevant if you can actually pull off a 51% attack |
| 22:11:02 | maaku: | otherwise you know you're going to lose in the long run so the question becomes liklihood of success , which depends on # confirmations, not pow days |
| 22:11:50 | gmaxwell: | maaku: so modifying your statement, "foocoin with 1ns blocks 6-conf is equal to btc 6-conf in realistic attack scenarios" |
| 22:15:39 | adam3us: | gmaxwell: i think it sipa had it better, shorter interval = lower reward loss/lower PoW cycles; but same probability |
| 22:15:56 | maaku: | [13:58:25] and so long as you're not approaching bandwith/latency limits |
| 22:16:10 | adam3us: | maaku: exactly. |
| 22:18:25 | adam3us: | maaku: actually i suppose the probability of pulling off a 51% attack per time interval is higher, because there are more block intervals pr time period (more attacks to run) |
| 22:19:28 | adam3us: | maaku: eg with lite coin i get 4 tries per hour, with bitcoin i get 1 (other params than block interval being equal, same total reward aggregate etc) |
| 22:21:09 | maaku: | adam3us: yes, but if you're trying every block then your costs similarly increase |
| 22:21:20 | maaku: | and the payoff remains the same, if measured as expected gain/loss per block |
| 22:22:07 | gmaxwell: | maaku: ignoring that fact that orphaning causes increased hashpower dillution |
| 22:22:18 | gmaxwell: | thats why I gave the 1ns example. |
| 22:22:27 | adam3us: | maaku: so probability of being able to double spend goes from p^6 to 1-(1-p^6)^4 |
| 22:23:07 | adam3us: | maaku: eg 25% hash power from .024% to .098% |
| 22:24:08 | adam3us: | maaku: your costs are the same i think .. no reward for 1hr period presuming same reward distribution per hour |
| 22:24:44 | maaku: | adam3us: the costs are whatever you're trying to double-spend, not the reward per se |
| 22:25:01 | maaku: | adam3us: also there's a reason I said "assuming standard bitcoin" |
| 22:25:06 | adam3us: | maaku: thats a (misgotten) profit not a cost? |
| 22:25:26 | maaku: | if you assume GHOST, then it actually makes the double-spend harder to pull off |
| 22:25:43 | adam3us: | maaku: (assuming something liquid with low commission to trade against with your fraud, like say ltc/btc or whatever) |
| 22:25:47 | maaku: | because the honest chain has stales the fraud chain does not |
| 22:26:22 | maaku: | and if you assume fractional proof of works are distributed it gets worse for the attacker |
| 22:27:04 | maaku: | adam3us: you will never find zero commision, zero spread |
| 22:29:14 | adam3us: | maaku: agreed the commission & spread is the additional cost |
| 22:33:30 | adam3us: | maaku: there seem to be faster params that are more secure against double spend. so like 8x 2.5min blocks less chance of double spend per hour, and less chance per try and shorter confirmation (than 6x10min) |
| 22:35:25 | adam3us: | maaku: p^6=.024%, p^8=.0015%, 1-(1-p^6)^4=.098%, 1-(1-p^8)^3=.0046% |
| 22:42:54 | adam3us: | maaku: but as u said the spv cost for more blocks is a problem with ghost. they even mention 1 second interval. surely that would lead to quite strong advantages for cloud hosted mining |
| 23:09:06 | andytoshi: | michagogo|cloud: that's correct, i am mulling over supporting unencrypted wallets |
| 23:09:26 | andytoshi: | michagogo|cloud: i just put a passphrase on my testnet wallet, which was annoying.. |
| 23:47:17 | jcrubino: | jcrubino has left #bitcoin-wizards |