Fwd: <nettime> Ten years in, nobody has come up with a use for blockchain

[\0xDynamite]

The CYPHERPUNK, a F/oss monthy

"A zine about internet culture, urban nomadism, and post-industrial
life (via radical sustainability and low-watt FM radio).  Taking back
the internet commons from the large-media conglomerates, providing
recipes for mental liberation, and strapping down the inhuman machine
that has become the American populace, putting on a harness, and
riding it like a bucking cowboy.  If you know how to code, this zine
is for you.  For those who are neophytes, Floss stands for “free,
libre, open-source software”.  The computer is a lawmaker, this is for
the liberators of the machine."

Anyone interested in writing an article?

\0xd

On 12/31/17, \0xDynamite <dreamingforward at gmail.com> wrote:
> There is a killer app though.
>
> On 12/31/17, jamesd at echeque.com <jamesd at echeque.com> wrote:
>> On 12/31/2017 10:01 AM, Steven Schear wrote:
>>> I'm still hoping a new cryptocoin/fork implements a client-determined
>>> miner selection capability similar to what we suggested in that 2013
>>> paper I've mentioned here.
>>
>> I cannot immediately find your link to your paper.
>>
>> Obviously, at full scale we are always going to have immensely more
>> clients than full peers, likely by a factor of hundreds of thousands,
>> but we need to have enough peers, which means we need to reward peers
>> for being peers, for providing the service of storing blockchain data,
>> propagating transactions, verifying the blockchain, and making the data
>> readily available, rather than for the current pointless bit crunching
>> and waste of electricity employed by current mining.
>>
>> The power over the blockchain, and the revenues coming from transaction
>> and storage fees, have to go to this large number of peers, rather than,
>> as at present, mostly to four miners located in China.
>>
>> Also, at scale, we are going to have to shard, so that a peer is
>> actually a pool of machines, each with a shard of the blockchain,
>> perhaps with all the machines run by one person, perhaps run by a group
>> of people who trust each other, each of whom runs one machine managing
>> one shard of the blockchain.
>>
>> Rewards, and the decision as to which chain is final, has to go to
>> weight of stake, but also to proof of service - to peers, who store and
>> check the blockchain and make it available.
>>
>> All durable keys should live in client wallets, because they can be
>> secured off the internet.  So how do we implement weight of stake, since
>> only peers are actually sufficiently well connected to actually
>> participate in governance?
>>
>> To solve this problem, stakes are held by client wallets.  Stakes that
>> are in the clear get registered with a peer, the registration gets
>> recorded in the blockchain, and the peer is gets influence, and to some
>> extent rewards, proportional to the stake registered with it,
>> conditional on the part it is doing to supply data storage,
>> verification, and bandwidth.
>>
>