I really should get around to writing some separator related unittests; we don't have any right now.
+1 Related note: JSON test vector data from bitcoin/bitcoin.git is reused in multiple projects: pynode, picocoin and now node-libcoin. |
|
|
|
Very cool. It is much like my recently introduced txtool utility. I tend to prefer the git-like sub-command model, rather than putting all the utilities in PATH. |
|
|
|
What happened to OP_RETURN? In bitcoin wiki it just says "Marks transaction as invalid." How could it satisfy any output? Has the definition changed?
wiki wording does not precisely match actual function. |
|
|
|
You really shouldn't mess with the file directly. Treat it like a black box and use the proper tools (bdb).
This is true for most people (but I am not most people <evil grin>) +1 to anyone making proper documentation of the key/value pairs though. I can think of a number of useful utilities that could be made more easily if people knew how.
+1 |
|
|
|
Title says it all, any documentation (other than the code) on the format of the wallet.dat file?
No. The file format is Oracle Berkeley DB. A quick google did not find any file format specification. (help requested!) The key-value pairs are encoded using standard serialization (binary encoding) found elsewhere in the bitcoin protocol. |
|
|
|
See the zeromq pull request.
A REST interface has also gained interest in some areas.
Can you explain? Is there a way to add zeromq to bitcoind? Can you add a step-by-step tutorial? A pull request is a source code change to bitcoind at https://github.com/bitcoin/bitcoin/ Someone has already written zeromq support for bitcoind. |
|
|
|
it makes it nearly impossible to create a alternative client, when the "standard" mutates all the time. bitcoin needs diversity in clients.
Would you like to only be able to use internet explore? sure it would work good. but really?
The standard does not mutate all the time (though I do agree client diversity is a good thing). |
|
|
|
Is there agreement that ideally a bitcoin daemon handing the public block chain and a bitcoin GUI should have a complete and well defined interface between them that could work over a network and allow different daemon and client implementations to work together?
I think there is agreement that is a long term goal for bitcoind, yes. |
|
|
|
|
As far as I know, zero clients "fully support" multi-sig.
Simply creating multi-sig transactions often requires using some expert mode in the software, if the client supports it at all. Consider that some balances are segmented into two categories: (1) outputs you may spend (control all keys), and (2) outputs you might be able to spend (control M-of-N keys). And, transactions must be passed around somehow in partially-signed state, which gathering signature from multiple parties. There are several use-case and user-interface issues to be solved for useful workflow.
|
|
|
|
I think Let's Talk Bitcoin covered the issue pretty well in Episodes 21 and 22. I've had the same beliefs for some time, and with the way the ASIC world is going, it is playing out. If the community doesn't step up and make the change, or at least have an open discussion on the issue, I see Bitcoin dead in less than a year.
Andreas is grossly wrong on this one. Indeed. See http://www.coindesk.com/bitcoin-developer-jeff-garzik-on-altcoins-asics-and-bitcoin-usability/ for some thoughts. |
|
|
|
|
See the zeromq pull request.
A REST interface has also gained interest in some areas.
|
|
|
|
What about creating a new node type "block-server". These nodes maintain historical data only.
That is an existing proposal known as "archive node." |
|
|
|
|
Cool stuff. It's great to see all the xperiments and side projects spurred by bitcoin's entrance into the technology world.
|
|
|
|
LevelDB is designed to survive certain kinds of file system corruption by ensuring that all commits are atomic .... on the assumption that file system renames and write() calls are atomic. If that underlying OS assumption is violated by bugs in the OS or hardware, LevelDB can corrupt itself as would any other database.
Write calls have never been atomic in any Unix-ish OS... They may be reordered by the OS between fsync/fdatasync calls, and may be reordered again at the hardware (disk) level, unless the OS sends a hardware flush command (FLUSH CACHE / SYNCHRONIZE CACHE). |
|
|
|
But the simpler fix is to just not run Bitcoin-Qt on Macs that might sleep a lot.
If leveldb cannot handle suspend/resume with full data integrity, then we may need to revisit it. |
|
|
|
Can you please disclose what OS, OS version, and Bitcoin version you're running?
Discussed this with you a few weeks ago. Happens to me every single time OSX ML fails to come back up from suspend. Pretty much the only reason why I stopped running a node. What is an OSX ML? |
|
|
|
I dont think ETF is huge. If i recall, it was just couple of millions.
It is huge to expand bitcoin access to the millions of people globally that already have a brokerage account. |
|
|
|
I'm a senior software engineer and I have been working on computer games and multi-platform development since 1979.
I just really prefer small code bases with minimal dependencies that are compiler and operating system agnostic.
There is little engineering upside to reimplementing highly complex cryptographic algorithms on your own, given the levels of engineering review and crypt-analysis of your own codebase versus an existing crypto lib. It might be personally satisfying, but it makes little sense unless you are truly an expert crypto mathematician. |
|
|
|
Seriously, I don't get how they get so much press. What have they actually done apart from buying some BTC and investing in a couple of co.s?
A bitcoin ETF is huge. (note: they are not the only ones working on one...) |
|
|
|
The chainstate sub folder contains leveldb representation of the UXTO right?
Yes. What is the significance of multiple xxxxxx.sst files?
There is also LOCK, LOG, and MANIFEST-xxxxxx files?
These are leveldb internal storage setup. Inherent in leveldb design. Analogy: Berkeley DB's low level storage format. The "blocks" subfolder contains leveldb representation of raw blocks right?
No. This is the raw bitcoin-specific wire format of blocks. Why are the files of difference size?
Bitcoin blocks differ in size. Also, some blk*.dat are larger because they were originally that way when imported the first time. If you use bootstrap.dat to initialize a new database then all your files should be nearly the same size. |
|
|
|
|
Show Posts
