Nostr notes by

📅 Original date posted:2012-07-25 📝 Original message:Hi ...

2023-06-07T10:25:00Z

In reply to nevent1q…l59x
_________________________

📅 Original date posted:2012-07-25
📝 Original message:Hi Steve,

I see dramatic differences in performance on virtual machines vs running directly on the iron. I am not an expert in virtual machines, but it seems to me that they are weak when it comes to disk i/o. And berkeley DB, as used by bitcoin is a sucker for disk i/o. In top I easily hit >1/#processors in top wa, meaning that the cpu doing the blockchain download is just waiting for the disk all the time.

I would like to do a test keeping database log files in memory. It should not matter for durability of the wallet, as it flushes at each write anyway. As for the blockindex, it will remain consistent, but might be lagging some blocks behind at startup, which shouldn't really matter (except that the same block could end up appearing twice in the block00X files, inelegant, but not really a problem).

Otherwise the system you describe (raid0 over 6 disks) should perform like crazy wrt disk i/o, at least on par with SSD. It is your virtualization I am worried about.

Have a safe trip to down under!

/M

On 24/07/2012, at 21:56, steve wrote:

> Hi Michael,
>
> from what I have noticed, bitcoin blockchain download/verfication all
> happens in 1 thread. (so multicores doesnt really help)
>
> That said, I have never tried on an ssd.
>
> What I do have is 6 SATA 6gbs configed as RAID0 Drives.
> 32gb of ram. ubuntu 64 (yeah I know), this runs upto 16 VM's
> (I have 4 of these)
>
> However I have not tried to download the blockchain on the master os,
> just in virtulisation. However, the dedicated machines that I have been
> using for benchmarking the VM's against is a q6600 8gb ram sata2 hdd -
> Win 7 (seems faster than slackware...) to me it has always felt like
> network bandwidth was the issue. I might instrument the bitcoin-qt exe
> to only pick low ping nodes (has someone already done this?)
>
> I guess it is time to start some benchmarking (like the gpu comparison page)
>
> hte verification for the 5 past 5 days was negliglable. I am off on a
> flight to australia tomorrrow, so I will set some breakpoints and do
> some timings in a debugger.
>
> This will all happen on an e-450 (wonderful machine!)
>
> Thanks very much for your response. it would seem that I am 'doing it
> wrong' :/
>
> cheers mate,
>
> steve
>
> (this message isnt signed because I have forgotten my password.)
>
> On 24/07/2012 09:25, Michael Grønager wrote:
>> Hi Steve,
>>
>> 45-90 minutes - note that its numbers from March/April, so a bit
>> longer today, but far, far away from the 12 hours.
>>
>> I am using libcoin and the bitcoind build based on this. Libcoin is
>> based on the Satoshi client, but refactured to use an async
>> concurrency model. I also did a minor tweeks to the db parameters. It
>> has earlier been tested up against Satoshi bitcoin where on some
>> OS'es it performs similarly (at least on some linuxes) and on some
>> faster (e.g. mac).
>>
>> What is your CPU load during a block download ? (both initially/up to
>> the point where verification sets in and after). The initial download
>> is typically disk I/O bound, the verification stage CPU bound, though
>> I lean to believe that even there it is disk I/O bound (at least on
>> my system ~50% CPU load). What should be better in libcoin is the
>> concurrency model. The Satoshi client uses a pure reentrant mutexes
>> model, that is not generally believed to motivate the best coding
>> practice nor performance, you might end up without the concurrency
>> you initially strived for *). As mentioned earlier libcoin uses a
>> pure async concurrency model (and so does libbitcoin btw).
>>
>> I would like to stress again that these numbers will depend largely
>> on the system running the test - I would call my laptop a bit over
>> the average today (MB Pro, 2.66Ghz i7 dual core, 8GBRAM, 512GB SSD).
>> But again 12 hours - I only reach such numbers on some of my VPS'es
>> (linode 1024) that are known for notoriously slow disk I/O. (here I
>> have a few % CPU load during the verification indicating indeed that
>> the disk i/o is the culprit).
>>
>> Cheers,
>>
>> Michael
>>
>>
>> *) I like this Dave Butenhof quote: "The biggest of all the big
>> problems with recursive mutexes is that they encourage you to
>> completely lose track of your locking scheme and scope. This is
>> deadly. Evil. It's the "thread eater". You hold locks for the
>> absolutely shortest possible time. Period. Always. If you're calling
>> something with a lock held simply because you don't know it's held,
>> or because you don't know whether the callee needs the mutex, then
>> you're holding it too long. You're aiming a shotgun at your
>> application and pulling the trigger. You presumably started using
>> threads to get concurrency; but you've just PREVENTED concurrency."
>>
>>
>>
>>
>> On 23/07/2012, at 17:54, steve wrote:
>>
>> Hi Michael,
>>
>> On 23/07/2012 10:00, Michael Grønager wrote:
>>>>> I get a full blockchain from scratch in 45 minutes on my
>>>>> laptop, /M
>>>>>
>> Hang on a sec, in 45 minutes you can download the entire chain from
>> the genesis block?
>>
>> I have been doing extensive testing in this area and would love to
>> know what is special about your setup (I have never had the entire
>> chain in under 12 hours, infact it is normally closerto 24.) I have
>> an extensive setup of test machines, everything from e4300 to
>> phenom2x6 to i5's.
>>
>> as an example on an amd e-450 with 4gb ram, and approx 3gb/s
>> internet connection it took 2 hours to sync the last 5 days.
>>
>> Maybe i am missing something important...
>>
>> Any additional information that you could provide to help me with
>> testing would be really appreciated.
>>
>> cheers,
>>
>> steve
>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond.
>>> Discussions will include endpoint security, mobile security and the
>>> latest in malware threats.
>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________ Bitcoin-development
>>> mailing list Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2012-07-24 📝 Original message:Hi ...

2023-06-07T10:24:51Z

In reply to nevent1q…m0ga
_________________________

📅 Original date posted:2012-07-24
📝 Original message:Hi Steve,

45-90 minutes - note that its numbers from March/April, so a bit longer today, but far, far away from the 12 hours.

I am using libcoin and the bitcoind build based on this. Libcoin is based on the Satoshi client, but refactured to use an async concurrency model. I also did a minor tweeks to the db parameters. It has earlier been tested up against Satoshi bitcoin where on some OS'es it performs similarly (at least on some linuxes) and on some faster (e.g. mac).

What is your CPU load during a block download ? (both initially/up to the point where verification sets in and after). The initial download is typically disk I/O bound, the verification stage CPU bound, though I lean to believe that even there it is disk I/O bound (at least on my system ~50% CPU load). What should be better in libcoin is the concurrency model. The Satoshi client uses a pure reentrant mutexes model, that is not generally believed to motivate the best coding practice nor performance, you might end up without the concurrency you initially strived for *). As mentioned earlier libcoin uses a pure async concurrency model (and so does libbitcoin btw).

I would like to stress again that these numbers will depend largely on the system running the test - I would call my laptop a bit over the average today (MB Pro, 2.66Ghz i7 dual core, 8GBRAM, 512GB SSD). But again 12 hours - I only reach such numbers on some of my VPS'es (linode 1024) that are known for notoriously slow disk I/O. (here I have a few % CPU load during the verification indicating indeed that the disk i/o is the culprit).

Cheers,

Michael

*) I like this Dave Butenhof quote: "The biggest of all the big problems with recursive mutexes is that they encourage you to completely lose track of your locking scheme and scope. This is deadly. Evil. It's the "thread eater". You hold locks for the absolutely shortest possible time. Period. Always. If you're calling something with a lock held simply because you don't know it's held, or because you don't know whether the callee needs the mutex, then you're holding it too long. You're aiming a shotgun at your application and pulling the trigger. You presumably started using threads to get concurrency; but you've just PREVENTED concurrency."

On 23/07/2012, at 17:54, steve wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Michael,
>
> On 23/07/2012 10:00, Michael Grønager wrote:
>> I get a full blockchain from scratch in 45 minutes on my laptop,
>> /M
>>
> Hang on a sec, in 45 minutes you can download the entire chain from
> the genesis block?
>
> I have been doing extensive testing in this area and would love to
> know what is special about your setup (I have never had the entire
> chain in under 12 hours, infact it is normally closerto 24.) I have an
> extensive setup of test machines, everything from e4300 to phenom2x6
> to i5's.
>
> as an example on an amd e-450 with 4gb ram, and approx 3gb/s internet
> connection it took 2 hours to sync the last 5 days.
>
> Maybe i am missing something important...
>
> Any additional information that you could provide to help me with
> testing would be really appreciated.
>
> cheers,
>
> steve
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJQDXO4AAoJEFvEB9dQFvtQxdcH/ieqQkyDCg8mKeOa6CqsWaS6
> fhoeny3Ke2b/CsvhYmsThCvntN9volIqR2CTn5tkHiVwG9OmlxyHZcNpN0ZTHhK5
> lsfLap/Y0QpiysXpV4Bu7Z4Hwp9jnhOP74TshT305r2pX6EGXPQ0CrlHqlIry/X/
> vNcunUclliou+KjL7EHcY50GH5wDpqJAjlNyF97Lj9YiPrAC9vahGwWdxkbCYtG+
> KUuWGBKMMdHuMAgcQh7nI9q0WT3k/gzRQtuC2kf+v0wvQhaGlTVkku4uanhpuw4p
> 99blRF3/SfWimGuQgsm6wT3Y7dk+z8MFHLb6XGPxmgV9+gF+TWNczfU3GRzfcXw=
> =CQkI
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2012-07-23 📝 Original message:I ...

2023-06-07T10:24:41Z

In reply to nevent1q…60kv
_________________________

📅 Original date posted:2012-07-23
📝 Original message:I would guess that you are running the blockchain download through the tor-proxy - that would give you the times you mention. Further, encrypting your disk (aes stuff) will not help you much either, and encrypting a the storage of a public blockchain seems to me a bit odd ?

I get a full blockchain from scratch in 45 minutes on my laptop, but, I still agree with Gregory that scalability improvements are needed, but the problem is far from critical in the sense outlined here.

/M

On 23/07/2012, at 09:35, Gregory Maxwell wrote:

> On Sun, Jul 22, 2012 at 6:37 PM, grarpamp <grarpamp at gmail.com> wrote:
>> It already takes a month to build a new blockchain, let alone keep up
>> with new incoming blocks.
>
> Please fix your software stack. Something is wrong with your system
> and I doubt it has much to do with bitcoin. A full sync here takes
> something like an hour.
>
> There are certainly lots of scalability things going on, but there is
> no cause for concern for regular hardware being unable to _keep up_
> without a hardforking change to the protocol first.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2012-02-21 📝 Original message:Hi ...

2023-06-07T03:08:39Z

In reply to nevent1q…ylay
_________________________

📅 Original date posted:2012-02-21
📝 Original message:Hi Wladimir / others,

I just downloaded the latest (0.6 rc1) source of bitcoin-qt and built it using qt-creator on MacOSX 10.7.3. Nice and easy experience, even though I had to change BDB version to 5.1 ;)

However, when running it, it is using 100% CPU (after initial block chain download that is...)
* All activity in debug.log seems normal (blocks/txes/addresses are processes and accepted etc) so it is not stuck (at least not in the MessageThread)
* Sampling the process shows that the majority of time in each thread is used for:
** __semwait_signal
** kevent
** __select
** mach_msg_trap
** boost::date_time::micro_sec_clock

None of this would usually alert me - sleeping and waiting for conditions should not consume CPU, the only issue seems to be the last line which is called from qtipcserver.cpp line 31:

if(mq->timed_receive(&strBuf, sizeof(strBuf), nSize, nPriority, d))

As I see it this should not consume cpu either, but, it is the only thing that seems a bit strange..

Have you seen this before?

/M

📅 Original date posted:2012-02-22 📝 Original message:Hi ...

2023-06-07T03:08:27Z

In reply to nevent1q…sq7e
_________________________

📅 Original date posted:2012-02-22
📝 Original message:Hi Gavin / Luke,

BIP-13 again... I started to implement a bitfield based parsing of the version byte using the description I got from Luke, but I then discovered that it does not hold:
Network class:
00xxxxxx - main network
01xxxxxx - reserved
10xxxxxx - reserved
11xxxxxx - test network

Network:
xx00xxxx - bitcoin
xx01xxxx - reserved
xx10xxxx - OTHER (next octet)
xx11xxxx - Namecoin

Network specific:
xxxx000y - PubKeyHash
xxxx001y - reserved
xxxx010y - p2sh
xxxx011y - public key (raw)
xxxx100y - signature
xxxx101y - reserved
xxxx110y - private key (raw)
xxxx111y - OTHER (next octet)

However, the definitions en base58.h are:

PUBKEY_ADDRESS = 0, (00000000)
SCRIPT_ADDRESS = 5, (00000101)
PUBKEY_ADDRESS_TEST = 111, (01101111) !!!
SCRIPT_ADDRESS_TEST = 196, (11000100) !!!

[as a side note litecoin is 48 (00110000) and namecoin is 52 (00110100)]

So there is no logic ?? I have searched the mailing list and the forum for discussions on this but found it hard to find any. If I overlooked something please direct me.

Cheers,

M

PS: I have said so before, but it would *really* be nice if discussions / conclusions / irc-summaries were taking place at one place - e.g. at the bitcoin-dev mailing list, not at 5-10 different threads in bitcointalk or in bip notes or solely on IRC...

On 20/02/2012, at 18:17, Gavin Andresen wrote:

> RE:
> > base58-encode: [one-byte network ID][20-byte hash][one-byte address class][3-byte checksum]
>
> How will the code distinguish between the old scheme:
> [one-byte-version][20-byte-hash][4-byte-checksum]
> and the new?
>
> 1 in 256 old addresses will have a first-byte-of-checksum that matches the new address class; I guess the code would do something like:
>
> a) If the 4-byte checksum matches, then assume it is a singlesig address (1 in 2^32 multisig addresses will incorrectly match)
> b) If the one-byte-address-class and 3-byte checksum match, then it is a valid p2sh
> c) Otherwise, invalid address
>
> The 1 in 2^32 multisig addresses also being valid singlesig addresses makes me think this scheme won't work-- an attacker willing to generate 8 billion or so ECDSA keys could generate a single/multisig collision. I'm not sure how that could be leveraged to their advantage, but I bet they'd find a way.
>
> RE: should it be a BIP: The BIP process is described in BIP 0001, and you're following it perfectly so far:
>
> 1) Post a rough draft of the idea here to see if there's any chance it'll be adopted
> 2) Assuming a positive response and no major flaws: write up a draft BIP
> 3) Post the draft BIP here, where it can be picked apart.
> 4) Assuming no major flaws, ask the BIP editor (Amir) for a BIP number
>
> I'd also encourage you to actually implement your idea between steps 3 and 4. But in this particular case, I think an attacker being able to create singlesig/p2sh address collisions counts as a major flaw.
>
> --
> --
> Gavin Andresen

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-20 📝 Original message:> ...

2023-06-07T03:08:24Z

In reply to nevent1q…zz8f
_________________________

📅 Original date posted:2012-02-20
📝 Original message:> How will the code distinguish between the old scheme:
> [one-byte-version][20-byte-hash][4-byte-checksum]
> and the new?
>
> 1 in 256 old addresses will have a first-byte-of-checksum that matches the new address class; I guess the code would do something like:
>
> a) If the 4-byte checksum matches, then assume it is a singlesig address (1 in 2^32 multisig addresses will incorrectly match)
> b) If the one-byte-address-class and 3-byte checksum match, then it is a valid p2sh
> c) Otherwise, invalid address

Exactly!

>
> The 1 in 2^32 multisig addresses also being valid singlesig addresses makes me think this scheme won't work-- an attacker willing to generate 8 billion or so ECDSA keys could generate a single/multisig collision. I'm not sure how that could be leveraged to their advantage, but I bet they'd find a way.

Nope - its almost like calling the version:0+5 possible collision with new evil, say "ponzicoin" with version=5 a possible flaw that could be exploited... And you can already create non-existing addresses with a matching checksum...

> I'd also encourage you to actually implement your idea between steps 3 and 4. But in this particular case, I think an attacker being able to create singlesig/p2sh address collisions counts as a major flaw.

I will rest my case, not due to the "flaw", but I got some info on the bitfields of the "version" (thanks Luke!) - this makes the +5 less arbitrary, however, I don't think the bitfield interpretation is that well known, so there might already be "version"-collisions...:

Network class:
00xxxxxx - main network
01xxxxxx - reserved
10xxxxxx - reserved
11xxxxxx - test network

Network:
xx00xxxx - bitcoin
xx01xxxx - reserved
xx10xxxx - OTHER (next octet)
xx11xxxx - Namecoin

Network specific:
xxxx000y - PubKeyHash
xxxx001y - reserved
xxxx010y - p2sh
xxxx011y - public key (raw)
xxxx100y - signature
xxxx101y - reserved
xxxx110y - private key (raw)
xxxx111y - OTHER (next octet)

y = 0/1 depending on aesthetics (I guess to force the address to be either 1 or 3).

This also opens up for extensions - (if xx10xxxx or xxxx111x) the next byte will be part of the version.

/M

>
> --
> --
> Gavin Andresen

📅 Original date posted:2012-02-20 📝 Original message:> ...

2023-06-07T03:08:18Z

In reply to nevent1q…y7u4
_________________________

📅 Original date posted:2012-02-20
📝 Original message:>
>> The "version" portion of the address has so far been labeled "network id",
>> and indicates from which network and which chain the address can be used
>> for.
>
> Where do you see this? It has always been "version" as far as I am aware, and
> we discussed formalizing the details of the bits in it a few months back.
> In any case, it was certainly originally intended as "version" as can be
> observed in Satoshi's reference implementation.

See: https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses

And the attached graphics - here it is defined as network byte and network id.

Anyway - can probably live with some bit level subdivision into network id and address class.

/M

📅 Original date posted:2012-02-20 📝 Original message:Just ...

2023-06-07T03:08:12Z

In reply to nevent1q…t060
_________________________

📅 Original date posted:2012-02-20
📝 Original message:Just posted this on the wiki BIP-13 discussion - should I make it into a BIP of its own ?

---
The "version" portion of the address has so far been labeled "network id", and indicates from which network and which chain the address can be used for. I think that this change from network id to version is much more fundamental and should not just be squeezed in along with bip16/17. The right way to do this is to structure the bitcoin address into:

base58-encode: [one-byte network ID][20-byte hash][one-byte address class][3-byte checksum]

This will move the possibility of using a faulty address from 1 to 4bill to 1 to 24mio. Recall that for most other payment systems this checksum is 1 to 9! So it should be sufficient. An old client will then render the new addresses as useless and they will still maintain their old familiar 1xxx look - the whole point in multisig is that it should not be a matter of the paying party to worry about securing wallet of the receiver, hence he should not be bothered with a new "3" kind of address now... --Michael Gronager/libcoin 10:49, 20 February 2012 (GMT)

📅 Original date posted:2012-02-28 📝 Original message:Hi ...

2023-06-07T03:04:57Z

In reply to nevent1q…5fne
_________________________

📅 Original date posted:2012-02-28
📝 Original message:Hi again - and thanks for testing and finding this!

I have fixed the bug you reported:

The culprit was an implicit string constructor for the ChainAddress that caused creation of a not fully initialized ChainAddress. The right way to do it is using chain::getAddress(string) as the ChainAddress is chain specific.

A git pull will fix it ;)

Cheers,

Michael

On 27/02/2012, at 20:03, Martinx - ジェームズ wrote:

> AWESOME!! Thank you!!
>
> Anyway, I found a new problem... lol
>
> /usr/local/bin/bitcoind getinfo #okay
> {
> "version" : 40001,
> "blocks" : 168753,
> "connections" : 8,
> "difficulty" : 1376302.26788638,
> "testnet" : false
> }
>
> /usr/local/bin/bitcoind getaccountaddress "" # okay...
> 1J4vNcvEdeCuLH4yvyoC2gxFEF4zquoJ87
>
> /usr/local/bin/bitcoind listaccounts # NOT okay...
> {
> }
>
> /usr/local/bin/bitcoind getaccountaddress "teste" # okay
> 1E6pGh6AAtuJdFXheZMp1zdYmvdqAQn9QT
>
> /usr/local/bin/bitcoind listaccounts # NOT okay...
> {
> "teste" : 0.00000000
> }
>
> Where is my default account listed at "listaccounts" output?!
>
> Best,
> Thiago
>
> 2012/2/26 Michael Grønager <gronager at ceptacle.com>
> And if you do an update now "help" is there too ;)
>
> /M
>
> On 25/02/2012, at 03:11, Martinx - ジェームズ wrote:
>
>> Thank you!!!
>>
>> It is all working now! Except "help"...
>>
>> Nice work Michael!!
>>
>> Best,
>> Thiago
>>
>> 2012/2/24 Michael Grønager <gronager at ceptacle.com>
>> OK - didn't took the weekend:
>>
>> support for "port" is on github now :)
>>
>> Only took two lines:
>>
>> ("port", value<unsigned short>(&port)->default_value(8333), "Listen on specified port for the p2p protocol")
>>
>> and using the port option in the Node constructor (was there already):
>>
>> Node node(chain, data_dir, args.count("nolisten") ? "" : "0.0.0.0", lexical_cast<string>(port)); // it is also here we specify the use of a proxy!
>>
>> /M
>>
>>
>>
>> On 24/02/2012, at 19:49, Martinx - ジェームズ wrote:
>>
>>> Hi Michael,
>>>
>>> Thank you for your attention!
>>>
>>> Now, I'm trying to start libcoin's bitcoind using high ports but, it always try to listen at 8332, no matter what I "say"...
>>>
>>> Look:
>>>
>>> $ cat .bitcoin/bitcoin.conf
>>> server=1
>>> daemon=1
>>> rpcuser=libcoin
>>> rpcpassword=LibCoin13
>>> rpcport=10332
>>> port=10333
>>>
>>> But:
>>>
>>> /usr/local/bin/bitcoind
>>> Error: Address already in use
>>>
>>> terminate called after throwing an instance of 'DbException'
>>> what(): DbEnv::close: Invalid argument
>>> Aborted
>>>
>>> When I "strace it", I can see:
>>>
>>> ...
>>> bind(12, {sa_family=AF_INET, sin_port=htons(8333), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
>>> ...
>>>
>>> I already tried:
>>>
>>> /usr/local/bin/bitcoind --rpcport 10332
>>> /usr/local/bin/bitcoind --rpcport=10332
>>>
>>> Without success...
>>>
>>> Thanks again!
>>> Thiago
>>>
>>> 2012/2/24 Michael Grønager <gronager at ceptacle.com>
>>> Hi Thiago,
>>>
>>> Forgot to comment on the two latter:
>>>
>>>> $ bitcoind getaccountaddress ""
>>>> HTTP error code: 401
>>>> Error: couldn't parse reply from server
>>>>
>>>> $ bitcoind listaccounts
>>>> HTTP error code: 401
>>>> Error: couldn't parse reply from server
>>>>
>>>
>>> 401 = permission denied - you need to setup username / password either on the commandline or in the bicoin.conf file to access those commands...
>>>
>>> See in the bitcoind.cpp file for commands that you can use with and without auth...
>>>
>>> Those that contains an "auth" requires auth:
>>>
>>> server.registerMethod(method_ptr(new GetBalance(wallet)), auth);
>>>
>>> As opposed to:
>>>
>>> server.registerMethod(method_ptr(new GetInfo(node)));
>>>
>>> auth is defined by:
>>>
>>> Auth auth(rpc_user, rpc_pass); // if rpc_user and rpc_pass are not set, all authenticated methods becomes disallowed.
>>>
>>> so you just experience the case explained in the comment ;) I admit that the output could be more readable, though!
>>>
>>> /M
>>>
>>>
>>>>
>>>> Any tips?! lol
>>>>
>>>> Thanks!
>>>> Thiago
>>>>
>>>> 2012/2/23 Martinx - ジェームズ <thiagocmartinsc at gmail.com>
>>>> AWESOME!!!
>>>>
>>>> I can compile libcoin at my Ubuntu 11.10... I just need to install:
>>>>
>>>> sudo aptitude install libboost1.46-all-dev
>>>>
>>>> ...alongside with another already installed dependencies, and now it works!!
>>>>
>>>> Thank you!
>>>> Thiago
>>>>
>>>> 2012/2/23 Michael Grønager <gronager at ceptacle.com>
>>>> Hi Martinx,
>>>>
>>>> Another note:
>>>>
>>>> boost 1.42 and openssl 1.0 has a conflict (you will see it when you try to compile coinHTTP with that specific combination: sslv2 has been removed from openssl, but boost still references it.)
>>>>
>>>> You should do a :
>>>>
>>>> sudo apt-get upgrade libboost-dev-all
>>>>
>>>> to get the 1.46.1 library
>>>>
>>>> /M
>>>>
>>>>
>>>> On 23/02/2012, at 18:31, Martinx - ジェームズ wrote:
>>>>
>>>>> Hi Michael!
>>>>>
>>>>> Thank you for libcoin! It is a awesome evolution for Bitcoin and for the CryptoCurrencies as a hole... Thanks!!!
>>>>>
>>>>> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At this machine, I have compiled and running Bitcoin (from sources), Namecoin, Devcoin, Litecoin, IXcoin and I0coin, all from sources but, when I try to compile libcoin, I got:
>>>>>
>>>>> ----
>>>>> user at desk:~/libcoin$ ./configure
>>>>> -- The C compiler identification is GNU
>>>>> -- The CXX compiler identification is GNU
>>>>> -- Check for working C compiler: /usr/bin/gcc
>>>>> -- Check for working C compiler: /usr/bin/gcc -- works
>>>>> -- Detecting C compiler ABI info
>>>>> -- Detecting C compiler ABI info - done
>>>>> -- Check for working CXX compiler: /usr/bin/c++
>>>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>>> -- Detecting CXX compiler ABI info
>>>>> -- Detecting CXX compiler ABI info - done
>>>>> -- Looking for include files CMAKE_HAVE_PTHREAD_H
>>>>> -- Looking for include files CMAKE_HAVE_PTHREAD_H - found
>>>>> -- Looking for pthread_create in pthreads
>>>>> -- Looking for pthread_create in pthreads - not found
>>>>> -- Looking for pthread_create in pthread
>>>>> -- Looking for pthread_create in pthread - found
>>>>> -- Found Threads: TRUE
>>>>> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so
>>>>> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found
>>>>> -- Looking for gethostbyname
>>>>> -- Looking for gethostbyname - found
>>>>> -- Looking for connect
>>>>> -- Looking for connect - found
>>>>> -- Looking for remove
>>>>> -- Looking for remove - found
>>>>> -- Looking for shmat
>>>>> -- Looking for shmat - found
>>>>> -- Looking for IceConnectionNumber in ICE
>>>>> -- Looking for IceConnectionNumber in ICE - found
>>>>> -- Found X11: /usr/lib/i386-linux-gnu/libX11.so
>>>>> -- Boost version: 1.42.0
>>>>> -- Found the following Boost libraries:
>>>>> -- date_time
>>>>> -- regex
>>>>> -- filesystem
>>>>> -- system
>>>>> -- program_options
>>>>> -- thread
>>>>> -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so
>>>>> -- Looking for Q_WS_X11
>>>>> -- Looking for Q_WS_X11 - found
>>>>> -- Looking for Q_WS_WIN
>>>>> -- Looking for Q_WS_WIN - not found.
>>>>> -- Looking for Q_WS_QWS
>>>>> -- Looking for Q_WS_QWS - not found.
>>>>> -- Looking for Q_WS_MAC
>>>>> -- Looking for Q_WS_MAC - not found.
>>>>> -- Found Qt-Version 4.7.2 (using /usr/bin/qmake)
>>>>> -- Found wxWidgets: TRUE
>>>>>
>>>>> The build system is configured to install libraries to /usr/local/lib
>>>>> Your applications may not be able to find your installed libraries unless you:
>>>>> set your LD_LIBRARY_PATH (user specific) or
>>>>> update your ld.so configuration (system wide)
>>>>> You have an ld.so.conf.d directory on your system, so if you wish to ensure that
>>>>> applications find the installed libcoin libraries, system wide, you could install an
>>>>> libcoin specific ld.so configuration with:
>>>>> sudo make install_ld_conf
>>>>>
>>>>> -- Configuring done
>>>>> -- Generating done
>>>>> -- Build files have been written to: /home/user/libcoin
>>>>> ----
>>>>>
>>>>> Now I tried make, without success:
>>>>>
>>>>> ----
>>>>> .....
>>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xf): undefined reference to `BN_init'
>>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x1e): undefined reference to `BN_copy'
>>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x38): undefined reference to `BN_set_negative'
>>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x4f): undefined reference to `BN_clear_free'
>>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xd3): undefined reference to `BN_clear_free'
>>>>> ../../lib/libcoin.a(Script.o): In function `operator<<(CBigNum const&, unsigned int)':
>>>>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x16): undefined reference to `BN_init'
>>>>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x2c): undefined reference to `BN_lshift'
>>>>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0xad): undefined reference to `BN_clear_free'
>>>>> ../../lib/libcoin.a(Script.o): In function `operator>>(CBigNum const&, unsigned int)':
>>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xf): undefined reference to `BN_init'
>>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x1e): undefined reference to `BN_copy'
>>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x47): undefined reference to `BN_clear_free'
>>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xcb): undefined reference to `BN_clear_free'
>>>>> ../../lib/libcoin.a(Script.o): In function `operator!=(CBigNum const&, CBigNum const&)':
>>>>> Script.cpp:(.text._ZneRK7CBigNumS1_[operator!=(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
>>>>> ../../lib/libcoin.a(Script.o): In function `operator>(CBigNum const&, CBigNum const&)':
>>>>> Script.cpp:(.text._ZgtRK7CBigNumS1_[operator>(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
>>>>> ../../lib/libcoin.a(Script.o): In function `uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)':
>>>>> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0x6d): undefined reference to `SHA256'
>>>>> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0xb8): undefined reference to `SHA256'
>>>>> collect2: ld returned 1 exit status
>>>>> make[2]: *** [bin/bitcoind] Error 1
>>>>> make[1]: *** [applications/bitcoind/CMakeFiles/app_bitcoind.dir/all] Error 2
>>>>> make: *** [all] Error 2
>>>>> -----
>>>>>
>>>>> What can I do?!
>>>>>
>>>>> Best,
>>>>> Thiago
>>>>>
>>>>>
>>>>> On 1 February 2012 12:18, Michael Grønager <gronager at ceptacle.com> wrote:
>>>>> Dear Bitcoiners,
>>>>>
>>>>> libcoin is now in a state ready for its first release, which I would like to share with you!
>>>>>
>>>>> === libcoin is a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. ===
>>>>>
>>>>> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the first version of the crypto currency library "libcoin" based on the bitcoin/bitcoin "Satoshi" client.
>>>>>
>>>>> libcoin also maintains a version of bitcoind that is a 100% compatible drop-in replacement of the bitcoin/bitcoind client: You can use it on the same computer on the same files and you can call it with the same scripts. And you can easily extend it without touching the basic bitcoin source files.
>>>>>
>>>>> The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!
>>>>>
>>>>> In libcoin, the Satoshi client code has been completely refactored, properly encapsulating classes, removing all globals, moving from threads and mutexes to a pure asynchronous approach. Functionalities have been divided into logical units and libraries, minimizing dependencies for e.g. thin clients.
>>>>>
>>>>> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, ...) specific settings are maintained from a single class (Chain) and hence experiments with chain settings, mining, security and digital currencies for research and educational purposes are easily accessible. See the ponzicoin example for how you define your own chain.
>>>>>
>>>>> The build system of libcoin is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows.
>>>>>
>>>>> The libcoin license is LGPL v. 3. This mean that you can use it in open source as well as in commercial projects, but improvements should go back into the libcoin library.
>>>>>
>>>>> ======
>>>>>
>>>>> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
>>>>>
>>>>> Join libcoin on twitter: http://twitter.com/libcoin
>>>>>
>>>>> Download "libcoin Satoshi release": http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Michael Gronager, PhD
>>>>> Director, Ceptacle
>>>>> Jens Juels Gade 33
>>>>> 2100 Copenhagen E
>>>>> Mobile: +45 31 45 14 01
>>>>> E-mail: gronager at ceptacle.com
>>>>> Web: http://www.ceptacle.com/
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>>> The most comprehensive online learning library for Microsoft developers
>>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>>> http://p.sf.net/sfu/learndevnow-d2d
>>>>> _______________________________________________
>>>>> Bitcoin-development mailing list
>>>>> Bitcoin-development at lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>>
>>>>
>>>> Michael Gronager, PhD
>>>> Director, Ceptacle
>>>> Jens Juels Gade 33
>>>> 2100 Copenhagen E
>>>> Mobile: +45 31 45 14 01
>>>> E-mail: gronager at ceptacle.com
>>>> Web: http://www.ceptacle.com/
>>>>
>>>>
>>>>
>>>
>>>
>>
>> Michael Gronager, PhD
>> Director, Ceptacle
>> Jens Juels Gade 33
>> 2100 Copenhagen E
>> Mobile: +45 31 45 14 01
>> E-mail: gronager at ceptacle.com
>> Web: http://www.ceptacle.com/
>>
>>
>
> Michael Gronager, PhD
> Director, Ceptacle
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 45 14 01
> E-mail: gronager at ceptacle.com
> Web: http://www.ceptacle.com/
>
>

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-27 📝 Original message:I ...

2023-06-07T03:04:53Z

In reply to nevent1q…ghzw
_________________________

📅 Original date posted:2012-02-27
📝 Original message:I tried this and got:

./bitcoind listaccount:
{
}

bitcoind getnewaddress
1DumTDw6quNqnUegJsXL2AJjDA9fmxRY7o

./bitcoind setaccount 1DumTDw6quNqnUegJsXL2AJjDA9fmxRY7o test

./bitcoind listaccounts{
"" : 0.00000000,
"test" : 0.00000000
}

Seem like the default account ( "" ) need to be initialized ?? Will test the same with the old client and see if it behaves similarly..

/M

On 27/02/2012, at 20:03, Martinx - ジェームズ wrote:

> AWESOME!! Thank you!!
>
> Anyway, I found a new problem... lol
>
> /usr/local/bin/bitcoind getinfo #okay
> {
> "version" : 40001,
> "blocks" : 168753,
> "connections" : 8,
> "difficulty" : 1376302.26788638,
> "testnet" : false
> }
>
> /usr/local/bin/bitcoind getaccountaddress "" # okay...
> 1J4vNcvEdeCuLH4yvyoC2gxFEF4zquoJ87
>
> /usr/local/bin/bitcoind listaccounts # NOT okay...
> {
> }
>
> /usr/local/bin/bitcoind getaccountaddress "teste" # okay
> 1E6pGh6AAtuJdFXheZMp1zdYmvdqAQn9QT
>
> /usr/local/bin/bitcoind listaccounts # NOT okay...
> {
> "teste" : 0.00000000
> }
>
> Where is my default account listed at "listaccounts" output?!
>
> Best,
> Thiago
>
> 2012/2/26 Michael Grønager <gronager at ceptacle.com>
> And if you do an update now "help" is there too ;)
>
> /M
>
> On 25/02/2012, at 03:11, Martinx - ジェームズ wrote:
>
>> Thank you!!!
>>
>> It is all working now! Except "help"...
>>
>> Nice work Michael!!
>>
>> Best,
>> Thiago
>>
>> 2012/2/24 Michael Grønager <gronager at ceptacle.com>
>> OK - didn't took the weekend:
>>
>> support for "port" is on github now :)
>>
>> Only took two lines:
>>
>> ("port", value<unsigned short>(&port)->default_value(8333), "Listen on specified port for the p2p protocol")
>>
>> and using the port option in the Node constructor (was there already):
>>
>> Node node(chain, data_dir, args.count("nolisten") ? "" : "0.0.0.0", lexical_cast<string>(port)); // it is also here we specify the use of a proxy!
>>
>> /M
>>
>>
>>
>> On 24/02/2012, at 19:49, Martinx - ジェームズ wrote:
>>
>>> Hi Michael,
>>>
>>> Thank you for your attention!
>>>
>>> Now, I'm trying to start libcoin's bitcoind using high ports but, it always try to listen at 8332, no matter what I "say"...
>>>
>>> Look:
>>>
>>> $ cat .bitcoin/bitcoin.conf
>>> server=1
>>> daemon=1
>>> rpcuser=libcoin
>>> rpcpassword=LibCoin13
>>> rpcport=10332
>>> port=10333
>>>
>>> But:
>>>
>>> /usr/local/bin/bitcoind
>>> Error: Address already in use
>>>
>>> terminate called after throwing an instance of 'DbException'
>>> what(): DbEnv::close: Invalid argument
>>> Aborted
>>>
>>> When I "strace it", I can see:
>>>
>>> ...
>>> bind(12, {sa_family=AF_INET, sin_port=htons(8333), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
>>> ...
>>>
>>> I already tried:
>>>
>>> /usr/local/bin/bitcoind --rpcport 10332
>>> /usr/local/bin/bitcoind --rpcport=10332
>>>
>>> Without success...
>>>
>>> Thanks again!
>>> Thiago
>>>
>>> 2012/2/24 Michael Grønager <gronager at ceptacle.com>
>>> Hi Thiago,
>>>
>>> Forgot to comment on the two latter:
>>>
>>>> $ bitcoind getaccountaddress ""
>>>> HTTP error code: 401
>>>> Error: couldn't parse reply from server
>>>>
>>>> $ bitcoind listaccounts
>>>> HTTP error code: 401
>>>> Error: couldn't parse reply from server
>>>>
>>>
>>> 401 = permission denied - you need to setup username / password either on the commandline or in the bicoin.conf file to access those commands...
>>>
>>> See in the bitcoind.cpp file for commands that you can use with and without auth...
>>>
>>> Those that contains an "auth" requires auth:
>>>
>>> server.registerMethod(method_ptr(new GetBalance(wallet)), auth);
>>>
>>> As opposed to:
>>>
>>> server.registerMethod(method_ptr(new GetInfo(node)));
>>>
>>> auth is defined by:
>>>
>>> Auth auth(rpc_user, rpc_pass); // if rpc_user and rpc_pass are not set, all authenticated methods becomes disallowed.
>>>
>>> so you just experience the case explained in the comment ;) I admit that the output could be more readable, though!
>>>
>>> /M
>>>
>>>
>>>>
>>>> Any tips?! lol
>>>>
>>>> Thanks!
>>>> Thiago
>>>>
>>>> 2012/2/23 Martinx - ジェームズ <thiagocmartinsc at gmail.com>
>>>> AWESOME!!!
>>>>
>>>> I can compile libcoin at my Ubuntu 11.10... I just need to install:
>>>>
>>>> sudo aptitude install libboost1.46-all-dev
>>>>
>>>> ...alongside with another already installed dependencies, and now it works!!
>>>>
>>>> Thank you!
>>>> Thiago
>>>>
>>>> 2012/2/23 Michael Grønager <gronager at ceptacle.com>
>>>> Hi Martinx,
>>>>
>>>> Another note:
>>>>
>>>> boost 1.42 and openssl 1.0 has a conflict (you will see it when you try to compile coinHTTP with that specific combination: sslv2 has been removed from openssl, but boost still references it.)
>>>>
>>>> You should do a :
>>>>
>>>> sudo apt-get upgrade libboost-dev-all
>>>>
>>>> to get the 1.46.1 library
>>>>
>>>> /M
>>>>
>>>>
>>>> On 23/02/2012, at 18:31, Martinx - ジェームズ wrote:
>>>>
>>>>> Hi Michael!
>>>>>
>>>>> Thank you for libcoin! It is a awesome evolution for Bitcoin and for the CryptoCurrencies as a hole... Thanks!!!
>>>>>
>>>>> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At this machine, I have compiled and running Bitcoin (from sources), Namecoin, Devcoin, Litecoin, IXcoin and I0coin, all from sources but, when I try to compile libcoin, I got:
>>>>>
>>>>> ----
>>>>> user at desk:~/libcoin$ ./configure
>>>>> -- The C compiler identification is GNU
>>>>> -- The CXX compiler identification is GNU
>>>>> -- Check for working C compiler: /usr/bin/gcc
>>>>> -- Check for working C compiler: /usr/bin/gcc -- works
>>>>> -- Detecting C compiler ABI info
>>>>> -- Detecting C compiler ABI info - done
>>>>> -- Check for working CXX compiler: /usr/bin/c++
>>>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>>> -- Detecting CXX compiler ABI info
>>>>> -- Detecting CXX compiler ABI info - done
>>>>> -- Looking for include files CMAKE_HAVE_PTHREAD_H
>>>>> -- Looking for include files CMAKE_HAVE_PTHREAD_H - found
>>>>> -- Looking for pthread_create in pthreads
>>>>> -- Looking for pthread_create in pthreads - not found
>>>>> -- Looking for pthread_create in pthread
>>>>> -- Looking for pthread_create in pthread - found
>>>>> -- Found Threads: TRUE
>>>>> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so
>>>>> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found
>>>>> -- Looking for gethostbyname
>>>>> -- Looking for gethostbyname - found
>>>>> -- Looking for connect
>>>>> -- Looking for connect - found
>>>>> -- Looking for remove
>>>>> -- Looking for remove - found
>>>>> -- Looking for shmat
>>>>> -- Looking for shmat - found
>>>>> -- Looking for IceConnectionNumber in ICE
>>>>> -- Looking for IceConnectionNumber in ICE - found
>>>>> -- Found X11: /usr/lib/i386-linux-gnu/libX11.so
>>>>> -- Boost version: 1.42.0
>>>>> -- Found the following Boost libraries:
>>>>> -- date_time
>>>>> -- regex
>>>>> -- filesystem
>>>>> -- system
>>>>> -- program_options
>>>>> -- thread
>>>>> -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so
>>>>> -- Looking for Q_WS_X11
>>>>> -- Looking for Q_WS_X11 - found
>>>>> -- Looking for Q_WS_WIN
>>>>> -- Looking for Q_WS_WIN - not found.
>>>>> -- Looking for Q_WS_QWS
>>>>> -- Looking for Q_WS_QWS - not found.
>>>>> -- Looking for Q_WS_MAC
>>>>> -- Looking for Q_WS_MAC - not found.
>>>>> -- Found Qt-Version 4.7.2 (using /usr/bin/qmake)
>>>>> -- Found wxWidgets: TRUE
>>>>>
>>>>> The build system is configured to install libraries to /usr/local/lib
>>>>> Your applications may not be able to find your installed libraries unless you:
>>>>> set your LD_LIBRARY_PATH (user specific) or
>>>>> update your ld.so configuration (system wide)
>>>>> You have an ld.so.conf.d directory on your system, so if you wish to ensure that
>>>>> applications find the installed libcoin libraries, system wide, you could install an
>>>>> libcoin specific ld.so configuration with:
>>>>> sudo make install_ld_conf
>>>>>
>>>>> -- Configuring done
>>>>> -- Generating done
>>>>> -- Build files have been written to: /home/user/libcoin
>>>>> ----
>>>>>
>>>>> Now I tried make, without success:
>>>>>
>>>>> ----
>>>>> .....
>>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xf): undefined reference to `BN_init'
>>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x1e): undefined reference to `BN_copy'
>>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x38): undefined reference to `BN_set_negative'
>>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x4f): undefined reference to `BN_clear_free'
>>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xd3): undefined reference to `BN_clear_free'
>>>>> ../../lib/libcoin.a(Script.o): In function `operator<<(CBigNum const&, unsigned int)':
>>>>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x16): undefined reference to `BN_init'
>>>>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x2c): undefined reference to `BN_lshift'
>>>>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0xad): undefined reference to `BN_clear_free'
>>>>> ../../lib/libcoin.a(Script.o): In function `operator>>(CBigNum const&, unsigned int)':
>>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xf): undefined reference to `BN_init'
>>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x1e): undefined reference to `BN_copy'
>>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x47): undefined reference to `BN_clear_free'
>>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xcb): undefined reference to `BN_clear_free'
>>>>> ../../lib/libcoin.a(Script.o): In function `operator!=(CBigNum const&, CBigNum const&)':
>>>>> Script.cpp:(.text._ZneRK7CBigNumS1_[operator!=(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
>>>>> ../../lib/libcoin.a(Script.o): In function `operator>(CBigNum const&, CBigNum const&)':
>>>>> Script.cpp:(.text._ZgtRK7CBigNumS1_[operator>(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
>>>>> ../../lib/libcoin.a(Script.o): In function `uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)':
>>>>> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0x6d): undefined reference to `SHA256'
>>>>> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0xb8): undefined reference to `SHA256'
>>>>> collect2: ld returned 1 exit status
>>>>> make[2]: *** [bin/bitcoind] Error 1
>>>>> make[1]: *** [applications/bitcoind/CMakeFiles/app_bitcoind.dir/all] Error 2
>>>>> make: *** [all] Error 2
>>>>> -----
>>>>>
>>>>> What can I do?!
>>>>>
>>>>> Best,
>>>>> Thiago
>>>>>
>>>>>
>>>>> On 1 February 2012 12:18, Michael Grønager <gronager at ceptacle.com> wrote:
>>>>> Dear Bitcoiners,
>>>>>
>>>>> libcoin is now in a state ready for its first release, which I would like to share with you!
>>>>>
>>>>> === libcoin is a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. ===
>>>>>
>>>>> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the first version of the crypto currency library "libcoin" based on the bitcoin/bitcoin "Satoshi" client.
>>>>>
>>>>> libcoin also maintains a version of bitcoind that is a 100% compatible drop-in replacement of the bitcoin/bitcoind client: You can use it on the same computer on the same files and you can call it with the same scripts. And you can easily extend it without touching the basic bitcoin source files.
>>>>>
>>>>> The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!
>>>>>
>>>>> In libcoin, the Satoshi client code has been completely refactored, properly encapsulating classes, removing all globals, moving from threads and mutexes to a pure asynchronous approach. Functionalities have been divided into logical units and libraries, minimizing dependencies for e.g. thin clients.
>>>>>
>>>>> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, ...) specific settings are maintained from a single class (Chain) and hence experiments with chain settings, mining, security and digital currencies for research and educational purposes are easily accessible. See the ponzicoin example for how you define your own chain.
>>>>>
>>>>> The build system of libcoin is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows.
>>>>>
>>>>> The libcoin license is LGPL v. 3. This mean that you can use it in open source as well as in commercial projects, but improvements should go back into the libcoin library.
>>>>>
>>>>> ======
>>>>>
>>>>> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
>>>>>
>>>>> Join libcoin on twitter: http://twitter.com/libcoin
>>>>>
>>>>> Download "libcoin Satoshi release": http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Michael Gronager, PhD
>>>>> Director, Ceptacle
>>>>> Jens Juels Gade 33
>>>>> 2100 Copenhagen E
>>>>> Mobile: +45 31 45 14 01
>>>>> E-mail: gronager at ceptacle.com
>>>>> Web: http://www.ceptacle.com/
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>>> The most comprehensive online learning library for Microsoft developers
>>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>>> http://p.sf.net/sfu/learndevnow-d2d
>>>>> _______________________________________________
>>>>> Bitcoin-development mailing list
>>>>> Bitcoin-development at lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>>
>>>>
>>>> Michael Gronager, PhD
>>>> Director, Ceptacle
>>>> Jens Juels Gade 33
>>>> 2100 Copenhagen E
>>>> Mobile: +45 31 45 14 01
>>>> E-mail: gronager at ceptacle.com
>>>> Web: http://www.ceptacle.com/
>>>>
>>>>
>>>>
>>>
>>>
>>
>> Michael Gronager, PhD
>> Director, Ceptacle
>> Jens Juels Gade 33
>> 2100 Copenhagen E
>> Mobile: +45 31 45 14 01
>> E-mail: gronager at ceptacle.com
>> Web: http://www.ceptacle.com/
>>
>>
>
> Michael Gronager, PhD
> Director, Ceptacle
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 45 14 01
> E-mail: gronager at ceptacle.com
> Web: http://www.ceptacle.com/
>
>

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-26 📝 Original message:And if ...

2023-06-07T03:04:46Z

In reply to nevent1q…dt80
_________________________

📅 Original date posted:2012-02-26
📝 Original message:And if you do an update now "help" is there too ;)

/M

On 25/02/2012, at 03:11, Martinx - ジェームズ wrote:

> Thank you!!!
>
> It is all working now! Except "help"...
>
> Nice work Michael!!
>
> Best,
> Thiago
>
> 2012/2/24 Michael Grønager <gronager at ceptacle.com>
> OK - didn't took the weekend:
>
> support for "port" is on github now :)
>
> Only took two lines:
>
> ("port", value<unsigned short>(&port)->default_value(8333), "Listen on specified port for the p2p protocol")
>
> and using the port option in the Node constructor (was there already):
>
> Node node(chain, data_dir, args.count("nolisten") ? "" : "0.0.0.0", lexical_cast<string>(port)); // it is also here we specify the use of a proxy!
>
> /M
>
>
>
> On 24/02/2012, at 19:49, Martinx - ジェームズ wrote:
>
>> Hi Michael,
>>
>> Thank you for your attention!
>>
>> Now, I'm trying to start libcoin's bitcoind using high ports but, it always try to listen at 8332, no matter what I "say"...
>>
>> Look:
>>
>> $ cat .bitcoin/bitcoin.conf
>> server=1
>> daemon=1
>> rpcuser=libcoin
>> rpcpassword=LibCoin13
>> rpcport=10332
>> port=10333
>>
>> But:
>>
>> /usr/local/bin/bitcoind
>> Error: Address already in use
>>
>> terminate called after throwing an instance of 'DbException'
>> what(): DbEnv::close: Invalid argument
>> Aborted
>>
>> When I "strace it", I can see:
>>
>> ...
>> bind(12, {sa_family=AF_INET, sin_port=htons(8333), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
>> ...
>>
>> I already tried:
>>
>> /usr/local/bin/bitcoind --rpcport 10332
>> /usr/local/bin/bitcoind --rpcport=10332
>>
>> Without success...
>>
>> Thanks again!
>> Thiago
>>
>> 2012/2/24 Michael Grønager <gronager at ceptacle.com>
>> Hi Thiago,
>>
>> Forgot to comment on the two latter:
>>
>>> $ bitcoind getaccountaddress ""
>>> HTTP error code: 401
>>> Error: couldn't parse reply from server
>>>
>>> $ bitcoind listaccounts
>>> HTTP error code: 401
>>> Error: couldn't parse reply from server
>>>
>>
>> 401 = permission denied - you need to setup username / password either on the commandline or in the bicoin.conf file to access those commands...
>>
>> See in the bitcoind.cpp file for commands that you can use with and without auth...
>>
>> Those that contains an "auth" requires auth:
>>
>> server.registerMethod(method_ptr(new GetBalance(wallet)), auth);
>>
>> As opposed to:
>>
>> server.registerMethod(method_ptr(new GetInfo(node)));
>>
>> auth is defined by:
>>
>> Auth auth(rpc_user, rpc_pass); // if rpc_user and rpc_pass are not set, all authenticated methods becomes disallowed.
>>
>> so you just experience the case explained in the comment ;) I admit that the output could be more readable, though!
>>
>> /M
>>
>>
>>>
>>> Any tips?! lol
>>>
>>> Thanks!
>>> Thiago
>>>
>>> 2012/2/23 Martinx - ジェームズ <thiagocmartinsc at gmail.com>
>>> AWESOME!!!
>>>
>>> I can compile libcoin at my Ubuntu 11.10... I just need to install:
>>>
>>> sudo aptitude install libboost1.46-all-dev
>>>
>>> ...alongside with another already installed dependencies, and now it works!!
>>>
>>> Thank you!
>>> Thiago
>>>
>>> 2012/2/23 Michael Grønager <gronager at ceptacle.com>
>>> Hi Martinx,
>>>
>>> Another note:
>>>
>>> boost 1.42 and openssl 1.0 has a conflict (you will see it when you try to compile coinHTTP with that specific combination: sslv2 has been removed from openssl, but boost still references it.)
>>>
>>> You should do a :
>>>
>>> sudo apt-get upgrade libboost-dev-all
>>>
>>> to get the 1.46.1 library
>>>
>>> /M
>>>
>>>
>>> On 23/02/2012, at 18:31, Martinx - ジェームズ wrote:
>>>
>>>> Hi Michael!
>>>>
>>>> Thank you for libcoin! It is a awesome evolution for Bitcoin and for the CryptoCurrencies as a hole... Thanks!!!
>>>>
>>>> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At this machine, I have compiled and running Bitcoin (from sources), Namecoin, Devcoin, Litecoin, IXcoin and I0coin, all from sources but, when I try to compile libcoin, I got:
>>>>
>>>> ----
>>>> user at desk:~/libcoin$ ./configure
>>>> -- The C compiler identification is GNU
>>>> -- The CXX compiler identification is GNU
>>>> -- Check for working C compiler: /usr/bin/gcc
>>>> -- Check for working C compiler: /usr/bin/gcc -- works
>>>> -- Detecting C compiler ABI info
>>>> -- Detecting C compiler ABI info - done
>>>> -- Check for working CXX compiler: /usr/bin/c++
>>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>> -- Detecting CXX compiler ABI info
>>>> -- Detecting CXX compiler ABI info - done
>>>> -- Looking for include files CMAKE_HAVE_PTHREAD_H
>>>> -- Looking for include files CMAKE_HAVE_PTHREAD_H - found
>>>> -- Looking for pthread_create in pthreads
>>>> -- Looking for pthread_create in pthreads - not found
>>>> -- Looking for pthread_create in pthread
>>>> -- Looking for pthread_create in pthread - found
>>>> -- Found Threads: TRUE
>>>> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so
>>>> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found
>>>> -- Looking for gethostbyname
>>>> -- Looking for gethostbyname - found
>>>> -- Looking for connect
>>>> -- Looking for connect - found
>>>> -- Looking for remove
>>>> -- Looking for remove - found
>>>> -- Looking for shmat
>>>> -- Looking for shmat - found
>>>> -- Looking for IceConnectionNumber in ICE
>>>> -- Looking for IceConnectionNumber in ICE - found
>>>> -- Found X11: /usr/lib/i386-linux-gnu/libX11.so
>>>> -- Boost version: 1.42.0
>>>> -- Found the following Boost libraries:
>>>> -- date_time
>>>> -- regex
>>>> -- filesystem
>>>> -- system
>>>> -- program_options
>>>> -- thread
>>>> -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so
>>>> -- Looking for Q_WS_X11
>>>> -- Looking for Q_WS_X11 - found
>>>> -- Looking for Q_WS_WIN
>>>> -- Looking for Q_WS_WIN - not found.
>>>> -- Looking for Q_WS_QWS
>>>> -- Looking for Q_WS_QWS - not found.
>>>> -- Looking for Q_WS_MAC
>>>> -- Looking for Q_WS_MAC - not found.
>>>> -- Found Qt-Version 4.7.2 (using /usr/bin/qmake)
>>>> -- Found wxWidgets: TRUE
>>>>
>>>> The build system is configured to install libraries to /usr/local/lib
>>>> Your applications may not be able to find your installed libraries unless you:
>>>> set your LD_LIBRARY_PATH (user specific) or
>>>> update your ld.so configuration (system wide)
>>>> You have an ld.so.conf.d directory on your system, so if you wish to ensure that
>>>> applications find the installed libcoin libraries, system wide, you could install an
>>>> libcoin specific ld.so configuration with:
>>>> sudo make install_ld_conf
>>>>
>>>> -- Configuring done
>>>> -- Generating done
>>>> -- Build files have been written to: /home/user/libcoin
>>>> ----
>>>>
>>>> Now I tried make, without success:
>>>>
>>>> ----
>>>> .....
>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xf): undefined reference to `BN_init'
>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x1e): undefined reference to `BN_copy'
>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x38): undefined reference to `BN_set_negative'
>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x4f): undefined reference to `BN_clear_free'
>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xd3): undefined reference to `BN_clear_free'
>>>> ../../lib/libcoin.a(Script.o): In function `operator<<(CBigNum const&, unsigned int)':
>>>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x16): undefined reference to `BN_init'
>>>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x2c): undefined reference to `BN_lshift'
>>>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0xad): undefined reference to `BN_clear_free'
>>>> ../../lib/libcoin.a(Script.o): In function `operator>>(CBigNum const&, unsigned int)':
>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xf): undefined reference to `BN_init'
>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x1e): undefined reference to `BN_copy'
>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x47): undefined reference to `BN_clear_free'
>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xcb): undefined reference to `BN_clear_free'
>>>> ../../lib/libcoin.a(Script.o): In function `operator!=(CBigNum const&, CBigNum const&)':
>>>> Script.cpp:(.text._ZneRK7CBigNumS1_[operator!=(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
>>>> ../../lib/libcoin.a(Script.o): In function `operator>(CBigNum const&, CBigNum const&)':
>>>> Script.cpp:(.text._ZgtRK7CBigNumS1_[operator>(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
>>>> ../../lib/libcoin.a(Script.o): In function `uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)':
>>>> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0x6d): undefined reference to `SHA256'
>>>> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0xb8): undefined reference to `SHA256'
>>>> collect2: ld returned 1 exit status
>>>> make[2]: *** [bin/bitcoind] Error 1
>>>> make[1]: *** [applications/bitcoind/CMakeFiles/app_bitcoind.dir/all] Error 2
>>>> make: *** [all] Error 2
>>>> -----
>>>>
>>>> What can I do?!
>>>>
>>>> Best,
>>>> Thiago
>>>>
>>>>
>>>> On 1 February 2012 12:18, Michael Grønager <gronager at ceptacle.com> wrote:
>>>> Dear Bitcoiners,
>>>>
>>>> libcoin is now in a state ready for its first release, which I would like to share with you!
>>>>
>>>> === libcoin is a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. ===
>>>>
>>>> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the first version of the crypto currency library "libcoin" based on the bitcoin/bitcoin "Satoshi" client.
>>>>
>>>> libcoin also maintains a version of bitcoind that is a 100% compatible drop-in replacement of the bitcoin/bitcoind client: You can use it on the same computer on the same files and you can call it with the same scripts. And you can easily extend it without touching the basic bitcoin source files.
>>>>
>>>> The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!
>>>>
>>>> In libcoin, the Satoshi client code has been completely refactored, properly encapsulating classes, removing all globals, moving from threads and mutexes to a pure asynchronous approach. Functionalities have been divided into logical units and libraries, minimizing dependencies for e.g. thin clients.
>>>>
>>>> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, ...) specific settings are maintained from a single class (Chain) and hence experiments with chain settings, mining, security and digital currencies for research and educational purposes are easily accessible. See the ponzicoin example for how you define your own chain.
>>>>
>>>> The build system of libcoin is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows.
>>>>
>>>> The libcoin license is LGPL v. 3. This mean that you can use it in open source as well as in commercial projects, but improvements should go back into the libcoin library.
>>>>
>>>> ======
>>>>
>>>> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
>>>>
>>>> Join libcoin on twitter: http://twitter.com/libcoin
>>>>
>>>> Download "libcoin Satoshi release": http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
>>>>
>>>> Best regards,
>>>>
>>>> Michael Gronager, PhD
>>>> Director, Ceptacle
>>>> Jens Juels Gade 33
>>>> 2100 Copenhagen E
>>>> Mobile: +45 31 45 14 01
>>>> E-mail: gronager at ceptacle.com
>>>> Web: http://www.ceptacle.com/
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>> The most comprehensive online learning library for Microsoft developers
>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>> http://p.sf.net/sfu/learndevnow-d2d
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>
>>> Michael Gronager, PhD
>>> Director, Ceptacle
>>> Jens Juels Gade 33
>>> 2100 Copenhagen E
>>> Mobile: +45 31 45 14 01
>>> E-mail: gronager at ceptacle.com
>>> Web: http://www.ceptacle.com/
>>>
>>>
>>>
>>
>>
>
> Michael Gronager, PhD
> Director, Ceptacle
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 45 14 01
> E-mail: gronager at ceptacle.com
> Web: http://www.ceptacle.com/
>
>

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-24 📝 Original message:OK - ...

2023-06-07T03:04:39Z

In reply to nevent1q…ks7m
_________________________

📅 Original date posted:2012-02-24
📝 Original message:OK - didn't took the weekend:

support for "port" is on github now :)

Only took two lines:

("port", value<unsigned short>(&port)->default_value(8333), "Listen on specified port for the p2p protocol")

and using the port option in the Node constructor (was there already):

Node node(chain, data_dir, args.count("nolisten") ? "" : "0.0.0.0", lexical_cast<string>(port)); // it is also here we specify the use of a proxy!

/M

On 24/02/2012, at 19:49, Martinx - ジェームズ wrote:

> Hi Michael,
>
> Thank you for your attention!
>
> Now, I'm trying to start libcoin's bitcoind using high ports but, it always try to listen at 8332, no matter what I "say"...
>
> Look:
>
> $ cat .bitcoin/bitcoin.conf
> server=1
> daemon=1
> rpcuser=libcoin
> rpcpassword=LibCoin13
> rpcport=10332
> port=10333
>
> But:
>
> /usr/local/bin/bitcoind
> Error: Address already in use
>
> terminate called after throwing an instance of 'DbException'
> what(): DbEnv::close: Invalid argument
> Aborted
>
> When I "strace it", I can see:
>
> ...
> bind(12, {sa_family=AF_INET, sin_port=htons(8333), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
> ...
>
> I already tried:
>
> /usr/local/bin/bitcoind --rpcport 10332
> /usr/local/bin/bitcoind --rpcport=10332
>
> Without success...
>
> Thanks again!
> Thiago
>
> 2012/2/24 Michael Grønager <gronager at ceptacle.com>
> Hi Thiago,
>
> Forgot to comment on the two latter:
>
> > $ bitcoind getaccountaddress ""
> > HTTP error code: 401
> > Error: couldn't parse reply from server
> >
> > $ bitcoind listaccounts
> > HTTP error code: 401
> > Error: couldn't parse reply from server
> >
>
> 401 = permission denied - you need to setup username / password either on the commandline or in the bicoin.conf file to access those commands...
>
> See in the bitcoind.cpp file for commands that you can use with and without auth...
>
> Those that contains an "auth" requires auth:
>
> server.registerMethod(method_ptr(new GetBalance(wallet)), auth);
>
> As opposed to:
>
> server.registerMethod(method_ptr(new GetInfo(node)));
>
> auth is defined by:
>
> Auth auth(rpc_user, rpc_pass); // if rpc_user and rpc_pass are not set, all authenticated methods becomes disallowed.
>
> so you just experience the case explained in the comment ;) I admit that the output could be more readable, though!
>
> /M
>
>
> >
> > Any tips?! lol
> >
> > Thanks!
> > Thiago
> >
> > 2012/2/23 Martinx - ジェームズ <thiagocmartinsc at gmail.com>
> > AWESOME!!!
> >
> > I can compile libcoin at my Ubuntu 11.10... I just need to install:
> >
> > sudo aptitude install libboost1.46-all-dev
> >
> > ...alongside with another already installed dependencies, and now it works!!
> >
> > Thank you!
> > Thiago
> >
> > 2012/2/23 Michael Grønager <gronager at ceptacle.com>
> > Hi Martinx,
> >
> > Another note:
> >
> > boost 1.42 and openssl 1.0 has a conflict (you will see it when you try to compile coinHTTP with that specific combination: sslv2 has been removed from openssl, but boost still references it.)
> >
> > You should do a :
> >
> > sudo apt-get upgrade libboost-dev-all
> >
> > to get the 1.46.1 library
> >
> > /M
> >
> >
> > On 23/02/2012, at 18:31, Martinx - ジェームズ wrote:
> >
> >> Hi Michael!
> >>
> >> Thank you for libcoin! It is a awesome evolution for Bitcoin and for the CryptoCurrencies as a hole... Thanks!!!
> >>
> >> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At this machine, I have compiled and running Bitcoin (from sources), Namecoin, Devcoin, Litecoin, IXcoin and I0coin, all from sources but, when I try to compile libcoin, I got:
> >>
> >> ----
> >> user at desk:~/libcoin$ ./configure
> >> -- The C compiler identification is GNU
> >> -- The CXX compiler identification is GNU
> >> -- Check for working C compiler: /usr/bin/gcc
> >> -- Check for working C compiler: /usr/bin/gcc -- works
> >> -- Detecting C compiler ABI info
> >> -- Detecting C compiler ABI info - done
> >> -- Check for working CXX compiler: /usr/bin/c++
> >> -- Check for working CXX compiler: /usr/bin/c++ -- works
> >> -- Detecting CXX compiler ABI info
> >> -- Detecting CXX compiler ABI info - done
> >> -- Looking for include files CMAKE_HAVE_PTHREAD_H
> >> -- Looking for include files CMAKE_HAVE_PTHREAD_H - found
> >> -- Looking for pthread_create in pthreads
> >> -- Looking for pthread_create in pthreads - not found
> >> -- Looking for pthread_create in pthread
> >> -- Looking for pthread_create in pthread - found
> >> -- Found Threads: TRUE
> >> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so
> >> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found
> >> -- Looking for gethostbyname
> >> -- Looking for gethostbyname - found
> >> -- Looking for connect
> >> -- Looking for connect - found
> >> -- Looking for remove
> >> -- Looking for remove - found
> >> -- Looking for shmat
> >> -- Looking for shmat - found
> >> -- Looking for IceConnectionNumber in ICE
> >> -- Looking for IceConnectionNumber in ICE - found
> >> -- Found X11: /usr/lib/i386-linux-gnu/libX11.so
> >> -- Boost version: 1.42.0
> >> -- Found the following Boost libraries:
> >> -- date_time
> >> -- regex
> >> -- filesystem
> >> -- system
> >> -- program_options
> >> -- thread
> >> -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so
> >> -- Looking for Q_WS_X11
> >> -- Looking for Q_WS_X11 - found
> >> -- Looking for Q_WS_WIN
> >> -- Looking for Q_WS_WIN - not found.
> >> -- Looking for Q_WS_QWS
> >> -- Looking for Q_WS_QWS - not found.
> >> -- Looking for Q_WS_MAC
> >> -- Looking for Q_WS_MAC - not found.
> >> -- Found Qt-Version 4.7.2 (using /usr/bin/qmake)
> >> -- Found wxWidgets: TRUE
> >>
> >> The build system is configured to install libraries to /usr/local/lib
> >> Your applications may not be able to find your installed libraries unless you:
> >> set your LD_LIBRARY_PATH (user specific) or
> >> update your ld.so configuration (system wide)
> >> You have an ld.so.conf.d directory on your system, so if you wish to ensure that
> >> applications find the installed libcoin libraries, system wide, you could install an
> >> libcoin specific ld.so configuration with:
> >> sudo make install_ld_conf
> >>
> >> -- Configuring done
> >> -- Generating done
> >> -- Build files have been written to: /home/user/libcoin
> >> ----
> >>
> >> Now I tried make, without success:
> >>
> >> ----
> >> .....
> >> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xf): undefined reference to `BN_init'
> >> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x1e): undefined reference to `BN_copy'
> >> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x38): undefined reference to `BN_set_negative'
> >> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x4f): undefined reference to `BN_clear_free'
> >> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xd3): undefined reference to `BN_clear_free'
> >> ../../lib/libcoin.a(Script.o): In function `operator<<(CBigNum const&, unsigned int)':
> >> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x16): undefined reference to `BN_init'
> >> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x2c): undefined reference to `BN_lshift'
> >> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0xad): undefined reference to `BN_clear_free'
> >> ../../lib/libcoin.a(Script.o): In function `operator>>(CBigNum const&, unsigned int)':
> >> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xf): undefined reference to `BN_init'
> >> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x1e): undefined reference to `BN_copy'
> >> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x47): undefined reference to `BN_clear_free'
> >> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xcb): undefined reference to `BN_clear_free'
> >> ../../lib/libcoin.a(Script.o): In function `operator!=(CBigNum const&, CBigNum const&)':
> >> Script.cpp:(.text._ZneRK7CBigNumS1_[operator!=(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
> >> ../../lib/libcoin.a(Script.o): In function `operator>(CBigNum const&, CBigNum const&)':
> >> Script.cpp:(.text._ZgtRK7CBigNumS1_[operator>(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
> >> ../../lib/libcoin.a(Script.o): In function `uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)':
> >> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0x6d): undefined reference to `SHA256'
> >> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0xb8): undefined reference to `SHA256'
> >> collect2: ld returned 1 exit status
> >> make[2]: *** [bin/bitcoind] Error 1
> >> make[1]: *** [applications/bitcoind/CMakeFiles/app_bitcoind.dir/all] Error 2
> >> make: *** [all] Error 2
> >> -----
> >>
> >> What can I do?!
> >>
> >> Best,
> >> Thiago
> >>
> >>
> >> On 1 February 2012 12:18, Michael Grønager <gronager at ceptacle.com> wrote:
> >> Dear Bitcoiners,
> >>
> >> libcoin is now in a state ready for its first release, which I would like to share with you!
> >>
> >> === libcoin is a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. ===
> >>
> >> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the first version of the crypto currency library "libcoin" based on the bitcoin/bitcoin "Satoshi" client.
> >>
> >> libcoin also maintains a version of bitcoind that is a 100% compatible drop-in replacement of the bitcoin/bitcoind client: You can use it on the same computer on the same files and you can call it with the same scripts. And you can easily extend it without touching the basic bitcoin source files.
> >>
> >> The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!
> >>
> >> In libcoin, the Satoshi client code has been completely refactored, properly encapsulating classes, removing all globals, moving from threads and mutexes to a pure asynchronous approach. Functionalities have been divided into logical units and libraries, minimizing dependencies for e.g. thin clients.
> >>
> >> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, ...) specific settings are maintained from a single class (Chain) and hence experiments with chain settings, mining, security and digital currencies for research and educational purposes are easily accessible. See the ponzicoin example for how you define your own chain.
> >>
> >> The build system of libcoin is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows.
> >>
> >> The libcoin license is LGPL v. 3. This mean that you can use it in open source as well as in commercial projects, but improvements should go back into the libcoin library.
> >>
> >> ======
> >>
> >> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
> >>
> >> Join libcoin on twitter: http://twitter.com/libcoin
> >>
> >> Download "libcoin Satoshi release": http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
> >>
> >> Best regards,
> >>
> >> Michael Gronager, PhD
> >> Director, Ceptacle
> >> Jens Juels Gade 33
> >> 2100 Copenhagen E
> >> Mobile: +45 31 45 14 01
> >> E-mail: gronager at ceptacle.com
> >> Web: http://www.ceptacle.com/
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Keep Your Developer Skills Current with LearnDevNow!
> >> The most comprehensive online learning library for Microsoft developers
> >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> >> Metro Style Apps, more. Free future releases when you subscribe now!
> >> http://p.sf.net/sfu/learndevnow-d2d
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> > Michael Gronager, PhD
> > Director, Ceptacle
> > Jens Juels Gade 33
> > 2100 Copenhagen E
> > Mobile: +45 31 45 14 01
> > E-mail: gronager at ceptacle.com
> > Web: http://www.ceptacle.com/
> >
> >
> >
>
>

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-24 📝 Original message:Just ...

2023-06-07T03:04:35Z

In reply to nevent1q…4qne
_________________________

📅 Original date posted:2012-02-24
📝 Original message:Just copied your bitcoin.conf file to my system and the server connects just fine to RPC on 10332
and I get using curl:

MacGronager:bin gronager$ curl --data-binary '{"jsonrpc": "2.0", "id":"curltest", "method": "getblockcount", "params": [] }' -H 'Content-Type: application/json' http://127.0.0.1:10332
{"jsonrpc":"2.0","result":168299,"error":null,"id":"curltest"}

Didn't do a retest on linux, but I am quite certain that it works there well as I had it running for weeks on port 9332 on amazon.

However, the "port" parameter will not work

> ...
> bind(12, {sa_family=AF_INET, sin_port=htons(8333), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
> ...

and as you can see it connects to 8333 - that for the bitcoin protocol.

I havn't implemented "port" (have a look at the possible options in bitcoind.cpp). It was not on the official help list in bitcoind 0.4.0 (see init.cpp or do a bitcoin/bitcoind -help). But, I can implement it over the weekend if your need it.

I also tested the bitcoind --rpcport=10332 and it worked too using the commandline - both running as server and client.

/M

> I already tried:
>
> /usr/local/bin/bitcoind --rpcport 10332
> /usr/local/bin/bitcoind --rpcport=10332
>
> Without success...
>
> Thanks again!
> Thiago
>
> 2012/2/24 Michael Grønager <gronager at ceptacle.com>
> Hi Thiago,
>
> Forgot to comment on the two latter:
>
> > $ bitcoind getaccountaddress ""
> > HTTP error code: 401
> > Error: couldn't parse reply from server
> >
> > $ bitcoind listaccounts
> > HTTP error code: 401
> > Error: couldn't parse reply from server
> >
>
> 401 = permission denied - you need to setup username / password either on the commandline or in the bicoin.conf file to access those commands...
>
> See in the bitcoind.cpp file for commands that you can use with and without auth...
>
> Those that contains an "auth" requires auth:
>
> server.registerMethod(method_ptr(new GetBalance(wallet)), auth);
>
> As opposed to:
>
> server.registerMethod(method_ptr(new GetInfo(node)));
>
> auth is defined by:
>
> Auth auth(rpc_user, rpc_pass); // if rpc_user and rpc_pass are not set, all authenticated methods becomes disallowed.
>
> so you just experience the case explained in the comment ;) I admit that the output could be more readable, though!
>
> /M
>
>
> >
> > Any tips?! lol
> >
> > Thanks!
> > Thiago
> >
> > 2012/2/23 Martinx - ジェームズ <thiagocmartinsc at gmail.com>
> > AWESOME!!!
> >
> > I can compile libcoin at my Ubuntu 11.10... I just need to install:
> >
> > sudo aptitude install libboost1.46-all-dev
> >
> > ...alongside with another already installed dependencies, and now it works!!
> >
> > Thank you!
> > Thiago
> >
> > 2012/2/23 Michael Grønager <gronager at ceptacle.com>
> > Hi Martinx,
> >
> > Another note:
> >
> > boost 1.42 and openssl 1.0 has a conflict (you will see it when you try to compile coinHTTP with that specific combination: sslv2 has been removed from openssl, but boost still references it.)
> >
> > You should do a :
> >
> > sudo apt-get upgrade libboost-dev-all
> >
> > to get the 1.46.1 library
> >
> > /M
> >
> >
> > On 23/02/2012, at 18:31, Martinx - ジェームズ wrote:
> >
> >> Hi Michael!
> >>
> >> Thank you for libcoin! It is a awesome evolution for Bitcoin and for the CryptoCurrencies as a hole... Thanks!!!
> >>
> >> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At this machine, I have compiled and running Bitcoin (from sources), Namecoin, Devcoin, Litecoin, IXcoin and I0coin, all from sources but, when I try to compile libcoin, I got:
> >>
> >> ----
> >> user at desk:~/libcoin$ ./configure
> >> -- The C compiler identification is GNU
> >> -- The CXX compiler identification is GNU
> >> -- Check for working C compiler: /usr/bin/gcc
> >> -- Check for working C compiler: /usr/bin/gcc -- works
> >> -- Detecting C compiler ABI info
> >> -- Detecting C compiler ABI info - done
> >> -- Check for working CXX compiler: /usr/bin/c++
> >> -- Check for working CXX compiler: /usr/bin/c++ -- works
> >> -- Detecting CXX compiler ABI info
> >> -- Detecting CXX compiler ABI info - done
> >> -- Looking for include files CMAKE_HAVE_PTHREAD_H
> >> -- Looking for include files CMAKE_HAVE_PTHREAD_H - found
> >> -- Looking for pthread_create in pthreads
> >> -- Looking for pthread_create in pthreads - not found
> >> -- Looking for pthread_create in pthread
> >> -- Looking for pthread_create in pthread - found
> >> -- Found Threads: TRUE
> >> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so
> >> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found
> >> -- Looking for gethostbyname
> >> -- Looking for gethostbyname - found
> >> -- Looking for connect
> >> -- Looking for connect - found
> >> -- Looking for remove
> >> -- Looking for remove - found
> >> -- Looking for shmat
> >> -- Looking for shmat - found
> >> -- Looking for IceConnectionNumber in ICE
> >> -- Looking for IceConnectionNumber in ICE - found
> >> -- Found X11: /usr/lib/i386-linux-gnu/libX11.so
> >> -- Boost version: 1.42.0
> >> -- Found the following Boost libraries:
> >> -- date_time
> >> -- regex
> >> -- filesystem
> >> -- system
> >> -- program_options
> >> -- thread
> >> -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so
> >> -- Looking for Q_WS_X11
> >> -- Looking for Q_WS_X11 - found
> >> -- Looking for Q_WS_WIN
> >> -- Looking for Q_WS_WIN - not found.
> >> -- Looking for Q_WS_QWS
> >> -- Looking for Q_WS_QWS - not found.
> >> -- Looking for Q_WS_MAC
> >> -- Looking for Q_WS_MAC - not found.
> >> -- Found Qt-Version 4.7.2 (using /usr/bin/qmake)
> >> -- Found wxWidgets: TRUE
> >>
> >> The build system is configured to install libraries to /usr/local/lib
> >> Your applications may not be able to find your installed libraries unless you:
> >> set your LD_LIBRARY_PATH (user specific) or
> >> update your ld.so configuration (system wide)
> >> You have an ld.so.conf.d directory on your system, so if you wish to ensure that
> >> applications find the installed libcoin libraries, system wide, you could install an
> >> libcoin specific ld.so configuration with:
> >> sudo make install_ld_conf
> >>
> >> -- Configuring done
> >> -- Generating done
> >> -- Build files have been written to: /home/user/libcoin
> >> ----
> >>
> >> Now I tried make, without success:
> >>
> >> ----
> >> .....
> >> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xf): undefined reference to `BN_init'
> >> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x1e): undefined reference to `BN_copy'
> >> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x38): undefined reference to `BN_set_negative'
> >> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x4f): undefined reference to `BN_clear_free'
> >> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xd3): undefined reference to `BN_clear_free'
> >> ../../lib/libcoin.a(Script.o): In function `operator<<(CBigNum const&, unsigned int)':
> >> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x16): undefined reference to `BN_init'
> >> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x2c): undefined reference to `BN_lshift'
> >> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0xad): undefined reference to `BN_clear_free'
> >> ../../lib/libcoin.a(Script.o): In function `operator>>(CBigNum const&, unsigned int)':
> >> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xf): undefined reference to `BN_init'
> >> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x1e): undefined reference to `BN_copy'
> >> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x47): undefined reference to `BN_clear_free'
> >> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xcb): undefined reference to `BN_clear_free'
> >> ../../lib/libcoin.a(Script.o): In function `operator!=(CBigNum const&, CBigNum const&)':
> >> Script.cpp:(.text._ZneRK7CBigNumS1_[operator!=(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
> >> ../../lib/libcoin.a(Script.o): In function `operator>(CBigNum const&, CBigNum const&)':
> >> Script.cpp:(.text._ZgtRK7CBigNumS1_[operator>(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
> >> ../../lib/libcoin.a(Script.o): In function `uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)':
> >> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0x6d): undefined reference to `SHA256'
> >> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0xb8): undefined reference to `SHA256'
> >> collect2: ld returned 1 exit status
> >> make[2]: *** [bin/bitcoind] Error 1
> >> make[1]: *** [applications/bitcoind/CMakeFiles/app_bitcoind.dir/all] Error 2
> >> make: *** [all] Error 2
> >> -----
> >>
> >> What can I do?!
> >>
> >> Best,
> >> Thiago
> >>
> >>
> >> On 1 February 2012 12:18, Michael Grønager <gronager at ceptacle.com> wrote:
> >> Dear Bitcoiners,
> >>
> >> libcoin is now in a state ready for its first release, which I would like to share with you!
> >>
> >> === libcoin is a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. ===
> >>
> >> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the first version of the crypto currency library "libcoin" based on the bitcoin/bitcoin "Satoshi" client.
> >>
> >> libcoin also maintains a version of bitcoind that is a 100% compatible drop-in replacement of the bitcoin/bitcoind client: You can use it on the same computer on the same files and you can call it with the same scripts. And you can easily extend it without touching the basic bitcoin source files.
> >>
> >> The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!
> >>
> >> In libcoin, the Satoshi client code has been completely refactored, properly encapsulating classes, removing all globals, moving from threads and mutexes to a pure asynchronous approach. Functionalities have been divided into logical units and libraries, minimizing dependencies for e.g. thin clients.
> >>
> >> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, ...) specific settings are maintained from a single class (Chain) and hence experiments with chain settings, mining, security and digital currencies for research and educational purposes are easily accessible. See the ponzicoin example for how you define your own chain.
> >>
> >> The build system of libcoin is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows.
> >>
> >> The libcoin license is LGPL v. 3. This mean that you can use it in open source as well as in commercial projects, but improvements should go back into the libcoin library.
> >>
> >> ======
> >>
> >> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
> >>
> >> Join libcoin on twitter: http://twitter.com/libcoin
> >>
> >> Download "libcoin Satoshi release": http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
> >>
> >> Best regards,
> >>
> >> Michael Gronager, PhD
> >> Director, Ceptacle
> >> Jens Juels Gade 33
> >> 2100 Copenhagen E
> >> Mobile: +45 31 45 14 01
> >> E-mail: gronager at ceptacle.com
> >> Web: http://www.ceptacle.com/
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Keep Your Developer Skills Current with LearnDevNow!
> >> The most comprehensive online learning library for Microsoft developers
> >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> >> Metro Style Apps, more. Free future releases when you subscribe now!
> >> http://p.sf.net/sfu/learndevnow-d2d
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> > Michael Gronager, PhD
> > Director, Ceptacle
> > Jens Juels Gade 33
> > 2100 Copenhagen E
> > Mobile: +45 31 45 14 01
> > E-mail: gronager at ceptacle.com
> > Web: http://www.ceptacle.com/
> >
> >
> >
>
>

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-24 📝 Original message:Hi ...

2023-06-07T03:04:28Z

In reply to nevent1q…77ht
_________________________

📅 Original date posted:2012-02-24
📝 Original message:Hi Thiago,

Forgot to comment on the two latter:

> $ bitcoind getaccountaddress ""
> HTTP error code: 401
> Error: couldn't parse reply from server
>
> $ bitcoind listaccounts
> HTTP error code: 401
> Error: couldn't parse reply from server
>

401 = permission denied - you need to setup username / password either on the commandline or in the bicoin.conf file to access those commands...

See in the bitcoind.cpp file for commands that you can use with and without auth...

Those that contains an "auth" requires auth:

server.registerMethod(method_ptr(new GetBalance(wallet)), auth);

As opposed to:

server.registerMethod(method_ptr(new GetInfo(node)));

auth is defined by:

Auth auth(rpc_user, rpc_pass); // if rpc_user and rpc_pass are not set, all authenticated methods becomes disallowed.

so you just experience the case explained in the comment ;) I admit that the output could be more readable, though!

/M

>
> Any tips?! lol
>
> Thanks!
> Thiago
>
> 2012/2/23 Martinx - ジェームズ <thiagocmartinsc at gmail.com>
> AWESOME!!!
>
> I can compile libcoin at my Ubuntu 11.10... I just need to install:
>
> sudo aptitude install libboost1.46-all-dev
>
> ...alongside with another already installed dependencies, and now it works!!
>
> Thank you!
> Thiago
>
> 2012/2/23 Michael Grønager <gronager at ceptacle.com>
> Hi Martinx,
>
> Another note:
>
> boost 1.42 and openssl 1.0 has a conflict (you will see it when you try to compile coinHTTP with that specific combination: sslv2 has been removed from openssl, but boost still references it.)
>
> You should do a :
>
> sudo apt-get upgrade libboost-dev-all
>
> to get the 1.46.1 library
>
> /M
>
>
> On 23/02/2012, at 18:31, Martinx - ジェームズ wrote:
>
>> Hi Michael!
>>
>> Thank you for libcoin! It is a awesome evolution for Bitcoin and for the CryptoCurrencies as a hole... Thanks!!!
>>
>> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At this machine, I have compiled and running Bitcoin (from sources), Namecoin, Devcoin, Litecoin, IXcoin and I0coin, all from sources but, when I try to compile libcoin, I got:
>>
>> ----
>> user at desk:~/libcoin$ ./configure
>> -- The C compiler identification is GNU
>> -- The CXX compiler identification is GNU
>> -- Check for working C compiler: /usr/bin/gcc
>> -- Check for working C compiler: /usr/bin/gcc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Check for working CXX compiler: /usr/bin/c++
>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Looking for include files CMAKE_HAVE_PTHREAD_H
>> -- Looking for include files CMAKE_HAVE_PTHREAD_H - found
>> -- Looking for pthread_create in pthreads
>> -- Looking for pthread_create in pthreads - not found
>> -- Looking for pthread_create in pthread
>> -- Looking for pthread_create in pthread - found
>> -- Found Threads: TRUE
>> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so
>> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found
>> -- Looking for gethostbyname
>> -- Looking for gethostbyname - found
>> -- Looking for connect
>> -- Looking for connect - found
>> -- Looking for remove
>> -- Looking for remove - found
>> -- Looking for shmat
>> -- Looking for shmat - found
>> -- Looking for IceConnectionNumber in ICE
>> -- Looking for IceConnectionNumber in ICE - found
>> -- Found X11: /usr/lib/i386-linux-gnu/libX11.so
>> -- Boost version: 1.42.0
>> -- Found the following Boost libraries:
>> -- date_time
>> -- regex
>> -- filesystem
>> -- system
>> -- program_options
>> -- thread
>> -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so
>> -- Looking for Q_WS_X11
>> -- Looking for Q_WS_X11 - found
>> -- Looking for Q_WS_WIN
>> -- Looking for Q_WS_WIN - not found.
>> -- Looking for Q_WS_QWS
>> -- Looking for Q_WS_QWS - not found.
>> -- Looking for Q_WS_MAC
>> -- Looking for Q_WS_MAC - not found.
>> -- Found Qt-Version 4.7.2 (using /usr/bin/qmake)
>> -- Found wxWidgets: TRUE
>>
>> The build system is configured to install libraries to /usr/local/lib
>> Your applications may not be able to find your installed libraries unless you:
>> set your LD_LIBRARY_PATH (user specific) or
>> update your ld.so configuration (system wide)
>> You have an ld.so.conf.d directory on your system, so if you wish to ensure that
>> applications find the installed libcoin libraries, system wide, you could install an
>> libcoin specific ld.so configuration with:
>> sudo make install_ld_conf
>>
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: /home/user/libcoin
>> ----
>>
>> Now I tried make, without success:
>>
>> ----
>> .....
>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xf): undefined reference to `BN_init'
>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x1e): undefined reference to `BN_copy'
>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x38): undefined reference to `BN_set_negative'
>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x4f): undefined reference to `BN_clear_free'
>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xd3): undefined reference to `BN_clear_free'
>> ../../lib/libcoin.a(Script.o): In function `operator<<(CBigNum const&, unsigned int)':
>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x16): undefined reference to `BN_init'
>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x2c): undefined reference to `BN_lshift'
>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0xad): undefined reference to `BN_clear_free'
>> ../../lib/libcoin.a(Script.o): In function `operator>>(CBigNum const&, unsigned int)':
>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xf): undefined reference to `BN_init'
>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x1e): undefined reference to `BN_copy'
>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x47): undefined reference to `BN_clear_free'
>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xcb): undefined reference to `BN_clear_free'
>> ../../lib/libcoin.a(Script.o): In function `operator!=(CBigNum const&, CBigNum const&)':
>> Script.cpp:(.text._ZneRK7CBigNumS1_[operator!=(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
>> ../../lib/libcoin.a(Script.o): In function `operator>(CBigNum const&, CBigNum const&)':
>> Script.cpp:(.text._ZgtRK7CBigNumS1_[operator>(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
>> ../../lib/libcoin.a(Script.o): In function `uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)':
>> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0x6d): undefined reference to `SHA256'
>> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0xb8): undefined reference to `SHA256'
>> collect2: ld returned 1 exit status
>> make[2]: *** [bin/bitcoind] Error 1
>> make[1]: *** [applications/bitcoind/CMakeFiles/app_bitcoind.dir/all] Error 2
>> make: *** [all] Error 2
>> -----
>>
>> What can I do?!
>>
>> Best,
>> Thiago
>>
>>
>> On 1 February 2012 12:18, Michael Grønager <gronager at ceptacle.com> wrote:
>> Dear Bitcoiners,
>>
>> libcoin is now in a state ready for its first release, which I would like to share with you!
>>
>> === libcoin is a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. ===
>>
>> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the first version of the crypto currency library "libcoin" based on the bitcoin/bitcoin "Satoshi" client.
>>
>> libcoin also maintains a version of bitcoind that is a 100% compatible drop-in replacement of the bitcoin/bitcoind client: You can use it on the same computer on the same files and you can call it with the same scripts. And you can easily extend it without touching the basic bitcoin source files.
>>
>> The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!
>>
>> In libcoin, the Satoshi client code has been completely refactored, properly encapsulating classes, removing all globals, moving from threads and mutexes to a pure asynchronous approach. Functionalities have been divided into logical units and libraries, minimizing dependencies for e.g. thin clients.
>>
>> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, ...) specific settings are maintained from a single class (Chain) and hence experiments with chain settings, mining, security and digital currencies for research and educational purposes are easily accessible. See the ponzicoin example for how you define your own chain.
>>
>> The build system of libcoin is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows.
>>
>> The libcoin license is LGPL v. 3. This mean that you can use it in open source as well as in commercial projects, but improvements should go back into the libcoin library.
>>
>> ======
>>
>> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
>>
>> Join libcoin on twitter: http://twitter.com/libcoin
>>
>> Download "libcoin Satoshi release": http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
>>
>> Best regards,
>>
>> Michael Gronager, PhD
>> Director, Ceptacle
>> Jens Juels Gade 33
>> 2100 Copenhagen E
>> Mobile: +45 31 45 14 01
>> E-mail: gronager at ceptacle.com
>> Web: http://www.ceptacle.com/
>>
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
> Michael Gronager, PhD
> Director, Ceptacle
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 45 14 01
> E-mail: gronager at ceptacle.com
> Web: http://www.ceptacle.com/
>
>
>

📅 Original date posted:2012-02-24 📝 Original message:Hi ...

2023-06-07T03:04:24Z

In reply to nevent1q…s94c
_________________________

📅 Original date posted:2012-02-24
📝 Original message:Hi Thiago

I had in mind using the JSON RPC 2.0 system.description standard command instead of help, but I got sidetracked implementing it. Will look into it asap. Thanks for noting!

/M

On 24/02/2012, at 03:17, Martinx - ジェームズ wrote:

> Hi Michael!
>
> I just run "bitcoind", from libcoin ("sudo make install") sources, with empty ~/.bitcoin directory and:
>
> Terminal 1: bitcoind # apparently okay
>
> Terminal 2:
>
> $ bitcoind getinfo # okay
> {
> "version" : 40001,
> "blocks" : 57733,
> "connections" : 8,
> "difficulty" : 11.84622815,
> "testnet" : false
> }
>
> # sleep a couple minutes
>
> $ bitcoind getinfo # ok
> {
> "version" : 40001,
> "blocks" : 67527,
> "connections" : 8,
> "difficulty" : 45.38582234,
> "testnet" : false
> }
>
>
> But...
>
>
> $ bitcoind help
> HTTP error code: 404
> JSON RPC Error code: -36001
> Method not found.
>
> $ bitcoind getaccountaddress ""
> HTTP error code: 401
> Error: couldn't parse reply from server
>
> $ bitcoind listaccounts
> HTTP error code: 401
> Error: couldn't parse reply from server
>
>
> Any tips?! lol
>
> Thanks!
> Thiago
>
> 2012/2/23 Martinx - ジェームズ <thiagocmartinsc at gmail.com>
> AWESOME!!!
>
> I can compile libcoin at my Ubuntu 11.10... I just need to install:
>
> sudo aptitude install libboost1.46-all-dev
>
> ...alongside with another already installed dependencies, and now it works!!
>
> Thank you!
> Thiago
>
> 2012/2/23 Michael Grønager <gronager at ceptacle.com>
> Hi Martinx,
>
> Another note:
>
> boost 1.42 and openssl 1.0 has a conflict (you will see it when you try to compile coinHTTP with that specific combination: sslv2 has been removed from openssl, but boost still references it.)
>
> You should do a :
>
> sudo apt-get upgrade libboost-dev-all
>
> to get the 1.46.1 library
>
> /M
>
>
> On 23/02/2012, at 18:31, Martinx - ジェームズ wrote:
>
>> Hi Michael!
>>
>> Thank you for libcoin! It is a awesome evolution for Bitcoin and for the CryptoCurrencies as a hole... Thanks!!!
>>
>> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At this machine, I have compiled and running Bitcoin (from sources), Namecoin, Devcoin, Litecoin, IXcoin and I0coin, all from sources but, when I try to compile libcoin, I got:
>>
>> ----
>> user at desk:~/libcoin$ ./configure
>> -- The C compiler identification is GNU
>> -- The CXX compiler identification is GNU
>> -- Check for working C compiler: /usr/bin/gcc
>> -- Check for working C compiler: /usr/bin/gcc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Check for working CXX compiler: /usr/bin/c++
>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Looking for include files CMAKE_HAVE_PTHREAD_H
>> -- Looking for include files CMAKE_HAVE_PTHREAD_H - found
>> -- Looking for pthread_create in pthreads
>> -- Looking for pthread_create in pthreads - not found
>> -- Looking for pthread_create in pthread
>> -- Looking for pthread_create in pthread - found
>> -- Found Threads: TRUE
>> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so
>> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found
>> -- Looking for gethostbyname
>> -- Looking for gethostbyname - found
>> -- Looking for connect
>> -- Looking for connect - found
>> -- Looking for remove
>> -- Looking for remove - found
>> -- Looking for shmat
>> -- Looking for shmat - found
>> -- Looking for IceConnectionNumber in ICE
>> -- Looking for IceConnectionNumber in ICE - found
>> -- Found X11: /usr/lib/i386-linux-gnu/libX11.so
>> -- Boost version: 1.42.0
>> -- Found the following Boost libraries:
>> -- date_time
>> -- regex
>> -- filesystem
>> -- system
>> -- program_options
>> -- thread
>> -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so
>> -- Looking for Q_WS_X11
>> -- Looking for Q_WS_X11 - found
>> -- Looking for Q_WS_WIN
>> -- Looking for Q_WS_WIN - not found.
>> -- Looking for Q_WS_QWS
>> -- Looking for Q_WS_QWS - not found.
>> -- Looking for Q_WS_MAC
>> -- Looking for Q_WS_MAC - not found.
>> -- Found Qt-Version 4.7.2 (using /usr/bin/qmake)
>> -- Found wxWidgets: TRUE
>>
>> The build system is configured to install libraries to /usr/local/lib
>> Your applications may not be able to find your installed libraries unless you:
>> set your LD_LIBRARY_PATH (user specific) or
>> update your ld.so configuration (system wide)
>> You have an ld.so.conf.d directory on your system, so if you wish to ensure that
>> applications find the installed libcoin libraries, system wide, you could install an
>> libcoin specific ld.so configuration with:
>> sudo make install_ld_conf
>>
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: /home/user/libcoin
>> ----
>>
>> Now I tried make, without success:
>>
>> ----
>> .....
>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xf): undefined reference to `BN_init'
>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x1e): undefined reference to `BN_copy'
>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x38): undefined reference to `BN_set_negative'
>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x4f): undefined reference to `BN_clear_free'
>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xd3): undefined reference to `BN_clear_free'
>> ../../lib/libcoin.a(Script.o): In function `operator<<(CBigNum const&, unsigned int)':
>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x16): undefined reference to `BN_init'
>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x2c): undefined reference to `BN_lshift'
>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0xad): undefined reference to `BN_clear_free'
>> ../../lib/libcoin.a(Script.o): In function `operator>>(CBigNum const&, unsigned int)':
>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xf): undefined reference to `BN_init'
>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x1e): undefined reference to `BN_copy'
>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x47): undefined reference to `BN_clear_free'
>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xcb): undefined reference to `BN_clear_free'
>> ../../lib/libcoin.a(Script.o): In function `operator!=(CBigNum const&, CBigNum const&)':
>> Script.cpp:(.text._ZneRK7CBigNumS1_[operator!=(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
>> ../../lib/libcoin.a(Script.o): In function `operator>(CBigNum const&, CBigNum const&)':
>> Script.cpp:(.text._ZgtRK7CBigNumS1_[operator>(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
>> ../../lib/libcoin.a(Script.o): In function `uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)':
>> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0x6d): undefined reference to `SHA256'
>> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0xb8): undefined reference to `SHA256'
>> collect2: ld returned 1 exit status
>> make[2]: *** [bin/bitcoind] Error 1
>> make[1]: *** [applications/bitcoind/CMakeFiles/app_bitcoind.dir/all] Error 2
>> make: *** [all] Error 2
>> -----
>>
>> What can I do?!
>>
>> Best,
>> Thiago
>>
>>
>> On 1 February 2012 12:18, Michael Grønager <gronager at ceptacle.com> wrote:
>> Dear Bitcoiners,
>>
>> libcoin is now in a state ready for its first release, which I would like to share with you!
>>
>> === libcoin is a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. ===
>>
>> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the first version of the crypto currency library "libcoin" based on the bitcoin/bitcoin "Satoshi" client.
>>
>> libcoin also maintains a version of bitcoind that is a 100% compatible drop-in replacement of the bitcoin/bitcoind client: You can use it on the same computer on the same files and you can call it with the same scripts. And you can easily extend it without touching the basic bitcoin source files.
>>
>> The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!
>>
>> In libcoin, the Satoshi client code has been completely refactored, properly encapsulating classes, removing all globals, moving from threads and mutexes to a pure asynchronous approach. Functionalities have been divided into logical units and libraries, minimizing dependencies for e.g. thin clients.
>>
>> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, ...) specific settings are maintained from a single class (Chain) and hence experiments with chain settings, mining, security and digital currencies for research and educational purposes are easily accessible. See the ponzicoin example for how you define your own chain.
>>
>> The build system of libcoin is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows.
>>
>> The libcoin license is LGPL v. 3. This mean that you can use it in open source as well as in commercial projects, but improvements should go back into the libcoin library.
>>
>> ======
>>
>> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
>>
>> Join libcoin on twitter: http://twitter.com/libcoin
>>
>> Download "libcoin Satoshi release": http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
>>
>> Best regards,
>>
>> Michael Gronager, PhD
>> Director, Ceptacle
>> Jens Juels Gade 33
>> 2100 Copenhagen E
>> Mobile: +45 31 45 14 01
>> E-mail: gronager at ceptacle.com
>> Web: http://www.ceptacle.com/
>>
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
> Michael Gronager, PhD
> Director, Ceptacle
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 45 14 01
> E-mail: gronager at ceptacle.com
> Web: http://www.ceptacle.com/
>
>
>

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-23 📝 Original message:Hi ...

2023-06-07T03:04:14Z

In reply to nevent1q…fda8
_________________________

📅 Original date posted:2012-02-23
📝 Original message:Hi Martinx,

Another note:

boost 1.42 and openssl 1.0 has a conflict (you will see it when you try to compile coinHTTP with that specific combination: sslv2 has been removed from openssl, but boost still references it.)

You should do a :

sudo apt-get upgrade libboost-dev-all

to get the 1.46.1 library

/M

On 23/02/2012, at 18:31, Martinx - ジェームズ wrote:

> Hi Michael!
>
> Thank you for libcoin! It is a awesome evolution for Bitcoin and for the CryptoCurrencies as a hole... Thanks!!!
>
> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At this machine, I have compiled and running Bitcoin (from sources), Namecoin, Devcoin, Litecoin, IXcoin and I0coin, all from sources but, when I try to compile libcoin, I got:
>
> ----
> user at desk:~/libcoin$ ./configure
> -- The C compiler identification is GNU
> -- The CXX compiler identification is GNU
> -- Check for working C compiler: /usr/bin/gcc
> -- Check for working C compiler: /usr/bin/gcc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Looking for include files CMAKE_HAVE_PTHREAD_H
> -- Looking for include files CMAKE_HAVE_PTHREAD_H - found
> -- Looking for pthread_create in pthreads
> -- Looking for pthread_create in pthreads - not found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - found
> -- Found Threads: TRUE
> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so
> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found
> -- Looking for gethostbyname
> -- Looking for gethostbyname - found
> -- Looking for connect
> -- Looking for connect - found
> -- Looking for remove
> -- Looking for remove - found
> -- Looking for shmat
> -- Looking for shmat - found
> -- Looking for IceConnectionNumber in ICE
> -- Looking for IceConnectionNumber in ICE - found
> -- Found X11: /usr/lib/i386-linux-gnu/libX11.so
> -- Boost version: 1.42.0
> -- Found the following Boost libraries:
> -- date_time
> -- regex
> -- filesystem
> -- system
> -- program_options
> -- thread
> -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so
> -- Looking for Q_WS_X11
> -- Looking for Q_WS_X11 - found
> -- Looking for Q_WS_WIN
> -- Looking for Q_WS_WIN - not found.
> -- Looking for Q_WS_QWS
> -- Looking for Q_WS_QWS - not found.
> -- Looking for Q_WS_MAC
> -- Looking for Q_WS_MAC - not found.
> -- Found Qt-Version 4.7.2 (using /usr/bin/qmake)
> -- Found wxWidgets: TRUE
>
> The build system is configured to install libraries to /usr/local/lib
> Your applications may not be able to find your installed libraries unless you:
> set your LD_LIBRARY_PATH (user specific) or
> update your ld.so configuration (system wide)
> You have an ld.so.conf.d directory on your system, so if you wish to ensure that
> applications find the installed libcoin libraries, system wide, you could install an
> libcoin specific ld.so configuration with:
> sudo make install_ld_conf
>
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/user/libcoin
> ----
>
> Now I tried make, without success:
>
> ----
> .....
> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xf): undefined reference to `BN_init'
> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x1e): undefined reference to `BN_copy'
> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x38): undefined reference to `BN_set_negative'
> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x4f): undefined reference to `BN_clear_free'
> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xd3): undefined reference to `BN_clear_free'
> ../../lib/libcoin.a(Script.o): In function `operator<<(CBigNum const&, unsigned int)':
> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x16): undefined reference to `BN_init'
> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x2c): undefined reference to `BN_lshift'
> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0xad): undefined reference to `BN_clear_free'
> ../../lib/libcoin.a(Script.o): In function `operator>>(CBigNum const&, unsigned int)':
> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xf): undefined reference to `BN_init'
> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x1e): undefined reference to `BN_copy'
> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x47): undefined reference to `BN_clear_free'
> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xcb): undefined reference to `BN_clear_free'
> ../../lib/libcoin.a(Script.o): In function `operator!=(CBigNum const&, CBigNum const&)':
> Script.cpp:(.text._ZneRK7CBigNumS1_[operator!=(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
> ../../lib/libcoin.a(Script.o): In function `operator>(CBigNum const&, CBigNum const&)':
> Script.cpp:(.text._ZgtRK7CBigNumS1_[operator>(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
> ../../lib/libcoin.a(Script.o): In function `uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)':
> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0x6d): undefined reference to `SHA256'
> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0xb8): undefined reference to `SHA256'
> collect2: ld returned 1 exit status
> make[2]: *** [bin/bitcoind] Error 1
> make[1]: *** [applications/bitcoind/CMakeFiles/app_bitcoind.dir/all] Error 2
> make: *** [all] Error 2
> -----
>
> What can I do?!
>
> Best,
> Thiago
>
>
> On 1 February 2012 12:18, Michael Grønager <gronager at ceptacle.com> wrote:
> Dear Bitcoiners,
>
> libcoin is now in a state ready for its first release, which I would like to share with you!
>
> === libcoin is a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. ===
>
> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the first version of the crypto currency library "libcoin" based on the bitcoin/bitcoin "Satoshi" client.
>
> libcoin also maintains a version of bitcoind that is a 100% compatible drop-in replacement of the bitcoin/bitcoind client: You can use it on the same computer on the same files and you can call it with the same scripts. And you can easily extend it without touching the basic bitcoin source files.
>
> The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!
>
> In libcoin, the Satoshi client code has been completely refactored, properly encapsulating classes, removing all globals, moving from threads and mutexes to a pure asynchronous approach. Functionalities have been divided into logical units and libraries, minimizing dependencies for e.g. thin clients.
>
> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, ...) specific settings are maintained from a single class (Chain) and hence experiments with chain settings, mining, security and digital currencies for research and educational purposes are easily accessible. See the ponzicoin example for how you define your own chain.
>
> The build system of libcoin is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows.
>
> The libcoin license is LGPL v. 3. This mean that you can use it in open source as well as in commercial projects, but improvements should go back into the libcoin library.
>
> ======
>
> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
>
> Join libcoin on twitter: http://twitter.com/libcoin
>
> Download "libcoin Satoshi release": http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
>
> Best regards,
>
> Michael Gronager, PhD
> Director, Ceptacle
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 45 14 01
> E-mail: gronager at ceptacle.com
> Web: http://www.ceptacle.com/
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-23 📝 Original message:I ...

2023-06-07T03:04:10Z

In reply to nevent1q…gmym
_________________________

📅 Original date posted:2012-02-23
📝 Original message:I tried on another 11.10 machine with the normal boost 1.42 and things also worked as they should.

However, I noticed a difference between your cmake output and mine:

> -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so

-- Found OpenSSL: /usr/lib/i386-linux-gnu/libssl.so;/usr/lib/i386-linux-gnu/libcrypto.so (found version "1..")

Are you sure that the openssl libraries/includes found are the correct ones ? cmake finds your openssl libraries at /usr/lib/ which most likely will make it think that the includes are at /usr/include. I can see that at least X11 stuff is in /usr/lib/x386-linux-gnu like my openssl.

Could there be an issue there ?

SHA256 would normally be found in openssl/sha.h but if that is somehow corrupt ?

Cheers,

M

PS: to get more debug output, please try a "make VERBOSE=1" That will show what g++ flags that are used, and might help us.

On 23/02/2012, at 18:31, Martinx - ジェームズ wrote:

> Hi Michael!
>
> Thank you for libcoin! It is a awesome evolution for Bitcoin and for the CryptoCurrencies as a hole... Thanks!!!
>
> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At this machine, I have compiled and running Bitcoin (from sources), Namecoin, Devcoin, Litecoin, IXcoin and I0coin, all from sources but, when I try to compile libcoin, I got:
>
> ----
> user at desk:~/libcoin$ ./configure
> -- The C compiler identification is GNU
> -- The CXX compiler identification is GNU
> -- Check for working C compiler: /usr/bin/gcc
> -- Check for working C compiler: /usr/bin/gcc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Looking for include files CMAKE_HAVE_PTHREAD_H
> -- Looking for include files CMAKE_HAVE_PTHREAD_H - found
> -- Looking for pthread_create in pthreads
> -- Looking for pthread_create in pthreads - not found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - found
> -- Found Threads: TRUE
> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so
> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found
> -- Looking for gethostbyname
> -- Looking for gethostbyname - found
> -- Looking for connect
> -- Looking for connect - found
> -- Looking for remove
> -- Looking for remove - found
> -- Looking for shmat
> -- Looking for shmat - found
> -- Looking for IceConnectionNumber in ICE
> -- Looking for IceConnectionNumber in ICE - found
> -- Found X11: /usr/lib/i386-linux-gnu/libX11.so
> -- Boost version: 1.42.0
> -- Found the following Boost libraries:
> -- date_time
> -- regex
> -- filesystem
> -- system
> -- program_options
> -- thread
> -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so
> -- Looking for Q_WS_X11
> -- Looking for Q_WS_X11 - found
> -- Looking for Q_WS_WIN
> -- Looking for Q_WS_WIN - not found.
> -- Looking for Q_WS_QWS
> -- Looking for Q_WS_QWS - not found.
> -- Looking for Q_WS_MAC
> -- Looking for Q_WS_MAC - not found.
> -- Found Qt-Version 4.7.2 (using /usr/bin/qmake)
> -- Found wxWidgets: TRUE
>
> The build system is configured to install libraries to /usr/local/lib
> Your applications may not be able to find your installed libraries unless you:
> set your LD_LIBRARY_PATH (user specific) or
> update your ld.so configuration (system wide)
> You have an ld.so.conf.d directory on your system, so if you wish to ensure that
> applications find the installed libcoin libraries, system wide, you could install an
> libcoin specific ld.so configuration with:
> sudo make install_ld_conf
>
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/user/libcoin
> ----
>
> Now I tried make, without success:
>
> ----
> .....
> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xf): undefined reference to `BN_init'
> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x1e): undefined reference to `BN_copy'
> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x38): undefined reference to `BN_set_negative'
> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x4f): undefined reference to `BN_clear_free'
> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xd3): undefined reference to `BN_clear_free'
> ../../lib/libcoin.a(Script.o): In function `operator<<(CBigNum const&, unsigned int)':
> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x16): undefined reference to `BN_init'
> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x2c): undefined reference to `BN_lshift'
> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0xad): undefined reference to `BN_clear_free'
> ../../lib/libcoin.a(Script.o): In function `operator>>(CBigNum const&, unsigned int)':
> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xf): undefined reference to `BN_init'
> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x1e): undefined reference to `BN_copy'
> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x47): undefined reference to `BN_clear_free'
> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xcb): undefined reference to `BN_clear_free'
> ../../lib/libcoin.a(Script.o): In function `operator!=(CBigNum const&, CBigNum const&)':
> Script.cpp:(.text._ZneRK7CBigNumS1_[operator!=(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
> ../../lib/libcoin.a(Script.o): In function `operator>(CBigNum const&, CBigNum const&)':
> Script.cpp:(.text._ZgtRK7CBigNumS1_[operator>(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
> ../../lib/libcoin.a(Script.o): In function `uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)':
> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0x6d): undefined reference to `SHA256'
> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0xb8): undefined reference to `SHA256'
> collect2: ld returned 1 exit status
> make[2]: *** [bin/bitcoind] Error 1
> make[1]: *** [applications/bitcoind/CMakeFiles/app_bitcoind.dir/all] Error 2
> make: *** [all] Error 2
> -----
>
> What can I do?!
>
> Best,
> Thiago
>
>
> On 1 February 2012 12:18, Michael Grønager <gronager at ceptacle.com> wrote:
> Dear Bitcoiners,
>
> libcoin is now in a state ready for its first release, which I would like to share with you!
>
> === libcoin is a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. ===
>
> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the first version of the crypto currency library "libcoin" based on the bitcoin/bitcoin "Satoshi" client.
>
> libcoin also maintains a version of bitcoind that is a 100% compatible drop-in replacement of the bitcoin/bitcoind client: You can use it on the same computer on the same files and you can call it with the same scripts. And you can easily extend it without touching the basic bitcoin source files.
>
> The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!
>
> In libcoin, the Satoshi client code has been completely refactored, properly encapsulating classes, removing all globals, moving from threads and mutexes to a pure asynchronous approach. Functionalities have been divided into logical units and libraries, minimizing dependencies for e.g. thin clients.
>
> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, ...) specific settings are maintained from a single class (Chain) and hence experiments with chain settings, mining, security and digital currencies for research and educational purposes are easily accessible. See the ponzicoin example for how you define your own chain.
>
> The build system of libcoin is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows.
>
> The libcoin license is LGPL v. 3. This mean that you can use it in open source as well as in commercial projects, but improvements should go back into the libcoin library.
>
> ======
>
> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
>
> Join libcoin on twitter: http://twitter.com/libcoin
>
> Download "libcoin Satoshi release": http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
>
> Best regards,
>
> Michael Gronager, PhD
> Director, Ceptacle
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 45 14 01
> E-mail: gronager at ceptacle.com
> Web: http://www.ceptacle.com/
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-23 📝 Original message:Hi ...

2023-06-07T03:04:06Z

In reply to nevent1q…kez2
_________________________

📅 Original date posted:2012-02-23
📝 Original message:Hi Martinx,

I am looking into it now - I just tried on my Ubuntu 11.10 - I got by Script.cpp with no problems.

I have Boost 1.48.1, but I can't see that causing the issue - I will retry with a cleaner machine...

/M

On 23/02/2012, at 18:31, Martinx - ジェームズ wrote:

> Hi Michael!
>
> Thank you for libcoin! It is a awesome evolution for Bitcoin and for the CryptoCurrencies as a hole... Thanks!!!
>
> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At this machine, I have compiled and running Bitcoin (from sources), Namecoin, Devcoin, Litecoin, IXcoin and I0coin, all from sources but, when I try to compile libcoin, I got:
>
> ----
> user at desk:~/libcoin$ ./configure
> -- The C compiler identification is GNU
> -- The CXX compiler identification is GNU
> -- Check for working C compiler: /usr/bin/gcc
> -- Check for working C compiler: /usr/bin/gcc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Looking for include files CMAKE_HAVE_PTHREAD_H
> -- Looking for include files CMAKE_HAVE_PTHREAD_H - found
> -- Looking for pthread_create in pthreads
> -- Looking for pthread_create in pthreads - not found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - found
> -- Found Threads: TRUE
> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so
> -- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found
> -- Looking for gethostbyname
> -- Looking for gethostbyname - found
> -- Looking for connect
> -- Looking for connect - found
> -- Looking for remove
> -- Looking for remove - found
> -- Looking for shmat
> -- Looking for shmat - found
> -- Looking for IceConnectionNumber in ICE
> -- Looking for IceConnectionNumber in ICE - found
> -- Found X11: /usr/lib/i386-linux-gnu/libX11.so
> -- Boost version: 1.42.0
> -- Found the following Boost libraries:
> -- date_time
> -- regex
> -- filesystem
> -- system
> -- program_options
> -- thread
> -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so
> -- Looking for Q_WS_X11
> -- Looking for Q_WS_X11 - found
> -- Looking for Q_WS_WIN
> -- Looking for Q_WS_WIN - not found.
> -- Looking for Q_WS_QWS
> -- Looking for Q_WS_QWS - not found.
> -- Looking for Q_WS_MAC
> -- Looking for Q_WS_MAC - not found.
> -- Found Qt-Version 4.7.2 (using /usr/bin/qmake)
> -- Found wxWidgets: TRUE
>
> The build system is configured to install libraries to /usr/local/lib
> Your applications may not be able to find your installed libraries unless you:
> set your LD_LIBRARY_PATH (user specific) or
> update your ld.so configuration (system wide)
> You have an ld.so.conf.d directory on your system, so if you wish to ensure that
> applications find the installed libcoin libraries, system wide, you could install an
> libcoin specific ld.so configuration with:
> sudo make install_ld_conf
>
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/user/libcoin
> ----
>
> Now I tried make, without success:
>
> ----
> .....
> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xf): undefined reference to `BN_init'
> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x1e): undefined reference to `BN_copy'
> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x38): undefined reference to `BN_set_negative'
> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x4f): undefined reference to `BN_clear_free'
> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xd3): undefined reference to `BN_clear_free'
> ../../lib/libcoin.a(Script.o): In function `operator<<(CBigNum const&, unsigned int)':
> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x16): undefined reference to `BN_init'
> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0x2c): undefined reference to `BN_lshift'
> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned int)]+0xad): undefined reference to `BN_clear_free'
> ../../lib/libcoin.a(Script.o): In function `operator>>(CBigNum const&, unsigned int)':
> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xf): undefined reference to `BN_init'
> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x1e): undefined reference to `BN_copy'
> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0x47): undefined reference to `BN_clear_free'
> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned int)]+0xcb): undefined reference to `BN_clear_free'
> ../../lib/libcoin.a(Script.o): In function `operator!=(CBigNum const&, CBigNum const&)':
> Script.cpp:(.text._ZneRK7CBigNumS1_[operator!=(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
> ../../lib/libcoin.a(Script.o): In function `operator>(CBigNum const&, CBigNum const&)':
> Script.cpp:(.text._ZgtRK7CBigNumS1_[operator>(CBigNum const&, CBigNum const&)]+0x14): undefined reference to `BN_cmp'
> ../../lib/libcoin.a(Script.o): In function `uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)':
> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0x6d): undefined reference to `SHA256'
> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256 Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > > >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >)]+0xb8): undefined reference to `SHA256'
> collect2: ld returned 1 exit status
> make[2]: *** [bin/bitcoind] Error 1
> make[1]: *** [applications/bitcoind/CMakeFiles/app_bitcoind.dir/all] Error 2
> make: *** [all] Error 2
> -----
>
> What can I do?!
>
> Best,
> Thiago
>
>
> On 1 February 2012 12:18, Michael Grønager <gronager at ceptacle.com> wrote:
> Dear Bitcoiners,
>
> libcoin is now in a state ready for its first release, which I would like to share with you!
>
> === libcoin is a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. ===
>
> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the first version of the crypto currency library "libcoin" based on the bitcoin/bitcoin "Satoshi" client.
>
> libcoin also maintains a version of bitcoind that is a 100% compatible drop-in replacement of the bitcoin/bitcoind client: You can use it on the same computer on the same files and you can call it with the same scripts. And you can easily extend it without touching the basic bitcoin source files.
>
> The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!
>
> In libcoin, the Satoshi client code has been completely refactored, properly encapsulating classes, removing all globals, moving from threads and mutexes to a pure asynchronous approach. Functionalities have been divided into logical units and libraries, minimizing dependencies for e.g. thin clients.
>
> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, ...) specific settings are maintained from a single class (Chain) and hence experiments with chain settings, mining, security and digital currencies for research and educational purposes are easily accessible. See the ponzicoin example for how you define your own chain.
>
> The build system of libcoin is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows.
>
> The libcoin license is LGPL v. 3. This mean that you can use it in open source as well as in commercial projects, but improvements should go back into the libcoin library.
>
> ======
>
> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
>
> Join libcoin on twitter: http://twitter.com/libcoin
>
> Download "libcoin Satoshi release": http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
>
> Best regards,
>
> Michael Gronager, PhD
> Director, Ceptacle
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 45 14 01
> E-mail: gronager at ceptacle.com
> Web: http://www.ceptacle.com/
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-01 📝 Original message:In the ...

2023-06-07T03:04:00Z

In reply to nevent1q…4uxh
_________________________

📅 Original date posted:2012-02-01
📝 Original message:In the CMakeLists.txt file in the libcoin root find the lines regarding Boost - it says

... 1.48 ...

Change that to 1.47 and try again. I suggest you first remove your CMakeCache.txt though...

(the Qt stuff is most likely not the culprit)

/M

On 01/02/2012, at 18:37, Luke-Jr wrote:

> On Wednesday, February 01, 2012 11:20:22 AM Michael Grønager wrote:
>> OK - from your path it looks like linux. What version of Boost do you use.
>> I require 1.47 or 1.48. - I will change that, but it is quite handy for
>> signal_sets - will make an alternative scheme though.
>
> Upgrading to 1.47 did not change the error at all... :/

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-01 📝 Original message:OK - ...

2023-06-07T03:03:50Z

In reply to nevent1q…gmp0
_________________________

📅 Original date posted:2012-02-01
📝 Original message:OK - from your path it looks like linux. What version of Boost do you use. I require 1.47 or 1.48. - I will change that, but it is quite handy for signal_sets - will make an alternative scheme though.

And, as for 0.4 vs 0.5 - I have tried to follow the changes, which were mostly (?) related to the integration of the qt client, which would have to be re-done anyway. Then there were some deadlock fixes, that I don't need ;). A fix for a special attack, that I have included. But I will go over everything again.

Cheers,

M

On 01/02/2012, at 16:26, Luke-Jr wrote:

> On Wednesday, February 01, 2012 9:18:32 AM Michael Grønager wrote:
>> libcoin is now in a state ready for its first release, which I would like
>> to share with you!
>
> Looks interesting. However, it doesn't configure for me:
> http://paste.pocoo.org/show/544135/
>
> I noticed it's forked from bitcoind 0.4.x. Do you plan to merge up to 0.5.x?
>
> Luke

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-01 📝 Original message:Just ...

2023-06-07T03:03:44Z

In reply to nevent1q…6u0h
_________________________

📅 Original date posted:2012-02-01
📝 Original message:Just wrote it in another mail, but I am quite certain it is the boost version - you need 1.48 (or 1.47).

/M

On 01/02/2012, at 17:15, Luke-Jr wrote:

> On Wednesday, February 01, 2012 10:58:28 AM Michael Grønager wrote:
>> Your CMake cannot find boost - use ccmake or cmake-gui to help it with the
>> location.
>
> I didn't see anything useful in ccmake. Boost is in the standard locations
> (/usr/include/boost/ and /usr/lib/libboost*
>
>> Btw what platform are you using ?
>
> Gentoo

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-01 📝 Original message:Hi ...

2023-06-07T03:03:38Z

In reply to nevent1q…w8yt
_________________________

📅 Original date posted:2012-02-01
📝 Original message:Hi Luke,

Your CMake cannot find boost - use ccmake or cmake-gui to help it with the location. Btw what platform are you using ?

/M

On 01/02/2012, at 16:26, Luke-Jr wrote:

> On Wednesday, February 01, 2012 9:18:32 AM Michael Grønager wrote:
>> libcoin is now in a state ready for its first release, which I would like
>> to share with you!
>
> Looks interesting. However, it doesn't configure for me:
> http://paste.pocoo.org/show/544135/
>
> I noticed it's forked from bitcoind 0.4.x. Do you plan to merge up to 0.5.x?
>
> Luke

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-03 📝 Original message:> ...

2023-06-07T03:03:32Z

In reply to nevent1q…8egx
_________________________

📅 Original date posted:2012-02-03
📝 Original message:> Hello Michael,
>
> I'm impressed by your refactorings, and hope some of them can make it into the Satoshi codebase.

Thanks:)

> I am however not sure what you've said above is safe. In particular, how do you guarantee that no other thread modifies the blockchain structure while you are performing your query on it? Does the query code operate on a const copy of the structure, or is there guaranteed only one thread accessing it?

The BlockChain class encapsulates all access to the blockchain and only give you access to certain restricted queries on the chain. Actually that was the case already in the satoshi client, I have only tried to formalize and encapsulate these queries in the code instead of having all the code poking around directly in the database and the blockfile.

I should note that the database still keeps a mutex to protect reads from writes.

I agree that constness alone does not guarantee thread safety, it is one of the things to use to get there. Great care should be taken not to read a value that is being changed at the same time, at least if that will render the result unusable.

The list of allowed queries are the const public methods of BlockChain. Some examples :
1. bool isSpent(Coin coin) const;
2. int getNumSpent(uint256 hash) const ;
3. uint256 spentIn(Coin coin) const;

/// Check if the hash of a block belongs to a block in the main chain:
4. bool isInMainChain(const uint256 hash) const;

/// Get the best height
5. int getBestHeight() const { return _bestIndex->nHeight; }

Or e.g.:
6. void getBlock(const uint256 hash, Block& block) const;

1-3. can be used to check if a COutPoint (now Coin) has been spent etc... This will only generate sane results, even if the two threads are both active on the same data structures.
Same goes for 4. and 6. copies a block from the block file to the Block& provided so no issues here either.

I do, however, admit, that an extra review of all the public const methods would be wise, to ensure that I have not overlooked something. I'll open an issue on this and use a cold winter night on looking them over again.

Cheers,

Michael

>
> I've been thinking about moving to read-write locks that allow multiple threads reading the datastructure simultaneously, but removing the locking all together sounds wrong to me.
>
> --
> Pieter

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-02 📝 Original message:I ...

2023-06-07T03:03:22Z

In reply to nevent1q…k0h7
_________________________

📅 Original date posted:2012-02-02
📝 Original message:I agree on your architectural considerations - and with libcoin you can have several wallets in the same application ( and several RPC servers for that matter). And ... they all use the same Node / blockchain.

You will also find the RPC server in libcoin blistering fast compared to the Satoshi client. (It was actually what got me to write libcoin in the first place...). The Satoshi client HTTP server executes all rpc commands in its own thread, but to do so, it needs to stop the thread of the Node, even though the command executed is just a query (i.e. not a SendTo), you hence have two threads blocking each other and when they wait, you wait... In libcoin all the query methods access the blockChain as a const object and they can hence safely query it without intervening the work of the Node thread. The exception are the SendTo methods that first query if a transaction can take place, then pushes it to the work-queue of the Node thread and again exits immediately. The actual execution then follows once the Node has finished its current tasks (e.g. validating a block).

I have attached the code for a very simple one node, two wallet, libcoin client below (~30 lines), and I have added it to the libcoin source as an example (example name: extrawallets).

Once running, you can access your extra wallet using the RPC interface:
./extrawallet extragetbalance
And youy normal wallet by:
./extrawallet getbalance

I'll leave the generalization to an n-wallet gui application to the reader ;)

Cheers,

Michael

....

// The derived classes below are only to get other class names (using the auto rpc name feature)
// I will put adding a "setName" method to the Method class on the todo.
class ExtraGetBalance : public GetBalance {
public:
ExtraGetBalance(Wallet& wallet) : GetBalance(wallet) {}
};
class ExtraSendToAddress : public GetBalance {
public:
ExtraSendToAddress(Wallet& wallet) : GetBalance(wallet) {}
};

int main(int argc, char* argv[])
{
logfile = CDB::dataDir(bitcoin.dataDirSuffix()) + "/debug.log";

Node node; // deafult chain is bitcoin

Wallet wallet(node, "wallet.dat"); // add the wallet
Wallet extra_wallet(node, "extra_wallet.dat"); // add the extra wallet

thread nodeThread(&Node::run, &node); // run this as a background thread

Server server;

// Register Server methods.
server.registerMethod(method_ptr(new Stop(server)));

// Register Node methods.
server.registerMethod(method_ptr(new GetBlockCount(node)));
server.registerMethod(method_ptr(new GetConnectionCount(node)));
server.registerMethod(method_ptr(new GetDifficulty(node)));
server.registerMethod(method_ptr(new GetInfo(node)));

// Register Wallet methods. - note that we don't have any auth, so anyone (on localhost) can read your balance!
server.registerMethod(method_ptr(new GetBalance(wallet)));
server.registerMethod(method_ptr(new SendToAddress(wallet)), Auth("username","password"));
server.registerMethod(method_ptr(new ExtraGetBalance(wallet)));
server.registerMethod(method_ptr(new ExtraSendToAddress(wallet)), Auth("username","password"));
server.run();

node.shutdown();
nodeThread.join();
}

On 02/02/2012, at 00:50, grarpamp wrote:

>> However, I think perhaps the bitcoin project should be split into a library, with a prototype client and the actual clients. This library facilitates this.
>
> I'll be trying your implementation soon. And libbitcoin/subvertx too.
> Partly because they're also non-interpreted, and partly to what seems
> better architected...
>
> To the minimal extent of my understanding... I'd like to see wallet
> ops completely separated from background chain ops. ie: have
> a chain daemon doing it's thing, updating, verifying, etc. The
> generator doing it's thing. And a wallet app that can independently
> manage separate wallets in parallel, referencing the live chain files
> as needed. It seems a library would allow quality focus on the separate
> functions and let apps/ui's use the fn's as desired on top. Right now, it
> seems I have to run bitcoind and can only deal with one wallet at a time,
> having to stop it, deal with state issues, swap in a new wallet, start
> it, and repeat till illness ensues :( And when the chain is being processed
> hard by the daemon cpuwise, bitcoin RPC takes minutes to respond, if ever
> or errors out. If wallet ops or statistical queries on the chain need it for
> integrity or reading, a db checkpoint/lock/logroll could be implemented into
> the chain demon processes with a client lib api to trigger it as needed.
> Don't know, just saying.
>
> fyi... boost 1.48 and db 4.8.30 work fine with 0.5.2, 0.5.x, and master,
> you just need to compile and include it by hand if you want it and
> your package manager doesn't have it.

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-01 📝 Original message:Would ...

2023-06-07T03:03:15Z

In reply to nevent1q…ejlg
_________________________

📅 Original date posted:2012-02-01
📝 Original message:Would be fine for me, depends on the community, and it is one of those chunks that make many stall...

The reason for building on bitcoin/bitcoin directly is that this created a history of all changes, and this way I had a working version running each day while doing the refactoring - with my wallet at stake!

However, I think perhaps the bitcoin project should be split into a library, with a prototype client and the actual clients. This library facilitates this.

Cheers,

M

On 01/02/2012, at 16:09, slush wrote:

> Very interesting. Do you have any plans to push your refactored code into Bitcoin upstream for future releases someday?
>
> slush
>
> On Wed, Feb 1, 2012 at 3:18 PM, Michael Grønager <gronager at ceptacle.com> wrote:
> Dear Bitcoiners,
>
> libcoin is now in a state ready for its first release, which I would like to share with you!
>
> === libcoin is a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. ===
>
> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the first version of the crypto currency library "libcoin" based on the bitcoin/bitcoin "Satoshi" client.
>
> libcoin also maintains a version of bitcoind that is a 100% compatible drop-in replacement of the bitcoin/bitcoind client: You can use it on the same computer on the same files and you can call it with the same scripts. And you can easily extend it without touching the basic bitcoin source files.
>
> The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!
>
> In libcoin, the Satoshi client code has been completely refactored, properly encapsulating classes, removing all globals, moving from threads and mutexes to a pure asynchronous approach. Functionalities have been divided into logical units and libraries, minimizing dependencies for e.g. thin clients.
>
> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, ...) specific settings are maintained from a single class (Chain) and hence experiments with chain settings, mining, security and digital currencies for research and educational purposes are easily accessible. See the ponzicoin example for how you define your own chain.
>
> The build system of libcoin is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows.
>
> The libcoin license is LGPL v. 3. This mean that you can use it in open source as well as in commercial projects, but improvements should go back into the libcoin library.
>
> ======
>
> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
>
> Join libcoin on twitter: http://twitter.com/libcoin
>
> Download "libcoin Satoshi release": http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
>
> Best regards,
>
> Michael Gronager, PhD
> Director, Ceptacle
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 45 14 01
> E-mail: gronager at ceptacle.com
> Web: http://www.ceptacle.com/
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-01 📝 Original message:Well, ...

2023-06-07T03:03:09Z

In reply to nevent1q…vw7g
_________________________

📅 Original date posted:2012-02-01
📝 Original message:Well, it should be simple. libcoin separates all the stuff you would like to do from a gui from the actual code, so I think it could be done cleanly. I havn't looked much at qt though... But help would be appreciated ;)

/M

On 01/02/2012, at 16:02, Wladimir wrote:

> Sounds very nice. Congratulations with the release!
>
> Any plans for porting over bitcoin-qt?
>
> Wladimir
>
> Op 1 feb. 2012 15:19 schreef "Michael Grønager" <gronager at ceptacle.com> het volgende:
> Dear Bitcoiners,
>
> libcoin is now in a state ready for its first release, which I would like to share with you!
>
> === libcoin is a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. ===
>
> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the first version of the crypto currency library "libcoin" based on the bitcoin/bitcoin "Satoshi" client.
>
> libcoin also maintains a version of bitcoind that is a 100% compatible drop-in replacement of the bitcoin/bitcoind client: You can use it on the same computer on the same files and you can call it with the same scripts. And you can easily extend it without touching the basic bitcoin source files.
>
> The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!
>
> In libcoin, the Satoshi client code has been completely refactored, properly encapsulating classes, removing all globals, moving from threads and mutexes to a pure asynchronous approach. Functionalities have been divided into logical units and libraries, minimizing dependencies for e.g. thin clients.
>
> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, ...) specific settings are maintained from a single class (Chain) and hence experiments with chain settings, mining, security and digital currencies for research and educational purposes are easily accessible. See the ponzicoin example for how you define your own chain.
>
> The build system of libcoin is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows.
>
> The libcoin license is LGPL v. 3. This mean that you can use it in open source as well as in commercial projects, but improvements should go back into the libcoin library.
>
> ======
>
> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
>
> Join libcoin on twitter: http://twitter.com/libcoin
>
> Download "libcoin Satoshi release": http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
>
> Best regards,
>
> Michael Gronager, PhD
> Director, Ceptacle
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 45 14 01
> E-mail: gronager at ceptacle.com
> Web: http://www.ceptacle.com/
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-01 📝 Original message:Hi ...

2023-06-07T03:02:59Z

In reply to nevent1q…lc64
_________________________

📅 Original date posted:2012-02-01
📝 Original message:Hi Gregory,

I played with the database sync as well to get further speedups, but in the latest version I could only get about 1% extra from this.

In the Satoshi client there is a bunch of sleeps and mutexes (put in there with great generosity) for making threads run smoother and to avoid deadlock I guess.

The big change in speed came from moving from the threading based setup to the async based setup, so I think these are the culprit. Further, as I also write somewhere in the wiki. I can measure that 50% of the time is consumed in verify, so there is not much left to optimize now. Actually, Berkeley DB does a quite decent job in caching reads so not even a cache should help.

Cheers,

M

On 01/02/2012, at 15:59, Gregory Maxwell wrote:

> On Wed, Feb 1, 2012 at 9:18 AM, Michael Grønager <gronager at ceptacle.com> wrote:
>> The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!
>
> Very interesting. Do you know where this speedup came from? It's not
> typical for straight refactors that don't change datastructures and
> the like to see such big speedups.
>
> I see you have commented out code that disables fsync, which was my
> first guess since I get big speedups from doing similar things.

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2012-02-01 📝 Original message:Dear ...

2023-06-07T03:02:53Z

In reply to nevent1q…epe6
_________________________

📅 Original date posted:2012-02-01
📝 Original message:Dear Bitcoiners,

libcoin is now in a state ready for its first release, which I would like to share with you!

=== libcoin is a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. ===

Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the first version of the crypto currency library "libcoin" based on the bitcoin/bitcoin "Satoshi" client.

libcoin also maintains a version of bitcoind that is a 100% compatible drop-in replacement of the bitcoin/bitcoind client: You can use it on the same computer on the same files and you can call it with the same scripts. And you can easily extend it without touching the basic bitcoin source files.

The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!

In libcoin, the Satoshi client code has been completely refactored, properly encapsulating classes, removing all globals, moving from threads and mutexes to a pure asynchronous approach. Functionalities have been divided into logical units and libraries, minimizing dependencies for e.g. thin clients.

libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, ...) specific settings are maintained from a single class (Chain) and hence experiments with chain settings, mining, security and digital currencies for research and educational purposes are easily accessible. See the ponzicoin example for how you define your own chain.

The build system of libcoin is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows.

The libcoin license is LGPL v. 3. This mean that you can use it in open source as well as in commercial projects, but improvements should go back into the libcoin library.

======

Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki

Join libcoin on twitter: http://twitter.com/libcoin

Download "libcoin Satoshi release": http://github.com/ceptacle/libcoin/zipball/v0.4.0.1

Best regards,

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/

📅 Original date posted:2011-12-22 🗒️ Summary of this ...

2023-06-07T02:50:48Z

In reply to nevent1q…ujdd
_________________________

📅 Original date posted:2011-12-22
🗒️ Summary of this message: In a distributed blockchain setup, miners are the only ones incentivized to do validations, leading to the possibility of super nodes and charging for validations.
📝 Original message:Just adding to Joels comment:

The only one with an incentive to do validations are miners (otherwise they could risk having their mined blocks invalidated later by less lazy miners) and the ones who are to send and accept a transaction. In a distributed stored and validated block chain setup, you would hence need to ask some miners if the inputs to a transaction is valid or download all the chain yourselves.

The latter is what we do today and will not scale, the former is the logical consequence of a non-enforced random validation approach - so this will give us super nodes, namely miners, and at some point they could choose to also charge for the validations. It might be the direction we are moving towards, but then the p2p network is only for the miners and the rest of us can connect through https and use json-rpc to post transactions etc to them. I do, however, prefer a setup where we keep everything really distributed...

/M

On 22/12/2011, at 13:14, Joel Joonatan Kaartinen wrote:

> On Thu, 2011-12-22 at 11:52 +0000, Andy Parkins wrote:
>> Why should they have to? Joining the network as a node is very low cost to
>> the other nodes. You can't force any node not to be lazy, since their option
>> is to disconnect themselves. As to maliciousness, that is defended against
>> because when a node negative announces a transaction, that transaction is
>> going to be checked (note that there is still no implicit trust) -- if a node
>> is incorrectly negative-announcing then it can justifiably be kicked.
>
> a node that is not doing any checking themselves can not reliably
> forward failed verifications without getting the blame for doing faulty
> work. Those nodes would then have the incentive not to relay the failed
> verifications. This ends up making it important to know which nodes will
> be checking transactions or not so you don't isolate yourself from other
> nodes that are also checking transactions.
>
> - Joel
>

Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: gronager at ceptacle.com

📅 Original date posted:2011-12-22 🗒️ Summary of this ...

2023-06-07T02:50:35Z

In reply to nevent1q…3s5j
_________________________

📅 Original date posted:2011-12-22
🗒️ Summary of this message: A decentralized system where every node randomly chooses whether to verify any particular transaction, with negative-announce transactions to flag invalid ones.
📝 Original message:It is analog to getting assigned a random part (based on IP) of the hashspace and then only verify transactions within this fraction.

But, there is in fact a subtle difference: If anyone can choose to verify at random, you will see lazy implementations where random means none, and as it is random you cannot, from the outside, judge if a node is taking part in the validation work or if it just benefitting from others announcements. In the hash space part, you can monitor peers and see if they did not tell you about a failed validation and then disconnect from them as they are either malicious or lazy.

Besides from that, I like a setup where we scream about failed verifications, but keep a low profile on things that actually verifies...

/M

On 22/12/2011, at 11:12, Andy Parkins wrote:

> On 2011 December 21 Wednesday, Christian Decker wrote:
>
>> Supernodes will be those nodes that verify all transactions and make them
>> available to miners. Since miners will become more and more specialized
>> these supernodes are likely to be owned by the miners themself. To be a
>> miner either you need to verify all the transactions you include (otherwise
>> others might be able to find an error in your block and thus drop it) or
>> have someone that verifies them for you. In the end I think we'll end up
>> with a hierarchical network, with the miners/supernodes tighly
>> interconnected at the top and the lightweight clients that simply verify
>> transactions (or their inputs to be precise) that are destined for them at
>> the bottom.
>
> A thought occurred to me. We already run a decentralised system, but it's
> done by making everyone duplicate all other work. There is no fundamental
> reason why all work needs to be duplicated though. What about this: every
> node randomly chooses whether to verify any particular transaction. If we
> assume the network is large and the random factor is correctly chosen, then we
> can still guarantee that every transaction is verified. Then, we simply add a
> protocol message that is a negative-announce transaction. That is to say, we
> give nodes a way of telling other nodes that they think a transaction is
> invalid. The other nodes are then free to verify _that_ assertion and forward
> the negative-announce.
>
> Miners can then listen for negative-announcements and use them to decide were
> to dedicate their verification efforts. They then don't need to verify all
> (or perhaps even any) transactions themselves and can dedicate their
> processing power to mining.
>
> (I've actually mentioned this idea before, but that time I was using it as a
> double-spend prevention method).
>
>
>
> Andy
>
> --
> Dr Andy Parkins
> andyparkins at gmail.com

📅 Original date posted:2011-12-22 🗒️ Summary of this ...

2023-06-07T02:50:29Z

In reply to nevent1q…x0wq
_________________________

📅 Original date posted:2011-12-22
🗒️ Summary of this message: Proposal for a decentralized block storage network to reduce the risk of a sybil attack. Broadcasting transactions may not be necessary, and thin nodes could serve as cache. The use of supernodes may simplify validation work, but a true p2p setup is necessary for scalability.
📝 Original message:>
> As for the DHT we had a few brainstorming sessions a while back on the forum http://bit.ly/sc2RLZ (gmaxwell didn't like it then either :D)
> Forcing someone to participate in a fixed position in the block storage network is a good way to reduce the risk of a sybil attack as Michael said. The hash should include only information that cannot be changed by the user, so IP can be used, but including the port is risky.

Agree, that is why we need to keep the different A.B segment requirement as is also imposed in the client today.

>
> Broadcasting the transactions would not need to be done, since miners fetch them from their storage place, alternatively we could use the inv broadcast to notify peers about a new block/transaction and let it retrieve them from the permanent storage (DHT or block storage network). If we route traffic internally in the DHT we could even start caching at nodes leading to the real location, since announcements would lead to flashcrowds, putting heavy load on the responsible nodes. Caching is not a risk since the hash of the object to be retrieved is already known.

I agree that in practice the thinner nodes would most likely just serve as cache, but they need notification on tx'es involving some of their tx outs or involving some of theirs bitcoin addresses. Today there are some designs that operate with a thin client that connects to a (web)server and subscribe to listen for transactions involving a specific bitcoin address. By letting that be a part of the hash space including that address you would not reveal your address to the server and we would keep a true p2p setup.

Best regards,

Michael

>
> Regards,
> Chris
>
> On Wed, Dec 21, 2011 at 1:41 PM, Michael Grønager <gronager at ceptacle.com> wrote:
> I find it likely that we will at some point have supernodes. If we have browser based wallets then the server for these automatically becomes supernodes. Further, if we move along that direction, it becomes much simpler to use both the scheme I proposed or to use a a lot of other schemes for sharing the validation work on a farm constituting the supernode.
>
> However, if we want to keep bitcoin in a real p2p setup and enable scalability in terms of ensuring both thin and fat client to connect then we need to go along the path I propose.
>
> Actually, after thinking a bit more about the possible new attack vector I don't find it that alarming - if you still require 7 confirmations of any bigger transaction before you, as receiver accepts the transaction as payed you will not risk anything. The question is then if it is sufficiently easy to fake small transaction to e.g. gain access to micropayment based web services. I would again say no - the requirement that you have ok from e.g. 8 different A.B nodes will make it extremely difficult to cheat, and that would even require you to gain some level of control over the network that the service you want to cheat is connected through.
>
> This means that you should not divide the hash space more finely than you would at all times be able to find 8 different A.B nodes. As the number of clients grows you can then divide the hash space further. (with 100000 nodes today and a division into 512 parts you would have approx 200 nodes to choose from).
>
> Cheers,
>
> M
>
>
>
> On 21/12/2011, at 12:42, Eric Lombrozo wrote:
>
>> Is it just me or does it seem inevitable that at some point supernodes
>> will emerge that other nodes trust to validate transactions for them?
>> Supernodes needn't even store the entire block chain and transaction
>> pool...it would be sufficient that they keep lists of IP addresses of
>> other trustworthy nodes and partition them into a hashspace.
>>
>> Anonymous peers have no reputation to defend...but a trusted supernode
>> would, which could provide just enough incentive for the supernode to
>> do its best to ensure the nodes it vouches for are indeed legit. Of
>> course, unless the supernode is validating the entire block chain and
>> transaction pool itself, it could only assess the trustworthiness of
>> other nodes by performing random sampling.
>>
>> Michael, I really like your ideas and the clarity you bring to the
>> issue. Regarding the potential attack vector you mention, would it be
>> possible to partition the hashspace to minimize the risk that an
>> attacker can manage to disproportionately gain control over a part of
>> the hashspace?
>>
>> ------------------------------------------------------------------------------
>> Write once. Port to many.
>> Get the SDK and tools to simplify cross-platform app development. Create
>> new or port existing apps to sell to consumers worldwide. Explore the
>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>> http://p.sf.net/sfu/intel-appdev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

📅 Original date posted:2011-12-21 🗒️ Summary of this ...

2023-06-07T02:50:22Z

In reply to nevent1q…syc9
_________________________

📅 Original date posted:2011-12-21
🗒️ Summary of this message: Supernodes may emerge for validating transactions, but to maintain a real peer-to-peer setup and enable scalability, a proposed path should be followed. The risk of a new attack vector is not alarming, and it would be difficult to cheat with the proposed scheme. The hash space should not be divided more finely than the ability to find eight different nodes at all times.
📝 Original message:I find it likely that we will at some point have supernodes. If we have browser based wallets then the server for these automatically becomes supernodes. Further, if we move along that direction, it becomes much simpler to use both the scheme I proposed or to use a a lot of other schemes for sharing the validation work on a farm constituting the supernode.

However, if we want to keep bitcoin in a real p2p setup and enable scalability in terms of ensuring both thin and fat client to connect then we need to go along the path I propose.

Actually, after thinking a bit more about the possible new attack vector I don't find it that alarming - if you still require 7 confirmations of any bigger transaction before you, as receiver accepts the transaction as payed you will not risk anything. The question is then if it is sufficiently easy to fake small transaction to e.g. gain access to micropayment based web services. I would again say no - the requirement that you have ok from e.g. 8 different A.B nodes will make it extremely difficult to cheat, and that would even require you to gain some level of control over the network that the service you want to cheat is connected through.

This means that you should not divide the hash space more finely than you would at all times be able to find 8 different A.B nodes. As the number of clients grows you can then divide the hash space further. (with 100000 nodes today and a division into 512 parts you would have approx 200 nodes to choose from).

Cheers,

M

On 21/12/2011, at 12:42, Eric Lombrozo wrote:

> Is it just me or does it seem inevitable that at some point supernodes
> will emerge that other nodes trust to validate transactions for them?
> Supernodes needn't even store the entire block chain and transaction
> pool...it would be sufficient that they keep lists of IP addresses of
> other trustworthy nodes and partition them into a hashspace.
>
> Anonymous peers have no reputation to defend...but a trusted supernode
> would, which could provide just enough incentive for the supernode to
> do its best to ensure the nodes it vouches for are indeed legit. Of
> course, unless the supernode is validating the entire block chain and
> transaction pool itself, it could only assess the trustworthiness of
> other nodes by performing random sampling.
>
> Michael, I really like your ideas and the clarity you bring to the
> issue. Regarding the potential attack vector you mention, would it be
> possible to partition the hashspace to minimize the risk that an
> attacker can manage to disproportionately gain control over a part of
> the hashspace?
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2011-12-21 🗒️ Summary of this ...

2023-06-07T02:50:16Z

In reply to nevent1q…dn2z
_________________________

📅 Original date posted:2011-12-21
🗒️ Summary of this message: Bitcoin faces scalability issues due to the rapid growth of the blockchain. Partitioning the transaction/block space through a Distributed Hash Table (DHT) approach can provide distributed validation and storage. However, ensuring trust and security while querying other nodes for validation and avoiding double spending remains a challenge. Designing a system based on assigning clients to serve a part of the block chain, block index, and bitcoin addresses can help address these issues.
📝 Original message:DHTs and Bitcoin:

First, lets define the problem we want to solve: scalability - when bitcoin takes over all credit card transactions (!), and even before that, we will meet a scalability problem. The blockchain will grow rapidly, (1MB/10min or 50GB/yr) and we will constantly have transactions pending to get into a block. Further, the clients will turn into toasters just from validating all transactions. At the same time we have a level of validation and block chain distribution that we really don't need - today txes are validated by 100k clients in the future that could be 100M clients, and they are stored at way more locations than they are today. So... all this calls for a partition of the transaction/block space, and for a more flexible than 1MB / block setup.

First things first. The partitioning of the tx space. One way to partition the tx space is through a partition in hash, namely the DHT approach. There might be other schemes, but as we already have both the ability to share addresses and maintain a hash space it seems obvious.

So we would like a scheme that provides distributed validation and storage keeping a similar level of trust and security as we have today. We hence need to be able to query another node for validation and ensure it is not pulling our leg (Sybil...).

There are two important aspects of bitcoin:
1. transaction signing / validation
2. to avoid double spending

1. Is a a simple and inclusive problem to solve, 2 is more complex and exclusive. 1. can to a large extend be solved by asking for transactions and validating these against the block chain - it is hard to cheat as you can match blocks containing your transaction with the block chain headers, requiring a false node to perform heavy proof of work tasks.
If we on the other hand query other nodes for 2. just blocking an answer would be enough to enable a double spend. (at least seen from the one node querying).

Today you can, assuming you have en up to date block chain, only block pending tx'es which gives you an approximate 10 minutes scale for cheating by double spending. If we create a setup where we distribute the block index and the block chain, we can fake any older transaction as well, and leave a node to believe that a tx has not been spend. The obvious way around it is to ensure a high level of connectedness and to query several geographically distributed nodes if a tx has already been spend. But this can be quite hard and also, you don't want to flood the network with to many extra commands.

If we design the system based on the above conclusions we get:

1. A client is, based on the hash of its ip:port assigned to serve a part of the block chain, a part of the block index and possibly also a part of the bitcoin addresses (hash160).

2. Further, the client can announce that it also serves any other hashspace fractions - e.g. to enable notification of payments to its bitcoin address or use of its coins (txouts).

3. On validation of a tx, the txins are queried for at the clients serving these and a possible double spend can be monitored. We need to query more clients to ensure we are not cheated by one. And we need to maintain the requirement that they come from separate A.B address spaces (so they don't just setup a matching hash from playing with C.D and ports).

4. The proper nodes are found using Chord DHT scheme (other schemes might be suitable as well).

Thin clients keep their spendable coins to a minimum and use only one bitcoin address, that way they will only serve and listen to 3 hash fractions. If we split the current space into 4096 parts we get roughly 100 clients for each hash space.

The (only?) new attack vector, compared to the current system is the possibility that a client has only evil peers within one hash range and hence can be fooled into believing an old tx can be spend again.

The new scheme will scale well as each client will only serve a part of the hashspace and hence the number of validations and block storage can be kept at a minimum. Further, it scales well for thin clients vs more full clients as you can add as many or as few (down to 1-3) hash space parts as you want, so the new scheme includes the old scheme in the limit of subscribing to all hash space parts.

I might have overlooked something - so please fill in some comments...

Cheers,

Michael

On 18/12/2011, at 22:19, Stefan Thomas wrote:

> Hey Chris,
>
>> The storage would be distributed, messages are routed on behalf of others, which makes finding the origin of the query hard to find (think Tor)
>
> This type of intermediate routing makes Tor slow. Bitcoin does not and imho should not make anonymity guarantees. Many users do not need them.
>
> Let those who want anonymity connect through Tor, Freenet, etc. It's easy to add anonymity via an extra layer, but it is impossible to add performance on top of a slow system.
>
> That's really the only thing I wanted to point out - if you do DHTs, focus on performance, not anonymity. :)
>
> Cheers,
>
> Stefan
>
> On 12/17/2011 2:37 PM, Christian Decker wrote:
>> A while back I had proposed a similar idea to the DHT, although my main goal was to reduce the need for broadcasts.
>>
>> My idea was to structure the network in a hypercube and use prefixes to address different parts of the network, and use those prefixes also to find the location where an item (transaction, block, ...) should be stored. Each vertex in the hypercube is a small, highly connected, cluster of nodes. The storage would be distributed, messages are routed on behalf of others, which makes finding the origin of the query hard to find (think Tor), each node would have to store only O(log(p)) items, with p being the prefix length, maximum number of hops is equal to the dimension of the hypercube O(log(n)).
>>
>> Newly created transaction will be sent directly to the location they'll be stored and miners retrieve new transactions at regular intervals. It might increase delays to the confirmations, but it reduces the number of broadcasts and storage requirements on nodes greatly.
>>
>> Regards,
>> Chris
>>
>>
>> On Sat, Dec 17, 2011 at 2:13 PM, Michael Grønager <gronager at ceptacle.com> wrote:
>> Hey Eric,
>>
>> Two comments.
>>
>> 1.
>> The ability to query for transactions belonging to pubkeys or bitcoin addresses is supported today by several implementations:
>> * blockexplorer.com
>> * bitcoin-js
>> * my own libBTC (will more on this soon)
>>
>> To query for transactions you need to use json-rpc and not the bitcoin protocol, however. But still the purpose is the same: to be able to build thin clients that can rely on a server for storing the blockchain and keeping connected on the p2p network.
>>
>> The reason for not having these queries part of the standard protocol (I think) are as they breaks anonymity, and that you would actually encourage people to participate in the p2p.
>>
>> 2. The second part you mention, to some how move the storage of the blockchain into a DHT based storage would be quite nice. The benefit of this is that it could be a way to integrate the smaller clients into the network without breaking the anonymity. But it should be thought out quite carefully. Further, if each client only store a fraction of the blockchain we should work out what fraction that need to be in order to ensure a similar service level. I would be happy to work with you on this.
>>
>> Cheers,
>>
>> Michael
>>
>> On 17/12/2011, at 08:41, Eric Lombrozo wrote:
>>
>>> Hey, guys.
>>>
>>> I haven't posted here before so I'll introduce myself. My name's Eric,
>>> I've been developing cryptocurrency-related
>>> software for several months now, I've implemented some libraries for
>>> dealing with core bitcoin datastructures, made
>>> some custom builds of bitcoind and interfaced it with a few apps I've written.
>>>
>>> In doing so, I've come to appreciate just how little of the potential
>>> for the bitcoin protocol is being exploited right now...
>>> not only in terms of the script features but in terms of the potential
>>> commands and node types that could exist.
>>>
>>> For instance, the protocol spec at
>>> https://en.bitcoin.it/wiki/Protocol_specification only has 16 commands
>>> listed and
>>> only one service type...despite having a full 12 bytes for a command
>>> code and a full eight bytes for a services
>>> type.
>>>
>>> The fact that only one node service type is specified is probably due
>>> to the fact that the satoshi client was written
>>> to be a standalone monolithic app that took care of all the essential
>>> needs for a network of peers.
>>> i.e. block chain storage/management, transaction signing/verification,
>>> key generation/wallet management, block mining, etc...
>>> However, I think there's an urgent need for breaking up all these
>>> different tasks into separate components that can run as independent
>>> services on different types of devices.
>>>
>>> One of the big issues I'm dealing with now pertains to block chain
>>> storage. As of right now, it is implemented as sequential
>>> disk files using Berkeley DB in the satoshi client. Then you have
>>> other projects that have been using SQL tables, etc...
>>> But I believe the direction this really needs to move towards is some
>>> sort of distributed hash table...and the database queries
>>> should be performed using the bitcoin protocol itself. Perhaps adding
>>> a few more commands. As things stand right now,
>>> the only way to query for transactions or blocks is by their hash. And
>>> once a transaction gets incorporated into a block and
>>> removed from the transaction pool, one can no longer query it by the
>>> transaction hash without stepping outside the bitcoin protocol.
>>> We need access to the disk file that stores the blocks whether it be
>>> via Berkeley DB or SQL or whatever.
>>>
>>> I propose an extension to the bitcoin protocol to provide methods for
>>> performing more sophisticated queries, such as "Give me
>>> an inventory of transactions involving this particular public key" or
>>> "Give me an inventory all transactions in the last n blocks with
>>> unredeemed outputs." This could be done by adding a few more commands.
>>>
>>> Furthermore, I propose a new network services type for nodes that
>>> serve as block chain/transaction pool storage.
>>>
>>> Of couse, any peer that wishes to verify the integrity of the block
>>> chain would still have to download at the very least
>>> all the block headers...and to be completely sure, also all the blocks
>>> themselves...and verify everything. But it would be
>>> very nice to be able to run thin services that can rely on other
>>> network peers to do this work. It is still possible to attain
>>> a high level of confidence in the integrity by querying multiple peers
>>> for similar objects and comparing. It is also possible
>>> to run your own dedicated block chain storage servers which you trust.
>>>
>>> There are other ideas I have for other types of services, too.
>>>
>>> Anyhow, I'm just throwing this out there...if anyone's interested I'd
>>> love to develop these ideas further and help put together some
>>> specs.
>>>
>>> -Eric Lombrozo
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Windows Azure Live! Tuesday, Dec 13, 2011
>>> Microsoft is holding a special Learn Windows Azure training event for
>>> developers. It will provide a great way to learn Windows Azure and what it
>>> provides. You can attend the event by watching it streamed LIVE online.
>>> Learn more at http://p.sf.net/sfu/ms-windowsazure
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Windows Azure Live! Tuesday, Dec 13, 2011
>> Microsoft is holding a special Learn Windows Azure training event for
>> developers. It will provide a great way to learn Windows Azure and what it
>> provides. You can attend the event by watching it streamed LIVE online.
>> Learn more at http://p.sf.net/sfu/ms-windowsazure
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Windows Azure Live! Tuesday, Dec 13, 2011
>> Microsoft is holding a special Learn Windows Azure training event for
>> developers. It will provide a great way to learn Windows Azure and what it
>> provides. You can attend the event by watching it streamed LIVE online.
>> Learn more at
>> http://p.sf.net/sfu/ms-windowsazure
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>>
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2011-12-17 🗒️ Summary of this ...

2023-06-07T02:49:46Z

In reply to nevent1q…d3v3
_________________________

📅 Original date posted:2011-12-17
🗒️ Summary of this message: Eric Lombrozo discusses the potential for exploiting the Bitcoin protocol, including the need for breaking up tasks into separate components and moving towards a distributed hash table for block chain storage.
📝 Original message:Hey Eric,

Two comments.

1.
The ability to query for transactions belonging to pubkeys or bitcoin addresses is supported today by several implementations:
* blockexplorer.com
* bitcoin-js
* my own libBTC (will more on this soon)

To query for transactions you need to use json-rpc and not the bitcoin protocol, however. But still the purpose is the same: to be able to build thin clients that can rely on a server for storing the blockchain and keeping connected on the p2p network.

The reason for not having these queries part of the standard protocol (I think) are as they breaks anonymity, and that you would actually encourage people to participate in the p2p.

2. The second part you mention, to some how move the storage of the blockchain into a DHT based storage would be quite nice. The benefit of this is that it could be a way to integrate the smaller clients into the network without breaking the anonymity. But it should be thought out quite carefully. Further, if each client only store a fraction of the blockchain we should work out what fraction that need to be in order to ensure a similar service level. I would be happy to work with you on this.

Cheers,

Michael

On 17/12/2011, at 08:41, Eric Lombrozo wrote:

> Hey, guys.
>
> I haven't posted here before so I'll introduce myself. My name's Eric,
> I've been developing cryptocurrency-related
> software for several months now, I've implemented some libraries for
> dealing with core bitcoin datastructures, made
> some custom builds of bitcoind and interfaced it with a few apps I've written.
>
> In doing so, I've come to appreciate just how little of the potential
> for the bitcoin protocol is being exploited right now...
> not only in terms of the script features but in terms of the potential
> commands and node types that could exist.
>
> For instance, the protocol spec at
> https://en.bitcoin.it/wiki/Protocol_specification only has 16 commands
> listed and
> only one service type...despite having a full 12 bytes for a command
> code and a full eight bytes for a services
> type.
>
> The fact that only one node service type is specified is probably due
> to the fact that the satoshi client was written
> to be a standalone monolithic app that took care of all the essential
> needs for a network of peers.
> i.e. block chain storage/management, transaction signing/verification,
> key generation/wallet management, block mining, etc...
> However, I think there's an urgent need for breaking up all these
> different tasks into separate components that can run as independent
> services on different types of devices.
>
> One of the big issues I'm dealing with now pertains to block chain
> storage. As of right now, it is implemented as sequential
> disk files using Berkeley DB in the satoshi client. Then you have
> other projects that have been using SQL tables, etc...
> But I believe the direction this really needs to move towards is some
> sort of distributed hash table...and the database queries
> should be performed using the bitcoin protocol itself. Perhaps adding
> a few more commands. As things stand right now,
> the only way to query for transactions or blocks is by their hash. And
> once a transaction gets incorporated into a block and
> removed from the transaction pool, one can no longer query it by the
> transaction hash without stepping outside the bitcoin protocol.
> We need access to the disk file that stores the blocks whether it be
> via Berkeley DB or SQL or whatever.
>
> I propose an extension to the bitcoin protocol to provide methods for
> performing more sophisticated queries, such as "Give me
> an inventory of transactions involving this particular public key" or
> "Give me an inventory all transactions in the last n blocks with
> unredeemed outputs." This could be done by adding a few more commands.
>
> Furthermore, I propose a new network services type for nodes that
> serve as block chain/transaction pool storage.
>
> Of couse, any peer that wishes to verify the integrity of the block
> chain would still have to download at the very least
> all the block headers...and to be completely sure, also all the blocks
> themselves...and verify everything. But it would be
> very nice to be able to run thin services that can rely on other
> network peers to do this work. It is still possible to attain
> a high level of confidence in the integrity by querying multiple peers
> for similar objects and comparing. It is also possible
> to run your own dedicated block chain storage servers which you trust.
>
> There are other ideas I have for other types of services, too.
>
> Anyhow, I'm just throwing this out there...if anyone's interested I'd
> love to develop these ideas further and help put together some
> specs.
>
> -Eric Lombrozo
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2011-10-27 🗒️ Summary of this ...

2023-06-07T02:35:45Z

In reply to nevent1q…9e36
_________________________

📅 Original date posted:2011-10-27
🗒️ Summary of this message: Michael Grønager argues that the OP_EVAL proposal breaks the clean mapping of cryptographic keys to assets in Bitcoin addresses. He supports checkmultisig as the standard transaction type.
📝 Original message:OK, let me try to explain what I see is the problem:

So far we the bitcoin addresses are (for all practical purposes) a one-to-one mapping between a pubkey and uint160. This mean that your wallet is defined solely by your privatekeys (from which you can extract pubkeys and then uint160 btc-addresses).

This also enables you to make a uint160 to tx mapping on a server (like on blockexplorer) and use a thin client to query for transactions just from a list of uint160 (whether it holds the private keys behind them or not).

In the case of a multisig transaction, lets say the 2of3 example, you could e.g. have all 3 corresponding uint160s but only one privkey, but still query the server and know the value of an asset of uint160s.

This, I find a nice and clean setup, where cryptographic keys can be mapped to assets.

If we now consider the OP_EVAL proposal. Here, a new use of the uint160, namely as a mapping of ripemd160(something extra and hash256(pubkey)) is introduced. This means that this clean mapping is broken. Your will have an extra "public key" being the "something extra", and there is no easy way to do the mapping from a list of private keys to public keys to uint160s that will result in the new condensed uint160, except if you also have the knowledge of the script that was used.

I agree that it will work and I (and bitcoin-js and blockexplorer) can of change the concept of a wallet to also include scripts, but it breaks an intrinsic logic of uint160s and transactions that has so far been quite nice and clean.

So I also support checkmultisig to be the standard transaction type, but I do not appreciate the support of OP_EVAL.

Cheers,

Michael

On 26/10/2011, at 17:00, Gavin Andresen wrote:

> On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager <gronager at ceptacle.com> wrote:
>> I think it is a very important feature to be able to extract transaction to/from you only from your private keys.
>
> Why? If somebody is sending me bitcoins, then they'll have to get
> either an address or one or more public keys from me. OP_EVAL just
> lets me give them a short address that represents an arbitrary number
> of keys combined in an arbitrary way.
>
> I agree with Gregory: it shouldn't matter if that address is
> HASH(public key) or HASH(op_eval_script), the issues are the same (if
> you lose or cannot re-create the key/script then you're in trouble).
>
> Maybe I'm missing something; are you worried that blockexplorer won't
> know that coins sent to HASH(op_eval_script) are actually a
> complicated transaction until the coins are spent again? I'd consider
> that a feature, not a bug, because only the people involved in the
> transaction need to know the details until after the transaction is
> complete.
>
> Feel free to contact me about your 'tiered implementation for thin
> clients' -- I don't think OP_EVAL will make that significantly harder.
>
> I also agree with Alan: using OP_EVAL is not mandatory, I'm proposing
> that CHECKMULTISIG becomes a standard transaction type.
>
> --
> --
> Gavin Andresen

Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: gronager at ceptacle.com

📅 Original date posted:2011-10-26 🗒️ Summary of this ...

2023-06-07T02:35:35Z

In reply to nevent1q…yk49
_________________________

📅 Original date posted:2011-10-26
🗒️ Summary of this message: The author discusses the importance of being able to extract transactions from private keys and how it is currently used in various projects. They also express concern about the potential impact of introducing a standard multikey payment that hides the address.
📝 Original message:I think it is a very important feature to be able to extract transaction to/from you only from your private keys. In the standard transactions this is easily accomplished - in the case you only want to find the addr to tx mapping:

vector<pair<opcodetype, vector<unsigned char> > > vSolution;
if (!Solver(scriptPubKey, vSolution))
return 0;

BOOST_FOREACH(PAIRTYPE(opcodetype, vector<unsigned char>)& item, vSolution)
{
vector<unsigned char> vchPubKey;
if (item.first == OP_PUBKEY)
// encode the pubkey into a hash160
return Hash160(item.second);
else if (item.first == OP_PUBKEYHASH)
return uint160(item.second);
}

This possibility is used today in:
* blockexplorer
* bitcoin-js
* my own tiered implementation for thin clients

I agree that you can of course always construct payment schemes to hide payments (hashes from classic novels, sending the private key off line etc), but I consider those either exotic or on purpose hidden, and hence they are not really a problem, nor an argument that this feature does not really exist today.

So, if we introduce a standard (multikey) payment that hides the address (or makes it overly complicated to extract it) it will be a major problem for the projects that I listed above.

I will post a more detailed technical comment reflecting directly on the BIPs, but the wiki is currently down and I need to re-read the BIPs first.

Cheers,

Michael

On 25/10/2011, at 18:47, Alan Reiner wrote:

> On Tue, Oct 25, 2011 at 10:49 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen <gavinandresen at gmail.com> wrote:
>> You give the hash to whoever is paying you, and store the hash -->
>> script mapping when you do that (assuming you're not using a
>> deterministic wallet; if you are, you probably just increment a
>> counter in the wallet).
>
> If anyone finds that solution unsatisfying, consider— It's already the
> case that I could take one of your disclosed public keys and create an
> infinite series of secondary keys out of it for which only you could
> decode, and the only way for you to find them in the blockchain would
> be to have performed the same procedure and made a note of the
> addresses you're watching for.
>
>
> (1) As I understand it, OP_EVAL is being proposed as an *optional* tool for multi-signature transactions. It sounds like to me, that you can still use the regular OP_CHECKMULTISIG if you are concerned about these things. If you're dealing with too many parties with questionable reliability that they will notify you of transacitons that include you, I don't see anything wrong with declaring that you'd only prefer dealing with OP_CMS transactions and not OP_EVAL (besides some grumbling from them that their way is "better"). Either way, they're screwing themselves, too, if they want to include you on transactions and don't notify you as such (kind of defeats the purpose of multi-sig txs).
>
> (2) I think it's unnecessary to discuss cases where you somehow lose your mappings but not your private keys. In order for OP_EVAL scripts to work, the subscripts/mappings are *just as important* as your regular private keys. They should be kept in your wallet forever just like your private keys--and thus you lose none of them or all of them. The only real difference is that they aren't sensitive like your private keys, so they don't have to be encrypted.
>
> (3) There should most definitely be a button on the main client that allows you to "Add OP_EVAL script" or something along those lines (maybe something with a less obscure name). We need to make it as easy as possible for someone to add such a script/mapping to their wallet. Although, this invites a breach of one of my core rules of user interfaces: if the functionality is dependent on the user performing some regular maintenance task, you better be prepared for all users to fail at doing it. Even diligent users are going to forget/mess-up sometimes. If failure at performing this task results in breaking the client or losing money, we should avoid promoting that usage paradigm.
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning at Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development