Topic: 【设计】比特币“零确认”但安全、实时的收付款交易机制 (Read 2897 times)

学习了，技术性文章一直是我的最爱

比特币“零确认”会安全吗

感覺起來還蠻穩的,不過某些時段 blockchain.info外連的node會降到300多,可能一些交易會收不到,如果websocket斷了,頁面更新即可

确实比特币可以滋生出太多的可能，看看现在层出不穷的山寨币以及如雨后春笋般涌出的创业公司，在比特币的世界里，可以向很多方向延伸。
0确认，之前在一个论坛听别人讨论过。

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

我做的小網頁,用來檢測安全可信賴的即時零確認交易,歡迎指教
Check the zero-confirmations immediate tiny-payment security

http://jimmyscratchlab.github.io/check-tinypayment/

是的，Bitcoin 协议中没有这个设计。我是在说这样一种实现可能性，如果可行，需要 Bitcoin 团队采纳这一想法。

只需要让矿工优先处理商家签名转发的交易，就可以支持这种“几乎实时的收款客户端”，就像现有的 Bitcoin 设计可以支持“轻客户端”一样。一个简单的处理，就可以支持商家专用的收款客户端了。

依目前 Bitcoin 的实现，商家（实体店）收款后立即让顾客走人，理论上是有风险的。
PS：既然有风险，就一定会被恶意利用，就像本来看似无足轻重的“交易延展性”一样。

调高手续费不可行

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

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

目前类似COINBASE这样的平台是会有生命力的，但是，由于没有解决“交易延展性”问题，COINBASE也会出现MTGOX的类似问题，只是多与少而已。当然目前很多人并不知道黑客利用“交易延展性”是偷不走个人钱包的钱（黑客可以利用木马等窃取用户钱包密码，以及钱包文件窃取客户钱财），因为个人计算往来账目是用脑袋来计算的，黑客对此没有任何办法。但是，交易所瞬间往来账目太多，只能用BC来判断，才会被黑客钻空子。如果BTC协议没有修补，当然它的支付功能应该大打折扣。这也是最近BTC不断下降的原因。跟MTGOX倒是没有太多关系，它只是引发寒流的主要因素之一。

不是另建P2P网络，就是通过Bitcoin的P2P网络——因为还需要由商家签名转播“付款交易”（矿工要优先处理商家签名转播的交易）。


如果没有“商家签名转播付款交易，同时矿工优先处理转播的交易”这个机制，这个研判无法防止“客户在购买商品立马走人”之后立即进行一次“汇款”（两笔加起来就超额了），从而可能导致商家的收款被判非法的情况。

PS：如果那笔“汇款”支付了较高的交易费，那商家之前收到的付款（间隔时间可能就几秒钟）被判非法的可能性就大多了。P2P 网络中的矿工无法严格按照交易发布的时间顺序来处理交易。

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

就是需要实时确认付款有效性的商家，运行收款客户端组成一个 P2P 网络互相通告：“某账户上已经消费了xxB了，尚未确认啊，大家记住了……请注意自己的收款啊！”

但是有一个必须的条件：矿工必须优先处理商家通告广播的交易（商家签名转播）。否则可能被顾客同一账户的汇款交易（没有商家互助通告）排挤掉。

理论上，商家是肯定愿意运行收款客户端的，因为收款后转播的交易会优先处理，这样就不会被超额付款所坑。如果有超额付款的情况，只会是“汇款交易”（没有商家组成的 P2P 网络帮助验证余额），但这样的交易会被矿工排除，也就无法真正实施超额汇款了。

有兴趣可参看这个讨论贴（外链）：http://bbs.btcman.com/thread-14819-1-1.html

中心化是一个解决办法，但说实在的，它会面临很多很大的挑战。

对于一个 P2P 分布式的系统，要在其上提供中心化的服务，业务的选择很重要——必须能够逻辑上良好契合互补，否则很容易被 P2P 的天然特性所击溃。

如果要想选择基于 P2P 虚拟币系统的中心化服务，个人建议做小微支付。这样的小微支付系统相对独立，可不受制于比特币的确认安全性问题。
可参考：适宜于小额“微支付”的虚拟币设计探讨

交易确认速度，和去中心化是一对矛盾。比特币这个确认时间的确会影响其日常使用的普及。

简单的办法是这些交易回归到中心化 --
到coinbase这样的支付平台或者（无耻小广告）我们LakeBTC这样的交易平台，站内即时确认，而且可以立刻平盘规避汇率风险。
对大多数普通商家来说是很好的选择。

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

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

这个倒是没错。

这个方法只是用于小额的即时购买，减低一些商家的风险——总比没有任何措施好得多。
一般的，收款之后（本地交易已产生），可以让顾客稍等一下以便充分侦听异地同址广播（应该不需要超过1分钟），以验证是否超额消费。

这当然不是完全的安全。即便可以等待P2P充分广播，但区块链一旦分叉，这种办法就有问题。

谢谢讨论！

PS： 现在有不少商家和交易平台支持1个确认到帐，这其实也是有区块链分叉风险的。但综合权衡，似乎也是可以接受的。

结论似乎是这个： 这个方法把交易的 “第一个确认” 的时间虚拟缩短到了秒级（或至少是很短），它的 安全性与“一个确认”几乎相等。

真正的安全当然是要等到 6 个以上确认了，这毫无疑问。

结论不对。支持思考精神。

1. 未确认交易无法很快广播全p2p网，分布式的网络，很难保证这个QoS。即便是有1、2个确认，如果blockchain分叉，也有可能被其他的分支取代。
2. 很容易被黑客利用
3. 要想快，多出手续费。

道理其实很简单，基本上与 Bitcoin 协议无关。

假设你的一个比特币地址有 10 个币，你在短时间内
1. 买了 2 份商品（商品购买是付款了就离开柜台），分别花费 4B 和 5B；
2. 发了 1 次汇款（付款了不会拿走任何东西），金额为 3B。

假设 3 笔交易是在 1 分钟内产生的，没有任何一笔交易得到确认，其中任意两笔交易加起来都不超过 10B。
也就是说：任意两笔交易都可以被接受，而第 3 笔交易会被判定为非法（超额了）。

请问：第 3 笔交易会是哪一笔？

Bitcoin 系统是 P2P 方式运作的，也就是说：不同的矿工判断为“非法的第 3 笔交易”是不同的——这样，就导致了矛盾。根据 PoW 机制，系统最终采用的只是算力决胜的哪一个矿工的判断（这样就解决了不同矿工因判断不同而导致的冲突）。

所以在未确认状态时，需要一个机制来保证商家收款后能够 “即时发现超额支付” 的情况。本帖提出的方案就是一个解决办法。

这只是简单的逻辑，不需要深刻理解 Bitcoin 协议。