I can see this being an issue if the users had to construct the multisig address themselves. Why don't people use Bitrated though? Do people not trust that it's constructing the 2 of 3 correctly? Or is it still too complicated? Or do people just trust the arbitrators on bitcointalk so much that they don't see the value in having even more security?


Sure, if you use localbitcoins then you have to use them as the arbitrator. But let's say you use something like Bitrated -- then you can choose anyone as the arbitrator, so you can just use the same people who already get used as arbitrators on bitcointalk. It just makes it impossible for them to steal the money without the cooperation of the seller too.

I guess it just blows my mind that after all this time we still aren't seeing people use what I think is one of the coolest features of Bitcoin (2 of 3 multisig) when it looks to me like people should have a clear incentive to use it.

I've been reading some of these escrow threads and I'm confused about something:

Is it really true that the most popular kind of escrow on Bitcointalk involves the buyer just sending the funds to a normal Bitcoin address owned by the escrow agent, and not sending it to a 2-of-3 multisig address? When I see arbitrators offering their services it seems like they're expecting to have full control of the funds. Or am I misunderstanding?

If I'm right that people here usually just trust the escrow agent with the funds, why do they choose to do that when they could instead of 2 of 3 multisig? Is multisig just too much trouble?

I've been trying to sync CLAMclient for over a week, and the syncing is so slow that my client is actually getting further behind as time passes. I'm wondering if I can do anything to speed it up.

I've already downloaded the bootstrap data from dooglas, then started syncing from nodes. My client shows that it is 3 weeks behind. Two days ago my client was at block 1914550. Now it's at 1915947. That's only 1397 blocks in two days, which is slightly less than one block per minute. So at this rate I'll never catch up.

Is there anything I can do to make the sync faster? (I'm using Linux, running clam-qt 1.4.17).

 

Sorry, by "signatures" I meant I submitted the signed messages for the BTC airdrop. As in, I signed my Semux address using the Bitcoin address that had funds, to quality for the BTC airdrop. Yet I still don't see that it went through on the list of all BTC airdrop addresses. Is this normal?

I submitted my signatures yesterday, but I don't see them on this list. Do they only update it rarely?

Wondering if I should be worried I did something wrong, since the deadline is tomorrow.

It seems like people in this thread are still focusing too much on tangential chess use cases, and not on the problem I described.

The problem is: how do you use the Bitcoin blockchain to enforce the rules of chess, such that you could bet on a game with your opponent without having to trust them? And, if this is not possible, is there a general solution that will be available in the future?

To clarify, I am interested in techniques that are general enough to support many other use cases without having to do a fork to support each one.

Yes, that's fine for my purposes. As I told the other person above, this is a learning exercise to explore what Bitcoin is capable of.


The point of using Bitcoin is that we want its blockchain to know the program and the inputs and verify the output, then release funds depending on the output. It isn't enough that both you and I can run the program off the blockchain, because one of us could lie and say "hey when I run this program it says I won, so give me the money." Trustless here means you don't have to trust your partner to be honest and pay you if he loses. The blockchain resolves any dispute about who the winner is, and causes funds to be paid to them.

The purpose of this question is not to play chess, it's to explore the power of smart contracts using Bitcoin. The idea is that if any technique that allows us to play chess using Bitcoin should be powerful enough to allow lots of other interesting uses.


The smart contract would not be generating moves. Just officiating a human vs. human match. I have in mind something like in the article I linked to. Checking whether a move is valid is far easier than generating good moves.


Timing moves is tricky, however it may be possible to play long games where the time per move is measured in blocks. If the time is long enough (for instance, 100 blocks per move), the variance of block creation may not be an issue. However since the goal is not to post every move on the chain (as mentioned in the original post, this is super inefficient), there may be some way to play with faster time controls with all verification done off-chain or over a Lightning channel.



I mention zero knowledge proofs because those are solutions that Greg mentioned already exist (ZKCP) or are eventually coming (SNARKS). You're right that it seems like zero knowledge shouldn't be needed for this. If anyone knows how to trustlessly verify an arbitrary computation without it, I'm interested to know how.

Someone recently posted an article about playing chess on an altcoin blockchain. It was interesting and got me thinking whether there's some way to do this with Bitcoin, and if not, if there was some plausible addition to Bitcoin that would allow it.

The TL;DR of the article is that putting every move on-chain is super expensive and not advisable with any blockchain. So a "challenge/response" system is developed where game-related transactions only hit the blockchain if there is a dispute. This seems like the right architecture for Bitcoin too. Ideally the whole game could be played over Lightning channels so even the result of the game didn't have to hit the blockchain.

However with the setup in the linked article, the blockchain still needs to be able to evaluate the following question: "is move M a valid move from board state S?" In other words the blockchain needs some way to represent the rules of chess.

It seems hard to write a Bitcoin script that takes a board state and a move and verifies whether the move is legal. Seems like there are too many possibilities, even with MAST. I was thinking maybe after you move you could also create a MAST script which accepts any valid continuation from your opponent. However without some smart contract that knows the rules of chess, you could just claim the moves you don't want your opponent to make aren't available to him.  

Greg Maxwell has a post talking about how various problems like this could be solved in Bitcoin.

The most heavy duty solution is SNARKS. They'll let you use an arbitrary program to verify a computation. So you wouldn't have to be restricted to Bitcoin Script. However that seems pretty far away.

The other option seems to be zero knowledge contingent payments (which Greg talks about here). It is claimed that you can run arbitrary programs which never hit the blockchain. It seems from Greg's description like the only downside is that the contract won't be private. This is fine in the chess case though. If contract privacy is the only difference in power between ZKCPs and SNARKS, then ZKCPs are a lot more powerful than I realized.

So, my question: is it actually possible today to use ZKCPs to play chess for bitcoins, trustlessly, using the Bitcoin blockchain in such a way that only one transaction hits the chain when the game ends?

If this is not possible, what is keeping it from being feasible?

Are there other approaches that I missed?

That makes more sense. Thanks for clarifying.

Just seeing your comment now. Yes, the DAO stuff is evidence against having such an expressive scripting language. However I see the mutable state vs script-like language are fairly orthogonal. Assuming that Bitcoin's more constrained system of state is better, what I wonder is whether a more declarative way to write Bitcoin-script-equivalent stuff would still be preferable. As mentioned above, I think the declarative style puts less mental load on developers and is more 'natural'.

The gist of an earlier comment of yours seemed to be: "writing smart contracts is inherently hard and unnatural, so it's fine if the scripting language is hard to understand." I just don't see how one aspect of writing contracts being hard (getting the logic right) implies that it would be better for other aspects to be harder than they need to be.

If a declarative version of Bitcoin script made mistakes less likely, what is the downside? Are you worried about newbs who just learned a bit of javascript thinking they can write secure smart contracts just because Bitcoin script v2 might look a bit more like javascript? So the fact that current script looks intimidating is actually good? If so would it have been even better if Satoshi made all op codes of the form OP_XYZ where X, Y, and Z were digits? And maybe disallowed spaces when not including them would still be unambiguous? That would certainly reinforce in people's mind that writing Bitcoin script is tricky.

Yes, smart contracts are different from normal software in many ways, but I'm not seeing why exactly this means they shouldn't be written in a declarative language. My premise is that a language like Script just adds to the developer's mental load without any corresponding benefit over a declarative language (which I am assuming are easier for the human mind to understand).

Note that I'm not suggesting Ethereum's language is better. This is just about declarative vs. <whatever Script's style is called>. I'm wondering whether it is possible to create a language that has equal power to Script, which just happens to be declarative. So for instance it would obviously not have loops, no gotos. Maybe just if statements / if/else, support for variables, the existing opcodes converted to declarative functions, and a cap on the # of instructions.

So for instance a P2PKH 'script' might look like:


Are there reasons why if Satoshi had done this instead of Script it would have been bad?

There is one area where I think Ethereum might have a smart contract advantage, that I haven't seen Bitcoiners discuss. It looks to me like writing Ethereum contracts is more 'natural' to developers than writing complex script constructions using Bitcoin. I haven't written scripts in either, but as a dev this is the sense I get by looking at their scripts. Is this a legit problem? If so, have the Bitcoin devs thought much about how to make Bitcoin script construction more accessible for normal devs (maybe either via dev tools, or by some simplified declarative language that compiles into Script)?

I thought Greg's description above was really good and was curious how Vitalik would reply so I posted it over in the Ethereum subreddit. For anyone else interested, he gave a detailed response at https://www.reddit.com/r/ethereum/comments/4g1bh6/greg_maxwells_critique_of_ethereum_blockchains/d2e24sy

IMO, no matter what happens to Bitcoin, if some people end up wanting decentralized money in the future they will have it. The technology can't be un-invented. If the 'main fork' of BItcoin eventually becomes highly centralized, some decentralized fork will spring up as long as there are cypherpunks who value it. Or some new cryptocurrency will be fill the 'hardcore decentralization' niche.

It might be good to have a second layer of confirmation in this case too, just in case someone accidentally hits 'y' once. Like "The fee is extremely high. Are you sure? (y/n)".

Glad it seems to work.

About the opening time: could you clarify why there's an extra delay?  I'm imagining that Alice would post her anchor tx and Bob would post his payment tx to Alice within seconds of each other. Bob is protected by a timeout, and Alice is protected because her tx is only paying herself at first. They wait until both txs are confirmed, then Bob can reveal his secret. Is this actually slower than your original method?

Let's assume that for some reason Bob wants it to be impossible for his tx to confirm and the anchor tx to be orphaned. I believe this can be solved by making Bob's payment outside of the channel dependent on an output from the anchor tx. The new anchor tx has a 5 BTC input from Alice, but now two outputs: one of value 1 satoshi spendable only by Bob, and another of 5 BTC (minus one satoshi) with spending requirements exactly like before. Bob broadcasts his tx paying Alice 2.5 BTC (if she knows his secret) using this 1 satoshi output as an input. Now Bob doesn't even have to wait for the anchor to be confirmed before revealing his secret, as long as he and Alice have exchanged suitable commitment txs that depend on the anchor's "main" output.

aj on the LN IRC channel suggested an improvement to this technique -- a better way for Bob to pay Alice instead of using a one way payment channel:


I also updated the original post to note that this does require BIP 62.

Recently Rusty figured out how LN could be made to work without malleability fixes (EDIT: except for BIP 62) : http://ozlabs.org/~rusty/ln-deploy-draft-01.pdf. The drawback of his approach is that monitoring the network to make sure the other guy doesn't post a revoked transaction is not outsourcable. You have to be monitoring the network yourself, otherwise the person you trusted to monitor it for you could give information to the other person on the LN channel and let them steal money from you.

My modification is a way to get the benefits of Rusty's modification, without giving up outsourcability.

In short, the reason malleability is a problem for the original LN design is that both people are funding the anchor tx, and one person is posting the anchor tx, and whoever posts it can modify it in such a way that he screws over both people.

A solution is to make the anchor transaction funded by just one person, and posted by that same person. That way, the funding person only screws over themselves if they modify the anchor tx before posting it.

Suppose Alice and Bob want a LN channel. Alice crafts an anchor tx funded by 5 BTC from herself. Its one output requires a signature from both Alice and Bob. (I'm simplifying by leaving out the details of OP_CSV and revoking commitments). Alice also crafts a commitment tx which spend's the anchor's output, sending all 5 BTC to an address Alice controls. Bob signs the commitment tx and send it back to Alice. Now Alice can post the anchor tx, because she knows she can spend it with the commitment tx that Bob just signed. Alice could modify the anchor's hash before posting it, but she would only be screwing over herself. So she posts the same anchor tx that her commitment tx refers to.

Now Alice can pay Bob, but Bob can't pay Alice via the LN channel because Bob has zero balance on the channel. However we can get to a state from here that is as if Alice and Bob had both funded the anchor tx with 2.5 BTC each. Bob just needs to pay Alice 2.5 BTC, and Bob and Alice need to modify the commitment txs and revoke the old ones. How can Bob pay Alice in a trustless way? He can open a simple temporary one-way payment channel to Alice. He transfers minuscule amounts of BTC over a one-way channel, and each time he does, he and Alice sign new commitment txns on the LN channel and revoke their old ones. At any point, Alice can only steal a minuscule amount from Bob (or vice versa -- they can do the transfers in either order, so either person is at risk of losing one cent or whatever the incremental transfer amount is). Once Bob transfers the 2.5 BTC to Alice via the simple one-way channel, Alice can close this channel and each person's "balance" on the LN channel is 2.5 BTC.

Because this avoids the escape transactions described in the paper linked above, either party can now outsource the work of watching the network for cheating attempts.

Will this work?