00:03:54 DougieBot5000_ has quit 00:15:01 mappum_ has joined #bitcoin-wizards 00:15:01 go1111111 has joined #bitcoin-wizards 00:16:03 mappum_ has quit 00:21:00 obscuren has quit 00:33:13 jcrubino has quit 00:38:17 rdymac has quit 00:44:42 obscuren has joined #bitcoin-wizards 00:44:56 <_ingsoc> _ingsoc has quit 00:45:03 jcrubino has joined #bitcoin-wizards 00:52:36 home_jg is now known as jgarzik 00:55:37 jcrubino has quit 00:58:24 obscuren has quit 01:11:10 jcrubino has joined #bitcoin-wizards 01:15:09 rdymac has joined #bitcoin-wizards 01:30:17 nsh has quit 01:34:28 jtimon has quit 01:47:37 mappum_ has joined #bitcoin-wizards 01:57:16 orperelman has joined #bitcoin-wizards 01:57:44 mappum_ has quit 01:59:29 wallet421 has joined #bitcoin-wizards 01:59:30 wallet42 is now known as Guest49318 01:59:30 Guest49318 has quit 01:59:30 wallet421 is now known as wallet42 02:01:26 CodeShar_ has joined #bitcoin-wizards 02:04:10 CodeShark has quit 02:16:44 orperelman has quit 02:17:07 andytoshi has quit 02:29:28 Ursium has quit 02:37:30 mappum_ has joined #bitcoin-wizards 02:56:35 There was a puzzle in the MIT mystery hunt that some folks here would like solving. 02:57:07 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:14 roidster has joined #bitcoin-wizards 03:14:30 roidster is now known as Guest32414 03:19:11 RoboTeddy has quit 03:48:42 justanotheruser1 has joined #bitcoin-wizards 03:49:06 justanotheruser has quit 03:49:16 justanotheruser has joined #bitcoin-wizards 03:49:16 justanotheruser has quit 03:49:16 justanotheruser has joined #bitcoin-wizards 03:52:55 brisque has joined #bitcoin-wizards 03:53:21 rdymac has quit 03:53:29 justanotheruser1 has quit 03:55:09 rdymac has joined #bitcoin-wizards 03:55:35 tubro has joined #bitcoin-wizards 04:00:11 tubro has quit 04:08:01 rdymac has quit 04:13:08 andytoshi has joined #bitcoin-wizards 04:14:09 rdymac has joined #bitcoin-wizards 04:38:44 is it possible to have an address that is both a valid litecoin and bitcoin address? 04:38:57 mappum_ has quit 04:50:44 coryfields is now known as cfields 04:53:32 jcrubino has quit 04:55:19 Guest32414 has quit 05:02:08 gmaxwell what do you do for a living? 05:02:38 Taek42, he works at mozilla doing stuff and things 05:17:25 wallet42 has quit 05:25:23 rdymac has quit 05:33:10 rdymac has joined #bitcoin-wizards 05:36:25 kyrio has left #bitcoin-wizards 06:00:40 roidster has joined #bitcoin-wizards 06:02:59 jcrubino has joined #bitcoin-wizards 07:04:01 rdymac has quit 07:19:10 rdymac has joined #bitcoin-wizards 07:24:46 jcrubino: no simply because of the fact that litecoins version number starts is L, not 1 07:29:26 Meistarin has quit 07:33:26 Meistarin has joined #bitcoin-wizards 07:35:19 Graet has quit 07:37:02 Graet has joined #bitcoin-wizards 07:38:45 justanotheruser: I have a testnet address that passes validation tests by both daemon clients 07:39:40 jcrubino: Hmm. I suppose if both daemons ignore the version it could be valid 07:39:57 rdymac has quit 07:40:07 justanotheruser: I explained in #bitcoin-dev that you can use the same public keys, just the address reads differently. 07:40:07 I chaes my tail in circles while unit testing over that 07:40:13 what character does the testnet address start with 07:40:18 m or n 07:40:28 ;;bc,wiki address prefixes 07:40:29 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 brisque: I meant for litecoin 07:40:44 does litecoin have a testnet? 07:40:52 yes 07:41:08 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 if the testnet prefix is the same it'll work with no problem 07:42:29 assumming I change out the address prefix in bitcoind to the litecoin version what else needs to change to make it litecoind ? 07:42:32 christo has quit 07:42:33 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 jcrubino: mainly just the POW system and the logo. 07:43:50 does a non mining daemon verify the pow or does it just relay ? 07:45:03 ever node validates the POW of every block 07:50:10 rdymac has joined #bitcoin-wizards 07:54:58 tubro has joined #bitcoin-wizards 07:57:42 roidster has quit 08:07:49 rdymac has quit 08:09:50 tubro has quit 08:11:40 rdymac has joined #bitcoin-wizards 09:09:47 rdymac has quit 09:23:17 wallet42 has joined #bitcoin-wizards 09:34:09 rdymac has joined #bitcoin-wizards 09:41:24 orperelman has joined #bitcoin-wizards 09:56:00 obscuren has joined #bitcoin-wizards 10:01:11 nanotube has quit 10:02:56 espes__ has quit 10:03:03 espes__ has joined #bitcoin-wizards 10:06:59 hnz has quit 10:10:33 nanotube has joined #bitcoin-wizards 10:12:03 hnz has joined #bitcoin-wizards 10:37:08 <_ingsoc> _ingsoc has joined #bitcoin-wizards 10:39:25 jtimon has joined #bitcoin-wizards 10:45:29 go1111111 has quit 11:03:45 mappum_ has joined #bitcoin-wizards 11:08:37 mappum_ has quit 11:09:35 Ursium has joined #bitcoin-wizards 11:10:45 <_ingsoc> _ingsoc has quit 11:13:40 nomailing has joined #bitcoin-wizards 11:24:05 rdymac has quit 11:26:40 rdymac has joined #bitcoin-wizards 11:48:06 epscy has quit 11:52:18 epscy has joined #bitcoin-wizards 11:54:44 Ursium has quit 11:54:50 orperelman has quit 12:14:38 nsh has joined #bitcoin-wizards 12:24:56 Ursium has joined #bitcoin-wizards 12:27:15 orperelman has joined #bitcoin-wizards 12:29:54 tubro has joined #bitcoin-wizards 12:44:38 mappum has quit 12:47:38 Ursium has quit 12:48:00 <_ingsoc> _ingsoc has joined #bitcoin-wizards 12:50:01 gwern has quit 12:50:49 gwern has joined #bitcoin-wizards 12:54:02 brisque has quit 13:05:38 orperelman has quit 14:00:30 wallet421 has joined #bitcoin-wizards 14:00:30 wallet42 has quit 14:00:30 wallet421 is now known as wallet42 14:42:35 jps has joined #bitcoin-wizards 14:47:50 jps has quit 14:48:23 tubro has quit 15:03:53 jps has joined #bitcoin-wizards 15:07:25 c0rw1n has quit 15:08:54 CodeShar_ has quit 15:09:12 CodeShark has joined #bitcoin-wizards 15:41:32 jps has quit 15:49:32 nsh has quit 15:49:32 nomailing has quit 15:49:33 cypherdial has quit 15:49:33 BlueMatt has quit 15:49:33 lianj has quit 15:49:33 heakins has quit 15:49:34 Taek42 has quit 15:50:30 cypherdial has joined #bitcoin-wizards 15:52:00 nsh has joined #bitcoin-wizards 15:52:01 nomailing has joined #bitcoin-wizards 15:52:01 BlueMatt has joined #bitcoin-wizards 15:52:01 lianj has joined #bitcoin-wizards 15:52:01 heakins has joined #bitcoin-wizards 15:52:01 Taek42 has joined #bitcoin-wizards 15:56:10 nsh has quit 15:56:11 nomailing has quit 15:56:11 BlueMatt has quit 15:56:11 lianj has quit 15:56:11 heakins has quit 15:56:11 Taek42 has quit 15:58:29 nsh has joined #bitcoin-wizards 15:58:29 nomailing has joined #bitcoin-wizards 15:58:29 BlueMatt has joined #bitcoin-wizards 15:58:29 lianj has joined #bitcoin-wizards 15:58:29 heakins has joined #bitcoin-wizards 15:58:29 Taek42 has joined #bitcoin-wizards 16:20:11 tubro has joined #bitcoin-wizards 16:27:41 shesek has joined #bitcoin-wizards 16:33:42 mr_burdell has joined #bitcoin-wizards 16:36:50 spin123456 has joined #bitcoin-wizards 16:36:50 spinza has quit 16:38:15 roidster has joined #bitcoin-wizards 16:38:30 roidster is now known as Guest57763 16:59:43 spin123456 is now known as spinza 17:05:50 spinza has quit 17:05:51 spin123456 has joined #bitcoin-wizards 17:20:24 justanotheruser1 has joined #bitcoin-wizards 17:21:57 justanotheruser2 has joined #bitcoin-wizards 17:23:16 obscuren has quit 17:24:19 justanotheruser has quit 17:25:26 justanotheruser1 has quit 17:26:26 tubro has quit 17:30:32 rdymac has quit 17:32:04 obscuren has joined #bitcoin-wizards 17:32:07 justanotheruser2 has quit 17:33:10 justanotheruser has joined #bitcoin-wizards 17:33:30 justanotheruser has quit 17:33:31 justanotheruser has joined #bitcoin-wizards 17:35:10 rdymac has joined #bitcoin-wizards 17:36:19 spin123456 has quit 17:36:39 spinza has joined #bitcoin-wizards 18:21:56 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:23:43 StAv2 has joined #bitcoin-wizards 18:25:18 rdymac has quit 18:27:11 justanotheruser, in general, no. 18:27:45 orperelman has joined #bitcoin-wizards 18:29:40 rdymac has joined #bitcoin-wizards 18:30:05 obscuren has quit 18:31:08 justanotheruser: the best you could probably do is several multiples, maybe an order of magnitude 18:35:52 spin123456 has joined #bitcoin-wizards 18:35:52 spinza has quit 18:38:19 shesek has quit 18:46:15 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 s/takes up a/uses a 18:46:30 c0rw1n has joined #bitcoin-wizards 18:48:57 * nsh frowns 18:54:19 orperelman has quit 18:56:44 Taek42 has quit 19:03:42 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 maybe another direction is a FPGA friendly design, and hope ASIC/FPGA advantage will narrow as a trend. 19:06:51 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 why does this pow wanking keep going on here? 19:07:38 I can't imagine a less interesting subject. 19:07:48 Does anyone here even care about it? 19:07:56 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 adam3us: maybe the PoW could require all the outputs. 19:09:00 One problem I see with this is verification taking a long time 19:09:15 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:39 c0rw1n has quit 19:09:42 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 (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 gmaxwell: It seems one of your altcoin ideas linked in the topic involves a modified PoW 19:10:43 maybe we need a #bitcoin-pow-wankery ;) 19:11:23 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 justanotheruser: many of the alts sole 'hook' (aka fake argument for existence/sales pitch) is a different pow for "decentralization" 19:12:04 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 It's just the kind of superficial thing that people can discuss forever. e.g. "random POW generator" 19:12:49 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 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 justanotheruser: seems to me asic-hardness ends up using more electricity typically 19:15:15 justanotheruser when your ASIC competitors are doing 4% profits, will you mine at -1%? 19:16:20 jtimon: ASICs probably wouldn't give them 4% profits because they would have to buy new hardware 19:16:42 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 The ops here seem to want us to change the topic though. 19:16:59 profits = gains after all costs, including capital costs 19:17:52 jtimon: I don't understand why you defined profits. It doesn't really change anything about what I said. 19:18:36 as i recall no one found a good answer to the 25/33% attack, and ghash is at 34% now coincidentally 19:19:40 adam3us: what's the 25/33% attack? Just them being able do a large reorg some of the time? 19:19:52 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:38 c0rw1n has joined #bitcoin-wizards 19:20:41 why does this pow wanking keep going on here? I can't imagine a less interesting subject. <--- thank you :) 19:21:56 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 adam3us: and with 25% you can do this too? 19:22:45 is there a pool that takes over 33% of the network regularly? 19:22:47 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 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 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 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 gmaxwell are you suggesting that ghash selfmines and that's why it gets more orphans? 19:24:33 jtimon: its plausible that would be the side effect 19:24:40 adam3us: So what percentage of blocks can you get given you have N% of the network? Is there a formula? 19:24:41 i parsed it as "that, or they're doing something wrong with their connetivity" 19:25:03 justanotheruser yeah there is a formula. in involves the variance 19:25:19 jtimon: someone should crunch the data and see if it supports that theory. 19:25:26 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 link? 19:25:57 so you could as well call "selfish mining", "block relay time optimization" 19:26:04 I have noticed an increase in depth 2 orphaning, so if so I don't think they're doing it successfully. 19:26:10 how will that destroy bitcoin? 19:26:17 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 justanotheruser: selfish-mining http://arxiv.org/pdf/1311.0243v2.pdf 19:26:37 thanks 19:27:20 I guess we would need to estimate their real block distribution latency to calculate the time they hold their blocks? 19:27:48 I don't know, network topology...too hard of a problem for me 19:27:53 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 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 Yes. 19:29:49 that may be a symptom if i got it right 19:29:50 would consecutive blocks for parties be significant? 19:29:59 jtimon: happens naturally. 19:30:13 I mean, count how many times they mine 2 in a row, 3 in a row, etc 19:30:16 more than you'd expect based on their hashrate would be interesting. 19:30:33 but the data is perhaps too undersampled to say with confidence. 19:30:51 long reorgs are more surprising. 19:31:11 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 sure though thats detectable for people mining on them. 19:32:09 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 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 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 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 *click* that's interesting 19:34:37 maaku: how would it know public? 19:34:50 it could blockchain the mining stats? 19:35:02 "blockchain the mining stats" 19:35:03 gmaxwell: either from local bitcoind or by asking Eliguis 19:35:04 * gmaxwell zot 19:35:14 c0rw1n: i hope you're kidding 19:35:40 * sipa gets his hammer; c0rw1n looks like a nail 19:35:58 maaku: I guess it can poll all configured pools and log when their prevs are different. 19:35:59 'k i'll shut up if i'm not this smart enough to talk :$ 19:36:40 maaku: It's odd that miners don't equal loadbalance pools almost at all, since that minimizes variance. 19:36:49 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 but I guess thats because they count on pools for monitoring/stats (doh) 19:37:30 "assuming GBT was not used" 19:38:18 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:39:14 obscuren has joined #bitcoin-wizards 19:40:19 obscuren has quit 19:40:57 what makes more expensive for pools to mine gbt/p2pool, bandwidth ? 19:41:00 maaku: selfish pool spot checking in mining client. not a bad feature. 19:42:43 maaku I don't get it wouldn't you detect selfish mining on your pool with p2pool/gbt alone ? 19:45:13 in p2pool concretely, could the pool operator find the block without the rest of the pool noticing? 19:46:44 jtimon: isnt p2pool p2p so there is no (central) operator so everyone learns everything? 19:46:46 tubro has joined #bitcoin-wizards 19:47:37 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 has left #bitcoin-wizards 19:49:00 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 adam3us: thats right. 19:50:02 there is no operator it just works like bitcoin itself does to get a payout consensus. 19:54:15 Meistarin has left #bitcoin-wizards 19:54:41 so selfish mining is not possible with p2pool? what about gbt? 20:07:34 go1111111 has joined #bitcoin-wizards 20:08:46 well, probably better here, maaku no answer from the concatenative people, no? 20:09:14 no, not yet 20:11:51 jtimon: I did email one concatenative researcher who was working on relevant stuff 20:11:58 hopefully I'll hear back at least from him 20:16:42 what's this in reference to, maaku/jtimon? 20:18:09 in relation to the latests merklized turing complete scripting language 20:18:15 discussions 20:18:41 ah 20:19:13 nsh: replacing bitcoin script with a turing-complete concatenative language a la Joy, Cat 20:19:38 maaku emailed a group inciting them to help us design it and become bitcoin scripting language experts, hehe 20:20:00 * nsh has not read much about concatenative programming languages, if anything at all 20:20:06 also now in #concatenative but doesn't seem a very active channel 20:20:19 nsh: well, bitcoin script is a concatenative language 20:20:26 just not a very expressive one 20:20:34 mm 20:20:38 basically anything Forth-derived, like postscript 20:20:49 stack based languages 20:21:19 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 oh, thanks 20:21:37 former already open in tab :) 20:22:23 hehe, still I have them in the tab too, only started reading the first one 20:22:42 i like that the first link goes over arithmetic expressions ... it's honest :) 20:24:17 f x y z = y^2 + x^2 - |y| = drop dup dup × swap abs rot3 dup × swap − + 20:24:43 yuck... but as an intermediate "high level assembly" representation it has its advantages 20:27:55 in ast: -(+(*($2,$2),*($3,$3)),abs($2)) 20:31:24 shesek has joined #bitcoin-wizards 20:37:25 jtimon has quit 20:48:05 shesek has quit 20:54:43 epscy has quit 21:00:33 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 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:01:13 shesek has joined #bitcoin-wizards 21:02:51 go1111111 has quit 21:03:44 (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 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 what do fractional confirmations mean? 21:06:53 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 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 nsh: or a 1/100th difficulty. with the objective to make pools less critical for more people. 21:08:03 hmmm 21:09:10 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 i'll take your word for it :) 21:11:31 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 nods 21:12:48 well the same you build on other people's blocks rather than undermining them 21:12:52 same reason* 21:13:22 i mean, you can get the full size reward by building on the 0.1 block too 21:13:31 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 yes 21:13:57 amiller: oh i see, got it. no new incentive to orphan 21:15:02 i'm not sure the discreteness of increments to the total work is irrelevant 21:15:11 amiller: you also said you thought you'd have to use GHOST if i recll 21:15:37 amiller: to combat the faster variable-sized block interval that may result 21:15:47 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 sipa: i think its utility is it reduces the need to pool. you can more likely direct mine. 21:16:39 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 but it's okay if there are two parameters clamping this space... 21:17:23 (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 amiller: do you know how GHOST proposes reward works i the adopted non-conflicting orphans in a give block? 21:17:33 ghost proposes no rewards i believe 21:17:49 i think it might not hurt to just include the rewards 21:17:59 i'm not sure thouhg. 21:18:22 amiller: i think there would need to be some incentive to adopt orphans? 21:19:10 spin123456 has quit 21:19:10 nanotube has quit 21:19:11 hno has quit 21:19:11 K1773R has quit 21:19:11 harrow has quit 21:19:12 ghtdak has quit 21:19:27 yeah, i don't have any good answer for how that should work 21:19:37 StAv2 has left #bitcoin-wizards 21:20:41 spin123456 has joined #bitcoin-wizards 21:20:41 nanotube has joined #bitcoin-wizards 21:20:41 hno has joined #bitcoin-wizards 21:20:41 K1773R has joined #bitcoin-wizards 21:20:41 harrow has joined #bitcoin-wizards 21:20:41 ghtdak has joined #bitcoin-wizards 21:23:25 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 adam3us: what do you mean by adopt? GHOST doesn't have anything like that (or need it) 21:24:17 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 i get nauseous everytime there appears to be another parameter to adjust to reward/discourage some behavior like orphan vs building 21:24:48 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 amiller, works for the standard model... 21:25:01 adam3us: no, ghost is just a new algorithm for selecting best block, taking into account stale blocks you might have seen 21:25:07 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 all we need is like 30-60 finely-tweaked otherwise-inexplicable parameters 21:25:27 adam3us: it's a local algorithm, not consensus based 21:25:38 maaku: oh, seems i misunderstood it! 21:26:24 maaku: what do you mean by local? 21:26:26 (then we "explain" it by resource to a anthropic blockchain landscape) 21:26:28