ht 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,
>
>
te:
> -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 c
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 blockch
Peter, I like the idea of being able to know what fees to expect from different
miners (it is like a service description / SLA for their service), but I would
prefer a more distributed discovery mechanism for the information on the fees
(Spent 10 years on Grid Computing...).
Miners could e.g. i
Hi Alan,
I am using an approach similar to your proposal in a service I am developing. I
have, however, chosen to sign using the following scheme:
1. take sha512 of document (=hash512)
2. take ripemd160 of hash512
3. create 512 bit data structure, where the first 352bits are '0', and the rest
is
If you are interested, I could push libcoin to bitcoin (e.g. bitcoin/libcoin)
and then you could build bitcoind bitcoin-qt on libcoin.
libcoin solved most of the problems you list below. And if you worry about the
copyright/license I am also willing to change that to make it fit.
libcoin have n
lready does something like that... I'm not a
> developer/code reader... Just a small nerd with big ideas... ^_^
>
> Thanks!
> Thiago
>
> 2012/2/28 Michael Grønager
> Hi again - and thanks for testing and finding this!
>
> I have fixed the bug you reported:
>
>
now about Diaspora* Project?
Yes, I even have an account :)
> 2- Do you have skills in Ruby on Rails development?
Nope...
/M
>
>
> Thank you!
> Thiago
>
> 2012/3/3 Michael Grønager
> Hi Martin,
>
> There are a couple of options of doing similarly...
>
&
Hi Eric,
What hooks are you looking for in particular ?
libcoin supports registration of listeners for new blocks and new transactions.
These are e.g. used for connecting the Wallet to the Node.
Cheers,
M
On 22/03/2012, at 06:39, bitcoin-l...@bluematt.me wrote:
> You might also want to chec
Sounds interesting, however, even after a couple of days, I cannot see how you
maintain protection against double spend using OP_CHECKEXPSIG. It is not until
you redeem the OP_CHECKEXPSIG transaction that you reveal which former
transactions that was involved?
I guess I am missing a point here?
>
> HTTP and JSON-RPC are a client-server model; there is no way for the server
> to
> make calls to the client. It's not practical to expect clients to run their
> own JSON-RPC server - many cannot listen on WAN ports at all.
Well, I think what Stefan had in mind was http keep-alive combined
l/bin/bitcoind listaccounts # NOT okay...
> {
> }
>
> /usr/local/bin/bitcoind getaccountaddress "teste" # okay
> 1E6pGh6AAtuJdFXheZMp1zdYmvdqAQn9QT
>
> /usr/local/bin/bitcoind listaccounts # NOT okay...
> {
>"teste" : 0.
> }
>
> Where is
CuLH4yvyoC2gxFEF4zquoJ87
>
> /usr/local/bin/bitcoind listaccounts # NOT okay...
> {
> }
>
> /usr/local/bin/bitcoind getaccountaddress "teste" # okay
> 1E6pGh6AAtuJdFXheZMp1zdYmvdqAQn9QT
>
> /usr/local/bin/bitcoind listaccounts # NOT okay...
> {
>"
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
>
ce 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/
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...
>
t;
> 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
> Hi Martinx,
>
> Another note:
>
> boost 1.42 and openssl 1.0 h
ror 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 - ジェームズ
> AWESOME!!!
>
>
locator > >)':
> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhE7uint256T_S8_[uint256
> Hash<__gnu_cxx::__normal_iterator std::allocator > > >(__gnu_cxx::__normal_iterator char*, std::vector > >,
> __gnu_cxx::__normal_iterator
gt; >)':
> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhE7uint256T_S8_[uint256
> Hash<__gnu_cxx::__normal_iterator std::allocator > > >(__gnu_cxx::__normal_iterator char*, std::vector > >,
> __gnu_cxx::__normal_iterator std::all
eratorIPhSt6vectorIhSaIhE7uint256T_S8_[uint256
> Hash<__gnu_cxx::__normal_iterator std::allocator > > >(__gnu_cxx::__normal_iterator char*, std::vector > >,
> __gnu_cxx::__normal_iterator std::allocator > >)]+0x6d): undefined reference to `SHA256'
> Script.cpp:(.text._Z
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:
00xx - main network
01xx - reserved
10xx - reserved
11xx - test network
Network
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
> 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 m
>
>> 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
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 vers
Thanks!
"required 5 posts and 4 hours"
Well, that is not so easy if you cannot post ;) I will apply for whitelisting -
strange policy though...
/M
On 19/02/2012, at 17:42, Harald Schilly wrote:
> On Sun, Feb 19, 2012 at 17:38, Michael Gronager wrote:
>> In the expectation of a embarrassingly
I have just uploaded a new application to libcoin: "coinexplorer"
It enables queries similar to that of blockexplorer.com, but locally on your
own chain.
coinexplorer builds on a new library addition: coinStat, that is a collection
of classes for gathering and querying the block chain for other
Hi Aidan,
Thanks, and the number is still 140700 - do we have a policy / logic on adding
new checkpoints ? It seems to me that the number could easily be bumped to
16 by now ?
Cheers,
Michael
On 03/02/2012, at 10:52, Aidan Thornton wrote:
> On Fri, Feb 3, 2012 at 9:22 AM, Mich
> 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 ar
Hi Gavin, others?
I am trying to redo the performance test of the libcoin client against the
0.5.2 Satoshi client, that I have learned also have received quite some
improvements in speed since 0.4.0 (e.g. from not verifying signatures on early
blocks).
However, I cannot find any tag with v0.5.
a
little while longer.
Will fix the Qt stuff in CMake - thanks!
Cheers,
Michael
On 02/02/2012, at 17:30, Luke-Jr wrote:
> On Thursday, February 02, 2012 8:46:05 AM Michael Grønager wrote:
>> Please test and feed back.
>
> I found the problem: you are trying to use static libra
I have added a simplified fall back class to the boost::asio::signal_set. This
should enable compilation on platforms with less than bleeding edge versions of
Boost. Most notably most of the currently deployed Linux'es that use Boost 1.42.
I also updated the root CMakeLists.txt to only require 1
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
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.
&
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 hel
ednesday, 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 not
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
ode 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 you!
>
> === lib
ery 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
. 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
> wrote:
>> The libcoin/bitcoind client downloads the entire block cha
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
mismatch between
comments and code.
Cheers,
M
On 29/12/2011, at 23:05, Michael Grønager wrote:
> In CNode::SendMessages there is a trickle algorithm. Judging from the
> comments it is supposed to:
>
> * at each update round a new (random) trickle node is chosen, with 120 nodes
>
In CNode::SendMessages there is a trickle algorithm. Judging from the comments
it is supposed to:
* at each update round a new (random) trickle node is chosen, with 120 nodes
and an average round time of 100ms (the sleep) we will have moved through
roughly all nodes every 12-15 seconds.
* when
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, y
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
rand
of 2MB of block data per second, which doesn't
> include broadcast overhead.
>
> On 12/21/2011 12:50 AM, Michael Grønager wrote:
>> when bitcoin takes over all credit card transactions (!), and even before
>> that,
>> we will meet a scalability problem. The blockcha
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 sha
gt; 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 confirm
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 bitc
OK, I admit that this is *really* of little importance...
But could someone with commit rights please update the CDataStream test table
in the code. The arguments for the custom stream are just way off (stringstream
wins by factor 10-20!). On OS X (g++) I get:
Further, if you get(got) bad stri
ot being aware of it when they start), I'd like to discuss
> it. I'm fairly confident that any such ideas could just be added to BIP 0010
> and thus reset the question of why anyone would need a competing idea.
>
>
>
> On 11/09/2011 03:03 PM, Michael Grønager wrote:
Crossing posts ;)
I like your idea! - It adds a pricetag to distributing a signature - and - as
you mention it will be part of the standard. It is only up to the clients if
they want to support it or not, but it does give you 0-conf world wide
instantaneous anonymously distribution of half-bake
Hi Gavin / Alan,
Agree that we would also need to consider these "half" transaction valid. At
least for the time being up to the lock_time, and one could have an extra
constrain - that the lock_time should be within e.g. 30minutes that would avoid
the will-never-be-completed cases.
My main con
Hi All,
Along with the multisig/op_eval BIPs (11/12) I am considering how the actual
client functionality could be.
Some of you might already have the solution for this - if not I would like to
propose the following...
Lets consider the 2 of 3 multisig - and lets say I now have some coins henc
>
> How would I know that unless you told me?
At least you would have a hunch that something like that had happened as one of
your addresses had been part of a transaction (at least in my setup it would
pop up immediately...).
>
> I think the right long-term solution is moving away from bitco
> Could you suggest how else we could gain the advantages of op_eval
> without it? How can I secure my wallet under whatever scheme I like—
> create a trust that requires multiparty signoff— and securely have
> senders pay into it without expecting them all to handle some rare and
> complicated p
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, 2
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 > > vSolution;
if (!Solver(scriptPubKey, vSolution))
/2011, at 14:50, Gregory Maxwell wrote:
> On Wed, Oct 5, 2011 at 8:31 AM, Michael Grønager
> wrote:
>> The vtxPrev stores 3 transactions back, but as transactions need 7 block to
>> maturity and respendability isn't it overkill - I mean it is highly unlikely
>> that a t
Hi !
I am looking into enabling a split between thin clients holding the wallet and
server(s) holding the blocks and txdb.
To that end I am considering to simplify the WalletTx a bit and I came across
the vtxPrev in the code. As I see it vtxPrev is only used for keeping a list of
supporting tr
Hi Brian,
Had a similar issue the other day with my cmake btc buildsystem - I just
changed the name to -mt, I think that is th way to go.
Cheers,
Michael
On 05/10/2011, at 01:40, Brian McQueen wrote:
> I installed boost via the mac ports. Its got lobboost_thread-mt, but
> it doesn't have lib
Sorry, by bad - first clean checkout for quite a while (must have changed it
earlier myself...).
/M
On 05/09/2011, at 14:42, Luke-Jr wrote:
> On Monday, September 05, 2011 3:25:47 AM Michael Grønager wrote:
>> Findings - compile (I do not use the UPNP feature):
>> in the makef
Hi Gavin,
Did a quick compile and run (bitcoind, Ubuntu 10.04.3 LTS)
Findings - compile (I do not use the UPNP feature):
in the makefile.unix I have to change the:
USE_UPNP:=0
to
USE_UPNP:=
i.e. it is defined if it is "0" !
running: no apparent issues (I have never managed to trigger the deadl
Hi Gavin (the list escaped the cc...),
I participated also in the hacakathon Sunday @ OnlyOneTV and I felt that this
had a strong chance to diverge. So - yes - I agree - no "constitution" changes
now. Further, I have thought later on on the analogy of a clerk and a safe.
WHen you enter the bank
65 matches
Mail list logo
