Messages

Suggesting that it'd be easier to build Truthcoin by making small modifications to bitcoin's codebase reminds me of a quote from this talk by Joe Armstrong: "Management thinks modifying legacy code is cheaper than a total rewrite." Granted, bitcoin is not as bad as legacy enterprise COBOL from the 1970s. But the Augur team's experience of modifying bitcoin to create "sidecoin" was what motivated the switch to ethereum script (even unstable as it is, it's still preferable).

The transition from "DApps as desktop apps" (ie. bitcoin-qt, electrum, openBazaar, namecoin, bitmessage, lighthouse, uTorrent, and so on) to "DApps in a browser" would be analogous to how the average internet user's software stack changed as web browsers became more powerful. Next to the Netscape 1.0 icon on windows 3.1, there was also a desktop app for newsgroups, another for e-mail, another for real-time chat, another for ftp, and so on. Nowadays, most people browse forums, send e-mail, and chat using different apps that run on the same higher-level platform (the web browser as "the new OS"). Ethereum is attempting to do something similar with crypto-currency/p2p clients. The vision for BitTorrent Inc.'s Project Maelstrom (also utilizing Chromium, like Ethereum's Mist) is along similar lines, but they're starting as a torrent client rather than as a crypto-currency client.

Decentral.ca is another accelerator that might be a good fit.

I'd be interested in joining a team.

Slick, nicely done.

Might as well share this old ipython notebook, a very incomplete work-in-progress.

[ownership]

Lotto is an example of value-storage. As I point out in my OP, that makes it blockchain-friendly, but you can do similar things with Truthcoin, as I also point out. My argument is that blockchains store ownership of value (and, possibly, names/'real estate').

A lottery mechanism needs the value to be transferred conditionally (or "purposefully" stored, as stated in your OP). SatoshiDice uses blockchain hashes to operate with provably-fair outcomes, but it is still centrally operated (so SatoshiDice can still steal funds, but they couldn't deny doing so). It is possible to implement a decentralized lottery in bitcoin script: here's an excellent tutorial.

Though a bitcoin script lottery has no central operator, it has other limitations, inherent in bitcoin script (particularly lack of state and value-blindness, as noted here). The bitcoin script lottery in the linked tutorial pays out 100% to a single winner. How about a lottery that pays out 80% to one winner, and 20% to another? How about a prize pool that rolls over, until some minimum threshold has been exceeded? You would be hard-pressed to do either of these, or any number of other variants, in bitcoin script.

The Ethereum argument is that a blockchain should store arbitrary state, ie. a blockchain should be viewed as a decentralized state machine. And with a powerful scripting language, the value can be transferred conditionally (conditional on the state of any variable stored in some contract).

How would TruthCoin support a wide variety of decentralized lotteries, without a scripting language?

Surely Eris and EtherEx are not user-level.

The a difference between an EtherEx exchange, and TruthCoin portfolio replication, is that on EtherEx the user would be able to actually buy/sell various crypto-coins. So EtherEx would be preferable to a user who is actually seeking delivery of DOGE. If all they care about is betting on the price change, then portfolio replication is sufficient. Also, portfolio replication is dependent on a reference price-feed from some other exchange (EtherEx would actually match trades, generating prices independently).

cryptocoinwatch would be an example of something a user might use - triggering a payment with a transaction, or as a function of a transaction. However, if a user had to use a machine to send a transaction, and have something else running (the Ethereum network?, another computer?), it isn't clear to me why a user wouldn't just authorize "whatever he was trying to trigger" directly.

If the users authorize the payments directly, then the payments are no longer atomic. It leads to the situation where I need to hand you a bitcoin, and you need to hand me a Truthcoin, but neither one of us trusts the other, so neither is willing to hand it over first. That's where a contract would help, by setting up a conditional transfer (only transfer the TRU, given a BTC payment) to be executed by the contract (as an atomic transaction).

This user-level project is 5 months old already: Denny's Lotto. Here's a screencast/walkthrough. Its a decentralized lottery - provably fair, with no central operator.

Dennis is also the programmer behind Eris, which was runner-up to the $100k bounty that Mike Hearn won for lighthouse. code,  screenshots, build instructions.

The EtherEx brand was announced in May. They at least have a whitepaper.

cryptocoinwatch is another project with a decent front-end.

DNSEth shows how to connect a namereg contract to a DNS daemon.

edit: corrected EtherEx announcement date.

[2] Ethereum would represent a counterexample to this thesis. However, looking at their forum's Project and Smart Contract sections, I don't see any actual projects at all. Am I missing something?

You're looking in the wrong place. The forum is full of "ideas for projects", its hard to sift out the projects with code. Try the github instead. You can find five functional clients in different programming languages: cpp-ethereum (C++ - aimed at developers), go-ethereum (Golang - aimed at users), pyethereum (python - vitalik's client), ethereumj (Java - aimed at an android version), and node-ethereum (unofficial but quite functional). All have screenshots and/or screencasts somewhere.

There are three higher-level language compilers, written by their respective client authors. Each compiles contract code (LLL in cpp-e, Serpent in py-e, and Mutan in go-e) to EVM (ethereum virtual machine) bytecode. Cpp-e also incorporates serpent (serpent->LLL->bytecode), and so does go-e. All five clients have a different EVM implementation that can run the same bytecode.

Additionally, there's a new, fourth high-level language at the concept stage, codenamed Solidity. The purpose of this fourth one is to provide formal descriptions of contract interfaces. These formal descriptions will be the basis for a DApp permission system, to provide wallet security without sacrificing usability. It will do this by translating formal interface descriptions into english language permission requests:

Untrusted ÐApp "Foo Sprocket DApp" attempting to transact in your name:
Send 45.780 GAV from the account of Your Name Here to an account accessible only by Foo Sprocket DApp.
Do you wish to allow this?

This will enable use of DApps seamlessly with user wallets. Should be a much improved experience over the tedious, error-prone task of copy/pasting deposit, payment, and withdrawal addresses between users' wallets and the third-party services they wish to use. (QR codes aren't much better)

Also in the official repo is an initial, proof-of-concept "randomized" proof-of-work mining algo. It generates a new circuit/problem every so many nonces (a nonce is a hash attempt - ie 100k hashes per second is 100k nonces per second). So every 512, or 1024 nonces, a new random hash function is generated. The parameter balances the time-spent-generating with the time-spent-evaluating. Too large and FPGA's would have an advantage over CPUs (an FPGA takes time to reprogram, but after reprogramming would be faster at evaluating than a CPU). Too small then there's more time spent generating than evaluating. Obviously, the mining algo is at a very early stage and who knows if they'll actually succeed at ASIC/FPGA resistance (the reason its desirable is a debate in itself), but at least its an active project.

These are all lower-level projects, at the platform/backend level. There are also projects at the user-level, i.e. DApp contracts with front-end interfaces. The most prominent of these would have to be GAVcoin and the exchange (these need to opened from within an ethereum client to work properly). The exchange is demoed here. There are plenty of example contracts, but not so many DApps with in-your-face front-ends just yet. One reason is because the clients are still alpha, so the contract compilers and javascript api's are unstable. This means progress on DApp contracts and front-ends is often frustrated by the need to do some amount of lower-level debugging. Another reason is probably due to DApp authors who hope to monetize their work on launch of the genesis block. They may not see incentive to publicize their work, nor share their code, prior to launch of the genesis block (the obvious concern is that doing so would only attract competition, and help them create clones/forks that would be competing DApps on launch day).

There are already individuals working on an Ethereum version, namely martinBrown.

somnicule as well.

If Ethereum were to implement Truthcoin as an Eth-contract, then that Eth-contract would compete with any Truthcoin blockchain(s).
[...]
If you'd like to discuss please post in the relevant thread.

Maybe not. Discussion continued here.

Continued from here.

3) I don't want to start over from scratch if Ethereum should die.

This is a good reason to have TruthCoin as a separate alt-chain. As much as I disfavor meta-coins, one thing I like about them is their ability to be ported to a separate blockchain in a worst-case scenario (MasterCoin has a contigency plan to move onto Litecoin, should bitcoin suffer some catastrophic failure). Similarly, I wouldn't argue that Ethereum should be the one-and-only blockchain. Some diversification is good (too much, though, is bad).

I don't see Ethereum and Truthcoin as competitors. If Ethereum were to implement Truthcoin as an Eth-contract, then that Eth-contract would compete with any Truthcoin blockchain(s). In the original whitepaper of January, I mentioned that Truthcoin may require Ethereum in order to exist.

Separately, I think that Ethereum, while hyped today, will not be very popular in the future. In fact, I believe that it is possible that Truthcoin will be the second of two blockchains, and that programmers will stop using Blockchains once they exist for money, namespaces, and data.

An eth-contract wouldn't necessarily have to compete with an alt-chain. If Truthcoin supported sidechains/treechains, then the eth-contract could host a TC sidechain instead of competing. This would get the benefits of both worlds: advantages of the eth-blockchain and seamless compatibility with other Ethereum contracts, without a competing chain/coin supply to dilute TC digital scarcity. Suppose there's technical progress on sidechains/treechains, but political blocks preventing a necessary bitcoin hard-fork. If a TruthCoin alt-chain launched with the script features needed for sidechains, then an Ethereum implementation could be a TC sidechain. Additionally, it would be easy to experiment with other TC variants: lower block times, different voting schedules, different branching schemes, enhanced market-maker algos, etc., all while maintaining coin supply/interchangability. How about that for a "second of two blockchains" scenario? (My two pet favorites, Ethers and Truthcoins, dominating the crypto 2.0 market ).

If ethereum is actually realistic, then maybe mere alt-coin side/treechains is within the realm of possibility.

From stress testing it, I seem to be able to buy 5 shares, and then sell 6, which is of course illegal.

fixed. Also added "risk to win" and decimal odds.

The theme is cracking me up. What century are we in?

The century before bootstrap (twitter's css theme).

I noticed a bug: when I bought some shares (2000 on every event) the "change prob. to" is not working - see screenshot attached.
EDIT: hm, guess the attachment did not work. However - it should be easy to reproduce.

2000 is a huge amount, I mostly experiment with sizes around 10-100. Anyway, that field isn't yet robust, you'll see a lot of NaN's and Infinity's if you change that field directly. It needs the ability to "sell short" an outcome (ie. buy an equal amount on every other outcome) before it can be robust. Until then, entering a probability that's lower than the current one will cause those errors (not sure if its the same bug you saw. I've used imgur to post screenshots here).

And I noticed one more thing: As a event author it will be VERY HARD to get your initial investment back.

The basic LMSR market maker isn't designed to be profitable - its designed to be subsidized. One thing that might alleviate this, even for basic LMSR, is to use an initial "b" vector with the probabilities at Vegas odds. Not sure how much this would help (and it would depend on the outcome anyway), but its on the TODOs (in the repo readme). Right now the b vector is uniform probabilities (ie, starts at 0.25 on all 4 outcomes).

Another of the TODOS is volume-parameterized (aka liquidity-sensitive) LMSR - where the "b" parameter increases as trade volume increases. These designs replace the "b" parameter with an "alpha" parameter, which acts as a percentage fee and creates a profit-making market-maker. Note that traditional sportsbooks maintain a "vig" of around 4%-5%.

I think it would be necessary to place classical buy/sell orders in the truthcoin blockchain that either get active as soon as the market maker price goes below them or that could be matched by other orders directly.

I like the idea of a hybrid classical order book + LMSR, described here. This would let users make offers, which adds liquidity (opposed to only permitting users to take offers, which in basic LMSR do not add liquidity).

A crude front-end: code and demo. Just discrete PM trading/betting, no forms for voting to resolve event outcomes, yet.

Slap it on top of your preferred TruthCoin back-end stack   And polish the UI/CSS theme while you're at it.

Suggestions, critiques, corrections?

PMs are not really for hedging, but for information-aggregation. In fact, elsewhere Hanson has even said something like "[PMs] use the market mechanism, but are otherwise not markets at all", claiming that PMs don't do a single thing unless subsidized (with $ or with entertainment-value), unlike markets which exist for efficiency reasons (and only aggregate information as a side-product).

I've been thinking more lately about the potential for using TruthCoin to hedge the price of bitcoin (effectively creating a way to hold decentralized dollars). So I'm particularly interested in this right now.

More generally, the applications pdf proposes hedging as an application of PMs:

Through creative use of the tradable shares, one can provide an entire marketplace of financial services, including risk-management, insurance

Further down there's a section for "Event derivatives" and insurance (as in, decentralized insurance). Isn't this hedging?

edit: Maybe instead I should ask, how is a PM different from or less efficient (and to what degree) than say, a futures market.

atomic cross chain trading------------------
Has existed for years in the bitcoin family of currencies.
The ability to trade coins on chain A for coins on chain B trustlessly.
Example: if I had bitcoin, and my friend has litecoin, and we wanted to trade.
https://en.bitcoin.it/wiki/Atomic_cross-chain_trading

The idea has existed, but nobody has implemented it (yet) afaik.

The authoritative post on bitcointalk, a twitter discussion, and blog post.

@socrates1024 @zooko @matthew_d_green @imichaelmiers P2PTradeX does not have any fundamental problem (except that you need to code it!)

Clarification: I asked what the difference is between "atomic cross chain trading" and "atomic cross chain transactions". Toast used those two terms... http://forum.truthcoin.info/index.php/topic,27.msg202.html#msg202
I just know this: "atomic transfers" https://bitcointalk.org/index.php?topic=193281.0 which is what you described as "atomic cross chain trading".

A simple one-way payment (a payment for nothing, as in "here, have some coins") is one transaction.

A "trade" is more complex, think of it as two simultaneous transactions. Say we trade BTC for LTC, basically what happens is you send me some BTC, and I send you some LTC - so that's two transactions. To safely trade with each other they have to be atomic transactions. Atomic means all-or-none, otherwise say you send me the BTC, then I sign off and keep both the BTC and the LTC. Atomic means its impossible for me to do that and steal your LTC.

Blockchain transactions are a form of database transactions. With a crypto-currency, the entry in the database (or ledger) is the coin balance of an address, and the balance is just a numeric value. But you can store any type of values in a database - numeric, string, hex, etc - any type of variable. To update those variables you do a database transaction (these variable updates change the contract "state").

For example, suppose someone is using a CounterParty crowdfunding address to raise money in a genesis sale of SupergreatCoin. And suppose there's a feature in the counterparty crowdfunding contract to broadcast an announcement on bitMessage, when the fundraising goal is reached - "Target goal achieved! Awesome! -- This message was automatically sent by SuperGreatCoin."  But we want that message to be announced on bitMessage *if and only if* (atomic, in other words) the goal amount was actually reached on the counterparty contract. Broadcasting a bitMessage announcement is a transaction, but its not a trade. So this would be a counterParty-to-BitMessage cross-chain atomic transaction. This would essentially would require upgrading at least one of the clients to be cross-compatible, in this case the BitMessage client would have to also connect to the bitcoin network and verify the counterParty transactions happening in bitcoin blocks. Then when the bitMessage client processes transactions, the verification process would look something like this: IF counterparty_tx_goal_reached AND bitmessage_tx_is_valid THEN includeMessageTxInBlock().

Thanks a lot, the new spreadsheet is much more clear.

I was going to ask for a citation on using those kind of scaled outcomes with LMSR. But I think I found it here:

A user who wants to express his opinion on the expected value of GDP change, how- ever, might prefer "linear" assets such as "Pays $xˆ," and "Pays $(1 − xˆ )," where we have defined a rescaled variable:

x_hat = max(0, min( x - x_max / x_max - x_min ))

which is zero up to x =x, is one above x =x ̄, and moves linearly with x in between.

That's equivalent to the scaled formula in the spreadsheet, correct?

But if using a scaled outcome is this simple, then what's with all the fuss over continuous variables in the literature?

Cost Function Market Makers for Measurable Spaces

This allows us to overcome the impossibility results of Gao and Chen [2010] and design the first automated market maker for betting on the realization of a continuous random variable taking values in [0, 1] that has bounded loss without resorting to discretization.

That paper proposes a convex optimization problem for the cost function (much more complicated than the simple LMSR formula). And with similarly dense math: Betting on the real line.

What's the advantage of these sophisticated methods over the simple scaled LMSR? It claims to be the "first" automated market for a continuous variable... isn't that what a scaled outcome LMSR is? Maybe it's over my head but I'd appreciate if anyone can help me understand the difference here.

We also know that "Bitcoin Core" already works with all Bitcoin merchants, the entire Bitcoin community, and all developed Bitcoin software!

That's a lot of reasons to just modify the existing Bitcoin software, don't you think?

Modifying the existing bitcoin software will create new bugs, especially for more complex transaction types / opcodes that truthcoin would need (votes, markets, etc). Alt-coin forks don't inherit the same security / reliability guarantees as the official bitcoin codebase.

A toolkit is a modular codebase with interface functions designed as a flexible base for versatile addition (assuming you're not mucking about in the interface implementations). If you fork a legacy codebase you'll probably be modifying brittle code, "fragile base classes" that were never meant to be flexible. That might be even more worrisome than using a newer toolkit which is designed for flexibility, though not as well-tested.