Bitcoin Forum
May 28, 2024, 06:14:09 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 [2] 3 4 5 6 7 8 9 »
21  Bitcoin / Development & Technical Discussion / Re: Discouraging "Selfish" mining on: November 13, 2013, 07:22:42 AM
For block-height ties, prefer the block whose locally-observed arrival time is closest to its internal timestamp.

Really like this idea.
Creates big incentives to screw with the subsecond accuracy of the network times.
Not sure I follow, could you give us an example of an attack?


Has the anti-convergence property where if a first block is announced with a bad time you can keep trying instead of moving forward and you'll be sure to replace it unless you end up with a race with a child of it.
You could. But this would just be a new (and less potent) variation of selfish mining, which is only applicable "if a block is announced with a bad time" (which would happen a lot less often since  nodes will be incentivised to keep their clocks accurate. More importantly it would not be a profitable strategy (compared to following the protocol).

I know that there has traditionally been reluctance to assume accurate clocks (since NTP is seen as a central point of failure), but this appears to me to be a very weak dependency. Even if you had the magical capability to change the clocks on all network nodes when you want (not when they choose to sync) to whatever time you want (typically the time that is in the header of your selfishly mined block) you only end up with a selfish mining attack which we are vulnerable to today anyway. So as far as I can see no worse attacks become possible and the one we knew about becomes immensely harder. But this could just be a failure of imagination on my part. 

22  Bitcoin / Development & Technical Discussion / Re: Discouraging "Selfish" mining on: November 13, 2013, 07:04:46 AM
My countermeasure for "Selfish" mining relies on the fact that pre-mined transactions from a selfish miner don't contain as many transactions of non-zero age from the memory pool. So conceptually, when a miner receives a transaction it should start a timer which measures the age of that transaction. When a block arrives it stops all the timers,  sums the total age of all transactions in that block and stores this value against the block. As this is a product of transactions and seconds I propose it should be called "transactionseconds" (similar to bitcoindays) . If another block arrives then the number of transactionseconds for the new block is measured as if it had arrived at the same time as the previous block. The block with the highest number of transactionseconds is used to build the next block.
If another block arrives and the existing block chain rules indicate that a block should be orphaned then the transactionseconds of the longer block chain should be calculated as if all the blocks had arrived at once and the orphaning should not be successful unless the longer chain also destroys a larger number of transactionseconds.

Careful, this means that in the presence of a selfish miner attack, anyone can DOS the network by sending thousands of tiny (in both kB and BTC terms) zero-fee transactions. Huge blocks stuffed full of these garbage transactions will win the transaction-seconds comparison against smaller blocks containing only normal transactions and once there are enough of these txs in the network to push us up against the block size limit, it becomes ineffective against the selfish miner attack anyway.

This can be alleviated somewhat by using transaction-fee-seconds as gmaxwell proposes, but even then, an attacker could build a maximum-size block that contains a bunch of insanely-high-fee transactions that it created itself and is keeping secret. As soon as it successfully builds a block, it publishes all the high-fee transactions, but not the block. This allows it to win any tx-fee-seconds races with competing blocks.
23  Bitcoin / Development & Technical Discussion / Re: Cunicula's rebuttal to Bitcoin is Broken Idiocy on: November 08, 2013, 08:54:14 PM
In a world of ASIC mining, effects of the value of capital assets on miner incentives become important. It is completely unreasonable to assume that ASIC prices do not fluctuate wildly with the price of bitcoin. If so, miners will no longer be short-sighted.

Stop fighting a straw man. I never claimed that ASIC prices would be unaffected, just that this is immaterial to the decision of an atomistic miner.

ASIC values are pretty tightly coupled to bitcoin prices, but you know what is coupled even more tightly to bitcoin prices. bitcoin.

Quote from: cunicula
The hashing power of any one decision maker is simply too small to make a difference. Therefore, individual decision makers ignore the effect of their decisions on attack success probability. This makes it irrelevant whether they have investments in bitcoin or not.

Reread that last sentence. In the absence of confirmation bias, you argued that even miners that were heavily invested in bitcoin would take part in an attack, since they were atomistic. Now you argue that atomistic miners that are heavily invested in bitcoin mining equipment won't take part in an attack. Why are the miners more easily swayed by the mining equipment that they hold  than by the actual coins?
24  Bitcoin / Development & Technical Discussion / Re: Cunicula's rebuttal to Bitcoin is Broken Idiocy on: November 08, 2013, 08:43:09 PM
I'm sorry but your whole argument is flawed. You need to treat miners as atomistic and you don't. That invalidates everything that follows, so I don't need to read any further. Rewrite your paper while sober. Remove all consideration of the possible effect a successful attack could have on the value of the miner's assets. Get the payoff matrix for the prisoner's dilemma right, and then try again.

What payoff matrix do you want?

Errm, any correct one will do. For someone who passes himself off as a source of game theory knowledge it is more than a little embarrrasing to get the payoff matrix for the prisoner's dilemma wrong. If you can't see a problem with the matrix in your paper I suggest starting with
http://en.wikipedia.org/wiki/Prisoner's_dilemma

You want me to get rid of price effects? How can we call selfish mining 'harmful' if we assume that it has no effect on future bitcoin prices?

No, for the hundredth time. I fully accept that a successful attack will destroy bitcoin, as does the atomistic miner. The atomistic miner hopes to hell that the attack fails,but takes part anyway, since his contribution is too small to make a difference between success or failure. This can also be stated as :
Quote from: cunicula

The hashing power of any one decision maker is simply too small to make a difference. Therefore, individual decision makers ignore the effect of their decisions on attack success probability. This makes it irrelevant whether they have investments in bitcoin or not.

As for writing this while sober... it is too difficult to face the stupidity of people like you while sober. I prefer to save sobriety for serious projects.

Nice.

"When you have no basis for an argument, abuse the plaintiff."
— 'Cicero
25  Bitcoin / Development & Technical Discussion / Re: Cunicula's rebuttal to Bitcoin is Broken Idiocy on: November 08, 2013, 08:27:00 PM
I'm sorry but your whole argument is flawed. You need to treat miners as atomistic and you don't. That invalidates everything that follows, so I don't need to read any further. Rewrite your paper while sober. Remove all consideration of the possible effect a successful attack could have on the value of the miner's assets. Get the payoff matrix for the prisoner's dilemma right, and then try again.

Whether they are atomistic or not is irrelevant.

No, it is not. I am tired of explaining why, but you clearly did understand this in the past.

"Rational", "atomistic" miners are of course "short term thinkers" by definition.
26  Bitcoin / Development & Technical Discussion / Re: Cunicula's rebuttal to Bitcoin is Broken Idiocy on: November 08, 2013, 07:16:39 PM
I'm sorry but your whole argument is flawed. You need to treat miners as atomistic and you don't. That invalidates everything that follows, so I don't need to read any further. Rewrite your paper while sober. Remove all consideration of the possible effect a successful attack could have on the value of the miner's assets. Get the payoff matrix for the prisoner's dilemma right, and then try again.
27  Economy / Service Discussion / Re: MTGOX makes doublespend transactions for btc withdrawal request on: November 08, 2013, 06:23:31 PM
And I've got the same thing AGAIN. Here's the raw tx from gox. Double spent. What a bunch of incompetent fools.

010000002959fa5bd13b53cfce03854c39ff5c7e259182e8d3c22317d9a85a16c379f749ea00000 0008c493046022100adb6e5ccfe2c50f25958534d163aebf897757148e7648f135ffa8d0ebdf6b8 d2022100eae1723880bb4813fe79e588b6ca3a6d67f3434bd9a67a73101fb2599776779b0141045 5bc0896a54b94a84c1a26f91535e825995a10a2acce6b38a49c72ee3bbceeeae0b1c9d16de259f8 0d27cf1fe6b180e5224a0145099aebf78908eeedcc7ddf54ffffffff6d9517d96b607818f32b66f cde3503f77c0638364440bce7e78519337fe636d4010000008b483045022100af24aa251b2c2683 5585b1dd584d799457750eebfe4c28d0ef40a6f244371f8602206c861043bd7f120278ff8899489 dabfd68ac17741bd8c37bd7d979a128c0b5d0014104b71937380ed6af7d7e32b80591e0014eb58f 32f7f40cf3f49ee2845cae19a2feadad62ca136385a425fc7769dc2c143f51019fc9efbd4f1d9ff 43b066ac02b21ffffffff2563abb722ca29b09bcb55709fb9e67c7c3d48920c45dfee205416d390 6f4f2c060000008b483045022041cf657cd218e95b622fabe701309e0c7bfaa88183845ac3e2cbd 6c40398eda502210093cf1bea223a7581d25f135e5487f6eb2e448680e06c9672985b20ef24d4b9 c9014104739a186ddb23a2494b32fcda1c47d077424e7b6ffa60c98ec48eece612ec19fa8e9dd50 7e7b153c93cac3bad36f3c1c6bea67cea67e3e30894dc5bfbf6c534e4ffffffffd7b31b0bcc0f02 674ebd8825abf263ed00a070b1eeb268bde397534f250856e9010000008a473044022056294c123 916758ba741979e003f2e952582ec7ef6cae020833200ae402cfbf302202e9c731072c1ed2c7bbc 6c4e699fd335b7090c0c753d898ed75313a6fa618aa901410466c28456276f940f6a65b93b4d311 b8647f064bbcb565614afeed9cf10868306307615753a64a05aac8dcfcd88d03320f3d6ac4ed7d2 1a63f0889bc4471020a2ffffffff84730416b78599126c7e963e7f64aa6d9432535973bad20fffd d5235548c4221000000008b483045022066259a668d461968af56d40fe5399c26e497e09cc6895e 3fa2d07dc5b89fc228022100d026adeda8c87d942877ff83c15160ac9e81beaa40719280ed7cfae 8d67fbe3c01410409a6fc0cc7253d3e9b58fc6de258c533aa6fd01274cf594927fe7174288f0da3 d79ae3095e5c1a60bf5c646523522f077d187ac9ea6db0aec4001df3c2f51a62ffffffff6d3a164 d045f7d397f798e85d666e76268aaf12e3b388d611c79334f585941c3000000008c493046022100 b615f26f63bd085ca4d1bac7c6b968294062b2d5982633c87a65e3fdcb8032e70221009492dc9ad 46d2c95e2e445f8163550096fcf1f73fbc8e57d7b24fe496705736801410455bc0896a54b94a84c 1a26f91535e825995a10a2acce6b38a49c72ee3bbceeeae0b1c9d16de259f80d27cf1fe6b180e52 24a0145099aebf78908eeedcc7ddf54ffffffffbf5b09b6619d632af8447b485dc5aadb4309cdd6 1c9cc534e4e860a771b8393d000000008b483045022100dcd8fbeb7c003181be60073f5ff0b479d 0d92736e6993a1a4923ba271d1860e2022066b71d92626cc71d311ebbd25f5d2888db3545342727 b4c3e34b90b1cecfdb41014104e27e3e225fbae544e417150465b74a8bef8bfbd574387fc137805 2c819fd4592dc2da2556d64102d2b30a1570a1a853b838eb85ef6f1e188e67263b38219b9cfffff ffffa54ab87154e009e803c428bb99a0728e279785de98a15b98ab088b565792723cb40000008b4 83045022100db5bb9342989b925fe440d0626c331700a76736acb10a3544ebd4b8615676f280220 101c7ce58d44b6d25fb1f09e02ca13471948d4011d005a3263e3d4a945277dfe0141043bb4aedbb c95f717702073f1fc0a574297d420b9cec210aa211be32b049a87638998c0a4e4e8d09499c2d13f 532b274c820a81d3134949660c4da1f872c97603ffffffff2d26eb14b8d7d4f2f75501898f68a8e aedc5d1f6464f30fbe4230e5e22e6b63e010000008b48304502202ed61411af06d52c7505e28afe 41ce44f2196a11b868351b05ac2347e08dafbb022100fc9c609f64fc9346b7e473dd2d51e25d977 869baea2bb8dc18168e2db1bb1bd70141047803fcc8661fadf7795f88df33a982de909ed42a6948 92edafe524c8def039b5e1236f3e56b21ac82d33609bd768388af5a9820eb0ea924a97320065054 fa320ffffffff10808d54d5f15406292ebf6044fe4979445491132ff1803b43c9c2aa277fa88501 0000008b48304502201102bbc66913fd202000e5349e64b3a0a49aede6d4108b7bc33e2bdf3e201 509022100e0c8cc3621c14add9cd255e37d0c574b0df837483a99e260f6b8c05537383d41014104 564154aeca0b54b07f2a4dba355e9dc501e611db509b3e78951b6fb3571036b5d374c35406d5da4 66c5f29d31ba3faebe4b3d56e7f7e983c24d5994bacf1c69cffffffff715ba372968fedbb63b6b8 5963e06bc54a441b499a3e8807d4f99e765f26dd57010000008b483045022100b875457e22e9bdd 1e68682f15c13512e89756ceaf7ae006b06ec73d8ca8958d10220031388f4cbeb4cfd5c0eca9124 d406fb75e604a6f346c6d2c64e665fd78dcde10141041a120c29517637a978b851e1efc345431b9 585a476b80539bdad22b7c889d715bfdcfa88f7923fc2764655d988e5dc0f09230953d9a637aed1 835d6197f6970dffffffff36b0ecfbc78de5b4e39961dcad49e10b9524e3006247c442815f763db 388644c010000008c493046022100dfa4b993b79de0aaaf99acd482b81c865e493b9281276bac2a 4f92d46e1d3a47022100dddce07b3626150e2d35feaa0f41295a00e20f480781b44761f59949fbe 299870141047ba433f0782fa5acf8626bbf085f8e2955cb0f5342d46292b39fc407abb8b99c064f 70db890672716661bbbd386dc93fd77240299423c9915cd7b12125712206ffffffffb0d5c8c0642 3643fc9f6d594647b87807ca09c6343299ca269224b819bbb4944010000008b483045022007326a 379f3d748edd709737710dfb58c7465fa0ece0c23a3c21939b7217a0e5022100c827ed2be66fd1f a8ad7b359926f3354e6fe72a90c375854811be926b2ae71ee014104c3e0413f33bd0074bf2897d2 bca2a74c56a7a77d8675b02d4e5fbad1b109c1392014eb2db3ec5c07ff5c0f65ba90c2122619871 b5d9a79e9847c109de135312effffffff0515a605d0ae6e4f635cc446d1dcfb969f71672c9701bd 0c0210b21367b6649b000000008b4830450220694ab45f84d15bb3d21a7a7c9247846e63ce45012 01046658b441d434b2ab557022100f74451f22cf42ebf238e6970414b55bb5cc1d274c2c5991315 b19d84b69eb50801410486f738cfcfa388a5b89bdf907a86574318f4094bb2d1b142902d9242fb0 068d1de627c5d20f668f502e7a78afe323a51eaf309932e3cc98ebe72dcdcd03dcbc4ffffffff45 89ba3730ad3070e014f558aba746daf2f845e6415628231401944015803a8c000000008b4830450 220757368a0ada8d2810bd59516a9ef6dd76846e35ce0ab68b7855750dce9914714022100c4bb6e 3588afaf825dfc8abf3a904af8c3b30ff3f93f0e6891a6d07a0fd9613e014104906e82f7afcc66c 5186a0abd82466e20074d3d6d795461e8e78a32cd9bc8a0c1cf2061339f28e95165a68d872b64e7 7ecda47a1b930b1f5879d2cb532fb647c0ffffffff6edadf010e8d0b72dcfe7846bfd3108ad4293 e9646d1ebc1a4511ea028491b92000000008c493046022100b31aafe9e4d00a40dedc16dab7a34d d1d3f28dba8e7c1676235d80368868e658022100bb811e0791cd233f1b2eaf5491742400dd4620f ab1b7e9f73d8bdb559e0182e201410455bc0896a54b94a84c1a26f91535e825995a10a2acce6b38 a49c72ee3bbceeeae0b1c9d16de259f80d27cf1fe6b180e5224a0145099aebf78908eeedcc7ddf5 4ffffffff626dce612551099a8cad25003f1419ef4888de9c1fa62e8328cbef1e16826592000000 008b483045022100d43a6beeb7e48fc42b045bfb33cc13cdc9ea1543b0f44d7c9ea5ab7071ddc98 f0220787af9b57d9baca2d08b5039c89ba65393e0e0435d88ad2f8db47985695b0a9a01410442a5 fcdb338227b75b43ecadb8598893bb9dff1ebd5a1b081453c2cae4e85c7bfdf843299f81b900f6e 39d953fbd0de1a2a2195f18fd343015eba57be5eae645ffffffff9a7153cf898c51059854c67e10 089bfd9aa957fe8e24c3a1b6c06541970cab69000000008c493046022100b754db9128e4794948b fcfc4c4a5dd9ba29b86208305fcada65baaf1240e934b0221008733c5e5a11f9a687d8583f8529c a0f6fde4186bd18d4c15a156c5985d5fd2310141044307b3180f1ec64c2c92b566e8de53340ea9a fe0d28d56ff2debf66258a9f872387fe9c6ead72054b7714abd3ea0b66a3ad25ea887370626bc44 736c0359121affffffff77b6f1490c923e1abeb7df5cbc50f44fcb2bc805f161c05f1a2c0d95a5b ddd2e000000008a47304402207850a87f277269a2d6a54a568b517188917e9ea96c85ce27fced99 a8c7d2b8c00220406975673733976136d49e297d4a0676ea03ea14f63f184ea164648f43aa2c1b0 14104624de45024d4dbeb8b979a3ed06b6e9bf831c25669204fa6ab0203c1fd7d39365fba01d41d 27b46416acb1d3155f2aa55d4612d3a93cfb09e9a081576a082f1ffffffffff23387083b1d1489a 7acd7e77df9d52fd0b7cdfc9718b9038a79dfe8ab442ee8490000008a473044022053dc73d03c15 a49823a5bb9e8ddd85f95dab1aec5e10ea72b3461d5edf32383302203435e0bb01ec97659210d87 64167d811e9261ba8d5c65b92e39e4f04cf0a39340141045726402ee66f4d65110434df7dab4267 c87ac20e6866de0027cdecc312f84b61348030f39ff3bacd8a375967e4ad7262726a63b9d645122 a9d5c851201a8bafeffffffff509ac97d0d746f465590ef26704fc73d2336f18249abe638516c5b 18adb075de000000008b483045022100b535c817dde2c7e691756395646d597125bddfb2e94e807 5812234829598bc4b0220410f3364c259354a206df23e4949b1d6619b74c8032bc8f91fff59294a 2426970141048af7b6fa9bee16006222ccf3904ad1c7a159eb53d0ea4f3d93375e44bb40233e041 e504ae389877a08c29f26896abdded80d796583713e5b0904229165be8a57ffffffffc91bdab376 1bd7eb70faa475527b96b52e448a6c09d52d1c37aa0541a9d2fad5040000008b483045022036af1 6720bbe625af9c2b090d5106ed63c6459044bc9c6803585558e8a15d5dc022100f6203df9364b58 31168f64d42fdeb7032073772b28ba2441afc1b60dfefb98a60141049af76cc4c0a042629f91de1 c00074518060a106717064b0b6882fe10fa1aba43d1e0a919a6bf5fe4234d4e51ea8df01cbf21d4 689aae8658209cc63dbf263adbffffffffcbd649f8253d98e8c990966e3e419315535aa810b1e80 41107b8e6c4014068a91a0000008b48304502202fdf38b254bf49124a339bb56e947cba2a6806cb e0ba1114b9c5399d8ff8ebca022100938a6f8aa777e3ba19e1de0a9ac44b14f67bc5e012717ebf1 ce6f20ff776d1a20141045b2447bd735f58f99dcabff50d8e30ffb0b0ddd63e742eb20868d6483c 6fed74f8a57d9e57f1edfe7cd11a9bda64767a8eb13ed6f030da535d25bd9b9d9fc956fffffffff 6bde35c62b7250dc4ddfa3cc759b2d544fbde4e9191eac58c30405247e082e9000000008b483045 0220212a567af8bfff46e960bfbbb491502465fb24e22e114bd42d8c001db53b66d1022100c037b 8856369ffb042c5a9c12a81dbe5c667038c3b96c87f649f32750b2de56f014104cc6a3ff2a3cf46 57f2cfd369a79e3665d31d20ac4db166c746d1b12a73243d7d8e609b41d0d75478a85c4e3caa5b4 d2566989d171105267e9dd0951545a86de4ffffffffecc2e78f39a4e4ad134f73000a5c23f9586c 8b0330f2dd830995e64960d5df58000000008b483045022100a08585882994a42aeb4143d8f4c6d 22b9df624ecc1ca75b70824dd2fa78bf09602203b961d25f685d6b3f1c9b7968a2ef4a7e7e7b816 24d2b12720815fec2715f9420141042ff0557e0262ed0d38454af09947f73621ce22ab7955d2c9d efe7d44e0ec2c545802bfd5382558e86110a39bbb05411b0e7c1b536d54b1b04ee208055c9bb65d ffffffffe2a07455e89fd50e34272296eb01ad21587d597dd72b6dd9d5214fc4501608cc0100000 08a47304402202561c714898898dd0e65f00553ba10e7f8786768275893459c377fd1e8556cd902 20493bdefeed9b38289df78c031f929631bd5bfbc7106dde6e6c97ab4a1795f714014104b1d4af5 8ef52e1df95eec430c7f6fb34e54894f2fd77a2b01b82afacf9d80f1e2abd5211e77c900fb0bfbf 337180045dfa44d60edc8b677c852f2689e6a998fdffffffffd35d529fdffb2fe76c4d59b82099f 053db86bd3af1313706c34831cbf3864a00000000008b48304502210093d6c578607b3acb1f453c 35ab8884b93d78f24c1c57e6610e4f8538216bb02f02204e57c08950a18fa1d507a3707c628c2f9 deda66f5023cab540a10c3fc48113570141045ba94ebf6d1e23068510d6ab264765b636afbc10c5 5f8f64debb4b057416f2d9224f854345772d4c785ea00c976e34482521b7bd99c12f297053f8f46 4a937fafffffffffc6fa8dcefc0004db1c615f58f063f18592fb6749bb5773e4c5f4059ebfacdce 010000008c493046022100cbe9f761b1597a2878010a94f16b2c92ac0a2f731bd11e4bf6d0cd7f5 5ddd6c4022100fc20827d347dbb016c04b591afb4e523eb470f4ea470cf8c656a693eee27b08601 41046178812e05ff7d62c0dbfcc69eacc9d6ac2b8f577b89974d1c328f8cdf3ff2227829dbcdffa a394ca6fd7e8a62f1d58d9b01c866ed02841d7b2c94c35af5079bffffffff129c4fae9cdfe3d417 7e62e38427e1c60e7cfabf412576f5d6772e1145a3cf39000000008b4830450221008adaabe2b00 5c97e64910faec98d4e8b69c1a4c38e8c9aacc0ad622263d95044022046ba28b2b7747e4a11c8bb c51112091fe8b1620bc4175a6933652e377e0ad3100141043e6c959ff990b7911665a82fe1254fc e9200e0978e5a7413fadb2eac37a5604cd25b3043620e7ef6930b8629cf5529d63ac7eed93a42c7 96ca4935685f0e599cffffffff3c815be05e2b9cb0ddf7ce5ef82a954cdf92fc2e2fcfe0e12533b b3e7543cab4000000008a4730440220583a5326bd615b0a08ad8a84f4b3b5a583cf3f8fe02cd61d 93e63f7391f580fa02204b8199c153cd10a5acc7961b9ccc87ec9c007be53e6fe5c18bd6671e388 cc4ad0141044e606f092855951f93030a526655823a6a115f27335740541e6c7eb27578080010b2 9ab4bf21ccfe498cfe3cc4bb4ad4e02acce122a2bac358b3d51de9e7c210fffffffff23387083b1 d1489a7acd7e77df9d52fd0b7cdfc9718b9038a79dfe8ab442ee8370000008c493046022100b671 ab2fea714c997aec728a3f777c050d30eb9f33e3ae07de3d128fceaccd35022100b43005101fc5b 78750c4835a40455d4d9371cc2cd86c6f6fd50c88364af93093014104cc1cd1ffb47e8cf039f976 805358138d3f22ed3dff340bfed248cf980d6d9347b9a6f3c5cc08b0fbd9c4c6373196fd25d3969 222402088811f68f91d8662ca54ffffffffc6e61cdeb4275cac2a90cc317f1a0a23dd19222ca988 a7787c9f75fa7f10d910890000008c493046022100ce2822dbeba0704941bb2ef2f4d8b8e9d563b 50513c2e1bc1a334c39e55ff4b5022100b1bf6e85c2971cbf8b20aee3ae4d0864509d4dbbbe2e9f 33d2f4293ffc238aeb0141049b79c22feca5687c913b941b8db9b667c5e8f4fd76e8e703ad0f52d f3f9af404557fa0a810dbcb6f6e87dbe6a6dc800350af6ae3460a06ff0420d0f1555f1125ffffff ff6d14ed0ecb758e3621b79d6a690cd2ae7c86b60a39da6ec595ef4cb0e8a42797010000008b483 045022067819664376a16326a6c57b8c0265882a0b10d00c39b94e79f7de80e05cb8a4402210081 9e11be611dbd92463c6751b5ade4e46b0e0313a0ff327c9a57694486fc5f350141040d214261c27 65777fff93c80e9a021eac4ecb0b933b58df6fc8abb3814d414592b9f6b8aedb3488da69348fc1b d820c717ad2258c4db29b35d1e6098e4adaa26ffffffff4484f79beb4aa0b31b9fa16921627e396 86a46392cc7214b444346de50d4e847000000008b483045022062a697ecb26a4b890911ae9c2ab5 57a5787b9713a1464afd68e4a48af84277ce022100fc56003e8ec7d128f96fe728308cc8edc5519 9da2304136ddb2fb797beb0e3c1014104c6244dfc891c0afff553c56e8952234a017f6788fe8427 4a2360b84e5be03bfa0af0860f97eeaefff43036e914889dbfef97477451c1f3d2f05bfd3282026 2d0fffffffff15644c75955db9645d68890e82b9a31cb7ba11da59e4184bea9aa6f7c9fc5610000 00008b483045022100aee20dee10e671f5860258d7786b9018e0d5f52e6a4d1162491b2dc0419c1 a5b02207c5946d30387ac83d9c30a23d4c8565f61c8088c9157cf7eb6dcb800884fd7220141043e 024c783b02f64c76c23d02ea5619578df10a490c56004c33dfd36b7cae757b4443842b849270799 31a17a2659027bd5c1646b8701056979964a18952ea4e72ffffffffa465769c1e4d711acb765086 76b8c795a5df78ccf2a91e882accb3b3f569426f000000008a47304402205eb7aa79b369a194253 943ba731679e156fabd603962eeeb3f2017be25ce75f40220626014bb6fb055d8dcad1dcee87878 75df708117819c5e427185ed4216166e5601410459ae1b08df3de63c2f80fac6846cf7eaec5c382 5359d2151f47543a1cc49cf815bcc3619912bceb4481446613771aab573efb035857ac08c69e5a9 e747149e59ffffffffac1536d5434202928c14c0168711f75ba386e320a6dd793e5468d03636af8 03f010000008a473044022066f47ab0ad97a2eacad5994bcad6b64644b8fa1638434e0f5e4e3e36 dc778bc20220133029d01d5901c7a63ea798cae31a301fd66cb2fc2e6f7ce14f154656aa54c2014 10452bb220d9843ab73cf7135a704f5d5f0e95f7f82f76a5e66fd6f815eb189f70aea17b95437cf e3800b919ed84478747fa81b56f6b03ef61aa6850b1df704042dffffffff115a36b4f080cdf260d 704eb240e1a19fd640ac97acbdd5378e0976abfa703aa000000008b483045022100a6d58a9c186b adb8001a172cf2ffd5f88aa78892a389cd9f340bcccf0b125b0d0220158d2037962c2e7e5bd4129 8bc01a1d6c04b5289cbd74257bf37a3c47d8a2db2014104e899832b96be1576b748087af107669d 14881f32bc0afda12b680304d2fd38690445579d164f02a2acf03b4c885ec8b974abbe3d2504744 741bb81293dfcd603ffffffffc1d020450ad9f84255c9060d7e96e4f38beae2e5b6e15a2127c054 1fa17a0bc6000000008b483045022100dbcdb9d0122ca40f49e38afb1b1a4eb63d2a143c4c7bd06 9531e24d84603158c02204325a45acc8bbe072f156d3876762a4543600bde3f3c75d376e51a65d4 19e2f8014104507bdcbfd09bf94eee01e33f3bdcece1082985f7391d426d3ef2e380838b2f3edc6 d617d20f561d18a5bee3770f36ddb441bc56bd12ec7707a52d0bcd75c9170ffffffff5fb33f2b02 f637c91cead8ba128c1a5f617d0b6fde2195f3cd92b03f7ef4e506000000008b483045022064af9 be35f682f377f0e55c805bedcdef995a8a51fa58ea12d895503dccf04d7022100dd94e552e276c5 1474f48d610bff5d5fbdd193faa903f9aa69b6f91f4110b02a014104652924fd700a76223ba71c4 9408c386d005bdf390fa3ed0188a96cdc9e3b63b009680afce98b1056fa95e7560a7a3090650051 098fdaee9c78d8b840d00c7f7cffffffffa45ce0ceed2cd0d611cd10f7844ec3901f426ac057cbf a40144a94e7afc32a19000000008b483045022100c117de2690a6719b8376a71b8258240ba9fba4 cb57447b309935f9c0323b8ad702206257601aec99d9d148e1c1d8ebcdb0277cad18f5411b87f99 4d4f54538318c3d014104f0a0a3a8e7ff06b1ec4fb22f931488319541cc5f0dafb87d4bd5c8167e b3b3230e32b3353ce59ecfe02e9ff63fd85b29f3fb8fde1ef725e8643d42cbbd94890fffffffff0 2ebcd9f29000000001976a914f0a671f0e57b7221e581ea79120aeee60b41b9bb88ac3bf551180b 0000001976a9143b8dba0a4c24c3ed13abdfe0ddcd9ffa1ea5105d88ac00000000
28  Bitcoin / Development & Technical Discussion / Re: Cunicula's rebuttal to Bitcoin is Broken Idiocy on: November 08, 2013, 12:56:46 PM
That is an assumption. The nash equilibrium stategy I described is based on mutually assured destruction. Basically, if anyone ever behaves badly, (even one atomistic guy once), then all miners will behave badly forever and forever. Since there is no threshold for bad behavior an atomistic miner, a small or even atomistic miner has the same marginal affect as a large-scale miner.  

Huh??? Are you drunk? I have been selfish mining with my CPU for the past 30 seconds, so I guess we're all F#@#ed now. Sorry guys, I must have misunderstood something somewhere.
29  Bitcoin / Development & Technical Discussion / Re: Remarkable sudden increase in confirmation time. Another fork? on: November 08, 2013, 11:26:35 AM
The transaction confirmation time is different from the average block time. In this case, the peak in average confirmation time is probably due to a recent sharp increase in transaction volume, which makes blocks more competitive.

That graph is transactions-per-block which you would expect to go up if there are more transactions or fewer blocks. However, no corresponding increase is visible on this graph of transactions-per-day, suggesting that there are indeed fewer blocks being produced. This has to be a sudden drop in hash power or variance. My gut-feel is that the swing is too large to be explained by variance, but one would have to do the math to be sure, preferably using only block times from after the OP to eliminate sampling bias.

30  Bitcoin / Development & Technical Discussion / Re: Cunicula's rebuttal to Bitcoin is Broken Idiocy on: November 08, 2013, 10:10:39 AM
If you assume that miners are atomistic, then the size of the investment is irrelevant, because the miner assumes that the attack will succeed or fail independently of whether he cheats. Therefore ANY consideration of the attack's impact on the valuation of any of his assets is erroneous. It is like trying to consider the effect of a possible crash of the stock market on my net wealth, when trying to decide whether to have egg or cereal for breakfast. Erroneous, not because I will be able to offload my shares fast enough, but for the more fundamental reason that the market will do what it does, for better or worse, irrespective of my choice of

Sigh, reread the pdf I never make any assumption about whether miners are atomistic or not. It doesn't matter for my argument.

It ABSOLUTELY mattters. If miners are atomistic, then your entire argument falls apart. Take for instance :

Quote from: cunicula
The miner enter’s(sic) the next period with k units of hardware.Surely he will cares(sic) if these hardware drop in value. This is the essential point. Because he own’s(sic) specialized hardware, the miner has a stake in the system.

The miner considers the probability of his hardware dropping in value as being independent of his decision to join the attack or not. Any subsequent consideration of hardware value when making the decision to mine selfishly or honestly is an error. The only way that this is not an error is if you claim that miners are not atomistic. But that is equivalent to saying that bitcoin is not decentralised.
31  Bitcoin / Development & Technical Discussion / Re: Cunicula's rebuttal to Bitcoin is Broken Idiocy on: November 08, 2013, 08:29:43 AM
Thanks for pointing this out. As usual, I'm right in both cases, but I admit to being a little opportunistic in my exposition. I'm sure if you dig deeper you will find old posts conceding that hardware ownership mitigates the incentive problem. I never emphasized this before because it didn't further my agenda at that time.

Interesting how you are "right in both cases", but when others use the same assumption, they are "incompetent" and have a "fundamental misunderstanding of the incentives".

The issue is liquidity.
You can sell off a small to medium-sized in investment in bitcoin very quickly.  Once you have a big investment this is no longer the case.

If you assume that miners are atomistic, then the size of the investment is irrelevant, because the miner assumes that the attack will succeed or fail independently of whether he cheats. Therefore ANY consideration of the attack's impact on the valuation of any of his assets is erroneous. It is like trying to consider the effect of a possible crash of the stock market on my net wealth, when trying to decide whether to have egg or cereal for breakfast. Erroneous, not because I will be able to offload my shares fast enough, but for the more fundamental reason that the market will do what it does, for better or worse, irrespective of my choice of breakfast.

If miners are not atomistic, then bitcoin is not decentralised.

Anyways, you go through a year of post history to try and attack my argument by impugning my character! Why not just meet me head on in battle if you are able?

Nope, not really, I wanted to use the atomistic assumption in a counter-argument, but I couldn't remember where I had seen it defined. Forum search and voilla, guess who?
32  Bitcoin / Development & Technical Discussion / Re: Cunicula's rebuttal to Bitcoin is Broken Idiocy on: November 08, 2013, 07:12:45 AM
Sorry man, but you are embarrassing yourself now. There is absolutely nothing wrong with their conclusion under the common game theory assumption that miners are rational and atomistic. If bitcoin mining truly is decentralised, then the atomistic assumption has to be true. A really smart guy who is worth listening to when he is not in full-on confirmation bias mode explained it as follows :

In game theory, "Atomistic" refers to the assumption that individual choices have no impact on aggregate variables, i.e. individuals are tiny and numerous like atoms; aggregate variables emerge through integration over infinite numbers of tiny atoms. It is a simplifying assumption for analyzing games with large numbers of players. Here it just means that individual decisions have no effect on whether the attack succeeds. The hashing power of any one decision maker is simply too small to make a difference. Therefore, individual decision makers ignore the effect of their decisions on attack success probability. This makes it irrelevant whether they have investments in bitcoin or not.

Similarly a rational atomistic miner will neglect the effect his selfishness will have on the bitcoin price or the value of his mining hardware. He is simply too small to matter and the price is unlikely to be affected by his individual action. Even if he believes that the price will be affected, the net gain can always be made positive by holding a sufficiently large short position.



33  Bitcoin / Development & Technical Discussion / Re: Majority is not Enough: Bitcoin Mining is Vulnerable on: November 06, 2013, 01:43:33 PM
Well done, you got me.  Work can be wasted if done at the wrong end of the chain.  If you read on to the end though, I clarify that expression.

Work can be wasted whenever orphan blocks are produced. Orphan blocks do not contribute to network security, they do not pay their creators, and they are not relayed to the rest of the network.


What may have tripped me up was the way they describe gamma on the various pages.  When I was reading the paper, I was struggling to find a unifying theme for all of the ways they use gamma.  It seems to be a choice on one page, and then an expression of the natural race between competing blocks on the next.

In regards to latency, you seem to be missing a very important aspect of reality on the bitcoin network.  If you are sitting on a block, waiting for the rest of the network to find one so that you can publish yours, the signal that you need to act is also the signal that you have already lost.  Don't feel bad, this entire paper was written because of the same misunderstanding.  You can not win races by waiting for the rest of the network to pass you.

If you are trying to achieve gamma=1 then yes, the signal that you need to act is also the signal that you have already lost. But unless I am the VERY LAST node on the network to receive this block, it may be possible for me to get my block to other nodes that have not yet seen the honest block and in this way recruit at least some of the honest miners to work on my chain. Even if you do not agree with this seemingly obvious statement, it DOESN'T MATTER. Because as I am getting tired of pointing out, the attack still works for gamma=0. This is the case where we assume that I was indeed the very last node to receive the block and not a single honest node will compute a single hash on my block in the case of a tie. In this magical case I need 33% of network hash-power to earn excess rewards.

The charts are very illuminating.  In figure 2, each of the simulation points is exactly on the calculated line.  This is a dead giveaway.  The only way that can happen is if their model is fully deterministic except for mining function.


BS I replicated this result and I can guarantee you that the mining function is not deterministic. Besides, your premise is laughable. How accurately can you really read that chart? Enough to say that the simulated results are within 1% of the predicted values? 0.1%? You can easily get simulation results accurate to a fraction of that in a modest amount of time on a dated single core machine. I know because I tried.

I agree with you so much that I traveled back in time to do it.  What is fully deterministic in their model is everything else.  When a new block is found, gamma of the network switches to it, while 1-gamma switches to the attack block.  This is not reality.

Nope still wrong. In my simulation, nodes get allocated to mine on one block or the other with a probability of gamma of being assigned to the attacking block (you've got the logic of gamma reversed by the way) and I replicated their results perfectly. What is more, for the interesting cases gamma=0 and gamma=1, the two approaches are exactly the same.

"every other node" was hyperbole, but not far off from what it would really take.  If the bitcoin network was laid out like an efficient mesh on a flat sheet, you wouldn't need many sensors.  But the bitcoin network is tangled up like a wad of Christmas lights.
I don't really want to argue this point. As I have repeatedly stated I think that gamma->1 is extremely pessimistic and probably not achievable in the current network. But that is a red herring. The fact is that gamma->0 is extremely optimistic and even under those circumstances, the attack works. No Sybil attack is needed, so I wish we could stop discussing whether the Sybil attack is possible.




34  Economy / Service Discussion / Re: Withdrawing BTC from MTgox 'Invalid bitcoin address, please confirm your input' on: November 06, 2013, 01:01:43 PM
Yeah, I eventually got mine to go through. Allthough the first few that "went through" actually didn't go through at all but were double-spends by gox (see thread on this elsewhere). I strongly suspect that the theory that this happens when gox's hotwallet is empty is spot-on. This happens whenever the gap between gox price and stamp price is narrower than usual. You get a run on withdrawals at gox which results in an empty hot wallet. Count on this taking ~2-3 days to resolve.  Angry
35  Bitcoin / Development & Technical Discussion / Re: Majority is not Enough: Bitcoin Mining is Vulnerable on: November 06, 2013, 12:43:48 PM
Quote from: hannesnaude link=topic=324413.msg3498091#msg3498091
As stated earlier, I agree that the existence of PPS pools makes this attack much less viable. But the existence of (reasonably priced) PPS pools is an assumption. Nothing in the protocol requires or guarantees it.
It is allowed by the protocol. That is all that is needed. I don't understand the use of game theory in computer science. It is always an attacker vs. A bunch of honest chaps who sit by and let themselves get fleeced. If someone can pop up and say "hey, honest chaps, let's take shelter in that cave. We will be better off and safe if we all go together." Then it's reasonable to guess that this is actually what will happen.

The problem is when there is an attack with no effective countermeasures. As in the true 51% attack. You know, the one that is actually a real problem.

And the "cave" or the countermeasure in this case is that one or more of the honest guys should bleed money operating a PPS pool at a loss until the attacker goes away. Errrm, yes that sounds like it will work. Roll Eyes
36  Bitcoin / Development & Technical Discussion / Re: Majority is not Enough: Bitcoin Mining is Vulnerable on: November 06, 2013, 12:16:43 PM
If it were an interesing problem, yes. But it is not an interesting or relevant problem.
Roll Eyes.Yeah, I feel the same about NP!=P. I could probably solve it in an afternoon if I put my mind to it. Wink

The upfront cost comes from yielding fewer blocks than average and either driving rational miners to PPS pools (and thus failing) or subsidizing miners by offering PPS yourself. 

As stated earlier, I agree that the existence of PPS pools makes this attack much less viable. But the existence of (reasonably priced) PPS pools is an assumption. Nothing in the protocol requires or guarantees it.
37  Bitcoin / Development & Technical Discussion / Re: Majority is not Enough: Bitcoin Mining is Vulnerable on: November 06, 2013, 11:45:09 AM
You need to model this as a dynamic game with entry and exit. They do not do this. The methodology is inappropriate to the problem at hand. They are not qualified for this. This is an industrial organization problem, not a computer science problem.
Done appropriately you would almost certiainly end up with multiple equilibria and sensitivity to assumptions about entry costs for pools and switching costs for individual miners. Game theory tells you very little of use for these types of problems.

It may indeed be possible to build a better mathematical model of this than they did. It may indeed be a much better use of the time of someone who is "qualified for it", than bashing the model that they put forth. But the model that they put on the table is vastly better than what we had before to describe this strategy, namely some hand-waving. Disagree? Was the 33% figure known before?

You need to model this as a dynamic game with entry and exit. They do not do this. The methodology is inappropriate tIn any case, this is all artificial since there are ways of achieving the same aim without any upfront cost. It is hard to sensibly analyze a costly attack approach when cost-free attack approaches that achieve the same aim are available.

Consider a loyalty program where you record each worker's cumulative contribution to the pool. In the event the pool acquires 51%, you divide the 50% of surplus attack revenue according to some function of current hashing power and historical contributions. The loyalty program has no upfront cost at all. As long as the attack has a nonzero chance of succeeeing, the dominant strategy is to always join the pool. The more people join the more attractive joining becomes.

And if the pool doesn't reach 51%? The selfish mining pool provides larger payouts from day 1 (or at least from the first time that 33% is exceeded. So there is no need to trust the operator for anything beyond your next payment. And what exactly are the upfront costs of the selfish mining strategy that you refer to? BTC-Guild could implement this today with a few lines of code. To be clear, I don't think it would work. If they tried that it would probably destroy their business. But I don't see the up-front cost.
38  Bitcoin / Development & Technical Discussion / Re: Majority is not Enough: Bitcoin Mining is Vulnerable on: November 06, 2013, 11:27:48 AM
This process runs away and leads any pool  that starts with >33% to end up with >50%, at which point the classic 51% attack becomes possible.


So that's the 51% attack mentioned in Satoshi's paper. I can't see any originality here

No, you don't need to get to 51%. IF you do then you can control the network. But even if you just have 40% of the hashing power, you can make outsize profits and push other miners into loss making territory, which very likely gets you to 50%. But recruiting/buying 33% of the network hash power and relying on economies of scale to get you to 50% is very different from simply recruiting/buying 50% of network hashpower.
39  Bitcoin / Development & Technical Discussion / Re: Majority is not Enough: Bitcoin Mining is Vulnerable on: November 06, 2013, 11:23:10 AM
Ideally I'd like to think about it carefully, read the paper a few times, and run some simulations before commenting, but I'll likely be tied up at the IETF all week and people are already panicking and pushing for hasty changes in response to this which may be ill-advised, so I'm going to offer some preliminary comments here.

Please do run your simulations.  When you do, make sure that you faithfully simulate a network with latency.  The word latency exists in their paper exactly one time, as a casual aside in the solution section, which should immediately set alarm bells ringing in all of our heads.  In addition, they seem to suffer from the strange notion that work in bitcoin can be wasted. 

If I boot up my multi TH mining rig and start mining blocks from the genesis block onward, is my work not wasted? Does it contribute to network security? Will I earn any block rewards for the blocks I mine? As far as the rest of the network is concerned, I might as well not exist.

Let me start with latency.  As far as I can tell from the paper, their "simulation" (and here you should imagine me doing very sarcastic air quotes) involves a network where the evil miners have magically found a way to detect the competing block in the honest miner's memory, before it has begins to spread on the network.  Gamma seems to play some sort of role here, but the meaning of it seems to change from page to page.  Or at the very least between pages 8 and 11.  Can anyone give me a good justification for abusing this poor variable in this way?

I have taken a look and cannot for the life of me understand what is confusing you. Gamma is defined quite clearly:"We denote by gamma
the ratio of honest miners that choose to mine on the [selfish] pool's block, and the other (1-gamma) of the non-pool miners mine on the other branch." The variable is consistently used with this meaning. And your assertion that "the evil miners have magically found a way to detect the competing block in the honest miner's memory, before it has begins to spread on the network." is plainly false. The situation that you describe would correspond to a gamma of 0 (the worst case). But even when gamma is 1 (i.e. "the honest miners have magically found a way to always work on the honest block in the case of a tie") the attack works for an attacker with >33% of network hash power. I find the researchers' claim that a gamma of 1 is attainable by an attacker in the current bitcoin network to be tenuous at best, but this is not that important, since the attack works even for the best case where gamma=0.

The charts are very illuminating.  In figure 2, each of the simulation points is exactly on the calculated line.  This is a dead giveaway.  The only way that can happen is if their model is fully deterministic except for mining function.


BS I replicated this result and I can guarantee you that the mining function is not deterministic. Besides, your premise is laughable. How accurately can you really read that chart? Enough to say that the simulated results are within 1% of the predicted values? 0.1%? You can easily get simulation results accurate to a fraction of that in a modest amount of time on a dated single core machine. I know because I tried.

The real gold of this paper comes on page 13.  On page 13 they handwave over the latency issue by pointing out that an attacker could insert itself between every other node on the network.  Let me just sum up a few years of discussion on this topic...


Strawman. Nowhere on page 13 do they suggest that or anything that I can interpret as being equivalent to an attacker being required to "insert itself between every other node on the network". If you disagree please post the relevant quote. As stated earlier, I find their assertion that gamma close to 1 is attainable to be tenuous, but this is just a misrepresentation of their position.

Of course, everyone instantly sees how silly that is, so they had to dress it up in pseudo-scientific gibberish so that people would click on their crappy website and check out the douchebag's glamour shot.

Real mature. This is peer-review, is it?
40  Bitcoin / Development & Technical Discussion / Re: Majority is not Enough: Bitcoin Mining is Vulnerable on: November 06, 2013, 09:06:06 AM
This paper is game theory fail.

Fail A
1) The benefit from selfish mining comes from future reductions in difficulty.
2) Until the reduction in difficulty happens, the selfish miner (like other miners) incurs losses.
3) Once difficulty falls, the lower difficulty is open to all. Some other selfish pool could step in and reap all the benefits. Socialized gains; private losses (and socialized losses). Doesn't seem rational unless you have some reason to believe that you can beat pools that copy the strategy. If you try to do the strategy and succeed in lowering difficulty, but ultimately some other pool comes out on top, then you will take losses.

Don't quite agree with you here.
1)  Agreed
2)  Agreed. But it is important to note that the selfish pool suffers smaller losses than the others. Therefore rational wealth maximising agents who denominate their wealth in BTC would join this pool (were it not for your observation under Fail B which I will get to next).
3) The lower difficulty is open to all, but the other pools are still underperforming relative to the selfish pool. Rational miners still join the selfish pool. It is entirely possible that another selfish pool starts up, but far from being a threat to initial selfish pool operator, it is actually the best thing that could happen to him. Since the gains grow superlinearly both pools will mine more coins by joining forces than they would have otherwise. This process runs away and leads any pool  that starts with >33% to end up with >50%, at which point the classic 51% attack becomes possible.

Fail B
Some pools offer PPS. As long as these pools commit to keep up their PPS scheme, miners will migrate to these pools in the event of the attack. This causes the attack to fail. Sure the PPS pools bleed coin in the beginning, but in the end they end up with more miners and the attack gets resolved. If you put this in a economic model with switching costs [i.e. people stay at a pool unless there is a significant benefit from switching], the attack is a probably a net win for the honest PPS pools.
To retain miners, the attacker would need to switch to a PPS system as well. But then he is essentially creating bad luck and insuring people against it simultaneously. This attack is a surefire way to bleed coin.

THIS is a critical observation, which I have not thought of or seen mentioned elsewhere.  Essentially PPS can invalidate the entire attack, since a rational miner would rather join a PPS pool, where he will earn even more income than from joining the selfish pool. One can reason that the PPS operator, (who takes the hit for all of the orphaned blocks) will cancel the service or put the price up enough to compensate. But this means that the attacker first needs to keep the attack up for long enough to drive all PPS operators out of business. Only when this is complete will rational miners flock to join the selfish pool. This makes PPS operators vulnerable to this attack, but it is not very different from the well known block-withholding attack that they have always been vulnerable to, in fact it is a little less serious since it can easily be detected. Also, if someone with deep pockets (Bitcoin Foundation? BTC guild?) publicly commits to keep at least one PPS operation afloat for the duration of any such attack, then the selfish pool attack suddenly becomes very unattractive indeed, since you need to incur a sustained loss (relative to what you could have earned with the same hashing power at a PPS pool), and only if you can sustain this loss for longer than the PPS operators can sustain the loss you are inflicting on them can the attack actually start recruiting other rational miners to help you. This is somewhat analogous to trying to enter a new market against an entrenched competitor who is committed to a strategy of predatory pricing i.e. they will sell their products at a loss until you eventually go bust or leave the market.

Combine this with Fail A and you can see that the entire paper is fail.

I actually think the paper is quite good. The attack is quite unlikely to work in practice, but the theory is incredibly important. The result  is counterintuitive, but undeniably correct. I've done my own calculations and simulations and arrive at the same results as they do. Some claim that the attack was known before, but I am afraid none of the rather vague hand-waving explanations of a mining cartel attack has managed to convince me that this is possible. The fairly basic math used in the paper convinced me in less than an hour.
Pages: « 1 [2] 3 4 5 6 7 8 9 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!