Search content
Sort by
Showing 20 of 351 results by Costia
Quote
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 itselfthis 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
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?)
nonewhat 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.
Re: [150GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
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: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.
Quote
Recent: 0.14% >210MH/s Shares: 26 (2 orphan, 0 dead) Peers: 11 (1 incoming)
Re: [150GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
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?Is there anything I can do about this?
210/250Mhz doesnt make sense.
CPUs run at ~2Ghz, GPUs at ~1Ghz
are the stales dead or orphans? (dead = miner problem, orphan = network problem)
i think that the whole point was to avoid a fork
otherwise they could implement their "perfect" solution and a few other features/fixes.
https://en.bitcoin.it/wiki/Hardfork_Wishlist
persinally i am in favor of bip17, but it looks like bip16 has the majority of dev's support.
So implement it in 0.6 and be done with this mess already.
https://en.bitcoin.it/wiki/P2SH_Votes
otherwise they could implement their "perfect" solution and a few other features/fixes.
https://en.bitcoin.it/wiki/Hardfork_Wishlist
persinally i am in favor of bip17, but it looks like bip16 has the majority of dev's support.
So implement it in 0.6 and be done with this mess already.
https://en.bitcoin.it/wiki/P2SH_Votes
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
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
Re: [150GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
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.
so it actually doesnt refuse rpc
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.
Quote
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