Use a 'switch' statement rather than a super-long if tree  |
|
|
|
Sorry, I agree with Nefario here. Keep Bitcoinica issues out of Bitcoin Conference thread. They are completely off-topic.
+1, agreed |
|
|
|
|
I occasionally think about making the number of rounds variable, based on some algorithmic factor: ALGO_A(passphrase), take lower N bits (16? 20?) as number of rounds of ALGO_B(passphrase)
|
|
|
|
|
FWIW the set of unspent tx-out's should fit nicely in RAM, for some time to come.
I know that's not helpful to applications doing historical queries, but it may be helpful for other queries.
|
|
|
|
Right now, the Satoshi client has no tx-forwarding capability.
This is certainly not true. If the Satoshi client did not forward transactions, nothing would get relayed on the network. But I'm guessing you meant new transactions? If so, you want the recently added sendrawtransaction RPC from the 'raw transactions' API. |
|
|
|
I don't intend to discourage or insult your efforts (in fact, I think you said you were getting similar speeds). Plus, I think that writing such a parser/scanner is both useful and educational. I just bring it up because I would guess that this is about as good as anyone can do with a non-SSD drive. And it's especially impressive considering I did no optimizations. I'm especially curious how leveldb works under the hood that it could be so efficient. Maybe there's something to learn from it.
LevelDB provides the backend to Google's services, so it is not surprising that it is so heavily optimized. One of the key optimizations is that writes go to a log, and then another thread comes along in the background and "optimizes" the log data back into the main database, using hueristics to hopefully place the data in a useful, locality-friendly location on disk. BitcoinJ author Mike Hearn has proposed replacing BDB with LevelDB in the Satoshi client, and we are looking seriously at that. Here is his pull request: https://github.com/bitcoin/bitcoin/pull/1619 |
|
|
|
Actually, XKCD has packed an amazing amount of password wisdom into a single comic: http://xkcd.com/936/Title: "password strength" |
|
|
|
There are many ways that the bitcoin software is more conservative than the protocol Only relaying standard transactions is another well-known example... |
|
|
|
EDIT: This would also rip to shreds Microsoft's silly whitepaper assertion that Bitcoin will "fail" when peers stop relaying traffic due to lack of incentive. Blast your traffic to thousands of miners yourself, and never worry that "no one" will hear your transaction due to greedy relays wanting your fee for themselves.
(emphasis mine) Relaying nodes do not receive any fees for relaying. And there are more than sufficient nodes on the network to prevent an attacker or miner from preventing a transaction from being relayed to others in 99% of the cases. |
|
|
|
When does "GetBalance" increment?
When the bitcoind receives a 0-confirm tx, after 1 confirmation, after 6?
Can this be modified short of modifying the source code and recompiling?
Had to ask sipa for the answer: 1 for external transactions, 0 for change or send-to-self ones |
|
|
|
We've survived hacks on major exchanges, thefts in the hundreds of thousands of dollars, and hundreds of thousands of bitcoins.
None of those incidents had anything to do with the core bitcoin software. We'll survive a responsible disclosure policy.
Responsible disclosure (edit) for a security researcher is ~two weeks.
Responsibility means evaluating the impact on users, recognizing that every situation is different, and that every solution takes a different amount of time to deploy. It is not responsible to pick an arbitrary length of time for disclosure, and stick to that regardless of circumstance or feelings of involved parties. |
|
|
|
It's probably fodder for another topic, but I am of the opinion that in the event of a very large reorg (where more than 6 blocks are rolled back), the proper behavior of a bitcoin client should be to stop functioning and demand that a new client be downloaded from the developer(s) of that client, and to assist the user in exporting their wallet and ensuring their replacement client is properly signed by the developer. This is based on philosophizing that it would be better for the bitcoin network to go down in an orderly fashion in the event of an attack - long enough for developers to agree on countermeasures tailored to the attack - just like the recent space rocket that changed its mind and aborted the launch at the last second - rather than for it to stay up and operate chaotically and at a financial loss to users.
During the output overflow incident, we were all rather glad that the collective client base did not do this. Once miners upgraded, everyone reorg'd back into working order. This is just one of many reasons why there is a 120-block new-bitcoin confirmation policy in place. |
|
|
|
Trying to investigate a luke-jr claim from IRC: <luke-jr> sipa: already we have p2pool + height-in-coinbase-bitcoind making ver=2,coinbase=no-height blocks
The dev team is working on BIP 34 - height in coinbase, and if what luke-jr says is true, then there is a buggy p2pool implementation out there generating invalid version 2 blocks. For those hackers out there, this is the BIP 34 change: - pblock->vtx[0].vin[0].scriptSig = (CScript() << pblock->nTime << CBigNum(nExtraNonce)) + COINBASE_FLAGS;
+ unsigned int nHeight = pindexPrev->nHeight+1; // Height first in coinbase required for block.version=2
+ pblock->vtx[0].vin[0].scriptSig = (CScript() << nHeight << CBigNum(nExtraNonce)) + COINBASE_FLAGS;
All that is required is that nHeight be the first element of the coinbase. |
|
|
|
|
Bitcoin was built so that anyone may validate data from untrusted sources, eliminating the need for super-nodes.
If indeed you are downloading headers, why would you compromise privacy and security by adding a trusted super-node back into the mix?
Connect to the normal network, get addresses, then "getheaders" (P2P command)
|
|
|
|
|
Transactions that cannot be connected to the main chain are known as "orphans." The standard bitcoin client will keep up to 10,000 orphans in memory, before randomly deleting them to keep that at or below 10,000.
Connect-able transactions are stored in the "memory pool" -- the zero-confirmation state -- until they appear in a block.
Assuming that A is broadcast as well as B, you are connected to the chain, and your transactions will not be orphans. Nodes will relay A and B for you.
As another poster noted, A and B may appear in the same block.
|
|
|
|
|
Pull requests for cpuminer are still welcomes.
cpuminer is definitely used on testnet and various other alt-coin scenarios.
|
|
|
|
The block chain database contains only one(single) block chain not all blocks from all forks.
The Wiki disagrees: https://en.bitcoin.it/wiki/Block_chainBlocks in shorter chains (or invalid chains) are called "orphan blocks", and while they are stored, they are not used for anything. Neither are true. All connectable blocks are stored and connected, so that we may switch from the current chain to a new chain at any time. |
|
|
|
|
If the users of bitcoin did not like the chain lock-ins from bitcoin/bitcoin.git, then it is trivial to ignore or compile-out those updates. Users vote by choosing the client they use to store their funds. They vote on chain rules, checkpoints, and any number of other technical details.
A block chain is ultimately a community consensus.
|
|
|
|
Github URL: https://github.com/jgarzik/pynodepynode is a simple bitcoin P2P client, originally based on ArtForz' half-a-node, which maintains a blockchain database and TX memory pool. All bitcoin-related code is separated into a "bitcoin" module, permitting you to use core features such as CBlock or P2P message serialization, without actually using the node itself. Therefore, pynode has two goals: 1. As a generic "python-bitcoin" library, for any project. Update: Now a separate project, https://github.com/jgarzik/python-bitcoinlib2. As a P2P node that may be used as a base for other projects, such as a network monitoring node or P2P proxy. At present, it is mainly for developers and not end users. Here is what pynode does not do: Here are the limited things that pynode can do at present: - Outgoing TCP connection to a single remote P2P node
- Initial blockchain download
- Maintain a transaction memory pool, with TX's removed as they are confirmed in blocks
- Maintain an indexed blockchain database
- Respond to JSON-RPC requests via an internal HTTP server
Over time it will become more capable, but this is an alpha quality release for developers at present. |
|
|
|
|
Show Posts
