Definitely. I will just go to this on 2 July.
http://st-artforum.com/participants
On 16/06/13 17:00, Cody R Wilson wrote:
> 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@???
> <mailto:genjix@riseup.net>> 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 <http://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
> <http://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
>
>
>
> _______________________________________________ unSYSTEM mailing
> list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
::
Re: [unSYSTEM] #NSA #PRISM #Hadoop …
