On Thu, Jul 18, 2013 at 06:46:16PM +0200, Wendell wrote:
> Heh, will do. If you have less confidence in your programming skills perhaps
> its best if you write documentation and we bring in someone else to do the
> heavy lifting? Maybe Eric Lombrozo would be interested in this, for example...
I
Heh, will do. If you have less confidence in your programming skills perhaps
its best if you write documentation and we bring in someone else to do the
heavy lifting? Maybe Eric Lombrozo would be interested in this, for example...
-wendell
grabhive.com | twitter.com/grabhive
On Jul 18, 2013, a
On Wed, Jul 17, 2013 at 03:37:41PM +0200, Wendell wrote:
> Peter,
>
> This sounds like a _very_ good idea for a desktop client, and probably
> acceptable to users so long as we take available disk space into
> consideration, and only ever use a fraction of it.
>
> Will you implement this?
I've
> SPV clients behaving normally are highly abusive: they use up maximum
> node resources with minimum cost to themselves.
>
This must be a new use of the word "abuse" I haven't come across before :)
At any rate, some of these assumptions are incorrect. Botnets of
compromised web servers are quite
On Thu, Jul 18, 2013 at 08:13:08AM -0400, Peter Todd wrote:
> A more sophisticated approach would be possible if there existed a
> version of H() with a computational trap-door - that is if there existed
> H'(s, i)=H(i) where H' had significantly faster running time than H(),
> but required knowled
Hi Bazyli,
Just did a fresh build based on git (Xcode) - had one issue: the paillier and
account tests were missing - please comment them out in tests/CMakeLists.txt,
then coinexplorer should build nicely.
Note I did a git push as well, so you need to do a git pull first.
/Michael
Hi Bazyli,
I actually do my main development on Mac OSX, so it surprises me to hear - I
build Xcode projects with libcoin daily on Mac OSX and linux, on Windows it is
agreeable more of a fight to build. QT is really not needed, I kept it there
for BitcoinQT, that was once part of the tree too,
On Wed, Jul 17, 2013 at 02:29:26PM +0200, Mike Hearn wrote:
> Partial UTXO sets is a neat idea. Unfortunately my intuition is that many
> SPV wallets only remain open for <1 minute at a time because the user wants
> to see they received money, or to send it. It'd be neat to get some
> telemetry fro
Hi!
I should introduce myself. I am the BitcoinKit developer. If you can call that
way a dude that wrapped up already existing code for Mac developers easier to
understand and use :-)
I'm replying mostly because libcoin is something that I would like to have a
closer look at.
Problems I've enc
> The 90 minutes is not - the blockchain has grown quite a lot since last
> year, and as for the 3.5 speed, I havn't tested it since Pieter's
> ultraprune - libcoin also has something similar to ultraprune, done
> directly in the sqlite database backend, but I should run a head to head
> again - co
On Wed, Jul 17, 2013 at 3:26 PM, Michael Gronager wrote:
> However, by having a merkle tree hash of all UTXOs they become downloadable
> in a trusted manner from any other client - something that enables bootstrap
> in minutes, so the old numbers becomes less relevant in this setting.
This, how
> Is that still accurate Michael?
>
The 90 minutes is not - the blockchain has grown quite a lot since last year,
and as for the 3.5 speed, I havn't tested it since Pieter's ultraprune -
libcoin also has something similar to ultraprune, done directly in the sqlite
database backend, but I shou
Is that still accurate Michael?
On Wed, Jul 17, 2013 at 4:58 PM, Wendell 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!"
>
> Good lord Michael, I wish we had known abo
"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!"
Good lord Michael, I wish we had known about libcoin a month ago!
-wendell
grabhive.com | twitter.com/grabhive
On Jul 17, 2013, at
Hi Wendell,
What Peter describes (a hash of the current set of UTXOs as part of the
coinbase) is already implemented in libcoin, on which you can easily build both
a bitcoind and any client. Libcoin is a library originally based on the satoshi
client, and as such it is compatible/replacable wit
Peter,
This sounds like a _very_ good idea for a desktop client, and probably
acceptable to users so long as we take available disk space into consideration,
and only ever use a fraction of it.
Will you implement this?
-wendell
grabhive.com | twitter.com/grabhive
On Jul 17, 2013, at 12:58 PM
On Wed, Jul 17, 2013 at 2:37 PM, Tamas Blummer wrote:
> A majority coalition of miner (pool operator) might even decide to change
> block reward
> rules if the rest of the network only verifies POW.
>
Which is why it's still vital that any "important" node in the economy uses
full validation.
A
On Wed, Jul 17, 2013 at 02:37:11PM +0200, Tamas Blummer wrote:
> Would not an SPV bitcoind transfer all control on validation rules to miner?
Yes
> A majority coalition of miner (pool operator) might even decide to change
> block reward
> rules if the rest of the network only verifies POW.
Wide
Would not an SPV bitcoind transfer all control on validation rules to miner?A majority coalition of miner (pool operator) might even decide to change block rewardrules if the rest of the network only verifies POW.Regards,Tamás BlummerFounder, CEOhttp://bitsofproof.com
-
Partial UTXO sets is a neat idea. Unfortunately my intuition is that many
SPV wallets only remain open for <1 minute at a time because the user wants
to see they received money, or to send it. It'd be neat to get some
telemetry from the Android wallet for this - I will ask Andreas to let
users opt
On Tue, Jul 16, 2013 at 04:16:23PM +0200, Wendell wrote:
> Hello everyone,
>
> In the previous thread, I expressed interest in seeing an SPV bitcoind,
> further stating that I would fund such work. Mike Hearn followed up with some
> of Satoshi's old code for this, which is now quite broken. The
You'd want to create and get merged patches in the following order:
1) Be able to store just block headers in the blk.dat files instead of
full block contents. At this point you are still *downloading* full blocks,
but they are not being stored. The contents are still sent to the wallet
for ex
Hello everyone,
In the previous thread, I expressed interest in seeing an SPV bitcoind, further
stating that I would fund such work. Mike Hearn followed up with some of
Satoshi's old code for this, which is now quite broken. The offer and interest
on my side still stand, as more diversity in SP
23 matches
Mail list logo
