Any progress on Picocoin? Been following this thread for a while ut it seems to be asleep for a few weeks now.. and if there is development. Any idea about compiling on windows?
Many devs, myself included, are on winter break ;p
Topic: [ANNOUNCE] picocoin and libccoin -- C-based bitcoin library and client - page 5. (Read 30594 times)
December 22, 2012, 07:31:58 PM
Many devs, myself included, are on winter break ;p
December 22, 2012, 06:09:57 AM
Any progress on Picocoin? Been following this thread for a while ut it seems to be asleep for a few weeks now.. and if there is development. Any idea about compiling on windows?
December 07, 2012, 10:43:00 AM
A total lamer here: if I have a private key of a bitcoin address, that has 1 BTC in it, can I spend it with picocoin? Or does it only know about transactions that are broadcast to it? Thank you.
In the future, when picocoin is complete, yes, you can spend it with picocoin.
Right now, while picocoin is under construction, that is not yet implemented.
picocoin will provide everything a bitcoin client should provide: you can receive and spend bitcoins.
December 07, 2012, 10:01:08 AM
A total lamer here: if I have a private key of a bitcoin address, that has 1 BTC in it, can I spend it with picocoin? Or does it only know about transactions that are broadcast to it? Thank you.
December 05, 2012, 02:39:17 PM
A bit of a non-announcement, as it Just Worked(tm), but picocoin is happily talking to IPv6 nodes on the network.
Tor support (SOCKS5) should be added sometime soon.
Tor support (SOCKS5) should be added sometime soon.
December 05, 2012, 01:17:01 PM
Hey, thanks for libccoin!!! I used it for a brute forcer for Casascius's BIP38 contest and it was very clearly laid out (at least from what I used on the library side.)
Thanks for giving it a try.
Quote
I did find a possible bug, though:
When generating a public key and Bitcoin address from a private key, the EC key is using the compressed form, when I believe it should be using the uncompressed form. I added this workaround here, but I don't know if it is the right way to go.
https://github.com/notespace/picocoin/commit/736235acabf08f2eae8856673bfd68574c8600fe
When generating a public key and Bitcoin address from a private key, the EC key is using the compressed form, when I believe it should be using the uncompressed form. I added this workaround here, but I don't know if it is the right way to go.
https://github.com/notespace/picocoin/commit/736235acabf08f2eae8856673bfd68574c8600fe
The developer consensus seems to be that uncompressed form just wastes bytes in the blockchain, which is true, so libccoin was coded to always used compressed form.
However, it might make sense to support uncompressed public keys for use cases such as yours, as long as the code still produces compressed form by default.
Such a change would involve adding "bool uncompressed" (default: false) to struct bp_key, and behaving accordingly based on that.
December 05, 2012, 05:55:46 AM
Hey, thanks for libccoin!!! I used it for a brute forcer for Casascius's BIP38 contest and it was very clearly laid out (at least from what I used on the library side.)
I did find a possible bug, though:
When generating a public key and Bitcoin address from a private key, the EC key is using the compressed form, when I believe it should be using the uncompressed form. I added this workaround here, but I don't know if it is the right way to go.
https://github.com/notespace/picocoin/commit/736235acabf08f2eae8856673bfd68574c8600fe
I am generating the private key bytes from the outputs of the EC multiply operation required by BIP 38, then using it like this:
bp_key_init(&wallet)
bp_key_secret_set(&wallet,finalKey,32)
bp_pubkey_get(&wallet, ((void **) &pubKey), &pubKeylen);
btcAddress = bp_pubkey_get_address(&wallet, 0);
Also, you can see the whole code for the bip38 cracker here, all code is in main.c:
https://github.com/notespace/bip38-cracker
I did find a possible bug, though:
When generating a public key and Bitcoin address from a private key, the EC key is using the compressed form, when I believe it should be using the uncompressed form. I added this workaround here, but I don't know if it is the right way to go.
https://github.com/notespace/picocoin/commit/736235acabf08f2eae8856673bfd68574c8600fe
I am generating the private key bytes from the outputs of the EC multiply operation required by BIP 38, then using it like this:
bp_key_init(&wallet)
bp_key_secret_set(&wallet,finalKey,32)
bp_pubkey_get(&wallet, ((void **) &pubKey), &pubKeylen);
btcAddress = bp_pubkey_get_address(&wallet, 0);
Also, you can see the whole code for the bip38 cracker here, all code is in main.c:
https://github.com/notespace/bip38-cracker
December 03, 2012, 10:42:11 PM
The "somewhat odd" comment is really strange. It is the standard way to strenghten the C type system from structural equivalence to name equivalence. The type systems taxonomy is the standard curriculum of pretty much every CS or SE course at the university level. In fact the C++ code I posted above is patterned after the sample C/C++ code and a paper that was included with the "cfront" C++ compiler distribution from Bjarne Stroustrup that I've seen on some dusty VAX at my school. I didn't claim the autorship and in fact the requirement of not overusing type-cast-ing is one of the standard admonishments in the C/C++ project specifications.
Nice lecture, I suspect that you didn't get my argument or I misunderstood what you're insisting on. I'm not saying that using the typesystem and avoiding typecasting all over the code is weird, I'm saying that endenanness is usually compartmentalized— you can handle it cleanly when serializing and deserializing and only at those boundaries, and in the manner specified for the kind of serialization being performed. Everywhere is just a single fundamental type, and there is no need to carry a union around and to pollute the whole codebase with type specifiers which are not only not useful but acutely dangerous— as adhoc serialization using the alternative references littered in the codebase may miss the required byteorder functions.
Programming is foremost an art of communicating between programmers. Forcing every machine integer into a specialized union type when the only conversions needed are at specialized serialization points weakens that communication and probably increases the frequency of errors. It certainly isn't the convention in the OSS C ecosystem.
December 03, 2012, 06:28:59 PM
Recent progress:
- libccoin now signs transactions. Handling chain re-org is now the last hurdle for proper backend client support
- Building on older Debian/Ubuntu Linux now supported
December 01, 2012, 03:03:41 PM
FWIW while I've never tried doing it QEMU can apparently emulate the big-endian PowerPC architecture. Here is one guys notes about getting it working from two years ago, specifically to test endian issues.
Thanks. The other option for big-endian testing on Intel little-endian laptop is running an IBM mainframe Linux eg. Debian or RedHat S390 on the Hercules emulator.http://www.hercules-390.org/
December 01, 2012, 02:37:27 PM
The frequent invocations of RedHat upthread are weird and misplaced. _I_ did the initial BE testing for Jeff. Lots of people have access to BE systems and pretty much anyone who wants to can have access to one (for a couple bucks on ebay if nothing else). ... but nothing Jeff is doing makes handling the endlessness hard as directly evidenced by the fact that he got it running fine on BE without using one. Your 'solution' of pushing unions everywhere for that is an odd one and I'm happy to not work on your codebase.
Now that you've made your numerous complaints would you please cut it out? The tangent is going nowhere. If you want bitcoin software written to your particular, and somewhat odd, specifications feel free to do so yourself or to pay someone to do so.
I apologize for misattributing anyone's work. I didn't actually read the commit log. From the way you wrote I have to assume that Jeff did 100% of work and you did 100% of testing. It doesn't really matter who did what, so long as it is getting done at a reasonable frequency.Now that you've made your numerous complaints would you please cut it out? The tangent is going nowhere. If you want bitcoin software written to your particular, and somewhat odd, specifications feel free to do so yourself or to pay someone to do so.
The "somewhat odd" comment is really strange. It is the standard way to strenghten the C type system from structural equivalence to name equivalence. The type systems taxonomy is the standard curriculum of pretty much every CS or SE course at the university level. In fact the C++ code I posted above is patterned after the sample C/C++ code and a paper that was included with the "cfront" C++ compiler distribution from Bjarne Stroustrup that I've seen on some dusty VAX at my school. I didn't claim the autorship and in fact the requirement of not overusing type-cast-ing is one of the standard admonishments in the C/C++ project specifications.
On the other hand the 1995-1997 copyright dates on glib.h show that the base GTK/GNOME code was designed during the darkest days of GCC, predating the EGCS fork: http://en.wikipedia.org/wiki/GNU_Compiler_Collection#EGCS_fork . At that time GCC was widely used as a baseline: it would reliably produce largest and slowest code after taking the longest time to build it; so almost anything looked better in comparison. From what I've heard from one of the Linux distribution maintainers was that many sub-optimal choices in open source packages were motivated by the desire to avoid tripping up GCC to produce very slow or incorrect code. Those days are long gone.
It really doesn't take an advanced computer science education to understand why poking holes in C/C++ type system by using unsafe casts is not a good architectural choice. It may be a good short term choice. Open source projects thrive on finding a group of people who while "scratching their own itch" actually scratch in the same place. It may well be the truth that many programmers here enjoy lookin at every uint32 and ponder wheteher to use it directly or through GUINT32_{TO,FROM}_LE macros.
I also know from the past experience that overall such people are not a majority, and would consider the above task a software engineering equivalent of digging diteches and filling them back in. For every one person who posted here there is at least 10 who read this thread with understanding. Of those 10 at least 2-3 will copy/paste the example code I wrote for a future reference.
So, yes, go ahead and play with the following somewhat longer example C code. Modify it to make mistakes and see which way is better for yourself.
Code:
#include
#ifdef _MSC_VER
#include
#define inline __inline
#define __builtin_bswap32 _byteswap_ulong
#endif
#ifdef __GNUC__
#define _byteswap_ulong __builtin_bswap32
#endif
/*
* type safe little endian
*/
union le_int {
unsigned char b[4];
int i;
};
/* little endian setter on little endian host */
static inline union le_int h2l_int(int a)
{
union le_int t;
t.i = a;
return t;
}
/* little endian getter on little endian host */
static inline int l2h_int(union le_int a)
{
return a.i;
}
/*
* type safe big endian
*/
union be_int {
unsigned char b[4];
int i;
};
/* big endian setter on little endian host */
static inline union be_int h2b_int(int a)
{
union be_int t;
t.i = _byteswap_ulong(a);
return t;
}
/* big endian getter on little endian host */
static inline int b2h_int(union be_int a)
{
return _byteswap_ulong(a.i);
}
/* excerpted from the Glib.h include tree */
typedef unsigned int guint32;
typedef signed int gint32;
#define GUINT32_SWAP_LE_BE(val) ((guint32) __builtin_bswap32 ((gint32) val))
#define GINT32_TO_LE(val) ((gint32) (val))
#define GINT32_TO_BE(val) ((gint32) GUINT32_SWAP_LE_BE (val))
#define GINT32_FROM_LE(val) (GINT32_TO_LE (val))
#define GINT32_FROM_BE(val) (GINT32_TO_BE (val))
/* end of Glib.h excerpt */
/* little endian type unsafe */
int lehmer1(int n)
{
int r = GINT32_TO_LE(1);
while (n--)
r = GINT32_TO_LE((16807 * GINT32_FROM_LE(r)) % 2147483647);
return GINT32_FROM_LE(r);
}
/* little endian type safe */
int lehmer2(int n)
{
union le_int r = h2l_int(1);
while (n--)
r = h2l_int((16807 * l2h_int(r)) % 2147483647);
return l2h_int(r);
}
/* big endian type unsafe */
int lehmer3(int n)
{
int r = GINT32_TO_BE(1);
while (n--)
r = GINT32_TO_BE((16807 * GINT32_FROM_BE(r)) % 2147483647);
return GINT32_FROM_BE(r);
}
/* big endian type safe */
int lehmer4(int n)
{
union be_int r = h2b_int(1);
while (n--)
r = h2b_int((16807 * b2h_int(r)) % 2147483647);
return b2h_int(r);
}
int main()
{
printf("%d\n",lehmer1(2112));
printf("%d\n",lehmer2(2112));
printf("%d\n",lehmer3(2112));
printf("%d\n",lehmer4(2112));
return 0;
}
#ifdef _MSC_VER
#include
#define inline __inline
#define __builtin_bswap32 _byteswap_ulong
#endif
#ifdef __GNUC__
#define _byteswap_ulong __builtin_bswap32
#endif
/*
* type safe little endian
*/
union le_int {
unsigned char b[4];
int i;
};
/* little endian setter on little endian host */
static inline union le_int h2l_int(int a)
{
union le_int t;
t.i = a;
return t;
}
/* little endian getter on little endian host */
static inline int l2h_int(union le_int a)
{
return a.i;
}
/*
* type safe big endian
*/
union be_int {
unsigned char b[4];
int i;
};
/* big endian setter on little endian host */
static inline union be_int h2b_int(int a)
{
union be_int t;
t.i = _byteswap_ulong(a);
return t;
}
/* big endian getter on little endian host */
static inline int b2h_int(union be_int a)
{
return _byteswap_ulong(a.i);
}
/* excerpted from the Glib.h include tree */
typedef unsigned int guint32;
typedef signed int gint32;
#define GUINT32_SWAP_LE_BE(val) ((guint32) __builtin_bswap32 ((gint32) val))
#define GINT32_TO_LE(val) ((gint32) (val))
#define GINT32_TO_BE(val) ((gint32) GUINT32_SWAP_LE_BE (val))
#define GINT32_FROM_LE(val) (GINT32_TO_LE (val))
#define GINT32_FROM_BE(val) (GINT32_TO_BE (val))
/* end of Glib.h excerpt */
/* little endian type unsafe */
int lehmer1(int n)
{
int r = GINT32_TO_LE(1);
while (n--)
r = GINT32_TO_LE((16807 * GINT32_FROM_LE(r)) % 2147483647);
return GINT32_FROM_LE(r);
}
/* little endian type safe */
int lehmer2(int n)
{
union le_int r = h2l_int(1);
while (n--)
r = h2l_int((16807 * l2h_int(r)) % 2147483647);
return l2h_int(r);
}
/* big endian type unsafe */
int lehmer3(int n)
{
int r = GINT32_TO_BE(1);
while (n--)
r = GINT32_TO_BE((16807 * GINT32_FROM_BE(r)) % 2147483647);
return GINT32_FROM_BE(r);
}
/* big endian type safe */
int lehmer4(int n)
{
union be_int r = h2b_int(1);
while (n--)
r = h2b_int((16807 * b2h_int(r)) % 2147483647);
return b2h_int(r);
}
int main()
{
printf("%d\n",lehmer1(2112));
printf("%d\n",lehmer2(2112));
printf("%d\n",lehmer3(2112));
printf("%d\n",lehmer4(2112));
return 0;
}
November 30, 2012, 04:15:05 AM
picocoin's library successfully validates both main and testnet3 block chains, including scripts. ("chain-verf" test in its testsuite)
It is working on Linux, MacOSX, FreeBSD and OpenBSD. The library compiles on Windows, but the client requires additional Windows work to be functional.
November 29, 2012, 01:45:57 PM
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.
November 29, 2012, 11:30:10 AM
Quote
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.
Please leave the environment-specified password as an option, however. In some environments (12-factor stacks like Heroku, for example) that remains the best available option.
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?
November 29, 2012, 11:04:42 AM
You could use an SPV client to reduce resource usage, but if you're running a web service that handles money, it's a really good idea to just pony up the resources for a full node. Security matters!
November 29, 2012, 10:43:00 AM
Any ideas if this client would be suitable for RPC-like usage ? I'm currently running bitcoind on a server to power up my web service via RPC calls. But it eats a HUGE share of memory, and over the weeks it keeps getting slow, so I have to restart it often.
November 28, 2012, 04:42:39 PM
cbitcoinlib!
Sorta like Yahoo! but cbitcoinlib!
Sounds exciting when I read it.
Search engines will also find it when people type "c bitcoin library"
Sorta like Yahoo! but cbitcoinlib!
Sounds exciting when I read it.
Search engines will also find it when people type "c bitcoin library"
November 28, 2012, 03:24:17 PM
I think "libccoin" is fine ... clean and to the point like the code.
November 28, 2012, 11:50:20 AM
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.
November 28, 2012, 10:58:36 AM
As I've noted: I've forgot that you are one of the very few Bitcoin developers with regular access to big-endian hardware. I'm thinking that you will continue to be the only one developer who can test picocoin on the big-endian architecture. The mojibake-endian problem will continue to badly affect the future contributors/users of your library if you aren't going to use your own medicine (that is "sparse" and "__le32")
The frequent invocations of RedHat upthread are weird and misplaced. _I_ did the initial BE testing for Jeff. Lots of people have access to BE systems and pretty much anyone who wants to can have access to one (for a couple bucks on ebay if nothing else). ... but nothing Jeff is doing makes handling the endlessness hard as directly evidenced by the fact that he got it running fine on BE without using one. Your 'solution' of pushing unions everywhere for that is an odd one and I'm happy to not work on your codebase.
Now that you've made your numerous complaints would you please cut it out? The tangent is going nowhere. If you want bitcoin software written to your particular, and somewhat odd, specifications feel free to do so yourself or to pay someone to do so.
Jump to: