[libbitcoin] First stepsThis tutorial will create a simple program in Python using libbitcoin’s Python bindings to read the version information of a remote bitcoin node. We will need to connect to the bitcoin node and send it a version packet. The other bitcoin node should respond back with their own version packet which we can examine.
|
|
|
[libbitcoin] First stepsThis tutorial will create a simple program in Python using libbitcoin’s Python bindings to read the version information of a remote bitcoin node. We will need to connect to the bitcoin node and send it a version packet. The other bitcoin node should respond back with their own version packet which we can examine.
|
|
|
libbitcoin is licensed as Lesser AGPL: - When used in the p2p network, you only need to provide changes on demand (LGPL). - When used on a webserver, you must proactively provide sourcecode for any changes you have made to libbitcoin. - Applications can link against libbitcoin, and they do not need to release their changes publically. Thanks to Aaron Williamson of the SFLC and Richard Stallman of the FSF for helping draft up this license.
|
|
|
Catherine Flick: Bitcoin and the Dual-Use DilemmaWhen me and Martin Dittus held the Bitcoin Weekend at the London Hackspace, Catherine Flick sent us this video on her research into bitcoin as a computer ethicist. Catherine is a researcher in technology ethics at Middlesex University. She started investigating the potential social and ethical impact of Bitcoin, and is currently evaluating a first survey.
|
|
|
Python bindings + tutorials are going to be released later this week: import bitcoin import time
class Application:
def __init__(self): self.stopped = False self.net = bitcoin.network() self.channel = None
def start(self): self.net.connect("localhost", 8333, self.handle_connect)
def stop(self): self.stopped = True
def is_stopped(self): return self.stopped
def create_version_message(self): vers = bitcoin.version() vers.version = 60000 vers.services = 1 vers.address_me.servies = 1 vers.address_me.ip = \ [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 255, 255, 127, 0, 0, 1] vers.address_me.port = 8333 vers.address_you.services = 1 vers.address_you.ip = \ [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 255, 255, 127, 0, 0, 1] vers.address_you.port = 8333 vers.user_agent = "/libbitcoin:0.4/example:1/"; vers.start_height = 0 vers.nonce = 42 return vers
# First we send our version message then the node will reply back def handle_connect(self, ec, channel): # check the error_code if ec: print 'Could not connect:', ec self.stop() return self.channel = channel version_message = self.create_version_message() self.channel.send_version(version_message, self.handle_send) self.channel.subscribe_version(self.read_version_reply)
def handle_send(self, ec): if ec: print 'Problem sending:', ec self.stop()
def read_version_reply(self, ec, vers): if ec: print 'Problem in reply:', ec self.stop() return # Display the version message back print vers.address_me.ip self.stop()
if __name__ == "__main__": app = Application() app.start() while not app.is_stopped(): time.sleep(0.1)
Some more stuff (crappy/hackish testing files): import bitcoin
d = bitcoin.data_chunk("001212") print d h = bitcoin.hash_digest("000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f") print h if h == "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f": print 'Yes' print len(h)
tx = bitcoin.transaction() print bitcoin.hash_transaction(tx)
netaddr = bitcoin.network_address() print netaddr.ip
s = bitcoin.script() o = bitcoin.operation() o.code = bitcoin.opcode.special s.push_operation(o) o.code = bitcoin.opcode.nop o.data = bitcoin.data_chunk("deadbeef") s.push_operation(o) o = bitcoin.operation() o.code = bitcoin.opcode.hash160 s.push_operation(o) print s print s.operations() print s.type()
import bitcoin
raw_tx_repr = "010000000187493c4c15c76df9f69ddd7aeb7ffbcddad4b7a979210f19602282d5b9862581000000008a47304402202d9e9f75be9c8a4c4304931b032e1de83fd2c6af2c1154a3d2b885efd5c3bfda02201184139215fb74499eae9c71ae86354c41b4d20b95a6b1fffcb8f1c5f051288101410497d11f5c33adb7c3fed0adc637358279de04f72851b7b93fb4a8655613729047c7e2908966551b5fb7f6899f6c3dd358b57eb20a61b2c9909aa106eac6310f9fffffffff0140420f00000000001976a91407e761706c63b36e5a328fab1d94e9397f40704d88b000000000" raw_tx = bitcoin.data_chunk(raw_tx_repr) print raw_tx print len(raw_tx)
ex = bitcoin.satoshi_exporter() tx = ex.load_transaction(raw_tx) print "txhash", bitcoin.hash_transaction(tx) print tx print ex.save_transaction(tx) print len(ex.save_transaction(tx)) assert str(ex.save_transaction(tx)) == raw_tx_repr import bitcoin
ec = bitcoin.elliptic_curve_key() print ec.new_key_pair() privdat = ec.private_key() print privdat
ec1 = bitcoin.elliptic_curve_key() ec1.set_private_key(privdat) assert str(ec1.private_key()) == str(privdat)
h = bitcoin.hash_digest("f003f0c1193019db2497a675fd05d9f2edddf9b67c59e677c48d3dbd4ed5f00b") print h sig = ec1.sign(h) print ec.verify(h, sig)
|
|
|
Founder of world’s largest ponzi company pimps bitcoinSergei Mavrodi was the founder of MMM, a Russian company that perpetuated one of the world's largest ponzi schemes of all time during the 1990s. Around 5 to 40 million people lost up to $10 billion. Its founder was eventually found guilty of defrauding 10,000 investors of $4.3 million and sentenced to four and a half years in a penal colony.
|
|
|
This talk needs more love! I think what you guys are doing is fantastic.
|
|
|
BitTalk.TV Stefan Thomas interviewStefan Thomas discusses bitcoin’s direction. There are many big speakers in the community, but Stefan is an actual developer having contributed a useful library that has enabled several interesting sites and wallets to exist. He understands the protocol and core code. And the bitcoin introduction video on the WeUseCoins website.
|
|
|
Red Emerald: As the codebase matures I'll start adding a ton of comments. The thing I hate more than uncommented code is out of date comments. License will now be Lesser AGPL.
You mean the Lesser GPL (LGPL) license, right? http://www.gnu.org/licenses/lgpl.html To my (very limited) knowledge, a Lesser AGPL license doesn't exist. I'm collaborating with the SFLC/FSF to sort that out. They resolved a bunch of licensing issues for me already. First tutorial (of many) is written. Just a high level overview. Next one should have some code, and then we'll go back and break everything down as we go along. [libbitcoin] Overviewlibbitcoin is a bitcoin library targeted towards high end use. The library places a heavy focus around asychronicity. The enables a big scope for future scalability as each component has its own thread pool. By increasing the number of threads for that component the library is able to scale outwards across CPU cores. This will be vital in the future as the demands of the bitcoin network grow. I tried to explain the design principles behind libbitcoin and why things are done how they are.
|
|
|
A little bit of a techy article/tutorial: [libbitcoin] Overviewlibbitcoin is a bitcoin library targeted towards high end use. The library places a heavy focus around asychronicity. The enables a big scope for future scalability as each component has its own thread pool. By increasing the number of threads for that component the library is able to scale outwards across CPU cores. This will be vital in the future as the demands of the bitcoin network grow.
|
|
|
More important than the flaw itself, is that it perhaps suggests that code changes are being made without proper review. I'd prefer to see a more conservative approach even if it meant a much slower development cycle.
Actually there is. I pointed this out to Gavin months ago in private chat but he disagreed with me. I still don't think the change was a good one. You don't comment out 2 lines of code because it produces a 6 hour speedup. The proper way is to restructure the code nicely but that takes more effort.
|
|
|
OK, I'm getting ready to finalise a 1.0 release by the end of this month (Feb).
License will now be Lesser AGPL. You can link and use libbitcoin in your closed source project, but the changes you make to libbitcoin must be public. I will give explicit permission through email to people 'myusername'@riseup.net (signed with my GPG key) if you want to be sure.
Will be heavily documenting and writing tutorials soon.
On the development front: - I have written a blockchain fuzzer which I will use to stress test the blockchain algorithm. - Node discovery needs to be completed (should be easy- the tricky part is designing a good API). - A high level synchronous interface for easy programming and integration of bitcoin in your project. This might not make it to 1.0 release. fellowtraveler, this is what you're asking for.
Right now the project is still rough around the edges, but it is rapidly approaching production capability in a rough way. We will have to smooth out some things while using it and the API may change a lot early on. I will also be making a test client as a proof of concept in order to perfect the API better.
libbitcoin requires advanced C++ knowledge (for now). It is heavily built around asynchronous interfaces and the library is thread safe. An understanding of thread contexts is required but I'll document this in the tutorials.
|
|
|
Cyber revolt!You got up, you worked, you slept, you died. Loyalties were to our immediate family, maybe our community. Work was only a means to provide for your family. Your ecology might only be your town (villages by today’s standards). Tribal or national boundaries were strong as a foreigner was strange. Unusual. Not a common occurence.
|
|
|
The concept of "team" is very important in all organizations and maybe even more so in open source projects. Team interaction and communication is key. If a person cannot communicate, lay down his ego, or continually brings up old issues then the whole team breaks down resulting in software paralysis.
Nope. Bitcoin is not a team. It is many teams in a community and part of a process. In project development, relationships aren't always and sometimes shouldn't be cordial. For instance a regulator and the company they are overseeing, should not have a cordial relationship. Or upstream and downstream if they are functioning properly will have a contentious relationship; I've had some vicious past arguments with downstream before but we remained amicable and professional while disagreeing. http://fedoraproject.org/wiki/Staying_close_to_upstream_projects#Tips_On_Upstreaming_PatchesMany of the characterisations I see people making all the time comparing bitcoin to a business, a team or charity (to name a few) are unrealistically simple and naive.
|
|
|
can we see theymos idea + non-backwards compatible new standard?
a blockchain fork will have to happen in the future.
see this as a good testbed, practice run or training level.
if we cannot get it right then bitcoin is doomed.
|
|
|
Miners (as a group) should not be given any say over issues like this. They do not necessarily know what the best option is. The issue should be decided by people very familiar with the protocol and the proposals.
I suggest that we compile a list of everyone who knows a lot about the Bitcoin protocol, invite them to a two-week discussion via email, and have those who participate in the discussion vote on the issue at the end of the two weeks. If one proposal gets enough votes (two-thirds, say), then Bitcoin clients will be programmed to apply the new restrictions ~3 months in the future. Miners will have to upgrade by then or their blocks will not be recognized by most clients. If there aren't enough votes for any proposal to pass, the issue will be shelved for a while.
I strongly agree and support theymos' proposal: http://bitcoinmedia.com/cathartic-progress/I propose theymos as the organiser. The organiser will be entrusted with running the system to take the votes. They will organise the platforms and structure the discussions to promote neutrality. theymos is a trusted long-term member of the community. His running of blockexplorer qualifies him technically; he is intimate with the code and issues. He has demonstrated a neutral objective character as the moderator of the bitcointalk forums. I think he's a good choice here.
|
|
|
|