Does this version have coin control? No, Coin Control was found to be poorly designed (how can you control specific outputs held by the same address?) and its maintainer disappeared. Parts of it (grouping logic) were merged into the new raw transaction RPC methods. At this point, getting Coin Control in probably means someone needs to step up to adapt it and clean it up to provide the same functionality as the raw transaction stuff. Together with multisig coin control is one of the most important features imho. No coin control is a deal breaker for me and potentially for anyone who ever used it... It is not quite clear to me, could you/team please clarify if it is possible via rpc in 0.7? Yes, it is possible via the raw transaction RPC API. Your software is required to know how to construct proper binary-format bitcoin transactions. Are there any plans for implementing the gui for it?
None immediately, no. |
|
|
|
Will the old addr.dat always hang around now that peers.dat has replaced it? I notice peers.dat is much smaller, is this because it is a more efficient internally managed method? Nice work again everyone, if there is any type of formal test plan I am happy to help run it.
The old addr.dat is never deleted. You may wish to swap back to an older version in an emergency. New users will never see addr.dat, once 0.7 is released. |
|
|
|
Summary: Add small-data OP_DROP transactions as standard transactions. URL: https://github.com/bitcoin/bitcoin/pull/1809This is likely to be controversial. It is useful to highlight this ancient thread, where satoshi, gavin, myself and others discuss the merits and perils of data in the chain. The consensus tends to be, - It bloats the chain
- It incentivizes non-currency chain usage, which negatively impacts all who use bitcoin as a currency
- It is unavoidable...
- ...so we might as well figure out a way to permit a few tiny uses, such as carrying a hash or auxiliary transaction id or comment along with each transaction, while creating some limits that discourage wholesale binary data storage in the main chain.
This change is intended to enable use cases like Mike Hearn's distributed bond markets example. |
|
|
|
No matter what, the core development group is dead set against using any auditable database technology for storage, so the cost of modifications will continue to be very high.
What specific technology would you rather we use? |
|
|
|
Very nice Gavin! What are the changes between rc1 and rc2?
Lots of minor bug fixes. Git users may view the shortlog with $ git shortlog --no-merges v0.7.0rc1..
|
|
|
|
valgrind is your friend  |
|
|
|
|
In general, it is simply not advised to expose the RPC server to the Internet. There are a great many things that should be done before it would be considered safe for exposing to the Internet.
A proxy server is a much better suggestion. Then you may expose precisely, and only, what you need. That's how pool servers work. Proxy servers also permit accessing multiple backend bitcoind's and other flexible solutions.
|
|
|
|
BIP 34 - block height in coinbase The wiki-entry says Backward compatibility
All older clients are compatible with this change. Users and merchants should not be impacted. Miners are strongly recommended to upgrade to version 2 blocks. Once 95% of the miners have upgraded to version 2, the remainder will be orphaned if they fail to upgrade. How do miners have to upgrade? Does this affect the single miner or also miners working in a pool? Also, It's not explicit what the change is for either. Somehow associated with the block reward change? I kind of hoped all the necessary groundwork would be in place from 0.1.0 (so this is a desirable but not vital alteration?) The BIP links directly to the code change. It's hard to be more explicit than that. |
|
|
|
BIP 34 - block height in coinbase Is there any web service to see the current ratio of v1 / v2? Not AFAIK. If you have access to a bitcoin node, the debug.log file will show SetBestChain: some_number of last 100 blocks above version 1
|
|
|
|
And it seems that Berkeley DB version 5.1 development library is what's required (and not 4.8 as in the above document, but the other dependencies listed are useful to getting the job done)
Version 4.8 is the recommended and upwards compatible version. Version 4.8 is what the official binaries are built with. However, your operating system may ship a more recent version by default. Or sometimes data downloaded from third party websites (not recommended!) is built with another version of BDB. |
|
|
|
Does this version have coin control?
The raw transaction API provides coin control, and is accessible via the GUI's RPC console. There is no coin control dialog, if that was your question. |
|
|
|
Which version of Berkeley DB libraries is preferable? Qt Creator is telling me it doesn't have <db_cxx.h>
Version 4.8 provides maximum file format compatibility, and is the recommended version. More recent BDB versions work also. |
|
|
|
It may need human assistance to be installed in some vendor's hosting arrangement.
It sounds like you did not read gmaxwell's post; it covers this. |
|
|
|
MT sig verf?
Multi-threaded signature verification Consider the number of P2P commands needed for your proposal, versus today. It's like 10x the number, with associated additional latency. |
|
|
|
I was talking on the #bitcoin-dev chat ( http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/08/25#l4357862). On there some discussion about block relaying came up. In fact this is a very important discussion and I'm surprised I haven't seen it come up very much. Here is an alternative solution to block relaying... 1. Nodes ask for block hashes though inventory messages as normal. 2. Nodes download the headers from several peers. 3. Nodes will validate headers as they come and fit them together. 4. Nodes will record download speeds for different peers and stop downloading from relatively slow peers and to download more important data from faster peers. 5. Nodes will download blocks in segments. How exactly is up to discussion but the merkle tree allows for download and validation of blocks segments. Blocks can be downloaded by multiple peers and blocks can be relayed before they are fully validated. It would be nice to improve block relay latency but the above proposal introduces a large amount of additional latency to the optimal case (bitcoin on tmpfs w/ MT sig verf). We don't want to slow things down like that. |
|
|
|
great! I'm waiting for it where can I look for that rc1 release? I see some features that are planned for 0.7 release (like get raw block/transaction data). Is there anyplace to download the development version for that 0.7?
Thanks
0.7.0rc1 is due out any day now. That's where the source code lives. Bitcoin software releases are uploaded to SourceForge: http://sourceforge.net/projects/bitcoin/ |
|
|
|
So far I've discovered the way bitcoin uses targets is silly. For instance, what is the point in blocks containing the target?
At a minimum, you do not need the entire blockchain history just to validate the block matches the target. Also the way you can't have a mantissa over 7FFFFF is stupid.
By "stupid" ITYM avoiding pointless, redundant support that would exist only to enhance the artificial sense of completeness that some computer scientists need. It's quite efficient, considering the limited storage (32 bits) into which a much larger number is stored. |
|
|
|
In addition to the fully validating node and python-bitcoin module, pynode also maintains a branch that contains a non-validating node calling a "mini-node", naturally found in the "mini-node" branch of pynode.git: https://github.com/jgarzik/pynode/tree/mini-nodeThis is essentially ArtForz' half-a-node, with the minimum needed to work on mainnet. Forks have already started appearing. blkmond inside pushpoold existed for a long time. And bitcoin network sniffer fork also just appeared. |
|
|
|
Script verification is now enabled by default. Unfortunately it is quite slow, for an unexpected reason: Python is very slow copying data structures. Therefore, I strongly urge users to download the chaindb.tar.bz2 archive mentioned earlier in the thread. Otherwise the block download could take a day or two. Plans to mitigate this include: - Do not verify scripts earlier than a checkpoint (reference client does this)
- Store database of only unspent CTxOut (sipa's reference client ultraprune branch does this)
- Swap out slow GDBM database for new pagedb database
|
|
|
|
I don't know if this is some sort of bug or attack or someone testing stuff. There has been 3 user transactions so far on the block chain. If anyone has more info about this let me know.
Did you change 'pchMessageStart'? If not someone who accidentally connects to the bitcoin network with ppcoin will bridge them and IP addresses will be shared. Could this result in bitcoin transactions being sent (and rejected) to ppcoin? Hmm you are right I didn't change that. That's why I guess I saw some 17k new addresses in the log. If it's needed I guess we can change this in a future release with a network protocol upgrade. Hopefully it doesn't cause too many problems at the moment. It is very important to change pchMessageStart. This will cause all manner of software confusion, because peers with the same pchMessageStart will exchange addresses and otherwise think they are talking with peers of the same network and block chain. A hard fork is not required to change pchMessageStart, just a tiny bit of bootstrapping. Blockchain integrity is not impacted. |
|
|
|
|
Show Posts
