I saw this linked elsewhere and it's a good watch about the S-Curve for technology adoption: http://www.youtube.com/watch?v=qHUPPYzzZrI

The network affect should encourage adoption similar to Google, Facebook and Twitter, so the case for an S-Curve has legs, IMO.

Assuming we will have S-Curve adoption, I wonder when it will arrive? Are we already at the start of it? The next few years could see value appreciate in a near vertical fashion, before tapering off again.

I found this article and thought it was very good. Naturally, it talks about Bitcoin and the end of state currencies.

http://papermoneycollapse.com/2012/06/the-death-of-banks-and-the-future-of-money/

I was pondering how transactions could be made in areas where mobile data connectivity is poor. Specifically, how shops could allow payments in such situations.

As a shop can quite easily get a land line based broadband connection, they should be able to interact with the bitcoin network. However, the shopper may not have Internet access for various reasons (and may not want to set up wifi/bluetooth etc). That got me wondering whether there was a way to perform a transaction with only the receiver being online.

If this has already been done or discussed, apologies for bringing it up again. I tried searching the forum and google, but couldn't find what I was looking for.

My idea was using temporary deterministic wallets for such transactions. You could create a number of wallets with a fixed denomination of bitcoins in them. You could then show the PR code to the cashier and they could scan the code to re-create the deterministic wallet. The cashier's till software could then transfer the money out to another account, to ensure that the shopper couldn't attempt to double spend.

If change was needed, the shop could still send money to the shoppers receiving PR code, even if the shopper couldn't confirm them. They could give you a receipt and the transaction details in case there was a problem. If the money failed to reach the account, the block chain could be examined with the details in the receipt. Obviously, the shop isn't going to want to get a bad reputation for not giving change.

Is the above possible and would it be easy to implement? Also, are there other alternatives which can be completed in similar circumstances?

Hi,

Firstly, I'd just like to say that Bitcoins are a great concept. I'm impressed with the distributed nature, as well as the incentive to create coins.

My only concern, is one of security. I have read the PDF and it seems convincing from a software engineer's perspective, but I am concerned/confused as to what happens if attack nodes become the majority. Hopefully, someone hear can clear the below questions up:

1. If over 50% of the CPU power is coming from attack nodes, what is the damage they can do? Could they just make phantom payments between consenting parties or could they make up completely fictitious payments? From the PDF, I think it is only the former (as the process requires the receivers' key) and it would be difficult to maintain. Could someone explain this further, as it seems to be the main potential chink in the armour I can see.
 
2. Would it be possible to have a 'stability rating' of some sort, which shows the (rough) percentage of disagreeing nodes? If there is a 45/55% split, people would likely be cautious when receiving payments. While this would hopefully be a rare occurrence, it would be good to know if, and to what degree, nodes are in disagreement.

3. If attackers create hardware to process the code very quickly (rather than generic CPUs running the code), would the 50%+ attacker scenario be more easily exploited? What sort of precautions could be put in place to prevent this from being a problem?

I'm keen to learn more about this project and I've already started generating coins with the Linux client (good to see support there so soon!). I the world is crying out for a reliable, distributed money and while governments may fear it, they may be glad of it if the current fiat structures continue their collapse.