A 40 GH/s farm isn't much more efficient than a 10GH/s farm. A 100 GH/s farm has no real economic advantage over a 40 GH/s farm. not necessarily true. a company could create an ASIC and keep it to itself this will be very inefficient for making a 10ghash farm, but could be better than FPGAS for 10terrahash farms currently the total value of bitcoin isnt large enough to attract "big players" |
|
|
|
|
If clients use bip16/17 before 51% of the miners support it, invalid P2SH transactions can end up in the chain, because old miners will think they are valid.
when 51% of the miners upgrade invalid p2sh transactions will be rejected by minersand will never end up in the block chain- so even if an old client thinks it's valid - it doesnt matter , because there wont be any invalid transactions in the blockchain
|
|
|
|
But where's the incentive for a miner to do this? Perhaps it is cheap enough to do this today, but as the tx volume grows it quickly becomes a significant cost, both in terms of computation power and bandwidth. And what is the punishment if a miner signs a tx and then reneges and mines an alternate version (perhaps because it includes a larger tx fee?)
none what is the incentive today of miners to include transactions at all? the 0.1BTC transaction fees? the incentive would be to keep the network working properly, otherwise bitcoins will lose their value. |
|
|
|
I meant to type Mhash of course as I mentioned it's a HD6850
I have no idea what kind of stales they are, the p2pool application does not report anything that seems relevant. Also the amounts of rejects is see reported by my miner are vastly lower than these very high stale percentages.
yes it does: Recent: 0.14% >210MH/s Shares: 26 (2 orphan, 0 dead) Peers: 11 (1 incoming) |
|
|
|
|
so basically you are saying: forget about backward compatibility and implement the best solution without any constraints?
|
|
|
|
I have consistently higher stales than the pool. Today I mined my HD8650 for 8 hours non-overclocked (so at ~210Mhz instead of ~250Mhz) and that did not improve it any. On average p2pool reports ~16%+-16 while the pool is usually about 8% (today it even reported 23%+-23% !)
Is there anything I can do about this?
mining on a CPU? 210/250Mhz doesnt make sense. CPUs run at ~2Ghz, GPUs at ~1Ghz are the stales dead or orphans? (dead = miner problem, orphan = network problem) |
|
|
|
|
cas, if you are proposing to do a chainsplit, then why not implement the 3 parts signature, why not implement the "perfect solution"?
|
|
|
|
|
you should use something like:
(hash of last block in the chain) mod (number of participants in the lottery)
otherwise you can enter yourself and say your entry is the winner
|
|
|
|
|
the GUI crashed for me a few times as well
bitcoind is stable
|
|
|
|
Is it a promise to reject any block contains a different transaction with the same inputs? That might leave the miner off the real chain forever no? But otherwise what does it matter? They'll mine the tx unless another gets in first? Not much help really.
its not a promise to reject, but a promise not to mine a conflicting transaction. and to include your transaction in a mined block (so even if a block is orphaned due to other reasons, the transaction will still be included later) so if you got a signed reply from 40-50% of the hashpower - you can be quite safe that a competing transaction won't end up in the longest blockchain. it's not 100% safe, but it's a good indicator. But i think it has the potential to flood the network when there are a lot of transactions.maybe there should be a way to consolidate miner sigs. so if a client sees 2 verifications it will send out 1 packet with both sigs, so after a while you will have only 1 confirmed transaction being flooded in the network with a long list of sigs. and maybe add a timeout - you can only send/propogate a certain signed transaction once every 2 seconds - you will have more chances hearing new sigs in that time. |
|
|
|
A client can estimate the hashing power of a miner by looking at the payouts of newly generated blocks. He can then send his transaction like normal, but get instant replies from miners. If a miner decides to include the transaction in his next block he will send a signed version of the transaction - signed by the private key of his payout address + attach the public key The client can listen for these "signed by miner" transactions, verify that the public key hashes to payout address and matches the sig, then estimate the total hashing power that "promised" to include his transaction in the next(or later) block was this already suggested? too tired to think of security holes right now  |
|
|
|
|
I know some of bots who would love that
|
|
|
|
I know it refuses when its loading. But does it refuse when it doesnt have the blockchain even after it finished loading but still downloading the chain? I got the bitcoind client from git master, and accidentally messed up my blockchain. couldnt get p2pool to work. so i waited for it to sync and then it worked fine. 1:20:14.481000 p2pool.util.jsonrpc.Error: -10 Bitcoin is downloading blocks... maybe its a specific call that fails... so it actually doesnt refuse rpc  |
|
|
|
from my experience bitcoind refuses any rpc request until it has the full blockchain so just wait |
|
|
|
|
can they trademark "4 to 6 weeks" by now ?
|
|
|
|
|
Show Posts
