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?

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?

I'm trying to figure out how to set up an RSS feed containing bitcointalk posts of all my favorite users.

I don't know of a direct way to do this, but Google/Blogger has a service that can turn your email inbox into an RSS feed. So if I could just get bitcointalk to email me when someone on my list of favorite users posts, it'd be awesome.

How hard would it be to add this functionality to bitcointalk?

Would anyone other than me find this useful?

I posted in the Technical sub-forum about an idea I was thinking about where a side-chain of Bitcoin could be made to inflate, at say 2% per year, in order to add security to the network and lower transaction costs on the side-chain. Full details at https://bitcointalk.org/index.php?topic=799465.0.

TLDR for the main idea: If you move X coins from Bitcoin to the side-chain, then move them back one year later, you can only unfreeze 0.95*X bitcoins, because the side-chain's coins are inflating at 5% per year. You can move coins back without waiting a year, of course, and they'll only have lost a proportional fraction of that 5%.

This thread is for anyone interested in discussing whether people would have real incentives to use such a side-chain, and the economic implications of that solution.

gmaxwell and andytoshi raised these issues:

(1) If you move coins to a side-chain to avoid paying transaction fees, but this side-chain is inflating, then won't any money you save on transaction fees just be eaten away by inflation anyway? Does the net effect perfectly cancel out?

(2) Just a general skepticism about any compelling reason why a Bitcoin user would move coins to an inflating side-chain.


Let's assume that the rules of the side-chain result in in taking one week to move coins from the side-chain back to the Bitcoin chain (for security reasons). What can we say about the price of side-chain coins?

The side-chain price won't be higher than the Bitcoin price, because you can always move X bitcoins into the side chain, turning them immediately into X side-chain-coins (call them sidecoins).

How much lower will the sidecoin price be than the bitcoin price? Since it takes a week to move coins from the side chain to the main chain, and inflation is 5% per year, then if you move coins from Bitcoin to the sidechain back to Bitcoin as fast as possible, they'll have lost 5/52 percent of their value, or roughly 0.1% of their value. So if you start out with $1000 worth of bitcoins and move them back and forth, you'll have about $999 worth of Bitcoin in a week (assuming the USD/BTC rate stays the same).

This means that the price of a sidecoin will be at least 99.9% the price of a bitcoin, because if it were lower then someone could buy up all the sidecoins, immediately convert them back to bitcoins, and sell them as bitcoins.

So even at a 5% inflation rate, the actual movement of coins from Bitcoin to the sidechain doesn't result in much immediate loss of value. What if transactions in Bitcoin were $1 each and transactions on the side-chain were 0.01 cent each? Then if you knew you were going to spend $100 worth of bitcoins next week, it'd definitely be worth converting even if you only spent it on 1 transaction. The more transactions you'd do in that week, the more it'd be worth it.

USD inflates at about 2% per year, and people still keep cash in their checking account / wallet, because for small amounts of cash, the effect of inflation is very small.

Someone might claim that the situation I describe is impossible ($1 Bitcoin fees, $0.0001 sidechain fees) because of some inherent relationships that must hold between the transaction fees, based on the inflation rate, etc. I didn't show that that isn't the case, but I don't see a good reason to believe that such a relationship exists.

Anyone have thoughts on this?


 

I am not an expert on side-chains, but I was recently thinking of how they could be used to solve a potential issue with Bitcoin security / transaction fees when block rewards are much lower. Can someone with more technical expertise let me know whether you think my solution below is feasible? I know side-chains are supposed to be able to allow basically anything ("the one change to rule them all", and all that), but I've not seen someone describe how the below could work in detail.

The problems:

Problem #1: The security of the Bitcoin network at time T will depend roughly on the price of Bitcoin, the block reward, the # of transactions, and the average transaction fee. Because the block reward changes on a relatively fixed schedule, and the future price could be any of a wide range of values, the level of network security we'll get in the future might be above or below what is optimal. Here optimal means "enough security so that a successful 51% attack is very unlikely, but not much more than that".

Problem #2: People will generally prefer to transact on networks with lower transaction fees. When Bitcoin block rewards get very small, it's uncertain whether people will want to pay high enough transaction fees to support, rather than move to a different network with higher block rewards and lower transaction fees (for a given level of security).

I'd prefer not to discuss whether these are "real" problems in this thread. I want to stick to the technical feasibility / drawbacks of my proposed solution:

Solution to both:

Suppose in the future the block rewards are super low, people are paying a few cents per transaction, but it's still not enough to provide enough security to the network to make a 51% attack hard enough. Imagine we figure out how much security would be ideal, then we create a side-chain that has a block reward large enough to provide that level of security mostly through block rewards, so transaction fees can remain low. "Now wait a minute -- side chains can't have block rewards! All the coins on the side-chain are supposed to correspond to frozen coins on the main chain!" is what you might be saying. Imagine that when you freeze coins on the main chain, and then unfreeze them 1 year later, you only actually can unfreeze 98% of them because now it takes 102 side-chain coins to unfreeze 100 main-chain coins. Because there has been inflation in the side-chain during that year.

Question #1: has anyone actually worked out concrete details of how something like this "inflating side-chain" could work? It seems plausible in a fuzzy way, although it also seems like there could be issues with timing where someone might trick the main chain into thinking that not much time has passed in the side-chain, and therefore they can redeem more main-chain coins than they should be able to, given the actual inflation in the side-chain.

Question #2: I'm also not a merge-mining expert. The problem with the above is that even if the side-chain has awesome security, the main chain still would have poor security. I imagine having a super-secure side-chain based on an insecure main-chain is not that desirable. I know merge-mining can be used to make a side-chain as secure as Bitcoin (if Bitcoin miners choose to merge-mine), but can merge-mining be used in the reverse way, to make Bitcoin as secure as a side-chain? And can this be done without having to modify the Bitcoin code every time you want it to be merge-mined with a particular new side-chain?

Is there any way I can get new bitcointalk posts from my favorite users on this forum, in the form of an RSS feed?

There used to be a service for doing this (see https://bitcointalk.org/index.php?topic=308954), but it stopped working a couple weeks ago.

You've all heard the environmental/waste argument "the Bitcoin network uses too much computing power."

Right now I don't think this is a good argument. We're not spending that many resources mining if you make the comparison with the cost of securing banks and credit cards. However, if bitcoins jump in price like a lot of us hope they will, this will be a legitimate problem.

Imagine that the price of BTC reached $1,000,000 USD on January of 2016. The block reward will still be 25 BTC, meaning that every day, 3.6 billion dollars worth of bitcoins is distributed to miners. Miners would be expected to spend almost 3.6 billion dollars per day to mine these coins. That's 1.3 trillion dollars per year, or almost 2% of the wealth produced globally every year (as of right now).

Of course in this situation, the Bitcoin network will be very widely used and worth protecting from attacks. The question is: is 2% of global wealth devoted to protecting the Bitcoin network overkill? Maybe it would have enough protection with just 1% of global wealth, or even 0.2%.

The general problem is that the rewards to miners will be somewhat arbitrary and not calibrated to the security needs of the network, because they're based on parameters that Satoshi picked before he knew what the adoption/price curve would look like.

Any cryptocurrency that succeeds in replacing Bitcoin will use the Bitcoin blockchain. Here's why:

Suppose a new cryptocurrency comes out which is a significant advancement over Bitcoin (something no existing altcoin can claim), call it Bitcoin2. Let's say Bitcoin2 uses a new blockchain. People invested in Bitcoin realize Bitcoin2 is superior and realize they should do something. They fork Bitcoin2 into a new cryptocurrency called Bitcoin3 which is identical to Bitcoin2, except it preserves the original Bitcoin blockchain.

Now people have a choice as to whether to use Bitcoin2 or Bitcoin3. Which one will people use? The people who are working on building the current Bitcoin infrastructure are heavily invested in the existing blockchain. These are some of the smartest cryptocurrency experts/developers/entrepreneurs in the world, and the cryptocurrency that they back will have a huge advantage.  Businesses and consumers will feel more comfortable with a currency developed and supported by the same people and businesses who brought us Bitcoin if there's no longer any technical reason to favor another coin. So Bitcoin3 will win out.

Another way to think of this is: is it harder for the smart people working on Bitcoin to clone a technical advancement from another coin, or is it harder for the founders of another coin to build something replicating Bitcoin's infrastructure and community?

There are about 20 people on bitcoin talk who I think are very smart and who always seem to post interesting stuff, but there seems to be no easy way to stay aware of their posts. Sadly most of the posts on this forum are not that interesting or educational, and wading through all of them to find the rare gems makes me not use this forum very much.

Can we add some functionality where I can create a list of people who I want to follow, and then there's a page called "latest posts by people on your follow list", which lists all of their most recent posting activity? Maybe use some of the forum's 6000 BTC to hire someone to add this? Currently I'd have to manually view the latest posts of every person separately.

Has Theymos (the person who runs this forum) ever revealed any personal info about himself? Do we know his name, where he lives, etc? Is the real person behind the Theymos handle an active member of the community apart from on this forum and on reddit?

I recently saw the following message two times yesterday. Both times I had entered my user ID and password to log into Bitstamp, been prompted to enter my two factor authentication using Google Authenticator, waited for perhaps 30 seconds or more, entered my authentication token, and then seen this message:

"forbidden (403) CSRF verification failed. Request aborted. You are seeing this message because this HTTPS site requires a 'Referer header' to be sent by your Web browser, but none was sent. This header is required for security reasons, to ensure that your browser is not being hijacked by third parties."

Does anyone else who uses Bitstamp see this occasionally? I'm trying to figure out whether I was the target of a legit XSS attack or whether it's some issue on Bitstamp's side. I asked Bitstamp support, but they weren't helpful and just said to "enable cookies." I don't think they understood that I only get this intermittently.

I've downloaded the entire blockchain about 3 times on Bitcoin-QT (v0.8.5.0-gef14a26-beta, the 'raring ringtail' edition). Once on Windows 8, once and Linux Mint 15, and now I'm doing so again on Linux Mint 15. The previous times I don't remember Bitcoin-QT having any significant CPU usage while syncing. However this time, QT will consume over 200% of CPU (I guess "top"'s calculation gets messed up by multiple cores) for 5-10 minutes at a time, then goes down to 1-2% for ~20 minutes, then the CPU spikes again.

Is it normal for QT to work this hard when syncing the blockchain for the first time? Is it simply "scanning the blockchain"? Or might there be an issue with my QT installation / data?

There's another poll asking people how many BTC they have in absolute terms. I think this is a more interesting question, because it shows how bullish people are about BTC. I'm hoping it will get more honest answers than the other poll for a couple reasons:

(1) Your answer doesn't automatically make you a target in the future, unless people have a good idea of your net worth. Someone might answer 100%, but they might only have 0.1 BTC and no other possessions. Or someone might answer 1-2% and have 20,000 BTC. No one can know unless they find out both your reply to this poll, and also know how rich you are in general. Note that there is no way for a poll author to find out who voted for which answer (try making your own poll and see for yourself).

(2) People can see the results without voting, and I also gave a voting option for people who don't want to answer.

The problem: suppose all global transactions are done using bitcoins. Then the value of a bitcoin should grow at the rate of GWP. This means that instead of investing in the stock market, I can just hold bitcoins and expect similar growth. I get the advantages of: liquidity, no fees, and maybe no taxes on gains. The more people do this, the less resources are invested in productive endeavors, and the lower GWP is. Unfortunately, it's in any individual's interest to hold bitcoins rather than invest them in an index fund. Maybe as a result GWP grows at 2% instead of 4%, and the world is worse off.

One might argue that the value of bitcoins would be bid up so that the expected rate of return would be closer to other extremely safe assets. Suppose at year t, each bitcoin is bid up to $X. Then at year t+1 bitcoins have gained less value than a share of GWP, as expected. The total value held in bitcoins has decreased in relation to GWP. But if rational people were OK with this new ratio of bitcoin price to GWP, why did they bid it up higher than this in the first place? And shouldn't that same reason apply at t+1, causing them to bid up the price again so that bitcoins do in fact grow in value at the rate of GWP?

NOTE: I am not claiming that individuals will not spend enough bitcoins. My argument is only about what happens to bitcoins that a person decides to save/invest.

On Let's Talk Bitcoin episode 11, there was talk of a feature where you could print out K pieces of paper, and you'd need K/2 + 1 of them to restore your wallet, eliminating the chance that someone finding one of your backups could steal your coins. I've looked around in the expert settings of Armory and it looks like it's not released yet. Have the devs commented on a timeline for this feature?

A while back I found this site: http://www.btcglobe.com/tool/calculate-future

If you play with it, you'll see that it is using this formula:

[(World GDP in dollars)*(fraction of economic transactions using bitcoin)]/[(supply of bitcoins)*(fraction of bitcoins used in transactions)]

Shouldn't there be a (velocity of bitcoins) term in the denominator? Like this:

[(World GDP in dollars)*(fraction of economic transactions using bitcoin)]/[(supply of bitcoins)*(fraction of bitcoins used in transactions)*(bitcoin velocity)]

That seems to work for some toy examples I invented with an economy of 3 people.

This shows the velocity of the US M1 money supply: http://en.wikipedia.org/wiki/File:Velocity_of_M1_Money_Stock_in_the_US.png

It seems we should be dividing the numbers from the value calculation link by something between 5 and 10, unless we have a good reason to think bitcoin velocity will be much different than M1 velocity. Am I missing something?

I don't fully understand the Bitcoin network, but wouldn't running QT leave you vulnerable to the below scenario?

Step 1: I decide to become an evil hacker, so I learn how to hack.
Step 2: I run a modified version of the QT client, which prints out a list of all the other nodes on the bitcoin network that are visible to me.
Step 3: I take my big list of IP addresses, and using my logical skills I deduce that a lot of those IPs correspond to machines with bitcoin wallets on them.
Step 4: I try to penetrate as many of the machines with those IPs as possible, install keyloggers on any that I can break into, and grab any wallets that I can find.
Step 5: Profit?

What's the flaw in my plan? Is step 4 just extremely hard?

 

Here is the method I plan on using to secure my bitcoins. There are two computers involved here: my Windows desktop, which is always connected to the Internet, and my laptop which I plan to use only for bitcoin stuff. Steps on my windows desktop begin with "D:", and steps on my laptop begin with "L:":

(1) D: Download Linux Mint 15 (64 bit) from http://www.linuxmint.com/edition.php?id=132 on my Windows machine
(2) D: Create a bootable USB with the above file, using http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/
(3) L: Using the above bootable USB, reformat my laptop'd HD, do a fresh install of Mint.
(4) L: Log in for the first time, connect the machine to the Internet
(5) L: Immediately run apt-get update and apt-get dist-upgrade to make sure I have all the latest versions of everything
(6) L: Run "apt-get install bitcoin-qt" and run bitcoin-qt and download the block chain
(7) L: Disconnect from the Internet
(8 ) L: Create a new encrypted wallet, creating a new password, and generate a bunch of key pairs
(9) L: Back up wallet and copy it to a USB drive that was freshly formatted on my Windows machine.
(10) W: Copy the newly created wallet to my Bitcoin-qt directory on my Windows machine
(11) W: Copy the wallet to a bunch of other USB drives and store them in different physical locations
(12) W: Give out the public keys that I generated on my Linux laptop (now visible in Bitcoin-QT on my Windows machine to anyone who wants to send me bitcoins.

Up until this point, my laptop has been completely disconnected from the Internet starting from before I encrypted my wallet. I've never typed my wallet password on any machine that has been "online".

How many bitcoins would you feel comfortable keeping in a wallet that was protected in this way (steps 1-12)?

These are the main security risks I see:

Security risk A: My password is bad, and my Windows machine is compromised so an attacker can get my wallet and crack my password. If my password is good, this isn't an issue.
Security risk B: Somehow the USB drive was compromised, either during/while I was creating the bootable image on my windows machine, or an attacker compromised my laptop between step 4-9, possibly installed a key-logger, and this key-logger was able to copy it's information onto the USB drive while I was performing step 9, and then this info was somehow sent to the attacker during/after step 10.

Regarding risk B, how likely is it that someone could penetrate a freshly installed copy of Mint via the Internet connection? Especially before I had installed the latest versions of all the packages? Should I worry about my security being significantly less before I update all my packages? And even if an attacker could infect my system, how likely is it that their virus/logger could be sophisticated enough to hop onto the USB stick around step 9 and then later be able to send my wallet password + wallet to the attacker after step 10?

Now suppose I connect my laptop to the Internet once per week for about an hour each time, after the above steps, and actually use it to send bitcoins by typing in the wallet password while connected to the Internet? This machine only has the default Mint programs plus Bitcoin-QT.

How many bitcoins would you now feel comfortable keeping in this wallet? (with the addition of the last step of connecting it to the Internet now and then).

Thanks!

We all know why the USD value of BTC on MtGox is so high, but I haven't seen any discussion of why there's been a large difference (currently $8) between Bitstamp and BTC-E lately.

I used to use campBX and am now in the process of switching to either BTC-e or Bitstamp because of the current lack of Dwolla-->CampBX transfers. I'm trying to decide which to use (as a US citizen myself). If I look only at the price, it seems I should use BTC-e. I figure there must be some reason I don't understand why this spread exists though.

-Is it a lot harder to get USD out of Bitstamp than out of BTC-e? (this is the "MtGox hypothesis")

-Is there something sketchy about BTC-e that I'm unaware of that's causing this? I was able to find some videos of the Bitstamp CEO and saw that he's somewhat active in the community. The people who run BTC-e seem more mysterious. Maybe people are less willing to keep their bitcoins on BTC-e because they're afraid they'll get stolen, so the supply of bitcoins is artificially low on BTC-e, driving the price up?

Anyone have other ideas?

Let's say my friend Jimmy is trying to do a double-spend against me, because I'm willing to give him money in exchange for 0-confirmation bitcoins. Can he reliably do this? Here's my understanding of how the situation would have to go down:

Jimmy modifies the source code of his own copy of Bitcoin-QT to allow him to do this doublespend attack.

Jimmy sends out a transaction to the network, sending 1 BTC from address 123 (which he controls) to address 456 (which I control).

Question 1: is there any way Jimmy can send this transaction just to my Bitcoin-QT client and not to the network in general? I'm assuming Jimmy is a master programmer and can modify Bitcoin-QT at will, or write his own wallet/node software.

Question 2: even if Jimmy could send the transaction only to me, since I am running the standard Bitcoin-QT client, I would automatically broadcast it to the entire network, and there's no way Jimmy could stop this (unless he controlled my access point to the Internet), right?

So it seems Jimmy has to execute the doublespend very quickly, otherwise the entire network will see the transaction from 123 --> 456, and will reject any later transaction from 123 --> 789 (assume Jimmy controls address 789). So let's say Jimmy broadcasts the transactions 123 --> 456 and 123 --> 789 at roughly the same time. He gets lucky and my computer sees 123 --> 456 first so it looks to me like everything is normal.

Question 3: Is it pretty trivial for Jimmy to broadcast the transactions in a way were roughly half the nodes in the network get one, and half get the other? Or is there something about how the network works that would make this unlikely? Maybe his broadcast messages for both transactions would tend to travel along other nodes in the same sequence, so the one he sent first would be overwhelmingly likely to be seen by almost all nodes first?

Even if my node saw 123 --> 456 first, I think my node would receive the transaction 123 --> 789 because it would be broadcast to me from other nodes in the network.

Question 4: My node would reject the above transaction, but would Bitcoin-QT alert me to the fact that not only was the payment I just got unconfirmed, but that it had just rejected a transaction from the same address? Basically this would be a doublespend alert, and would let me know something fishy is happening, and to not hand over any money to Jimmy until I get at least one confirmation.

If Bitcoin-QT would alert me in the above scenario, then isn't it pretty safe to accept 0-confirmation transactions after waiting only 10 seconds to verify that Bitcoin-QT doesn't flag any other transactions as being seen with the same 'from' address? The only thing I really need to worry about is Jimmy controlling a lot of the network's hash power so that he might solve the next block on his own and explicitly prefer his transaction to himself over his transaction to me, right?

EDIT: Maybe if Jimmy sends the transaction to himself with a higher transaction fee, then most mining nodes would include his transaction to himself in their block rather than his transaction to me, even though the transaction to me was seen by them first. Anyone know if most miners currently would pick the larger fee transaction if they see two incompatible transactions?