Like I'd really appreciate for others to make a company around this,
bring money and pay developers. There is a big demand for services
around this and commercial products but I can't manage everything and
write good code.

If I have 2 Python developers, and some money helping me that's all I
need to build all this stuff. I have one part-time dev helping me
because he believes in this but he has his own projects (Bitcoin
also). He's already been a massive boost (he created the Python
bindings, I just perfected them).

For more information on my technical design see:

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

On 16/06/13 16:20, Amir Taaki wrote:
> 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
>
> _______________________________________________ unSYSTEM mailing
> list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>