00:00:55 | abc56889: | well, shit :p |
02:19:45 | Luke-Jr: | abc56889: tbh, I'm surprised nobody's abused it yet. they'd get effectively 200% PPS |
02:21:56 | phantomcircuit: | Luke-Jr, i thought about doing it but then decided not to |
02:51:09 | G_Qu: | evening all |
03:55:24 | abc56889: | 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:47 | Luke-Jr: | abc56889: ? |
03:55:50 | Adohgg: | Adohgg is now known as professor_bitcor |
03:56:26 | abc56889: | re p2pool/51%. |
03:57:20 | Luke-Jr: | abc56889: well.. you're wrong? :p |
03:58:38 | Luke-Jr: | (I can't explain how you're wrong since you didn't explain hwo you came to that conclusion) |
04:04:27 | wallet42: | wallet42 is now known as Guest15561 |
04:04:27 | wallet421: | wallet421 is now known as wallet42 |
04:28:30 | Guest14473: | abc56889: the attacker would drop shares but build off blocks |
04:29:47 | abc56889: | 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:20 | Guest14473: | abc56889: it does increase the number of blocks if he lets blocks through |
04:30:27 | abc56889: | until they realise whats going on and join another pool. |
04:30:33 | Luke-Jr: | abc56889: the other peers keep building blocks with the attacker in the payout |
04:31:44 | Guest14473: | abc56889: when the 49%-er builds a block, they use the longest share chain, which includes only the attacker |
04:31:59 | Guest14473: | so when they do find a block, it gets on the bitcoin network and pays to the attacker |
04:32:14 | Guest14473: | with just 0.5% going to the 49%-er |
04:33:17 | abc56889: | cripes. thats right isnt it |
04:35:20 | abc56889: | 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:56 | Guest14473: | well it should be automatic anyway that if your orphan rate is too high you go elsewhere |
04:35:56 | Luke-Jr: | you don't want to block withhold |
04:36:01 | Luke-Jr: | just reject the chain before you mine it |
04:36:17 | Luke-Jr: | but then the attacker just programs in the rule |
04:36:23 | Luke-Jr: | and gets just-under that limit |
04:49:14 | Guest14473: | Guest14473 is now known as maaku |
07:30:21 | professor_bitcor: | professor_bitcor is now known as Adohgg |
07:32:55 | maaku: | maaku is now known as Guest83623 |
10:02:34 | cajg_: | cajg_ is now known as cajg |
11:50:48 | BurritoBazooka: | BurritoBazooka has left #bitcoin-wizards |
13:08:09 | fanquake: | fanquake has left #bitcoin-wizards |
13:48:21 | mr_burde_: | mr_burde_ is now known as mr_burdell |
14:41:43 | Guest83623: | Guest83623 is now known as maaku |
14:56:06 | Quanttek_: | Quanttek_ is now known as Quanttek |
14:59:40 | Eliel: | 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:33 | Eliel: | I don't think the 0.16% extra for a big pool is true I mean |
15:01:24 | Eliel: | I suppose the problem is with the wasted time concept. |
15:01:41 | dsnrk: | I don't understand what "time wasted" is supposed to be |
15:02:29 | Eliel: | I guess the thinking goes like "you hash -> you don't find a block and difficulty increases -> you wasted that work." |
15:03:59 | dsnrk: | huh. the expected outcome would be the same. |
15:04:31 | Eliel: | the problem is, most miners can't spot the problem and will think that's true. |
15:04:51 | dsnrk: | 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:22 | dsnrk: | they're probably worse off with ghash.io compared with any other pool. ghash.io has a terrible orphan block rate. |
15:28:09 | Adohgg: | Adohgg is now known as PROFESSOR_BITCOR |
15:33:05 | PROFESSOR_BITCOR: | PROFESSOR_BITCOR is now known as Adohgg |
15:39:51 | amiller: | Eliel, dsnrk what does that have to do with the "while the difficulty is increasing" bit |
15:40:05 | amiller: | 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:25 | jgarzik: | zing. |
15:46:33 | jgarzik: | * jgarzik destroys the thesis for MyriadCoin in one tweet. |
15:57:44 | ielo: | amiller, i disagree, |
15:57:52 | ielo: | ielo has left #bitcoin-wizards |
15:58:11 | jgarzik: | Random: |
15:59:03 | jgarzik: | 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:21 | jgarzik: | I suppose you could faux-merge-mine and require the second algo be in the merge-mined area. |
16:00:14 | sl01: | jgarzik: which attack surface are you referring? |
16:01:13 | jgarzik: | sl01, eliminating Single Point Of Failure at the algo level, by presuming any one algo may be eventually weakened |
16:01:46 | jgarzik: | sl01, upgrading PoW algo in bitcoin takes time and thinking. never a "flag day" |
16:01:48 | sl01: | isn't that more of an issue for the non PoW parts of btc though ? |
16:02:58 | amiller: | thats not an arugment against working it out for the PoW part sl01 |
16:03:21 | jgarzik: | 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:01 | sl01: | hrm, and adding another one doesn't increase attack surface? by adding more potential things to weaken? |
16:04:24 | jgarzik: | The three big areas of note (missing any?) are: PoW algo (sha256x2), validation algo (sha256x2), and ECDSA signatures |
16:06:06 | amiller: | jgarzik, if $newalgo is roughly the same cost as sha2, doesn't that mean increasing the difficulty for new miners? |
16:06:08 | jgarzik: | 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:17 | amiller: | by, say, 50%? |
16:06:46 | jgarzik: | amiller, I would say introduction costs seem likely to be highly asymmetric at first :/ |
16:07:37 | sl01: | i undersatnd the logic for spof, but it might actually introduce more attack surface in terms of secret weakenings |
16:08:10 | jgarzik: | 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:21 | Eliel: | jgarzik: I think you'd have to figure out some way to reward the miners who do the new algo. |
16:08:27 | Eliel: | without hard fork |
16:08:33 | amiller: | hmmm |
16:08:47 | amiller: | you could do that in a pretty loose way just with a foundation fund |
16:08:54 | jgarzik: | Eliel, That's a can of worms |
16:08:58 | amiller: | enough just to steer people through until it's accepted as a hardfork |
16:09:02 | amiller: | like for a year |
16:09:04 | sl01: | easier to find weakness in either SHA256 or SHA3 than just in either one |
16:09:12 | jgarzik: | cost cost cost |
16:09:21 | jgarzik: | What is the easiest for hardware vendors to implement today? |
16:09:34 | sl01: | 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:53 | jgarzik: | sha256-scrypt :) |
16:10:03 | Eliel: | we have already existing hardware accelerators for aes in intel processors at least :P |
16:15:17 | sl01: | Eliel: and i think intel chips will have sha accelerators in 2015 |
16:21:40 | jgarzik: | sl01, Intel chips already do SHA1 |
16:21:50 | sl01: | you sure about that ? |
16:22:40 | sl01: | i think it's new in skylake which isn't out yet http://en.wikipedia.org/wiki/Skylake_(microarchitecture) |
16:22:58 | jgarzik: | sl01, https://software.intel.com/en-us/articles/intel-sha-extensions |
16:23:39 | sl01: | right, i dont think thats out till 2015 |
16:24:48 | jgarzik: | it's out in dev |
16:25:22 | sl01: | what's that mean? |
16:37:02 | jgarzik: | sl01, the chips exist, and are probably in the hands of Red Hat and Microsoft |
16:37:13 | jgarzik: | and whoever else gets early SDVs |
16:38:07 | sl01: | jgarzik: ah ok yea makes sense |
16:40:10 | sl01: | although then you should say Intel chips already do SHA1 and SHA256 :P |
16:54:18 | jgarzik: | sl01, I could have sworn that SHA1 was already rolled out, ahead of SHA256, but maybe that's wrong info. |
16:55:05 | jgarzik: | sl01, Nope, I was right, SHA1 came with Sandy Bridge: http://en.wikipedia.org/wiki/Sandy_Bridge |
16:56:37 | sl01: | ah no shit... we were looking at this the other day for openssl, do you know if openssl makes use of it? |
16:57:22 | sl01: | 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:00 | sl01: | 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:59 | nsh: | sl01, SSE? |
17:16:40 | nsh: | Streaming SIMD Extensions |
17:23:00 | sl01: | 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 |
17:25:17 | nsh: | hmm |
18:38:08 | danneu: | go |
18:56:32 | cym: | cym is now known as pen |
19:40:30 | Luke-Jr: | sl01: SHA1 is not SHA2 |
19:43:13 | sl01: | Luke-Jr: i know this, why are u telling me? :P |
20:26:03 | kazcw: | kazcw has left #bitcoin-wizards |
20:29:02 | amiller: | seen this paper? http://arxiv.org/pdf/1405.7418v2.pdf |
20:29:16 | amiller: | Deanonymisation of clients in Bitcoin P2P network |
20:30:55 | midnightmagic: | amiller: Hah are those the guys? flashlights in the dark? |
20:31:06 | amiller: | what guys? |
20:31:11 | amiller: | what's flashlights in the dark? |
20:31:31 | amiller: | midnightmagic, ? |
20:34:08 | amiller: | The actual transmission of the scheduled ADDR messages |
20:34:08 | amiller: | does not happen immediately. Every 100 milliseconds one |
20:34:08 | amiller: | neighbour is randomly selected from the list o all peer's |
20:34:08 | amiller: | neighbours and the queue for outgoing ADDR messages is |
20:34:08 | amiller: | ushed for this node only. We call the node chosen at the |
20:34:09 | amiller: | beginning of a 100 milliseconds round trickle node and the |
20:34:13 | amiller: | procedure as a whole as trickling. |
20:34:15 | amiller: | is that even true? |
20:37:47 | nsh: | hm |
20:39:25 | nsh: | -- |
20:39:26 | nsh: | The crucial idea is that each client can be uniquely iden- |
20:39:26 | nsh: | tified by a set of nodes he connects to (entry nodes). We |
20:39:26 | nsh: | show that this set can be learned at the time of connection |
20:39:26 | nsh: | and then used to identify the origin of a transaction. |
20:39:27 | nsh: | -- *frown* |
20:40:11 | nsh: | In a concrete example, an attacker with |
20:40:12 | nsh: | a few GB of storage and no more than 50 connections to each |
20:40:12 | nsh: | Bitcoin server can disclose the sender’s IP address in 11% 3 |
20:40:12 | nsh: | of all transactions generated in the Bitcoin network. If the |
20:40:12 | nsh: | attacker allows a slight DoS of the network, he may achieve |
20:40:12 | nsh: | deanonymization rates up to 60%, which has been confirmed |
20:40:14 | nsh: | by the experiments in the Bitcoin test network. We estimate |
20:40:16 | nsh: | the cost of the attack on the full bitcoin network to be under |
20:40:18 | nsh: | 1500 EUR per month. |
20:40:20 | nsh: | -- science does not work that way. |
20:40:57 | Apocalyptic: | nsh, pastebin next time ? |
20:41:04 | nsh: | sorry |
20:48:15 | jgarzik: | Random: |
20:48:30 | jgarzik: | Am starting to use the term "pre-stake" rather than "pre-mine" |
20:48:53 | G_Qu: | afternoon everybody |
20:54:45 | nsh: | 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:52 | nsh: | 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:16 | nsh: | (e.g. extortion) |
21:00:49 | midnightmagic: | 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:46 | midnightmagic: | So.. possible countermeasures against their attack are pointless because botnet. |
21:03:53 | midnightmagic: | (p. 5) |
21:04:44 | midnightmagic: | As is their apprehension of ASIC's reconfigurability for a plain SHA2 PoW function (since they're all dSHA2) |
22:07:12 | G_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:48 | amiller: | G_Qu, that's offtopic try #bitcoin-dev I guess |
22:11:14 | G_Qu: | thanks amiller |
22:11:31 | G_Qu: | G_Qu has left #bitcoin-wizards |
22:41:03 | Guest12621: | Guest12621 is now known as ageis |