I'm meeting Thiel on the 21st, and presenting to eventures and others in
July. Happy to put this into a legal and commercial vehicle, Amir.

Going to need you to come over here probably. There are a number of
idealistic and talented valley kids who want to do the work.

crw
On Jun 16, 2013 9:30 AM, "Amir Taaki" <genjix@???> wrote:

> > 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
> >
> > _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>