謝謝各位報價，目前已換到所需充值，下次有機會再請大家幫忙，感恩。

價格浮動只供參考，服務與手續費用請加到報價中。

因為要在掏寶購買小額商品，請PM報價充值支付寶50換多少比特幣，價格現可參考 CoinDesk BPI http://www.coindesk.com/price-cny/

用 websocket 做的網頁不錯，只是不知道 blockchain.info api 的 websocket 穩不穩，斷了是否可以自動重連？

看起來我誤解了，現階段你陳述的作法應該不在比特幣協定支援中可實做，預計 0.9 版支援出現的 Payment Protocol 確實付款端會有機會碰觸到收款端（http/file），收款端出收據即可，但沒有設計收款端還廣播到 p2p 網路這種機制，這樣是否必要？

個人認為目前只要區塊未凝固前，如出現重複可疑的可花費交易來源就等區塊凝固確認即可，因正常交易不應會同一個區塊大量出現同一筆可花費交易。雖然導致這個交易無法實時完成需要等待，但這類交易畢竟佔少數，讓這少數可疑交易等的時間對全部客戶實時結帳體驗影響不大。

如理解無誤你是指在比特幣p2p之外另建一個 p2p 供通報？這點就有點奇怪，關於通報交易這件事，基本上付款端將可付出交易簽名廣播出去後，收款端只要像礦池節點一樣監聽比特幣p2p網路就有機會收到交易，只是礦池忙著列入block並計算，而普通收款端只要累計並研判該付款交易是否正常即可，這樣為何還需要另建新的p2p網路？關於這點不是很了解。

很棒的想法，如果了解無誤的話，舉剛剛監聽廣播紀錄分析如下：

Tx   6dcbd37ef73994e022d481e92745c282d58c8e2b3a62a3651fa5c14fde7060fa: Seen by 1 peer. Pending/unconfirmed.
     in   [304502204649f2f2478aa779e98b7e2aab806667396c9e532aeeddb74f9b4029e449058d022100d8c1e3f6081045f87aace8fd1a32591e9e7f398b3488d1ffcd43a456fba2385001] [04e1e8a7e0d6b69b5b69a8b19eec13456e65adfca8ceaa99b7ef6a13724e025bad72516719a3b1a5412188e30f398f00f52a2dd322e970f1af40aba23662fe6859] / 9cb36a2d82898a5f0c6b6b56dd7cd4e065e9abf02d653af2a728a3cb5c98e1f5:0
     out  DUP HASH160 [90ffd482a2d90e5e393db7f3241433fb127a798c] EQUALVERIFY CHECKSIG 0.05465 BTC
     out  DUP HASH160 [8015cc93b07e10b4cc506ac3db57910b391b6a55] EQUALVERIFY CHECKSIG 0.01505 BTC

Tx   68d01c13ed7ab641d40cb9727a3f5c8c22cb46c09dbd956fa459a0eb77504b3e: Seen by 1 peer. Pending/unconfirmed.
     in   [3045022100c4581a71113aa2dfb9e3214686d0e3f85deafb5c0839e17a7322d3c20b7a937a02207242edcb13935bb53f5a3b5bc76cf36362c756554c66deab8ff2fa543d3435a701] [02a525c468e8605871a12209d4abbda3d7644754f5b32fc3ea22a86ecf6fb30178] / cd8670ad525e6a4fc5e5b65d59df56b169b75adf63a58b3b29b84f902c7247c9:0
     in   [304402200bdcf8e62fb7af97b62af772169f55ca9c30dc1b9b240dd7df5ae6214be320e802202b4238bb8eb5569f4a398e41b98b2fdf2ebb83fbb4e7a84fc43cd3dc17bdad5601] [029a8432e38cd6a8cb1a7095d06e0fec06b131dca6ed12a3b3af7b8d588324af08] / 3f096ab56e2a0d2de29be93cbbda9f57c617fa46212a6395dc16a3448e72c27d:1
     out  DUP HASH160 [ef953062aa5273b096945aa8e4cd92cd992baf5a] EQUALVERIFY CHECKSIG 1.31762548 BTC
     out  DUP HASH160 [89a76f92adccb0632ad187d1cd4b14afa4da454f] EQUALVERIFY CHECKSIG 0.0965 BTC

一般收款注意的是 out 部份是否進來，地址數量是否無誤，但樓主建議監聽過去幾分鐘的 in 的 OUTPOINT 來確認是否出現2/3多花議題，這樣可加速實時確認。舉例上面要紀錄的是

9cb36a2d82898a5f0c6b6b56dd7cd4e065e9abf02d653af2a728a3cb5c98e1f5:0
cd8670ad525e6a4fc5e5b65d59df56b169b75adf63a58b3b29b84f902c7247c9:0
3f096ab56e2a0d2de29be93cbbda9f57c617fa46212a6395dc16a3448e72c27d:1

這三個未確認的OUTPOINT是否在這次區塊未定前出現在你收款交易裡面，如無出現則只要監聽到正確OUTPUT地址數量就放行（正常這個應該佔大多數）。

交易範例收款xxxx3062aa5273b096945aa8e4cd92cd992bxx地址，數量1.23456BTC。

Tx   xxx01c13ed7ab641d40cb9727a3f5c8c22cb46c09dbd956fa459a0eb77504b3e: Seen by 1 peer. Pending/unconfirmed.
     in   [xxxx022100c4581a71113aa2dfb9e3214686d0e3f85deafb5c0839e17a7322d3c20b7a937a02207242edcb13935bb53f5a3b5bc76cf36362c756554c66deab8ff2fa543d3435a701] [a525c468e8605871a12209d4abbda3d7644754f5b32fc3ea22a86ecf6fb30178] / cd8670ad525e6a4fc5e5b65d59df56b169b75adf63a58b3b29b84f902c7247c9:0
     out  DUP HASH160 [xxxx3062aa5273b096945aa8e4cd92cd992bxxxx] EQUALVERIFY CHECKSIG 1.23456 BTC
     out  DUP HASH160 [xxxx6f92adccb0632ad187d1cd4b14afa4dxxxx] EQUALVERIFY CHECKSIG 0.8888 BTC

這時上面三個 OUTPOINT 中一個 cd8670ad525e6a4fc5e5b65d59df56b169b75adf63a58b3b29b84f902c7247c9:0 出現在你的交易裡面，那這個交易的實時確認可行度就大幅降低，這時就要算一下是否超過或是等到下個區塊確認。這樣一來通常除非客戶端軟體被駭或是刻意詐騙，不然收款端可以讓大多數交易都可實時確認。