libbitcoin

[virtualcodewarrior]

Thanks,

That indeed did the trick.
It seems I still have a lot to learn about development on linux 

[1713582053]

1713582053

[1713582053]

1713582053

[1713582053]

1713582053

[1713582053]

1713582053

[genjix]

Thanks,

That indeed did the trick.
It seems I still have a lot to learn about development on linux 

No worries, we're all at different stages of beginner.

[phelix]

Hmm strange, anyway I'm upgrading to latest Ubuntu 13.10. Will post a fix here afterwards.

Windows/Mac: in around 1 month (next release). I've got both platforms working before but unsupported.

cool

[jedunnigan]

genjix, I am curious what you think about this post by satoshi:

I don't believe a second, compatible implementation of Bitcoin will ever be a good idea.  So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.  The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.

[genjix]

Shocked Satoshi would think that since he's often showed a lot of foresight.

And I was shut out of development and prevented from doing work in the early days. So I went my own way because I see Bitcoin development differently to the current Bitcoin establishment.



----------

Good news everyone! The Python front is progressing nicely!

http://libbitcoin.dyne.org/labs.html

People creating cool stuff. My goal now is to get these projects all merged together into one pure Python package for wallet developers.

[kjj]

Satoshi is exactly right about alternate implementations.  They are hard to do right, and can cause a hell of a mess when done wrong.

But, it comes down to which of the two bad options do we like least.  Virtually no one currently active on the project wants a monoculture.  We are willing to take on the challenges and risks of multiple implementations because we feel that the risks of having just a single client are even worse.

Perhaps he'll turn out to have been right about this too, in the long run.  We should be able to answer that question fairly well in another 10 or 20 years.

[marcus_of_augustus]

Shocked Satoshi would think that since he's often showed a lot of foresight.

And I was shut out of development and prevented from doing work in the early days. So I went my own way because I see Bitcoin development differently to the current Bitcoin establishment.



----------

Good news everyone! The Python front is progressing nicely!

http://libbitcoin.dyne.org/labs.html

People creating cool stuff. My goal now is to get these projects all merged together into one pure Python package for wallet developers.

The Dude Abides.

[btcven]

----------

Good news everyone! The Python front is progressing nicely!

http://libbitcoin.dyne.org/labs.html

People creating cool stuff. My goal now is to get these projects all merged together into one pure Python package for wallet developers.

Dead link, I wan't to check it out

[lclc]

Dead link, I wan't to check it out

It's just that the website seems to be down right now..

BTW: Great work, I think having more than one implementation of the protocol is very much needed.

[genjix]

back up again!

btw hope all friends here have seen our crowdfunding campaign by now:

http://www.indiegogo.com/projects/bitcoin-dark-wallet

if you can get the word out about libbitcoin and all that we're trying to achieve here, that's much appreciated. thanks!

[hivewallet]

Satoshi is exactly right about alternate implementations.  They are hard to do right, and can cause a hell of a mess when done wrong.

But, it comes down to which of the two bad options do we like least.  Virtually no one currently active on the project wants a monoculture.  We are willing to take on the challenges and risks of multiple implementations because we feel that the risks of having just a single client are even worse.

Perhaps he'll turn out to have been right about this too, in the long run.  We should be able to answer that question fairly well in another 10 or 20 years.

Talk to us about the kind of mess it could potentially cause. Satoshi's "menace to the network" statement was maybe a bit vague.

[jedunnigan]

Satoshi is exactly right about alternate implementations.  They are hard to do right, and can cause a hell of a mess when done wrong.

But, it comes down to which of the two bad options do we like least.  Virtually no one currently active on the project wants a monoculture.  We are willing to take on the challenges and risks of multiple implementations because we feel that the risks of having just a single client are even worse.

Perhaps he'll turn out to have been right about this too, in the long run.  We should be able to answer that question fairly well in another 10 or 20 years.

Talk to us about the kind of mess it could potentially cause. Satoshi's "menace to the network" statement was maybe a bit vague.

On the discussion of alternative implementations, I am torn; I think it's a double edged sword, largely because the potential upside is real. That being said, Satoshi has a point.

The hell of a mess he was referring to would be a fork, or some other disastrous scenario where an alt implementation is not kept up to date with changes to source or was poorly implemented in the first place. Or perhaps it's not prepared for some fringe race condition. Who knows... what might happen exactly depends on the context.

I don't take a side in this debate, because honestly it wouldn't be appropriate given my programmatic experience (or lackthereof). Regardless, these are real issues with real consequences.

[hivewallet]

On the discussion of alternative implementations, I am torn; I think it's a double edged sword, largely because the potential upside is real. That being said, Satoshi has a point.

The hell of a mess he was referring to would be a fork, or some other disastrous scenario where an alt implementation is not kept up to date with changes to source or was poorly implemented in the first place. Or perhaps it's not prepared for some fringe race condition. Who knows... what might happen exactly depends on the context.

I don't take a side in this debate, because honestly it wouldn't be appropriate given my programmatic experience (or lackthereof). Regardless, these are real issues with real consequences.

Right. Vague memory of a conversation between Peter Todd, Greg Maxwell, and Pieter Wuille in San Jose this year about that very subject...

[MoonShadow]

Satoshi had a point.  He hasn't been here for some time, and his comments were relevent to the state of Bitcoin at that time.  The main client was still, itself, very rough.  Very much still beta.  IT's also a monolithic implimentation.  Which is fine for early work.

We are beyond early work.  I have long complained that the main bitcoin client didn't have simple unix like tools.  Libbitcoin seems to intend to be that set of unix tools.  I want to be able to pipe a transaction to a file, move it with a usb sneakernet, and pipe it to the bitcoin network on another machine.  I want a client that can do this for me, automaticly.  I want a client that I can create the keypairs on one machine, and manage the funds on a headless server half way around the world, without either of those machines even knowing the IP address of the other.  I want an online wallet service client that can logic bomb my funds onto the bitcoin network if tripwire is activated.  If the tools exist to perform each of the simple operations that the bitcoin client performs; then clients that can do a great many things can be developed to suit small group needs.

[jedunnigan]

Satoshi had a point.  He hasn't been here for some time, and his comments were relevent to the state of Bitcoin at that time.  The main client was still, itself, very rough.  Very much still beta.  IT's also a monolithic implimentation.  Which is fine for early work.

We are beyond early work.  I have long complained that the main bitcoin client didn't have simple unix like tools.  Libbitcoin seems to intend to be that set of unix tools.  I want to be able to pipe a transaction to a file, move it with a usb sneakernet, and pipe it to the bitcoin network on another machine.  I want a client that can do this for me, automaticly.  I want a client that I can create the keypairs on one machine, and manage the funds on a headless server half way around the world, without either of those machines even knowing the IP address of the other.  I want an online wallet service client that can logic bomb my funds onto the bitcoin network if tripwire is activated.  If the tools exist to perform each of the simple operations that the bitcoin client performs; then clients that can do a great many things can be developed to suit small group needs.

Very good points. I am in agreement in many respects; I think modular nodes are vital (see: Bits of Proof). We can't wait for the core devs to do everything, that's not fair. We just need to make sure we are very careful and meticulous in our preparations...

[kjj]

Satoshi is exactly right about alternate implementations.  They are hard to do right, and can cause a hell of a mess when done wrong.

But, it comes down to which of the two bad options do we like least.  Virtually no one currently active on the project wants a monoculture.  We are willing to take on the challenges and risks of multiple implementations because we feel that the risks of having just a single client are even worse.

Perhaps he'll turn out to have been right about this too, in the long run.  We should be able to answer that question fairly well in another 10 or 20 years.

Talk to us about the kind of mess it could potentially cause. Satoshi's "menace to the network" statement was maybe a bit vague.

Each node validates network messages.  If some nodes think that a block or transaction is valid, while other nodes think it is invalid, you can have a fork.  This is what happened when the BDB bug hit a while back.

In the case of the BDB bug, the people running the network (aka, "us") decided that we'd invalidate one fork to re-merge the network.  This option is not likely to be possible or practical for all such forks in the future.  In particular, as more implementations start up, the fraction of the network hurt by any given fork will grow smaller and smaller and at some point the majority will refuse to insert bug compatibility.

In practice, this will cause accidental or intentional forks at small numbers of nodes.  As in, someone may be able to carefully craft a transaction or block that will knock one node out of sync, with the intention of doing mischief to that node.  Equally possible will be that such things will just happen by chance, and some times they will go unexploited, but other times people will lose money because of it.

The only real safety is to be running the exact same software as the majority, and in the exact same environment.  Note that the BDB thing didn't hit all nodes that it potentially could have hit, because it depended partially on the environment.*

The monoculture carries different risks, but it is largely resistant to these sorts of problems.

Are you familiar with the Brown M&Ms thing from rock history?  It was parodied in Wayne's World II.  But it was there for a reason.  Van Halen put on a huge show, and to do it safely, they had a list of detailed technical requirements they presented to the local promoter.  The brown M&Ms were a canary.  If the promoter forgot that step, it was assumed that the other things in the contract had also been neglected, so they had to check everything personally.  If the promoter presented the M&Ms correctly, it was likely that they were careful with everything else too.

In a similar way, the people that are most familiar with the software have a sort of list of likely forks points in the code, where if someone gets it wrong, their node will (or at least can) eventually fork from the rest of the network.  When someone posts a new implementation, they can check a few of those, and if they aren't done right, the devs are pretty safe saying "Your code has big obvious flaws.  It probably has other more subtle flaws too.  Please do not let anyone use this code until you can show that you really understand the reference software."

*  I run one ancient node for amusement.  By some quirk of fate, it was not hit by the BDB thing, even though it really should have.  I think that all of my nodes that are merely old did get hit by it.

[MoonShadow]

Satoshi is exactly right about alternate implementations.  They are hard to do right, and can cause a hell of a mess when done wrong.

But, it comes down to which of the two bad options do we like least.  Virtually no one currently active on the project wants a monoculture.  We are willing to take on the challenges and risks of multiple implementations because we feel that the risks of having just a single client are even worse.

Perhaps he'll turn out to have been right about this too, in the long run.  We should be able to answer that question fairly well in another 10 or 20 years.

Talk to us about the kind of mess it could potentially cause. Satoshi's "menace to the network" statement was maybe a bit vague.

Each node validates network messages.  If some nodes think that a block or transaction is valid, while other nodes think it is invalid, you can have a fork.  This is what happened when the BDB bug hit a while back.

In the case of the BDB bug, the people running the network (aka, "us") decided that we'd invalidate one fork to re-merge the network.  This option is not likely to be possible or practical for all such forks in the future.  In particular, as more implementations start up, the fraction of the network hurt by any given fork will grow smaller and smaller and at some point the majority will refuse to insert bug compatibility.

In practice, this will cause accidental or intentional forks at small numbers of nodes.  As in, someone may be able to carefully craft a transaction or block that will knock one node out of sync, with the intention of doing mischief to that node.  Equally possible will be that such things will just happen by chance, and some times they will go unexploited, but other times people will lose money because of it.

The only real safety is to be running the exact same software as the majority, and in the exact same environment.  Note that the BDB thing didn't hit all nodes that it potentially could have hit, because it depended partially on the environment.*

The monoculture carries different risks, but it is largely resistant to these sorts of problems.

Are you familiar with the Brown M&Ms thing from rock history?  It was parodied in Wayne's World II.  But it was there for a reason.  Van Halen put on a huge show, and to do it safely, they had a list of detailed technical requirements they presented to the local promoter.  The brown M&Ms were a canary.  If the promoter forgot that step, it was assumed that the other things in the contract had also been neglected, so they had to check everything personally.  If the promoter presented the M&Ms correctly, it was likely that they were careful with everything else too.

In a similar way, the people that are most familiar with the software have a sort of list of likely forks points in the code, where if someone gets it wrong, their node will (or at least can) eventually fork from the rest of the network.  When someone posts a new implementation, they can check a few of those, and if they aren't done right, the devs are pretty safe saying "Your code has big obvious flaws.  It probably has other more subtle flaws too.  Please do not let anyone use this code until you can show that you really understand the reference software."

*  I run one ancient node for amusement.  By some quirk of fate, it was not hit by the BDB thing, even though it really should have.  I think that all of my nodes that are merely old did get hit by it.

This is all fine opinion, but this is still all conjecture.  It's also one reason that we have the running testnet, so alternate clients can test their functions against a running network before going live on the main network.  Libbitcoin isn't the first alternate client either, as a couple of different simple clients have been written in Java and Python.  Notablely, those clients were developed after Satoshi disappeared, and they managed to not break anything.  The network is rather resilient, actually.  The bugs are only a problem when they are discovered in a client that has been widely adopted already.  The BDB bug was in the main reference client.  It's impossible to protect against all screwups.

[MykelSilver]

Feel very stupid to ask this question: Can the bitcoins of the original bitcoin-qt client and the libbitcoin client be transferred to each other? Or are the coins completely different?
I really a start for dummies about libbitcoin. Any other links than http://libbitcoin.dyne.org/ and http://bitcoinmagazine.com/6234/what-libbitcoin-and-sx-are-and-why-they-matter/ are welcome.  Reason I am interested in libbitcoin is that I am worried about my stack of bitcoins being destroyed by any possible government intervention in the future. Looking for a possible exit in case of an emergency. Thanks in advance.
EDIT: Just found http://www.indiegogo.com/projects/bitcoin-dark-wallet
Really interesting stuff.....

[K1773R]

Feel very stupid to ask this question: Can the bitcoins of the original bitcoin-qt client and the libbitcoin client be transferred to each other? Or are the coins completely different?
I really a start for dummies about libbitcoin. Any other links than http://libbitcoin.dyne.org/ and http://bitcoinmagazine.com/6234/what-libbitcoin-and-sx-are-and-why-they-matter/ are welcome.  Reason I am interested in libbitcoin is that I am worried about my stack of bitcoins being destroyed by any possible government intervention in the future. Looking for a possible exit in case of an emergency. Thanks in advance.
EDIT: Just found http://www.indiegogo.com/projects/bitcoin-dark-wallet
Really interesting stuff.....

you dont transfer coins around, you would transfer privkeys. as the protocol is the same, you just have to import the privkey and you (obviously) have access to all the coins

[MykelSilver]

you dont transfer coins around, you would transfer privkeys. as the protocol is the same, you just have to import the privkey and you (obviously) have access to all the coins

Very cool. Thx for sharing.