BTW I need help on everything.
Here are some basic tasks:
- - I have a full node daemon which you can interact with over Apache
Thrift RPC and it publishes over ZeroMQ. Thrift isn't asynchronous, so
I want to replace it with ZeroMQ reqrep. ZeroMQ is also a much more
powerful library which can scale to create massive clusters.
I have a full node daemon with the RPC written both in Python (using
libbitcoin Python SWIG bindings) and C++ (using libbitcoin). I also
have a fullnode example written in C (using experimental libbitcoin C
wrapper). It's easy to add the RPC stuff to the C example.
- - I need packages for libbitcoin in the Debian repos. I can offer a
bounty even of 600 EUR for this. Otherwise just having packages anyway
would be really great. I have 2 Debian devs willing to mentor anyone
who wants to do this.
- - An extension library for libbitcoin of common classes, utilities and
functions people need. Like a layer of additional things on top
without complicating core libbitcoin.
- -- 'reactorloop'. Loop, and wait for sigterm signals, all app to exit
using a simple barrier and spinlock.
(see the while loop in main()
http://libbitcoin.dyne.org/doc/network.html#tut-protocol )
- -- 'wallet'. I have a design for a great wallet. But this should maybe
be left until last.
- -- 'fullnode'. The fullnode example is something I'd reusing a lot in
projects. Would be good to have it there as something you can inherit
and it will call your stubs when a new block arrives .etc Also gives
you access to all the underlying services in case you want to do
something deeper inside libbitcoin.
http://libbitcoin.dyne.org/doc/examples/fullnode.html
- -- 'sync_blockchain'. Synchronises the asynchronous blockchain
methods. I don't really want people to use this in their projects, but
I recognise it is something people want. It is very useful though for
testing concepts against the blockchain with minimal effort.
https://github.com/genjix/query/blob/master/src/sync_blockchain.hpp
- - Wallet. This is really cool. Your wallet is on disk. You can encrypt
it by mounting an encrypted file share or store it in memory using
tmpfs. You have a directory/file based system instead of using a database.
(I've clipped the full addresses. -> denotes a symlink.)
wallet/
# Tags are arbitrary collections of keys.
tags/
foo/
1Afgoy....priv -> wallet/keys/1Afgoy... [symlink]
1Fufjp....priv -> wallet/keys/1Fufjp...
bar/
1CJAWj....pub -> wallet/keys/1CJAWj..
a56fea....seed -> wallet/det/a56fea...
keys/
1Afgoy....priv
1Fufjp....priv
# Public keys only from deterministic wallet
1CJAWj....pub
1KmeZr....pub
1AQzE9....pub
# Private keys from deterministic wallet
1BKxks....priv
12AYuB....priv
1EsKE6....priv
det/
# Two different deterministic wallet.
# One only has the master public key and so can
# only generate the public keys for that wallet.
# The other is a normal deterministic wallet.
#
# We know the number of keys in the wallet by
# the number of files in there.
a56fea....seed/
1BKxks....priv -> wallet/keys/1BKxks....priv
12AYuB....priv -> wallet/keys/12AYuB....priv
1EsKE6....priv -> wallet/keys/1EsKE6....priv
cc4add....mpk/
1KmeZr....pub -> wallet/keys/1KmeZr...
1AQzE9....pub -> wallet/keys/1AQzE9...
We lazy evaluate everything. No preloading is done.
I'd add a hook to later enable .enc encrypted versions of the files
(.pub.enc instead of .pub, or .seed.enc -> .seed, .priv.enc -> .priv)
so the owner of the wallet doesn't need to manage the encryption.
You can find the tags for an address by doing a quick 'find' inside
the tags directory to see all the tags an address is inside. This
should be relatively fast for thousands of files.
DeterministicWallet
PrivateKey
PublicKey
.add_tag(name)
.remove_tag(name)
.tags()
.export()
DeterministicWallet
PrivateKey
.save_public()
.unlink()
-> remove symlinks.
-> remove wallet manager's watched addrs.
DeterministicWallet
.addrs()
.new_addr()
WalletManager
.watched_addrs = {"1EsKE6...":
callback(pending_balance, paid_balance)}
.watch(addr, callback)
.unwatch(addr)
- - Improvements to libbitcoin. The protocol should be able to allow
max_outbound to be adjusted and a way to intercept version messages.
If we're in the initial blockchain download then new transactions
should be rejected. A way to estimate the latest block number from
other nodes by getting the median value. The seqlock write possibly
only needs to happen during database writes (investigate this).
- - Upgrade to a ZeroMQ Remote Request interface. I have the basic
design of the code already laid out. But I'm busy working on the
underlying C wrapper first.
On wire messages from client:
([METHODNAME] [ARG1] [ARG2] [ARG3]..., callback)
-> [...] [CHECKSUM]
rand_nonce created and added to request.
make_req(rand_nonce, data, callback)
make_req(rand_nonce, data, callback)
map[rand_nonce] = callback
retry_queue.push(timest, rand_nonce, data, callback)
send_req(rand_nonce, data)
Reactor:
update:
read_reply() # async queue
resend_expired_reqs() # async queue
read_reply()
while poll:
new reply received
remove reply from map
remove reply from retry_queue
call callback with arguments.
resend_expired_reqs()
for (request: retry_queue)
if (current_time - request.last_send_time)
send_req(request.rand_nonce, request.data)
Even pseudo C:
strict qbc_request_t
{
method_nonce
args
checksum (uint32_t - same as Bitcoin checksums)
callback (accepts an array of N strings)
rand_nonce
last_send_timest
};
The callback would assert if N args isn't the correct size it expects.
- - Payments API. You have a Wallet and the Daemon TCP connection
(Thrift or ZeroMQ).
Wallet:
- Manages your keys
- Create payments out (new Bitcoin transactions)
Daemon TCP connection to full node:
- Send payments out to Bitcoin network.
- Notify of new Bitcoin payments to wallet.
- Fetch history for an address.
wallet = Wallet(path)
...
new_key = PrivateKey(wallet)
privkey_data = new_key.export()
# Save private key somewhere.
# Then ask backend to notify you of new payments.
backend.notify(new_key.address(), my_callback(pending, paid))
- - Whistleblower software I mentioned in a previous email.
- - Tor bridges sold for Bitcoins. Would depend on above software.
- - Software/platform that people unpack to create a Bitcoin bank
(wallet service like blockchain.info - become your own bank).
I'm trying to do this all myself but am really under-resourced. Having
the packages for libbitcoin is fundamental to help me make all this.
More developers, more money. I'm only me working on this, and a little
help from Pablo sometimes.
On 16/06/13 14:00, Juraj Bednar wrote:
> Hi,
>
>> I don't know Dennet, but this looks like a good approximative
>> technique to skim through texts and find such linguistic fulcra.
>> However, once found, their existance doesn't confutes their
>> validity, which has still to be challenged out of emphasis.
>
> you're right.
>
>> the network that makes value cirtulate is not, and cannot be
>> ever, neutral: not even Bitcoin is, or the Internet itself,,
>> while having the merit of aiming to be more neutral than other
>> existing networks...
>
> It is not neutral currently (because it's mainly used by
> speculators, hackers, nerds and silk road users). The more neutral
> it gets the better. And probably the side-effect will be putting
> more of our values in the general public's heads. It's already
> happening. 15 years ago, there was almost no talk that FED is evil
> (and it was as evil as it is today). Now it's almost mainstream
> opinion (for those who know what FED is at least).
>
>> Value flows have been controlled for example by Wall Street,
>> where broad access was given to certain values instead of
>> others.
>
> I bet Wall Street is capable of doing anything that's not approved
> or endorsed by Washington. That's why I think the Occupy Wall
> Street thing is bullshit - they were on the wrong street.
>
> Wall Street does what everyone else does - what is best for them.
> The deformations were done in Washington, London with "sacred
> approval" of the voters who believe in democracy.
>
> The more free the market is, more neutral it's becoming. Or rather
> than "neutral" I would say it reflects the needs and wishes of it's
> users more.
>
> That's why I think Bitcoin has huge positive impact on this world -
> it enables us to value things ourselves and trade whatever we
> want.
>
>> It is not a coincidence that BRIC countries today are interested
>> in starting their own stock market infrastructure, because the
>> one in place and based on euro/dollars is biased for the
>> advantage of former colonial empires.
>
> I don't think the reason here is currency, the problem is
> regulation. Or it's at least a larger problem than currency.
>
>> however, the abstraction and approximation of my sentences here
>> make me somehow uncomfortable, I'd rather discuss this in person
>> over a coffee or beer.
>
> I'm sure we can do that soon enough. Await me to come unexpected
> with a lighted joint, which I'll happily share, but you are free to
> drink coffee or beer if you want as well :).
>
>> what I'm trying to state aided by broader geopolitical examples
>> is that it does not exist an infrastructure of exchange that is
>> open and purely constituted out of the equal sum of subjective
>> perception and participation: this is a rather unrealistic utopia
>> that omits the crucial question of network neutrality and
>> ultimately power from the picture.
>
> yes, this is for "in-person" talk, but the mistake as I see here is
> "sum". The moment you start counting aggregates, averages, sums,
> you are averaging away people's needs, perception of value, etc.
> And I think that's the major fault in current traditional economy.
>
> Economy should be value-neutral (i.e. it should not matter if you
> are buying half a kilo of weed, a gun or aspirin) which I believe
> translates to network neutral for Bitcoin.
>
> Anyway, to talk about the question of miner, I said that we need
> independent implementations and good, honest miners.
>
> We do not need to switch reference implementation to something
> else (that's too difficult, politically). We should do something
> else instead. Let's make it easy for miners to switch
> implementations and make sure they are not telling which one they
> use. Any protocol change would need to be put into all major
> implementations (thus removing "reference implementation"), because
> it would not matter what Gavin commits into his little tree, even
> if it's labeled reference, if miners refuse blocks it creates.
> They would need to balance threats from world's powers and fear of
> fork. I believe for Bitcoin, fear of forking is still higher.
>
> It does not and should not matter what's on bitcoin.org domain,
> but what people use (and that comes to miners). Miners have
> significant investments in Bitcoin and that makes it even better.
>
>> well put. yet I don't see how such a project can survive a
>> backdoor inserted by the lead developer on behalf of a national
>> espionage agency inside the main implementation of the tech.
>
> Do you use the main implementation? I don't.
>
>> Maybe the way out can be that other implementations become the
>> central reference?
>
> Or just the fact that we don't know what miners use, when they'll
> upgrade, ...
>
>>> I am also curious how will all of this proceed and I hope for
>>> the best, but I don't think hacker culture is responsible for
>>> any narratives.
>>
>> but i disagree with this. from the most recent example of
>> Wikileaks to other less globalized episodes in the past, hacker
>> culture is a motor for narration.
>
> My friends from Ztohoven have a nice phrase for this: "Media
> sculpture". They try to say something, but that's just the basic
> stone and it is sadly shaped into its final form by the media.
>
> We can try and we should try, but I believe that who understands
> us is probably a hacker anyway. And who does not gets most of
> information from the media. We are not controlling the narrative,
> we are mainly setting a theme. That's a start, but it can end up
> worse than it started and we have no control about the result.
>
> That does not mean we should not try.
>
> I am happy to share other stories less globalized episodes to
> explain what I mean later.
>
> Good luck,
>
> Juraj. _______________________________________________ unSYSTEM
> mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>