Messages

blockchains that I expect to exist in the future:
1) store of value (bitcoin)
2) prediction markets
3) bounty market/assassination market
4) anonymous mixing. use bitcoin which is tainted with your identity to buy anoncoin, participate in a mixer, then use your now anonymous anoncoin to purchase bitcoin.
5) forum/social network/blogging (bitmessage and twister are early examples)
6) p2p games of perfect knowledge, particularly games which are resistant to artificial intelligence: go, chess, 6-in-a-row, amirra, goofspiel, civilization
7) slot machine games: blackjack, satoshidice, etc.
lotteries
9) votecoin. one address per citizen. This type of coin is evil. My hope is that all the good developers will refuse to make it.

I expect every blockchain to have coins with an exchange rate against bitcoin.
I do not expect anyone to use side-chains.
I do not expect any of this to be built on top of bitcoin.

I spend my time trying to make a very simple blockchain which can be used as a starting point to build any of the blockchains listed above. https://github.com/zack-bitcoin

just a suggestion: http://legacy.python.org/dev/peps/pep-0008/

The discussion has forked and IDK which thread you check, here's my response/question on btstalk:

I'm arguing FOR one blockchain to rule them all. If someone argued against it, I would expect them to (at a bare minimum) describe one hypothetical situation where a blockchain would be required that did NOT involve the storage of money (Bitcoin) or escrow of money (Truthcoin).

Hmmm...

* We need a blockchain that can handle 1000x TC's transaction volume (bandwidth) at some given time for the purpose of currency exchange
* We need a blockchain that can handle 1000x TC's storage at a given time for the purpose of domain name record storage

So these two only work if resources available >> resources needed, but for any given resource bound there is a range where the specialized one can succeed and TC can't.

The more important one:

* We need a blockchain where the value of the equity reflects the service performed by the nodes running the network to attract more such "useful" nodes, which means mapping core asset creation/destruction to particular operations.

Are you claiming that all possible incentive structures that need control over their token can be somehow simulated with PMs?

Contracts are by definition all on the some chain, as long as they don't use separate meta-protocols they are inherently compatible so saying "cross-contract" makes it sound more impressive than it is.

What sort of contracts wouldn't use meta-protocols? For an autonomous system to be a proper value-adding mechanism doesn't it need to have total sovereignty over its native token, otherwise it is at best a service like coloredcoins, right? Do you expect Ether to be used as the unit of account for the most popular dapps?

[edit: ah, I just saw cross-chain atomic *transaction* and not trading. NVM, we do not have that planned for the short term.]

Eg if separate bitShares chains were all capable of doing cross-chain atomic transactions with each other, that kind of protocol-compatibility would be something to brag about (but please not in the all-too-common way entrepreneurs in this space tend to oversell their products, and claim to have features long before they are actually implemented).

Of course we cannot brag before we have it but atomic cross-chain trading is a critical feature and essential to having a powerful market peg for all chains that implement BTS X. It had been implemented in previous alpha iterations and it was in the original whitepaper long before "bitshares" was given a promotion to refer to all chains and not just what is now called the BTS X family.

edit:  ah, I just saw cross-chain atomic *transaction* and not trading. NVM, we do not have that planned for the short term.

This will cost some $ but is more than worth it. If successful will it would make $$

How would it make money? Capital appreciation? Bitcoin is unprofitable without constant infusion of capital, are you going with that model?

Consider the DAC *metaphor* for truthcoin. The first thing you did right is that you are not paying miners more than TC is making as income from fees. So you are cash-flow positive once you are off the ground, except that cash isn't being funneled to further the project but sort of spread out to whoever can afford to run the miners profitably.

Now you need something analogous to capital infusion. I've suggested mastercoin/AGS style fundraiser as a way of initially allocated the initial <votecoins/truthcoins I forget>.

In our dpos chains we have the ability for delegates to pledge some of their "miner revenue" to particular causes to help build the DAC.

I don't think this is possible in any system where you can't "downvote" the pool operators, since they will just offer their revenue to whoever supports them.

I think if you made a POW variant where all hashes still contribute to security but you can hash "for" or "against" a pool operator, then the pool operators are forced to do something to further the cause of Truthcoin with their income.

Now I agree with you on that, but I am not sure the needs of the services that requires reliability will be meet with only two blockchains.

Yep, this is really the main selling point. If you could convince me ethereum would be as cheap and as decentralized (look at GHash.io for BTC....) as 1000 individual blockchains then I'd agree with you.

Now instead of a browser opening an HTTP connection to a web server in front of a daemon API, replace all that with a webkit view provided by a native client, with a direct hook API into the blockchain. The contract/DApp author creates the special-purpose UI in html/js, as a client-side html5 app (nothing more than a few html and js files). This is the DApp front-end, a zip of html/js files which call the ethereum hook API functions. The ethereum client opens them up in a webview, displaying to the user some buttons and forms for sending transactions and data to the contract (with access-control to the user's wallet, similar to how iOS apps do a password pop-up for in-app purchases).

bitshares clients are also going this route, so the only difference is whether the backend is written in LLL or c++.

So I think Ethereum's advantage here shows for stuff that deals simultaneously with separate contracts / DACs, like cross-chain (cross-contract?) trading between totally disparate chains/contracts. But in either case, both sides have to implement something on their end (and both will have out-of-the-box solutions to let you do it).

I think this is the right approach, Qt-based bitcoin clone UIs are all terrible.

sorry to derail but
holy fucking shit are you THE gwern? Big fan here...

Luckily, SVD happens to be efficiently-verifiable and so it should be rather simple to outsource the computations (again, the contract only verifies the solution).

Who pays for this outsourced comp time, and with which token? Not a counterpoint, just curious about the design.

and maintaining the full client/server stack customized around that one single coin (the GUI, the client, the server daemon and rpc-API, a web API, all the plumbing, and so on).

If you are using an embedded token inside ethereum, wouldn't you also need to do all of this? The ethereum team probably isn't going to be building special-purpose UI elements for every single smart contract in their blockchain or build RPC calls for exchanges to deal with special-rule embedded token, right? The only things you get out of the box are things present in bitcoin or bitshares as well (client/rpc/wallet shells).


It seems we disagree about whether special- or general-purpose is better, but our reasons are almost identical. I'd say, "special-purpose is better because you aren't tied to an existing decentralized infrastructure, so you can optimize around constraints related to the blockchain itself". It just comes back to comparing feature lists in a space there isn't much precedent in.

I suppose time and the market will tell.
IMO the best answer is, "why not both?" (or all four, in this case).

If I didn't already like James and Paul, I would say "I hope so, only to demonstrate the futility of going after the creators of systems like this!"

Another reason for doing an initial distribution more favorable to the creators than just BTC airdrop: If it becomes a success then they should have enough money to move to a tropical island and hire bodyguards =)

[the principle of building a network (and building network effects)]

I'm only giving the coins to miners as they mine in the future. The rest of the coins are going to Bitcoin owners.

Satoshi solved the allocation problem by distributing the coins not to whoever he thought deserved them, but to anyone interested enough in Bitcoin to prove that interest by CPU mining. The point was that he didn't make it about himself, or his preferences (because there are a lot of people in the world, who could have copied Bitcoin and made it about themselves or their preferences), but instead made it on the principle of building a network (and building network effects). That is what I am trying to emulate.

Its not about copying Bitcoin because Bitcoin is good, its about plugging into the best network.

Ah, that makes sense.

Still, I'm curious about why you care about network effect if you don't have anything to lose from a fork attempt. You could pick an allocation that is more favorable to yourself, and if it gets forked to pure BTC then you are no worse off than if you had started with a pure BTC distribution to begin with. (I'm assuming you're not secretly a large BTC holder).

Of course the *perception* that mining is "fair" might make you more resistant to a fork. But do you care about fork resistance if you're giving away the vast majority of the equity to a few miners?

[more]

If you read Satoshi's whitepaper, you'll see the blockrewards were distributed to miners for two reasons. Firstly, they provided subcontracting, but secondly they "[provided] a way to initially distribute coins into circulation". Kaldor-Hicks (profitability) is not enough, a value network must be a Pareto Improvement (incentive compatible for a critical mass) to get people to switch and re-create the network effects of money (which are paramount). This second reason contributed more to Bitcoin's success, in my view, than the first "subcontractor" reason. If Satoshi had given (not mined) any coins to himself, he would invite an immediate fork(s) of the project, and critical mass and network effects would never have emerged.

This worked because bitcoin was cpu mined for a huge chunk of the initial distribution. Claiming that mining gives a widespread distribution is ignoring the reality that mining power is *extremely* centralized, not much better than the few project leaders giving all shares to themselves.

Since the Bitshares Toolkit is moving to a relational database

Have to add that every time I've said "relational" I really meant "transactional" - there's no relational algebra happening on the blockchain.
Of course the functionality you can implement is still the same - just a nitpick.

This is very interesting chicken-and-egg problem. AGS/PTS represents the Bitshares community, which is valuable if it is valuable and valueless if it is valueless.

I would imagine such a community would want to get one really simple, solid, successful product release out early, and have something really ambitious in the pipe.

I agree with the focus (for blockchain projects) on the network effect, which is exactly why I'm interested in a Bitcoin snapshot for the 'money'.

Now that I understand better: "Truthcoins" should be allocated to whatever you decide is most "fair" or marketable - like bitcoin airdrop. "Votecoins", the things that earn income from the network's operation, should drop on AGS/PTS/proto-truthcoin(fundraiser)/premine, etc