...annnnd it's paid for itself, USD-wise. 33 BTC earned in just 91 hours.  A bit more to go to break-even BTC-wise yet. Well, I just earned 50+ BTC last night solo mining.  |
|
|
|
|
If the users are not voting (validating), then it is trivial for miners to rewrite the rules.
If the users are fully validating, then a miner decision to have each block produce 50 BTC again would be instantly rejected.
|
|
|
|
Hold off on using this dataset. Due to a local linking mistake, it was built with BDB 5.x.
Issue fixed. Dataset updated. OP updated with new hashes and byte size. |
|
|
|
|
1MB blocks were tested without incident long ago on testnet, under the same rules that failed on March 11th.
The issue is not block size, but more complex, something like "number of existing BDB transaction index records accessed during block verification" (past transactions accessed/spent).
|
|
|
|
You would need to consider how peers can discover each other. Even if routing data can be extracted from the block chain, the protocol requires direct communication between all parties (ie, TCP connections). IP addresses change. One possibility is to require all participants to use Tor and then embed your hidden service key in a transaction. That way you get authentication, encryption and privacy for free. This boils down to using (abusing?) the Tor HSDir servers as a secure rendezvous mechanism. The short key hash (onion address) can be added to the channel transactions using OP_DROP. Note that whilst the Tor protocol is very slow/heavy for connecting, there is a proposed optimization for the case where participants don't actually care about being hidden:
My idea was a separate P2P network, where the cost of the identity and cost of the message transmission could be expressed and verified (either directly by bitcoin payment, or indirectly by burning coins). |
|
|
|
|
Hold off on using this dataset. Due to a local linking mistake, it was built with BDB 5.x.
Rebuilding the dataset with BDB 4.8 will complete in a few hours.
|
|
|
|
|
FWIW, I've been talking on IRC about a decentralized network of bots (numbering 3, 5, or 7, not large numbers) that would facilitate off-chain transactions, escrow, auctions, etc.
Check out the #bitcoin-dev logs from last night.
|
|
|
|
I have seen it posted that 0.7 can itself produce blocks that some instances of 0.7 will reject;
That is true, though unlikely. |
|
|
|
Can you explain how locking is handled better by leveldb for the particular type of database transaction that can require unbounded locks on bdb?
It is simply a different design. leveldb does not need per-page locks, and is not an ACID database. leveldb has a concept called a "batch", and batches are committed atomically. |
|
|
|
What's the best way to orient the machine for best heat dissipation? I noticed the "bottom" (large surface with most screws) is the hottest. Would placing the machine hot-side up be the best? Or would that be unadvised in case something comes loose due to fan vibration? I've seen a few people stand their machines up vertically too.
Standing the machine up vertically led to increased temperature readings, here. I saw in the brief Bitcoin Foundation video that Yifu had oriented the machine laying down; I copied that. |
|
|
|
After reading all the responses to the issue, I think I would be satisfied if I could just build the thing on Windows using Visual Studio 2010 without fetching endless external dependencies and without a set of build instructions that rivals the size of the Bible (old testament).
If it makes you feel any bigger, sipa would love to ditch the OpenSSL dependency ;p (and has been coding in that direction) |
|
|
|
Withdraw offer (50 @ 0.715)
Got them from other seller
Huh? With practically every auction it is binding. When you buy something on ebay, or when you go into a house/property auction, you can't withdraw your offer willy-nilly. This is also why you can't edit/delete posts here. Give him a break New offer, 50 @ 0.72 |
|
|
|
For diagnostic purposes, here is a blockchain dataset built by a 0.7.2 bitcoind w/ db 4.8 + "-detachdb": http://gtf.org/garzik/bitcoin/chain-db48-h225429.tar.bz2It contains blockchain + index, up to height 225429, making it easy to reproduce an injection of too-large blocks at the precise juncture where the recent chain fork occurred. Byte size: 5776366736 (5.3G) MD5: f26deaaf05197bcbc73d33fed2443db3 SHA1: 743d1eaac3b590e996a22e707288fd9a21aa4c63 SHA256: 4dfd766c7cdfa346ad10e648900476dfc590605f78a78dff0c2608131c0f6c46 |
|
|
|
For diagnostic purposes, here is a blockchain dataset built by a 0.7.2 bitcoind w/ db 4.8: http://gtf.org/garzik/bitcoin/chain-db48-h225429.tar.bz2It contains blockchain + index, up to height 225429, making it easy to reproduce an injection of too-large blocks at the precise juncture where the recent chain fork occurred. Byte size: 5755999214 (5.3G) MD5: 479e6364352d0ec68ea5cf87200f7f1e SHA1: 18bc8ff5e572fc4a27828341249477eb8355f012 SHA256: 41787306487da1957717d72407fc1e01ed5965202802f7d18e2930a30fc169a2 |
|
|
|
I just found out there is a minimum payout ... switching back to p2pool - I am too small for eligius too. May be later Technically speaking, there is a minimum payout with p2pool also, due to higher difficulty. I'm waiting for eligius and other pools to start setting the global minimum difficulty above 1.0... |
|
|
|
|
Show Posts
