00:00:55abc56889:well, shit :p
02:19:45Luke-Jr:abc56889: tbh, I'm surprised nobody's abused it yet. they'd get effectively 200% PPS
02:21:56phantomcircuit:Luke-Jr, i thought about doing it but then decided not to
02:51:09G_Qu:evening all
03:55:24abc56889:Luke-Jr: I thought about it and it seemed to me that rather than getting 200% PPS, they'd just kick some capacity out of the network temporarily and the difference would go to the entire bitcoin network, not just the p2pool instance.
03:55:47Luke-Jr:abc56889: ?
03:55:50Adohgg:Adohgg is now known as professor_bitcor
03:56:26abc56889:re p2pool/51%.
03:57:20Luke-Jr:abc56889: well.. you're wrong? :p
03:58:38Luke-Jr:(I can't explain how you're wrong since you didn't explain hwo you came to that conclusion)
04:04:27wallet42:wallet42 is now known as Guest15561
04:04:27wallet421:wallet421 is now known as wallet42
04:28:30Guest14473:abc56889: the attacker would drop shares but build off blocks
04:29:47abc56889:Luke-Jr: p2pool attacker stops including other peer's blocks in share chain. It doesn't increase the number of bitcoin blocks he'll discover though. p2pool 49%ers temporarily have 100% orphan rate.
04:30:20Guest14473:abc56889: it does increase the number of blocks if he lets blocks through
04:30:27abc56889:until they realise whats going on and join another pool.
04:30:33Luke-Jr:abc56889: the other peers keep building blocks with the attacker in the payout
04:31:44Guest14473:abc56889: when the 49%-er builds a block, they use the longest share chain, which includes only the attacker
04:31:59Guest14473:so when they do find a block, it gets on the bitcoin network and pays to the attacker
04:32:14Guest14473:with just 0.5% going to the 49%-er
04:33:17abc56889:cripes. thats right isnt it
04:35:20abc56889:I was wrong then. So is that easy to mitigate against, by clients not releasing blocks if their share orphan rate is too high?
04:35:56Guest14473:well it should be automatic anyway that if your orphan rate is too high you go elsewhere
04:35:56Luke-Jr:you don't want to block withhold
04:36:01Luke-Jr:just reject the chain before you mine it
04:36:17Luke-Jr:but then the attacker just programs in the rule
04:36:23Luke-Jr:and gets just-under that limit
04:49:14Guest14473:Guest14473 is now known as maaku
07:30:21professor_bitcor:professor_bitcor is now known as Adohgg
07:32:55maaku:maaku is now known as Guest83623
10:02:34cajg_:cajg_ is now known as cajg
11:50:48BurritoBazooka:BurritoBazooka has left #bitcoin-wizards
13:08:09fanquake:fanquake has left #bitcoin-wizards
13:48:21mr_burde_:mr_burde_ is now known as mr_burdell
14:41:43Guest83623:Guest83623 is now known as maaku
14:56:06Quanttek_:Quanttek_ is now known as Quanttek
14:59:40Eliel:I think this misconception is part of the reason ghash.io grew so big. (well, my gut says there's something wrong with the calculation. but I'm having trouble pinpointing the problem.) https://www.reddit.com/r/Bitcoin/comments/282r9g/infograph_math_about_big_vs_small_pools/
15:00:33Eliel:I don't think the 0.16% extra for a big pool is true I mean
15:01:24Eliel:I suppose the problem is with the wasted time concept.
15:01:41dsnrk:I don't understand what "time wasted" is supposed to be
15:02:29Eliel:I guess the thinking goes like "you hash -> you don't find a block and difficulty increases -> you wasted that work."
15:03:59dsnrk:huh. the expected outcome would be the same.
15:04:31Eliel:the problem is, most miners can't spot the problem and will think that's true.
15:04:51dsnrk:it doesn't matter if I am mining in the biggest pool, the smallest pool, or solo. the expected outcome will always be the same. (ignoring orphans, all that)
15:05:22dsnrk:they're probably worse off with ghash.io compared with any other pool. ghash.io has a terrible orphan block rate.
15:28:09Adohgg:Adohgg is now known as PROFESSOR_BITCOR
15:33:05PROFESSOR_BITCOR:PROFESSOR_BITCOR is now known as Adohgg
15:39:51amiller:Eliel, dsnrk what does that have to do with the "while the difficulty is increasing" bit
15:40:05amiller:i still don't think it makes sense, but i also don't undersatnd what it is they thinkt hey're syaing with that
15:46:33jgarzik:* jgarzik destroys the thesis for MyriadCoin in one tweet.
15:57:44ielo:amiller, i disagree,
15:57:52ielo:ielo has left #bitcoin-wizards
15:59:03jgarzik:Can you soft-fork a block? Soft upgrade to sha256x2 + $newalgo, where old miners validate PoW algo v1, but new miners validate PoW algo v2.
15:59:21jgarzik:I suppose you could faux-merge-mine and require the second algo be in the merge-mined area.
16:00:14sl01:jgarzik: which attack surface are you referring?
16:01:13jgarzik:sl01, eliminating Single Point Of Failure at the algo level, by presuming any one algo may be eventually weakened
16:01:46jgarzik:sl01, upgrading PoW algo in bitcoin takes time and thinking. never a "flag day"
16:01:48sl01:isn't that more of an issue for the non PoW parts of btc though ?
16:02:58amiller:thats not an arugment against working it out for the PoW part sl01
16:03:21jgarzik:sl01, it is an issue yes, but you have a much larger economic motivation to pursue a weakened PoW for your own gain
16:04:01sl01:hrm, and adding another one doesn't increase attack surface? by adding more potential things to weaken?
16:04:24jgarzik:The three big areas of note (missing any?) are: PoW algo (sha256x2), validation algo (sha256x2), and ECDSA signatures
16:06:06amiller:jgarzik, if $newalgo is roughly the same cost as sha2, doesn't that mean increasing the difficulty for new miners?
16:06:08jgarzik:sl01, it is the same basic SPOF logic applied elsewhere. The number of things to attack are increased, but your resilience against attack and failure is also increased.
16:06:17amiller:by, say, 50%?
16:06:46jgarzik:amiller, I would say introduction costs seem likely to be highly asymmetric at first :/
16:07:37sl01:i undersatnd the logic for spof, but it might actually introduce more attack surface in terms of secret weakenings
16:08:10jgarzik:sl01, familiar argument for decentralized systems in general. DC introduces more complexity than a centralized system, and as such, are more difficult to secure (or to reason through and assure yourself they are secure)
16:08:21Eliel:jgarzik: I think you'd have to figure out some way to reward the miners who do the new algo.
16:08:27Eliel:without hard fork
16:08:47amiller:you could do that in a pretty loose way just with a foundation fund
16:08:54jgarzik:Eliel, That's a can of worms
16:08:58amiller:enough just to steer people through until it's accepted as a hardfork
16:09:02amiller:like for a year
16:09:04sl01:easier to find weakness in either SHA256 or SHA3 than just in either one
16:09:12jgarzik:cost cost cost
16:09:21jgarzik:What is the easiest for hardware vendors to implement today?
16:09:34sl01:or is it possible to do it ina way that you have to weaken both of them at the same time to get any advantage?
16:09:53jgarzik:sha256-scrypt :)
16:10:03Eliel:we have already existing hardware accelerators for aes in intel processors at least :P
16:15:17sl01:Eliel: and i think intel chips will have sha accelerators in 2015
16:21:40jgarzik:sl01, Intel chips already do SHA1
16:21:50sl01:you sure about that ?
16:22:40sl01:i think it's new in skylake which isn't out yet http://en.wikipedia.org/wiki/Skylake_(microarchitecture)
16:22:58jgarzik:sl01, https://software.intel.com/en-us/articles/intel-sha-extensions
16:23:39sl01:right, i dont think thats out till 2015
16:24:48jgarzik:it's out in dev
16:25:22sl01:what's that mean?
16:37:02jgarzik:sl01, the chips exist, and are probably in the hands of Red Hat and Microsoft
16:37:13jgarzik:and whoever else gets early SDVs
16:38:07sl01:jgarzik: ah ok yea makes sense
16:40:10sl01:although then you should say Intel chips already do SHA1 and SHA256 :P
16:54:18jgarzik:sl01, I could have sworn that SHA1 was already rolled out, ahead of SHA256, but maybe that's wrong info.
16:55:05jgarzik:sl01, Nope, I was right, SHA1 came with Sandy Bridge: http://en.wikipedia.org/wiki/Sandy_Bridge
16:56:37sl01:ah no shit... we were looking at this the other day for openssl, do you know if openssl makes use of it?
16:57:22sl01:i didn't see any speedup between evp and non evp (for sha1), but maybe openssl always uses the SHA instructions if they're available
17:00:00sl01:I see the stuff already out there just uses SSE to make a faster SHA implementation, the new stuff are actual specific SHA instruction sets
17:15:59nsh:sl01, SSE?
17:16:40nsh:Streaming SIMD Extensions
17:23:00sl01:yea SSE3 apparently https://software.intel.com/en-us/articles/improving-the-performance-of-the-secure-hash-algorithm-1, i wonder how much faster the new instructions will be
18:56:32cym:cym is now known as pen
19:40:30Luke-Jr:sl01: SHA1 is not SHA2
19:43:13sl01:Luke-Jr: i know this, why are u telling me? :P
20:26:03kazcw:kazcw has left #bitcoin-wizards
20:29:02amiller:seen this paper? http://arxiv.org/pdf/1405.7418v2.pdf
20:29:16amiller:Deanonymisation of clients in Bitcoin P2P network
20:30:55midnightmagic:amiller: Hah are those the guys? flashlights in the dark?
20:31:06amiller:what guys?
20:31:11amiller:what's flashlights in the dark?
20:31:31amiller:midnightmagic, ?
20:34:08amiller:The actual transmission of the scheduled ADDR messages
20:34:08amiller:does not happen immediately. Every 100 milliseconds one
20:34:08amiller:neighbour is randomly selected from the list o all peer's
20:34:08amiller:neighbours and the queue for outgoing ADDR messages is
20:34:08amiller:ushed for this node only. We call the node chosen at the
20:34:09amiller:beginning of a 100 milliseconds round trickle node and the
20:34:13amiller:procedure as a whole as trickling.
20:34:15amiller:is that even true?
20:39:26nsh:The crucial idea is that each client can be uniquely iden-
20:39:26nsh:tified by a set of nodes he connects to (entry nodes). We
20:39:26nsh:show that this set can be learned at the time of connection
20:39:26nsh:and then used to identify the origin of a transaction.
20:39:27nsh:-- *frown*
20:40:11nsh:In a concrete example, an attacker with
20:40:12nsh:a few GB of storage and no more than 50 connections to each
20:40:12nsh:Bitcoin server can disclose the sender’s IP address in 11% 3
20:40:12nsh:of all transactions generated in the Bitcoin network. If the
20:40:12nsh:attacker allows a slight DoS of the network, he may achieve
20:40:12nsh:deanonymization rates up to 60%, which has been confirmed
20:40:14nsh:by the experiments in the Bitcoin test network. We estimate
20:40:16nsh:the cost of the attack on the full bitcoin network to be under
20:40:18nsh:1500 EUR per month.
20:40:20nsh:-- science does not work that way.
20:40:57Apocalyptic:nsh, pastebin next time ?
20:48:30jgarzik:Am starting to use the term "pre-stake" rather than "pre-mine"
20:48:53G_Qu:afternoon everybody
20:54:45nsh:amiller, entry peer randomisation would be a mitigation but the ADDR/transaction propagation logic could probably do with some side-channel analysis. it's stateful and leaks state through timing and diffusion statistics
20:55:52nsh:not sure i trust their estimates for attack costs but i doesn't seem infeasible that the technique could be used to some annoyance
20:56:16nsh:(e.g. extortion)
21:00:49midnightmagic:Running multiply-connected nodes to more than one major networks would help users defeat the Tor disconnection tactic; besides, Tor-only nodes are immune to it. The interesting comments they have in there seem to be suggesting that connections themselves be made more expensive by PoW-like mechanisms applied to them, which reminds me of gmaxwell's old proof-of-storage comments from way back..
21:03:46midnightmagic:So.. possible countermeasures against their attack are pointless because botnet.
21:03:53midnightmagic:(p. 5)
21:04:44midnightmagic:As is their apprehension of ASIC's reconfigurability for a plain SHA2 PoW function (since they're all dSHA2)
22:07:12G_Qu:hey there everyone. looking for a resource that demonstrates how to write the cpp OP codes in script for Apple terminal. Anyone?
22:10:48amiller:G_Qu, that's offtopic try #bitcoin-dev I guess
22:11:14G_Qu:thanks amiller
22:11:31G_Qu:G_Qu has left #bitcoin-wizards
22:41:03Guest12621:Guest12621 is now known as ageis