I'm a little confused, does this project do full validation or not? Am I understanding it correctly that picocoin is and will remain a SPV thin-client, but libccoin implements (or will implement if it doesn't already) everything required to build a full validating node?
Yes, libccoin implements everything needed to do full validation. If you wanted to build a "full node" with libccoin, you could do that. |
|
|
|
How about calling it glibbitcoin, jgbitcoin or libbitcoin-jg ?
Bleh  If someone actually does come up with a cool name I'd consider it But anything directly related to (a) my name or (b) a dependency lib's name is right out. |
|
|
|
Thanks to jrmithdobbs for helping in bringing up OpenBSD (and more FreeBSD help from denisx). Here's the autogen.sh and configure magic he used for OpenBSD. Some are specific to his system, but it is an illlustrative example: AUTOMAKE_VERSION=1.11 AUTOCONF_VERSION=2.68 ./autogen.sh && \
CC=clang LD=llvm-ld CFLAGS='-O2 -Wall -g -I/usr/local/include/event2 \
-I/opt/OpenBSD/5.1/amd64/jansson-2.4/include -I/usr/local/include/event2' \
LDFLAGS='-L/opt/OpenBSD/5.1/amd64/jansson-2.4/lib -L/usr/local/lib -L/usr/lib' \
./configure --prefix=/opt/OpenBSD/5.1/amd64/picocoin-0.0 && \
make all check
|
|
|
|
|
Thanks to denisx on IRC, who helped get picocoin/libccoin going on FreeBSD and GLib < 2.30 as well.
|
|
|
|
Everything builds and tests pass on MacOS X 10.7. Good job on this code, you've written the client Satoshi should have.
Appreciated. Thanks in particular for testing OSX. That was a big item on the checklist. |
|
|
|
404 here also. US. The bitcoin story is mentioned on the main BBC news page http://www.bbc.co.uk/news/ and the link there is the same as the one posted here (404/broken). |
|
|
|
For starters, you'll have heck of a time to remove your dependency on glib.h from GTK.
You mean "remove your dependency on glib.h from libccoin", I presume? GTK has no relevance to this, besides being the administrative umbrella project for GLib. Removing the GLib dependency is straightforward for any developer. GLib is used for a few ADTs like variable length strings, hash tables and arrays. Both GLib and OpenSSL are heavy duty harvester combines. Removing the dependencies on them will at least halve the resource usage.
For a RedHat-ter at least make the code work with newlib instead of glib. The required knowledge should be no more than the internal phone call away for you. This includes a whole sermon on why you don't want to build a dependency on them.
Not sure you understand the problem space... First, newlib is wholly different from GLib, and does not provide the ADTs that GLib provides. Second, replacing GLib and OpenSSL would not change resource usage much at all. ADTs, Big Integer support, SHA hashing and ECDSA are required regardless of lib chosen. They would simply be replaced with... code that did the same thing under name other than "OpenSSL" or "GLib." The performance loss for passing unions around may have been true for GCC 2.96. I'm not normally working with Linux kernel and/or GCC.
It continues to be true for all known compilers I've seen or heard of, when compared with a simple, native machine integer as used by the current implementation. All in all, I apologise for jumping in into the battle between you and MatthewLM. Regretfully I can't easily build neither of yours code, because I'm almost exclusively working on the closed-source platforms like Windows, MacOS, etc. and standalone environments not relying on GCC/GLIB/autogen.
It will soon be building on MacOSX and Windows. Will post when this happens (volunteers willing to post building outputs are helpful). As stated, it is a developer-only release right now, so there are plenty of rough edges. But it is a shame that another C implementation of Bitcoin is useless for the developers of Bitcoin hardware wallets.
I respectfully disagree with that assessment. Anyone looking at the code may see precisely what dependencies need replacing, for an embedded environment. If anyone actually developing hardware or embedded bitcoin solutions wishes to contact me, I would be happy to illustrate how it would work. |
|
|
|
So am I understanding right? I could run picocoin and it would be lightweight like Electrum but also support the Bitcoin network by interacting on the network like a full satoshi client. I've been using Electrum mostly to get away from having to use around 5GB disk space and for quick install/startup but I'd really prefer to be supporting Bitcoin more by being another validating node in it's network.
picocoin is only a lightweight client. It is not a "full node" and probably never will be. The included library, libccoin, does provide all the tools and gadgetry needed to build your own "full node" bitcoin client that takes 5GB disk space, if you have the programming chops to do that. |
|
|
|
But even the definitions in your "ccoin" include files are deeply incompatible with any standalone environment, even if it uses GCC toolchain. Major rework would be required even now, when there's just couple of hundred lines of code.
This seems quite an exaggeration, with no supporting evidence of what needs a major rework. I do embedded programming for the day job, so I don't see this. The Linux kernel is as bare metal as it gets, and must work in all environments, all platforms. The main chore of embedded use is simply the dependencies, most notably OpenSSL, and to a lesser extent GLib. Once you have that, or its replacement, embedded use is straightforward. The big-endian compatibility is already super-confusing. Istead of using uint32_t in bu256_t use an "union le_int32" to at least flag the mixing of little endian uint32_t with guint32_t.
Using "union" decreases the performance and quality of code output for zero gain. It is trivial enough to use sparse with a type specifier to guarantee endian purity, like the Linux kernel does, if that is desired ("__le32" etc.) 1) from the start build also on Mac Leopard or Snow Leopard to verify the endian-neutrality with "-arch ppc" with Rosetta on Intel CPU. Edit: Never mind, I forgot that you have access to the Linux on POWER and z/Arch through your association with RedHat.
The code has long since been verified to work on big endian. |
|
|
|
AES encryption is applied to the wallet. Passphrase is specified via environment variable PICOCOIN_PASSPHRASE. Is this secure? My understanding is that the environment isn't a safe place to store/transmit information. That's temporary. It will input via fd like GPG soon. |
|
|
|
Jeff, I have one comment that has value only very early in the design of your architecture. Since you've made a choice of C as a implementation language I suggest that you add one more target to the list of supported platforms: standalone a.k.a. bare metal.
Yes, embedded usage is another target. Each module in libccoin is carefully designed to minimize internal dependencies. The core data structures, address generation, script execution and transaction validation are wholly independent of any filesystem or network design. These modules may be used on a non-POSIX flash filesystem, with zero network support, today. picocoin (the client) requires certain network, filesystem and process features, but libccoin (the library) does not. This is by design. |
|
|
|
Given a transaction, what methods exist to detect which of the outputs is most likely to be the change?
It is intentionally randomized to make it harder to guess |
|
|
|
Source code URL: https://github.com/jgarzik/picocoin/I'd like to announce another bitcoin implementation, which is really two useful pieces in one: libccoin - a bitcoin library, written in C picocoin - A lightweight, C-based SPV bitcoin wallet client libccoin supports all key network datastructures (block, transaction, etc.), script parsing and validation, transaction and block validation, a "headers-only" or full block database, and many other features essential to any bitcoin client. libccoin passes all key encoding, script and transaction tests available in the Satoshi reference bitcoin client. picocoin is much more under construction. When complete, it will be a very low resource, command line / JSON-driven bitcoin wallet. Advanced security features already implemented include required wallet encryption, fork-based process separation of P2P networking and wallet (and chroot/SELinux jailing coming soon), something that the reference Satoshi client does not even support. Status: Alpha quality, developer release. Passes reference client base58/script/transaction tests, but is still a developer-only preview.Feature list: - Liberal Mit/X11 free software license
- A full-feature bitcoin support library. The library will not be limited to "what picocoin needs."
- Supports all core data structures and network messages
- Full script implementation
- Passes hundreds of available reference client tests
- Supports multiple block chains: main or testnet3
- Very low resource usage (cpu, disk, and memory)
- Small codebase (both source code and compiled object)
- Fast. Loads all block headers in under 2 seconds.
- Supports advanced thin-client features such as bloom filtering, an upcoming proposal that will reduce client bandwidth usage.
- Works on big endian machines, as well as little endian machines
- Multi-platform: Linux, Mac OSX, BSD are working. Windows support in progress.
- Library works on Windows. picocoin will work on Windows with some modifications, but be a bit less secure than other platforms due to lack of fork.
- Improved security: fork-based process separation firewall between networking and wallet code -- your wallet is never directly exposed to the network.
- Follows the philosophy of "do, not hype." This library is already far more secure and capable than other libraries hyped as the "future of bitcoin" by their authors.
Code contributions are welcome (see github URL above). Comments are welcome. Donations are welcome too (see signature). |
|
|
|
Bitcoin is not tied to any specific country, and as such not restricted by any law.
Quite the opposite. Bitcoin use is bound by the laws of your local jurisdiction. |
|
|
|
and hashMerkleRoot are simply valid, or not. The miner has no choice in their value.
uh No. The miner can search for hashMerkleRoot values to get particular ones. You're micro-parsing. What is meant is that the value of hashPrevBlock and hashMerkleRoot are very specifically defined by algorithm and validation. The miner also "controls" the value of hashPrevBlock, in the same micro-parsing sense you've provided, by electing to not mine a particular block, thereby skipping a hashPrevBlock. The basic point is that the miner cannot select any random garbage for those fields. |
|
|
|
Yes, miners can control every field in the block. Your game would be especially vulnerable to a Finney type attack.
Not quite. The value of nonce and some other fields (extranonce in scriptSig) are totally up to the miner. The value of nTime is somewhat up to the miner. Other fields are simply non variant: hashPrevBlock and hashMerkleRoot are simply valid, or not. The miner has no choice in their value. |
|
|
|
|
Show Posts
