|
362
|
Bitcoin / Development & Technical Discussion / Re: bitcoind stops responding to RPC requests
|
on: March 25, 2011, 08:42:49 AM
|
|
I think we got a deadlock in there...
rpc:
sendfrom
CRITICAL_BLOCK(cs_mapWallet)
SendMoneyToBitcoinAddress(strAddress, nAmount, wtx)
SendMoney(scriptPubKey, nValue, wtxNew, fAskFee)
CRITICAL_BLOCK(cs_main)
...
processmessages:
CRITICAL_BLOCK(cs_main)
ProcessMessage(pfrom, strCommand, vMsg)
AddToWalletIfMine()
AddToWallet(wtx)
CRITICAL_BLOCK(cs_mapWallet)
|
|
|
|
|
363
|
Bitcoin / Development & Technical Discussion / Re: CreateNewBlock too slow (especially while bitcoin is under tx spam attack)
|
on: March 25, 2011, 08:30:35 AM
|
|
Yes, only once every 60 seconds.
note that CreateNewBlock holds cs_main and cs_mapTransactions while doing its thing.
So it not only blocks RPC for that time, but also processing and sending of p2p messages and ... really, pretty much everything.
On a decent box with 1500 cached tx, it takes 1.7 seconds.
In extreme cases (lots of cached tx, slow cpu, low free memory so a decent % of reads actually have to hit disk), well north of 10 seconds.
And it's entirely avoidable.
|
|
|
|
|
365
|
Bitcoin / Mining / Re: UltraSPARC III @ 1200Mhz
|
on: March 24, 2011, 12:04:47 PM
|
|
According to sun, T2 can do "32 Gb/s/chip" for SHA-1
let's just assume it's as fast for SHA-256.
let's further assume it's magic and has 0 setup cost.
SHA256 block size is 512 bits, so 32Gb/s / 512 = 62.5M sha256 blocks/s
one bitcoinhash is 2 sha256 blocks, so 62.5M / 2 =
31.25Mhash/s.
Not bad for a crypto accel.
A $110 HD5770 does > 5x that.
|
|
|
|
|
367
|
Bitcoin / Bitcoin Discussion / Re: Mining power of Bitcoin vs other networks
|
on: March 21, 2011, 04:01:59 PM
|
|
Yeah, typo, meant 2*2858T = ~ 5700TFLOP/s
current estimated network speed is all over the place depending on if you use difficulty, 1-day avg, 1-week avg or whatever
so "somewhere around 5-6 PFLOP/s"
[edit]
argh, 2*2858T = ~ 5700TFLOP/s, not G
|
|
|
|
|
368
|
Bitcoin / Bitcoin Discussion / Re: Mining power of Bitcoin vs other networks
|
on: March 21, 2011, 08:39:59 AM
|
|
5.8 petaflops, or 5800 teraflops...
on pretty much all recent archs with vector units, one 32-bit INTOP = 2 single precision FLOP
one bitcoinhash is ~6.35k x86 INTOP
450G hash/s * 6.35k INTOP/hash = 2858T INTOP/s
2858T INTOP/s * 2 FLOP/INTOP = ~6700T FLOP/s
|
|
|
|
|
370
|
Other / CPU/GPU Bitcoin mining hardware / Re: PS3 miner?
|
on: March 21, 2011, 02:04:05 AM
|
|
It's not that hard to calculate.
We have 6 SPEs available, each can do one 4*32 bit vector op/clock. clocked at 3.2GHz.
6 * 4 * 3.2G = 76.8GINTOPs
No native bitrotate, no ch()-like opcode, so we need about 6350 ops/bitcoinhash.
76800M / 6350ops/hash = ~ 12.1 Mhash/s
Not THAT bad for a >5 year old design.
About on par with a modern CPU, completely outclassed even by a midrange GPU.
PS3: 12.1Mh/s, ~80W, ~$250
HD5770: 156.8Mh/s, ~110W, ~$130
|
|
|
|
|
372
|
Bitcoin / Development & Technical Discussion / Re: [PATCH] bitcoin scratch-off cards
|
on: March 18, 2011, 10:52:34 PM
|
|
Yep, that works.
You still can't tell a scratchoff spend from a normal transaction, so assuming scratchoffs come in 50btc sizes, an attacker has to try that for every 50btc transaction he sees.
Of course attacker can also choose different time/space tradeoff (store 2**40 points, 2**24 add G + lookup ...).
Random idea: what if you make code->secret more costly, let's say pbkdf2-hmac-sha256 with 100k iterations?
that way a simple airthmetic lookup table wont work anymore, you'd have to pretty much create a few arbitrary pubkey->code functions and build rainbow tables.
as the tx really only needs to be secure enough to make it economically uninteresting to break it before it gets into a block (attacker needs to find privkey, create double-spend, get THAt into a block before the orig tx makes it into a block...).
|
|
|
|
|
375
|
Bitcoin / Mining / Re: Flash Player under a 5970 lowers core MHZ and hash speed.
|
on: March 17, 2011, 02:01:26 AM
|
|
The problem iirc is, if anything uses gpu video acceleration, ATI driver switches to "media playback" clock, which is 400 core/max mem.
Possible solutions:
a) enable overdrive, manually edit the overdrive config .xml to change state 2 core clock to state 0 core clock
b) use RBE to hack the cards BIOS and change the clocks/voltages for the 400 mhz core/max mem clock state there to have same high core clk as normal 3d mode state.
|
|
|
|
|
376
|
Bitcoin / Mining / Re: The determining factor on MH/s?
|
on: March 12, 2011, 08:27:49 PM
|
|
published FLOPS for GTX580: 1581.1G
512 ALUs * 1544 MHz shader clock * 2 (muladd factor) = 1581.056G
published FLOPS for HD5970: 4640G
3200 ALUs * 725MHz * 2 (muladd factor) = 4640G
hey, what a coincidence!
|
|
|
|
|
377
|
Bitcoin / Mining / Re: The determining factor on MH/s?
|
on: March 12, 2011, 07:13:47 PM
|
|
off-by-3-orders-of-magnitude.
HD5xxx needs about 4150 integer operations per hash
HD4xxx and nvidia 2/4/5xx about 6350 integer operations.
for all current architectures integer ops/second = number of shader ALUs * clock.
so a 5870 at 1600 ALUs * 850MHz = 1360000M intops/second, / 4150 = ~ 327.7Mh/s
4870: 800 * 750M / 6350 = ~ 94.5 Mh/s
GTX580: 512 * 1544M / 6350 = ~ 124.5Mh/s
etc...
usually published FLOPS numbers are simply intops * 2 (one muladd counts as 2 operations).
|
|
|
|
|
378
|
Bitcoin / Development & Technical Discussion / Re: [PATCH] UPnP
|
on: March 12, 2011, 09:40:29 AM
|
One more consideration.
Can someone guarantee that there is not a single buffer overflow or some other vulnerability in bitcoin code present and future? And put a 21m BTC bond to make such guarantee worthwhile too? If not than we'd better have this off by default.
Otherwise, consider the risk of a 0 day exploit coming up and someone cleaning up balances of all nodes accepting incoming connections. This would be the end of bitcoin.
Without UPnP by default only supernodes would get robbed and they should know better than keep any decent money anywhere near node accepting connections. This still would be nasty but not fatal.
There is simply no argument against this risk assessment. Case closed.
P.S. vote whatever you want 'upnp on' decision will be vetoed either by Gavin or by Satoshi himsef. So do not rush selling all your BTC's just yet.
In a remote buffer overflow scenario all nodes participating in the normal p2p network are pretty much fucked, no matter if they accept incoming connections or not. Consider the following scenario: Attacker exploits bug and disables all public nodes allowing incoming connections. Nodes *not* allowing incoming connections see their outgoing connections count dropping and try to connect to new peers. Only nodes left accepting incoming connections are under control of the attacker and exploit same bug in nodes connecting to them. Whoops. |
|
|
|
|
Show Posts
