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