00:52:36home_jg:home_jg is now known as jgarzik
01:59:30wallet42:wallet42 is now known as Guest49318
01:59:30wallet421:wallet421 is now known as wallet42
02:56:35gmaxwell:There was a puzzle in the MIT mystery hunt that some folks here would like solving.
02:57:07gmaxwell: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:30roidster:roidster is now known as Guest32414
04:38:44jcrubino:is it possible to have an address that is both a valid litecoin and bitcoin address?
04:50:44coryfields:coryfields is now known as cfields
05:02:08Taek42:gmaxwell what do you do for a living?
05:02:38phantomcircuit:Taek42, he works at mozilla doing stuff and things
05:36:25kyrio:kyrio has left #bitcoin-wizards
07:24:46justanotheruser:jcrubino: no simply because of the fact that litecoins version number starts is L, not 1
07:38:45jcrubino:justanotheruser: I have a testnet address that passes validation tests by both daemon clients
07:39:40justanotheruser:jcrubino: Hmm. I suppose if both daemons ignore the version it could be valid
07:40:07brisque:justanotheruser: I explained in #bitcoin-dev that you can use the same public keys, just the address reads differently.
07:40:07jcrubino:I chaes my tail in circles while unit testing over that
07:40:13justanotheruser:what character does the testnet address start with
07:40:18brisque:m or n
07:40:28brisque:;;bc,wiki address prefixes
07:40:29gribble: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:36justanotheruser:brisque: I meant for litecoin
07:40:44brisque:does litecoin have a testnet?
07:41:08justanotheruser: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:22brisque:if the testnet prefix is the same it'll work with no problem
07:42:29jcrubino:assumming I change out the address prefix in bitcoind to the litecoin version what else needs to change to make it litecoind ?
07:42:33justanotheruser: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:48brisque:jcrubino: mainly just the POW system and the logo.
07:43:50jcrubino:does a non mining daemon verify the pow or does it just relay ?
07:45:03brisque:ever node validates the POW of every block
14:00:30wallet421:wallet421 is now known as wallet42
16:38:30roidster:roidster is now known as Guest57763
16:59:43spin123456:spin123456 is now known as spinza
18:21:56justanotheruser: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:11nsh:justanotheruser, in general, no.
18:31:08maaku:justanotheruser: the best you could probably do is several multiples, maybe an order of magnitude
18:46:15justanotheruser: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:27justanotheruser:s/takes up a/uses a
18:48:57nsh:* nsh frowns
19:03:42adam3us: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:45adam3us:maybe another direction is a FPGA friendly design, and hope ASIC/FPGA advantage will narrow as a trend.
19:06:51justanotheruser: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:30gmaxwell:why does this pow wanking keep going on here?
19:07:38gmaxwell:I can't imagine a less interesting subject.
19:07:48gmaxwell:Does anyone here even care about it?
19:07:56adam3us: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:47justanotheruser:adam3us: maybe the PoW could require all the outputs.
19:09:00justanotheruser:One problem I see with this is verification taking a long time
19:09:15andytoshi: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:42gmaxwell: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:07gmaxwell:(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:24justanotheruser:gmaxwell: It seems one of your altcoin ideas linked in the topic involves a modified PoW
19:10:43adam3us:maybe we need a #bitcoin-pow-wankery ;)
19:11:23gmaxwell: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:46adam3us:justanotheruser: many of the alts sole 'hook' (aka fake argument for existence/sales pitch) is a different pow for "decentralization"
19:12:04gmaxwell: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:25gmaxwell:It's just the kind of superficial thing that people can discuss forever. e.g. "random POW generator"
19:12:49justanotheruser: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:32adam3us: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:59adam3us:justanotheruser: seems to me asic-hardness ends up using more electricity typically
19:15:15jtimon:justanotheruser when your ASIC competitors are doing 4% profits, will you mine at -1%?
19:16:20justanotheruser:jtimon: ASICs probably wouldn't give them 4% profits because they would have to buy new hardware
19:16:42adam3us: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:47justanotheruser:The ops here seem to want us to change the topic though.
19:16:59jtimon:profits = gains after all costs, including capital costs
19:17:52justanotheruser:jtimon: I don't understand why you defined profits. It doesn't really change anything about what I said.
19:18:36adam3us:as i recall no one found a good answer to the 25/33% attack, and ghash is at 34% now coincidentally
19:19:40justanotheruser:adam3us: what's the 25/33% attack? Just them being able do a large reorg some of the time?
19:19:52gmaxwell: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:41maaku: why does this pow wanking keep going on here? I can't imagine a less interesting subject. <--- thank you :)
19:21:56adam3us: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:44justanotheruser:adam3us: and with 25% you can do this too?
19:22:45c0rw1n:is there a pool that takes over 33% of the network regularly?
19:22:47adam3us: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:19adam3us: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:26gmaxwell: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:08adam3us:justanotheruser: with 25% you can still get an advantage presuming you can succeed to race publication of other winners via good connectivity
19:24:18jtimon:gmaxwell are you suggesting that ghash selfmines and that's why it gets more orphans?
19:24:33adam3us:jtimon: its plausible that would be the side effect
19:24:40justanotheruser:adam3us: So what percentage of blocks can you get given you have N% of the network? Is there a formula?
19:24:41c0rw1n:i parsed it as "that, or they're doing something wrong with their connetivity"
19:25:03c0rw1n:justanotheruser yeah there is a formula. in involves the variance
19:25:19gmaxwell:jtimon: someone should crunch the data and see if it supports that theory.
19:25:26adam3us:justanotheruser: they have a graph in their paper, its not fully modeling some real-world effects, but its interesting and should work
19:25:57jtimon:so you could as well call "selfish mining", "block relay time optimization"
19:26:04gmaxwell:I have noticed an increase in depth 2 orphaning, so if so I don't think they're doing it successfully.
19:26:10jtimon:how will that destroy bitcoin?
19:26:17justanotheruser: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:34adam3us:justanotheruser: selfish-mining http://arxiv.org/pdf/1311.0243v2.pdf
19:27:20jtimon:I guess we would need to estimate their real block distribution latency to calculate the time they hold their blocks?
19:27:48jtimon:I don't know, network topology...too hard of a problem for me
19:27:53gmaxwell: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:24justanotheruser: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:49c0rw1n:that may be a symptom if i got it right
19:29:50jtimon:would consecutive blocks for parties be significant?
19:29:59gmaxwell:jtimon: happens naturally.
19:30:13jtimon:I mean, count how many times they mine 2 in a row, 3 in a row, etc
19:30:16gmaxwell:more than you'd expect based on their hashrate would be interesting.
19:30:33gmaxwell:but the data is perhaps too undersampled to say with confidence.
19:30:51gmaxwell:long reorgs are more surprising.
19:31:11adam3us: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:25gmaxwell:sure though thats detectable for people mining on them.
19:32:09adam3us: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:58gmaxwell: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:15jtimon: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:36maaku: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:35c0rw1n:*click* that's interesting
19:34:37gmaxwell:maaku: how would it know public?
19:34:50c0rw1n:it could blockchain the mining stats?
19:35:02gmaxwell:"blockchain the mining stats"
19:35:03maaku:gmaxwell: either from local bitcoind or by asking Eliguis
19:35:04gmaxwell:* gmaxwell zot
19:35:14sipa:c0rw1n: i hope you're kidding
19:35:40sipa:* sipa gets his hammer; c0rw1n looks like a nail
19:35:58gmaxwell:maaku: I guess it can poll all configured pools and log when their prevs are different.
19:35:59c0rw1n:'k i'll shut up if i'm not this smart enough to talk :$
19:36:40gmaxwell:maaku: It's odd that miners don't equal loadbalance pools almost at all, since that minimizes variance.
19:36:49adam3us:gmaxwell: well they could hide the most recent block by handing different blocks with same parent block (assuming GBT was not used)
19:36:51gmaxwell:but I guess thats because they count on pools for monitoring/stats (doh)
19:37:30jtimon:"assuming GBT was not used"
19:38:18maaku: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:57jtimon:what makes more expensive for pools to mine gbt/p2pool, bandwidth ?
19:41:00adam3us:maaku: selfish pool spot checking in mining client. not a bad feature.
19:42:43jtimon:maaku I don't get it wouldn't you detect selfish mining on your pool with p2pool/gbt alone ?
19:45:13jtimon:in p2pool concretely, could the pool operator find the block without the rest of the pool noticing?
19:46:44adam3us:jtimon: isnt p2pool p2p so there is no (central) operator so everyone learns everything?
19:47:37jtimon: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:04gwern:gwern has left #bitcoin-wizards
19:49:00adam3us: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:40gmaxwell:adam3us: thats right.
19:50:02gmaxwell:there is no operator it just works like bitcoin itself does to get a payout consensus.
19:54:15Meistarin:Meistarin has left #bitcoin-wizards
19:54:41jtimon:so selfish mining is not possible with p2pool? what about gbt?
20:08:46jtimon:well, probably better here, maaku no answer from the concatenative people, no?
20:09:14maaku:no, not yet
20:11:51maaku:jtimon: I did email one concatenative researcher who was working on relevant stuff
20:11:58maaku:hopefully I'll hear back at least from him
20:16:42nsh:what's this in reference to, maaku/jtimon?
20:18:09jtimon:in relation to the latests merklized turing complete scripting language
20:19:13maaku:nsh: replacing bitcoin script with a turing-complete concatenative language a la Joy, Cat
20:19:38jtimon:maaku emailed a group inciting them to help us design it and become bitcoin scripting language experts, hehe
20:20:00nsh:* nsh has not read much about concatenative programming languages, if anything at all
20:20:06jtimon:also now in #concatenative but doesn't seem a very active channel
20:20:19maaku:nsh: well, bitcoin script is a concatenative language
20:20:26maaku:just not a very expressive one
20:20:38maaku:basically anything Forth-derived, like postscript
20:20:49maaku:stack based languages
20:21:19jtimon: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:27nsh:oh, thanks
20:21:37nsh:former already open in tab :)
20:22:23jtimon:hehe, still I have them in the tab too, only started reading the first one
20:22:42maaku:i like that the first link goes over arithmetic expressions ... it's honest :)
20:24:17maaku:f x y z = y^2 + x^2 - |y| = drop dup dup × swap abs rot3 dup × swap − +
20:24:43maaku:yuck... but as an intermediate "high level assembly" representation it has its advantages
20:27:55sipa:in ast: -(+(*($2,$2),*($3,$3)),abs($2))
21:00:33adam3us: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:52adam3us: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:44adam3us:(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:26adam3us: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:08nsh:what do fractional confirmations mean?
21:06:53adam3us: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:23adam3us: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:42adam3us:nsh: or a 1/100th difficulty. with the objective to make pools less critical for more people.
21:09:10adam3us: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:36nsh:i'll take your word for it :)
21:11:31adam3us: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:47nsh:* nsh nods
21:12:48amiller:well the same you build on other people's blocks rather than undermining them
21:12:52amiller:same reason*
21:13:22amiller:i mean, you can get the full size reward by building on the 0.1 block too
21:13:31adam3us: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:57adam3us:amiller: oh i see, got it. no new incentive to orphan
21:15:02sipa:i'm not sure the discreteness of increments to the total work is irrelevant
21:15:11adam3us:amiller: you also said you thought you'd have to use GHOST if i recll
21:15:37adam3us:amiller: to combat the faster variable-sized block interval that may result
21:15:47amiller: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:26adam3us:sipa: i think its utility is it reduces the need to pool. you can more likely direct mine.
21:16:39amiller: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:57amiller:but it's okay if there are two parameters clamping this space...
21:17:23amiller:(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:24adam3us:amiller: do you know how GHOST proposes reward works i the adopted non-conflicting orphans in a give block?
21:17:33amiller:ghost proposes no rewards i believe
21:17:49amiller:i think it might not hurt to just include the rewards
21:17:59amiller:i'm not sure thouhg.
21:18:22adam3us:amiller: i think there would need to be some incentive to adopt orphans?
21:19:27amiller:yeah, i don't have any good answer for how that should work
21:19:37StAv2:StAv2 has left #bitcoin-wizards
21:23:25adam3us: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:41maaku:adam3us: what do you mean by adopt? GHOST doesn't have anything like that (or need it)
21:24:17adam3us: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:19amiller:i get nauseous everytime there appears to be another parameter to adjust to reward/discourage some behavior like orphan vs building
21:24:48amiller: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:52nsh:amiller, works for the standard model...
21:25:01maaku:adam3us: no, ghost is just a new algorithm for selecting best block, taking into account stale blocks you might have seen
21:25:07adam3us: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:18nsh:all we need is like 30-60 finely-tweaked otherwise-inexplicable parameters
21:25:27maaku:adam3us: it's a local algorithm, not consensus based
21:25:38adam3us:maaku: oh, seems i misunderstood it!
21:26:24sipa:maaku: what do you mean by local?
21:26:26nsh:(then we "explain" it by resource to a anthropic blockchain landscape)
21:26:28adam3us:maaku: so which is the best block in ghost?
21:26:57adam3us:amiller: yeah i think game-theory and self-interest are security-fragile.
21:27:14maaku:adam3us: at each step, choose the branch with the most total work, including stales
21:27:39amiller:but, we now have a more specific guiding goal
21:27:43sipa:maaku: right, but that can change over time
21:27:53amiller:getting whatever people want or can get from p2pool within the main game itself....
21:28:34maaku:sipa: yes, but with a stable outcome
21:29:26adam3us: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:45adam3us:maaku: (I mean you switch to mining on)
21:31:58maaku: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:50maaku:if two branches have the same weight, then you use some other factor (like say when you heard about it)
21:33:06maaku:but yes, maybe one has more stales and therefore more weight
21:33:20maaku:another way of saying this is choose the branch that you have more evidence of hashpower commitement to
21:33:34maaku:because, in the long run, it's the branch more likely to pull ahead
21:33:35qwertyoruiop:maaku: so basically, 51% easier.
21:33:47maaku:qwertyoruiop: ?
21:34:09qwertyoruiop:the biggest pool can have more luck at double spending
21:34:36maaku:qwertyoruiop: no. not unless they are already >50%
21:35:16qwertyoruiop:you'd be making it easier for < 50% attackers trying to doublespend.
21:35:26maaku:qwertyoruiop: no i'd be harder
21:36:54maaku:because if the attacker has <50%, then he would have less evidence of work on his chain
21:37:07maaku:so people *wouldn't* switch to it, even if he managed to pull ahead by getting lucky
21:37:49adam3us: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:17maaku:he'd have to surpass not just the linear work of the honest chain, but all the stales too
21:38:29adam3us:maaku: doesn the orphan still get no reward and so give advantge to better latency connected miners?
21:38:41qwertyoruiop:what would exactly the point of adopting orphans be?
21:38:43maaku:adam3us: stales not orphans, and there's no reason to decrease the interblock time
21:39:12maaku:it gets you no practical advantage with a *huge* hit to SPV users
21:39:13adam3us:maaku: well i know no need, but i thought that was one of their claimed reasons and advantages for the approach?
21:39:28maaku:they misunderstand the tradeoffs involved
21:39:37maaku:but yes, that is what they are proposing
21:40:06adam3us:qwertyoruiop: maaku is explaining there is no orphan adoption in ghost
21:40:08maaku:GHOST lets you approach closer to the limits of what given bandwidth and latency assumptions allow
21:40:22maaku:closer that stock bitcoin at least
21:40:42adam3us:maaku: but that seems to create centralization risks if there is no reward for stales
21:40:51adam3us:maaku: (latency centralization)
21:41:34maaku:adam3us: bitcoin protocol is not the place to correct that
21:41:44maaku:do something like p2pool does
21:42:06maaku:adam3us: GHOST lets us increase the block size more, or decrease the block interval lower
21:42:35maaku:they mistakenly advocate shorter block times when in fact larger block sizes are more likely
21:43:25maaku: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:29maaku:(i'm making up numbers)
21:44:37maaku: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:40maaku:(forrestv ^^)
21:45:31justanotheruser: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:46:12adam3us: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:17maaku:justanotheruser: or, you could simply point a miner at their pool and see if they're building of non-public work
21:46:41maaku:adam3us: advocating smaller interblock times (bad) vs. increasing the block size (good)
21:47:15maaku:smaller interblock times get you nothing unless you can get under a second
21:47:19maaku:which is impossible
21:47:33maaku:so actually, we want the *largest* acceptable interblock time
21:47:46maaku:since that minimizes strain on SPV devices
21:48:05justanotheruser:maaku: wow, that is a lot easier
21:48:33justanotheruser:maaku: except they might be doing this attack using cex.io
21:49:06adam3us: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:40maaku:justanotheruser: correct, hosted miners are far worse than pools
21:50:49adam3us: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:52maaku:adam3us: SPV nodes must download headers + merkle path + coinbase tx for every block. that alone is a large but manageable cost already
21:52:06maaku:plus they must perform a boom or prefix query for the contents of each block
21:52:27sipa:* sipa likes boom queries
21:54:09adam3us: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:53sipa:adam3us: depends on whether your attack model is about someone buying hash power, or buying hashes
21:54:55adam3us: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:56sipa:i think
21:55:18maaku:adam3us: yes, but how often are those few minutes really worth it?
21:55:52adam3us:maaku: (sorry meant "ltc faster..." not "ltc securer" as people said yes but weaker so not usefully faster)
21:56:07maaku: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:24adam3us:maaku: spv min feed bloat is bad, yes.
21:57:42justanotheruser:Any idea how much of ghash is cloud mining?
21:57:45adam3us: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:02maaku:adam3us: actually it is generally true that you should compare confirmations, not work done
21:58:11maaku:at least in standard bitcoin
21:58:29maaku:and so long as you're not approaching bandwith/latency limits
21:59:06adam3us: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:14sipa:maaku: i've suggested using (total_work_at_tip - total_work_at_inclusion)/current_difficulty as measure for confirmations
21:59:31sipa:"PoW equivalent time"
22:00:05adam3us:maaku: you cant determine work done really. luck. if you meant that in a strict sense
22:00:24michagogo|cloud:;;later tell andytoshi Heh, your cj client is impossible to use on unencrypted wallets
22:00:24gribble:The operation succeeded.
22:01:28sipa:unfortunately, the current PoW-equivalent confirmation time of the genesis block is around 50 days
22:01:50adam3us:maaku: maybe you meant compare ltc 6-conf to btc 6-conf (rather than compare ltc 24 to btc 6)
22:03:08adam3us: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:41maaku:michagogo|cloud: why?
22:03:52michagogo|cloud:Because it assumes there's a passphrase
22:04:15maaku:michagogo|cloud: ah
22:04:16adam3us:sipa: the formula is nice for long confirmations separated by difficulty adjustments
22:04:34michagogo|cloud:maaku: http://imgur.com/4RYgCpJ
22:04:49maaku:adam3us: i'm saying ltc 6-conf is equal to btc 6-conf in realistic attack scenarios
22:05:13maaku:e.g. a pool trying to win money from a zero-conf service
22:06:35maaku:if the question is "what's the probability of my fraud chain pulling ahead?" interblock time doesn't factor into that
22:06:38sipa:adam3us: http://bitcoin.sipa.be/powdays-50k.png
22:06:57adam3us:sipa: yeah i know, i saw it, very nice :)
22:09:26maaku:sipa: it's an interesting measure, but it doesn't really factor into real attack analysis now does it?
22:10:03maaku:i should say, it's relevant if you can actually pull off a 51% attack
22:11:02maaku: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:50gmaxwell:maaku: so modifying your statement, "foocoin with 1ns blocks 6-conf is equal to btc 6-conf in realistic attack scenarios"
22:15:39adam3us:gmaxwell: i think it sipa had it better, shorter interval = lower reward loss/lower PoW cycles; but same probability
22:15:56maaku:[13:58:25] and so long as you're not approaching bandwith/latency limits
22:16:10adam3us:maaku: exactly.
22:18:25adam3us: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:28adam3us: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:09maaku:adam3us: yes, but if you're trying every block then your costs similarly increase
22:21:20maaku:and the payoff remains the same, if measured as expected gain/loss per block
22:22:07gmaxwell:maaku: ignoring that fact that orphaning causes increased hashpower dillution
22:22:18gmaxwell:thats why I gave the 1ns example.
22:22:27adam3us:maaku: so probability of being able to double spend goes from p^6 to 1-(1-p^6)^4
22:23:07adam3us:maaku: eg 25% hash power from .024% to .098%
22:24:08adam3us:maaku: your costs are the same i think .. no reward for 1hr period presuming same reward distribution per hour
22:24:44maaku:adam3us: the costs are whatever you're trying to double-spend, not the reward per se
22:25:01maaku:adam3us: also there's a reason I said "assuming standard bitcoin"
22:25:06adam3us:maaku: thats a (misgotten) profit not a cost?
22:25:26maaku:if you assume GHOST, then it actually makes the double-spend harder to pull off
22:25:43adam3us:maaku: (assuming something liquid with low commission to trade against with your fraud, like say ltc/btc or whatever)
22:25:47maaku:because the honest chain has stales the fraud chain does not
22:26:22maaku:and if you assume fractional proof of works are distributed it gets worse for the attacker
22:27:04maaku:adam3us: you will never find zero commision, zero spread
22:29:14adam3us:maaku: agreed the commission & spread is the additional cost
22:33:30adam3us: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:25adam3us:maaku: p^6=.024%, p^8=.0015%, 1-(1-p^6)^4=.098%, 1-(1-p^8)^3=.0046%
22:42:54adam3us: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:06andytoshi:michagogo|cloud: that's correct, i am mulling over supporting unencrypted wallets
23:09:26andytoshi:michagogo|cloud: i just put a passphrase on my testnet wallet, which was annoying..
23:47:17jcrubino:jcrubino has left #bitcoin-wizards