> 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 see
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
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 n
On Wed, Feb 1, 2012 at 4:15 PM, 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/inc
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.
Boost 1.46.1 is the lat
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
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
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
Sounds great.
Does it support merged mining?
Also, I'm a bit skeptic about it being chain agnostic. I want to
implement a chain with demurrage and I think I'll need to also change
coinWallet and not only create an implementation of the interface
Chain.
Anyway, this will make the task much easier. T
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 relea
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 wa
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. Congratula
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 dead
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
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 wrote:
> Dear Bitcoiners,
>
> libcoin is now in a state ready for its first release, which I would like
> to share with y
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" het
volgende:
> Dear Bitcoiners,
>
> libcoin is now in a state ready for its first release, which I would like
> to share with you!
>
> === libcoin
On Wed, Feb 1, 2012 at 9:18 AM, Michael Grønager 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
ty
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
On 2012 January 31 Tuesday, Andy Parkins wrote:
> - Increase the version number in transactions to make a new transaction
>structure
> - Dump the "scriptPubKey" field completely. Everything will be pay-to-
>script-hash in version2 transactions
> - Replace it with "hashOfClaimingScript"
On 2012 February 01 Wednesday, Pieter Wuille wrote:
> > old clients won't they? They don't pass IsStandard().
>
> IsStandard() is for accepting transactions into the memory pool.
> Non-standard transactions are verified just fine when they are in the block
> chain.
Ah. My misunderstanding then
Op 1 feb. 2012 10:48 schreef "Andy Parkins" het
volgende:
>
> On 2012 January 31 Tuesday, Luke-Jr wrote:
>
> > Both BIP 16 and 17 are backward compatible enough that people can
continue
> > to use the old clients with each other. An upgrade is only required to
> > send to (or create/receive on) th
On 2012 January 31 Tuesday, Luke-Jr wrote:
> Both BIP 16 and 17 are backward compatible enough that people can continue
> to use the old clients with each other. An upgrade is only required to
> send to (or create/receive on) the new 3...-form addresses. That being
Is that true? (I'm happy to be
On 2012 January 31 Tuesday, Gregory Maxwell wrote:
> I think you've been deceived by people who have some interest in
> promoting this as some sort of big controversy, or perhaps just
> confused by the general level of noise.
Well that's good that there is no real problem.
> It does not, in fact
23 matches
Mail list logo
