The best new Bitcoin PROJECT from China! (Tablets and BITCOINS)

[Andreas Schildbach]

Why are you guys keep talking about BitcoinJ and etc... blockchain.info-like wallets are the future..

No way, I'd never give away my private keys to anyone.

By the way, the official blockchain.info app also uses BitCoinJ (-:

[1714848210]

1714848210

[1714848210]

1714848210

[1714848210]

1714848210

[1714848210]

1714848210

[1714848210]

1714848210

[caveden]

So either way, patches for BitCoinJ are badly needed.

Bounty time?

I'm a Java developer, perhaps besides pledging I may also help with some little stuff that doesn't require deep knowledge of the code to be done quickly. I don't have much free time though, unfortunately.

[unclescrooge]

Why are you guys keep talking about BitcoinJ and etc... blockchain.info-like wallets are the future..

No way, I'd never give away my private keys to anyone.

By the way, the official blockchain.info app also uses BitCoinJ (-:

Then use a client like BitcoinSpinner, which rely on a central server only for hanling the blockchain, but you and you alone keep the private key.

[caveden]

Why are you guys keep talking about BitcoinJ and etc... blockchain.info-like wallets are the future..

No way, I'd never give away my private keys to anyone.

You don't need to give away your private keys. But the transaction history will be known by the server, unless you use their Alerts Disabled mode, but then I don't know how would your local software know how much money you've got.

By the way, the official blockchain.info app also uses BitCoinJ (-:

Sure? I thought it was BitconJS, the javascript implementation.

[Andreas Schildbach]

So either way, patches for BitCoinJ are badly needed.

Bounty time?

I'm a Java developer, perhaps besides pledging I may also help with some little stuff that doesn't require deep knowledge of the code to be done quickly. I don't have much free time though, unfortunately.

First step would be to join the developer group. If you describe which feature you want to implement, I'm sure we'll help you with separating this into small steps.

[apetersson]

imo, such a deployment should use some kind of intermediate bitcoin supernode. either something like the blockchain client or BCCAPI. for simple consumers of these devices it would be unacceptable to know anything about blockchains, loading times.

properly implemented this would have no real downsides. keys on device, passwords for encryption.

next step: ship the tablets with an app store that uses bitcoins for purchase!

[Andreas Schildbach]

By the way, the official blockchain.info app also uses BitCoinJ (-:

Sure? I thought it was BitconJS, the javascript implementation.

Yes, because the blockchain.info app is a fork of an earlier version of Bitcoin Wallet.

https://github.com/zootreeves/My-Wallet-Android/blob/master/pom.xml
(search for the bitcoinj dependency)

Android uses Java, not JavaScript.

[unclescrooge]

imo, such a deployment should use some kind of intermediate bitcoin supernode. either something like the blockchain client or BCCAPI. for simple consumers of these devices it would be unacceptable to know anything about blockchains, loading times.

+1

BCCAPI allow lightweight client without having to trust a third party with his wallet keys.

Of course, what would also be awesome would be to be able to buy these tablets with bitcoins. And to have a market app accepting bitcoin

[caveden]

imo, such a deployment should use some kind of intermediate bitcoin supernode. either something like the blockchain client or BCCAPI. for simple consumers of these devices it would be unacceptable to know anything about blockchains, loading times.

properly implemented this would have no real downsides. keys on device, passwords for encryption.

All implementations I've seen had a privacy downside. The server knows everything that goes in and out of your wallet.

I'm thinking, that could be avoided though.

Some steps that could be implemented so that the server cannot see the transactions of its clients:

• First of all, the server must not have access neither to the private, nor to the public keys of its clients.
• At each new block, the server sends it to the client, so that it can verify if it received anything.
• Alternatively, to decrease bandwidth usage, if the block has a large number of outputs (> 500?), the server can send only the output list of each block. If the client has an address on such list, it requests the entire block. The server will not be able to infer which addresses belong to the client if the list is large enough, and if people don't reuse their addresses much

It still possible to the server to log the outgoing transactions though. Maybe that could be avoided by requesting a list of bitcoin nodes to the server, and sending the transaction to these nodes directly instead of routing it through the server. But then these nodes could see the client's IP, if it doesn't use Tor or something else.

I wonder... is this the way blockchain.info Alerts Disabled mode works?

[ThomasV]

are you going to run full bitcoin nodes on those tablets?
are they for exportation or for the chinese domestic market?

[caveden]

Yes, because the blockchain.info app is a fork of an earlier version of Bitcoin Wallet.

https://github.com/zootreeves/My-Wallet-Android/blob/master/pom.xml
(search for the bitcoinj dependency)

Android uses Java, not JavaScript.

Oh, OK, but I was thinking about the web app. That uses what?

[Foxpup]

Full node on every mobile device is not necessary and can't tackle the problem of "Great Firewall" blocking Bitcoin transactions. Another idea is setup full Bitcoin nodes in every major city with satellite internet connectivity.

It is necessary and can tackle the problem of the Great Firewall if these devices form an ad-hoc network in addition to connecting to the Internet. Then as long as at least one device can connect to a free Internet, that node can relay everyone else's transactions. It's brilliant.

[caveden]

Some steps that could be implemented so that the server cannot see the transactions of its clients:

• First of all, the server must not have access neither to the private, nor to the public keys of its clients.
• At each new block, the server sends it to the client, so that it can verify if it received anything.
• Alternatively, to decrease bandwidth usage, if the block has a large number of outputs (> 500?), the server can send only the output list of each block. If the client has an address on such list, it requests the entire block. The server will not be able to infer which addresses belong to the client if the list is large enough, and if people don't reuse their addresses much

It still possible to the server to log the outgoing transactions though. Maybe that could be avoided by requesting a list of bitcoin nodes to the server, and sending the transaction to these nodes directly instead of routing it through the server. But then these nodes could see the client's IP, if it doesn't use Tor or something else.

he, I guess I just described how a light weighted p2p client like BitcoinJ works. And plus, it doesn't rely on a single server that can be easily blocked by the Great Firewall.

Yeah, the more I think about it, the more I conclude that going p2p instead of client-server is imperative here. It's perfectly possible to do it "lightweight" to the point that even a mobile phone can handle. A tablet should take it easily.

[caveden]

Full node on every mobile device is not necessary and can't tackle the problem of "Great Firewall" blocking Bitcoin transactions. Another idea is setup full Bitcoin nodes in every major city with satellite internet connectivity.

It is necessary and can tackle the problem of the Great Firewall if these devices form an ad-hoc network in addition to connecting to the Internet.

It is not necessary (to be full node while being p2p) and I definitely wouldn't count on forming an ad-hoc network.

[Andreas Schildbach]

Yeah, the more I think about it, the more I conclude that going p2p instead of client-server is imperative here. It's perfectly possible to do it "lightweight" to the point that even a mobile phone can handle. A tablet should take it easily.

+1

I think we should think about reasonable enhancements to the existing Bitcoin P2P protocol and discuss that with the whole Bitcoin developer community (BIP process).

Goals to tackle:

- better support for lightweight clients
- being more firewall agnostic (perhaps by defining a HTTP(S)/SPDY variant of the protocol?)

Also, the peer discovery needs to be enhanced. Currently it uses DNS and IRC, and for both I think its a fixed server (that could be blocked easily).

[minorman]

This is truly awesome news, roger. The chinese are so
entrepreneureal once they "get" bitcoin the drive to leverage it for all sorts of things will be awesome - and lead to awesome things.

[casascius]

Full node on every mobile device is not necessary and can't tackle the problem of "Great Firewall" blocking Bitcoin transactions. Another idea is setup full Bitcoin nodes in every major city with satellite internet connectivity.

It is necessary and can tackle the problem of the Great Firewall if these devices form an ad-hoc network in addition to connecting to the Internet. Then as long as at least one device can connect to a free Internet, that node can relay everyone else's transactions. It's brilliant.

Not really.  An ad-hoc Bitcoin network would be a sitting duck for authorities to shut down at a firewall level if they didn't like it: Bitcoin network nodes promiscuously track and advertise their own IP's and the IP's of other nodes, giving the authorities a reliable targeted list of exactly where to find Bitcoin users and who to block to cut off the network, exactly the same way they can go find out the list of public Tor nodes from public Tor servers and block them in bulk.  Bitcoin traffic is also fairly easy to identify at a firewall level.

On the other hand, if a Bitcoin-behind-firewall setup is to be resilient, then the traffic needs to blend in and look like typical traffic for other non-banned applications.  It needs to look like SSL web browsing, or like instant messaging or Skype or BitTorrent at the network level, and it needs to go to a diverse set of IP's all around the world.

Given a company able to produce appliances, one nifty Bitcoin appliance they could produce is a router for non-Chinese customers that could earn Bitcoins for its owner.  That router would allow the non-Chinese user's IP to be borrowed for relaying traffic from China, to be administered by a centralized VPN company that leased the use of that router to a very small number of customers, who of course would pay in Bitcoin and the revenues would be shared with the router owners, much like a "Fonero".  With routers spread across a highly diverse set of IP's and no list of them published where the Great Firewall admins can block them all in a single brush stroke, THIS would bring resiliency to the ability to move Bitcoins through firewalls.

[Piper67]

Why isn't piuk all over this already? Earth calling piuk... Earth calling piuk... This could be huge.

[caveden]

Not really.  An ad-hoc Bitcoin network would be a sitting duck for authorities to shut down at a firewall level if they didn't like it:

Ad-hoc networks cannot be controlled by authorities. The nodes themselves are the routers. The only way they could control such a thing would be to physically search each node, seize them and punish their operators somehow. That would be much more expensive than keeping a firewall, and would definitely increase the level of "tension" between the Chinese government and its subjects.
But the thing is, current technology and its dissemination is many years away from being able of support such a thing. We cannot rely on ad-hoc networks.

[kangasbros]

To give you some kind of info about what kind of problem this is: http://www.youtube.com/watch?v=DX46Qv_b7F4

But for starters, the developers need not to worry that much - just make simple lightweight clients or something, and if they really bundle their devices with those, awesome! It hink the chinese goverment won't even think about bitcoin for a long time...