 Show Posts
|
|
Pages: « 1 [2] 3 4 »
|
|
Bither is a bitcoin wallet on both iOS and Android, and it is also open source.
Bither have two mode
Bither Hot Wallet: running on your daily phone, can easily monitor your bitcoin assets, and you can also save small amout of bitcoins in it to pay bitcoins anytime, anywhere.
Bither Cold Wallet: running on your backup phone (old or cheap one), keep the phone offline and save large amount of bitcoins in it, then you can keep your bitcoins as safe as possible.
Communicating between Bither Hot and Bither Cold is simple, the only thing you need to do is scanning the QR-Code.
You can have a try.
|
|
|
|
回楼上: 结合使用Armory或electrum钱包离线签名技术 即可
这两个钱包仍然是需要用u盘连接上一台不联网且存有你私钥的电脑。麻烦不说，u盘也是传播病毒、木马的重要途径。 不用U盘，可以用二维码传送 是得用二维码。那二维码怎么扫呢，电脑扫电脑么？ |
|
|
|
慢慢做就做成blockchain.info了  |
|
|
|
回楼上: 结合使用Armory或electrum钱包离线签名技术 即可
这两个钱包仍然是需要用u盘连接上一台不联网且存有你私钥的电脑。麻烦不说，u盘也是传播病毒、木马的重要途径。 |
|
|
|
|
楼主说的方法让比特币钱包在创建、储存的过程是比较安全了。但有个问题被忽略了，如何安全的使用。如果比特币是买来一直放着给后代的，那么这个问题倒可以忽略，让儿子们去考虑就好了。
要是需要用钱时把纸钱包的私钥一抄出来，然后输入了带木马的机器。。。然后就没有然后了
|
|
|
|
现在交易所都这么发达了，还在担心大家都会存起来不卖么？真当交易所里都是机器人大战么  |
|
|
|
|
20年太远，变数太多，谁知道会发生什么
但想想20年前的互联网，心情会愉悦不少
|
|
|
|
100B以下 黑客不敢兴趣
那我10币以下更不用担心了哈哈 蚊子腿都是肉，黑客不会嫌肉塞牙的。如果分分钟就能偷的当然顺手就。。。 |
|
|
|
若此阶段还在用和钱相关手机应用的，只能说你是高级一点的小白！
对手机应用的安全性的担忧实际上是一种误解，无论是android还是iOS在系统上都是被设计为不能跨应用访问数据，简单来说就是另一个应用无法访问钱包这个应用的数据（比如加密后的私钥等）。这点上来说比windows之类的桌面操作系统来说要安全的多。你电脑上装个multibit，那么是很容易（分分钟）的写个程序访问到.wallet文件的。 大家经常诟病的android的不安全，往往是因为大家将android机器root了，破坏了系统本身的安全保护。另外android的各大市场因为较乱，所以有不少流氓软件。但流氓软件通常也只能被用于上传通讯录、偷发短信、偷跑流量等，并不能偷取其它应用的私有数据。 |
|
|
|
|
可以试用下比太钱包，android和iOS版本都有
|
|
|
|
You haven't replied on this, yet?  I think a new problem has been arisen. So have you done that? Did you forgot about the license agreement? OR is voisine wrong? What do you mean by "Bither is a server trusting wallet"? Please check carefully and please don't spread false news!   You are correct. My apologies. I mistook the code that connects to the bither server api for the code that handles transaction and balance data. The bitheri library appears to have copied large portions from the breadwallet source, and is in violation of the MIT copyright license I published it under.  I've submitted a github issue requesting they retain my copyright notice in compliance with the terms of the MIT license. ~~MZ~~ Sorry for the late reply. It is holiday in China from Oct.1st to Oct.7th. Other members of our team are still on vacation now. I came back earlier, so I saw your PR and merged it. In the past, we were working hard on improving our solution. We just used script to add license infomation automatically, and we had planned to add these after we released the stable version. We will maintain all related copyright notices in the future ASAP. |
|
|
|
I do recommend cold wallets, robust ones, like Armory
If you get a "malicious"/"bug" Armory, how can you protect your bitcoins? With your " robust"? |
|
|
|
新版本的bither android 0.0.9采用了我们自己的Bitherj引擎，比之前的版本稳定了不少，也省电了不少，大家可以试用下！ |
|
|
|
I can very very cheaply create 100 difficulty 1 blocks and feed them to your client and claim that they're the tip of the best chain. You'd know no better. I don't think compromising the security of SPV wallets further is worth an unnoticeable small improvement. A zero trust compression of the past headers with log(n) scaling is possible too, and will hopefully be deployed for other applications. Because of the above point it is not very interesting for SPV, but if it were deployed in any case using it would be much better than having an unverified and unverifiable dependence on peers. Dear gmaxwell: Thanks for your suggestion. I will read and try to understand the link you post. Zhou Qi Bither Team |
|
|
|
In this BIP, I want to improve the way to find the first block header we are going to store in the client. What you are saying is since which block we may want the transactions in it. In another word, I'm talking about which block to start header downloading. While you are talking about which block to start body downloading, which means header downloading should end in the mean time. We are not talking about the same problem here.
If you read carefully I moved the problem to the FCU simply because it's pointless to set a checkpoint without considering the FCU, unless you intend to support raw monitors that only observe upcoming blocks and transactions. I don't see any advantage for SPV wallets with some history, whereas a protocol message providing a (timestamp -> checkpoint_hash) mapping would be much more useful for both monitors and wallets. By checkpoint_hash I don't mean "the first block with transactions", rather a checkpoint block the way you meant in your previous posts. Example: "hey peer, I want to start syncing from 'Jan 01, 2012' (or from now on). I don't have any idea about what the hash of the first block to start sync from could be, can you give it to me?" For now, FCU is only use for decide to use getblock message or getheader message which means download block's transaction or not. But we still need to know the first block's hash, and get the first block's block time to decide with FCU. OK, may be you think why not peer direct give us a block hash that before a point time? I think it may be a future improve for Bitcoin, and may be another BIP. |
|
|
|
SPV mode stores only the most recent block headers. When a user uses the light wallet for the first time, the light wallet will sync with the Bitcoin nodes from a staring point of block header. The getblockhash message contains only one uint32_t field that means block height to indicate the needed block. bitcoinj and other SPV clients infer the starting block using the fast catch-up timestamp concept, that is typically the timestamp of the oldest key in the wallet or -in other words- the timestamp before which we know no relevant transactions exist. The FCU is totally blockchain agnostic so there should be a way to translate the timestamp to an effective checkpoint block instead. Using a block height instead of a hash is of no help to me, we don't know in advance which height to start at anyway. In this BIP, I want to improve the way to find the first block header we are going to store in the client. What you are saying is since which block we may want the transactions in it. In another word, I'm talking about which block to start header downloading. While you are talking about which block to start body downloading, which means header downloading should end in the mean time. We are not talking about the same problem here. |
|
|
|
|
