Bitcoin Forum

先祝大家情人节快乐！呵呵。。。

目前 Bitcoin 系统每个区块创建的时间间隔平均是 10 分钟，这是一个综合考虑多种影响因素而选择的一个折中值。太短的时间间隔难以充分广播一个较大的链块，这制约了每个块所能包含的交易数量，综合效率不高。但这样的间隔时长并不适合即时的购物交易——很难想象面对面的柜台付款之后，商家要并不安心地等待 10 分钟以上才能确认客户是否诚实，或者客户要等待 10 分钟才能证明自己诚实并拿走商品（这还只是一个平均时间，偶尔碰上迟迟不能确认也并非少见）。

无疑地，要么商家忐忑不安让客户即购即走以提供良好购物体验，要么客户购物后百无聊赖等待商家放行……（PS：如果虚拟币流行，以后的付款方式可能改变，如不再是柜台即时付款，而是顾客选购时即可自主扫描商品付款，柜台只是验证付款状态。～～但也不能排除急购急走的需求）

或许你会说，买的东西又不贵，暂且先相信素不相识的顾客吧——人之初性本善。
或者你又说，如果买的东西很贵的话，那就让客户委屈一下多等等咯～～

这样的对待方式和客户体验并不好：商家不安心，客户很无奈……而不老实的客户欺诈购买会很容易——10分钟内一笔款多次操作（如网购、转账、当面购等混合采用）。

那是否有一种方式，可以让没有确认的交易也安全可靠呢？购物顾客只管买了就走，付款绝无欺诈？

答案是：有！～～但需要一些“基础设施”。

我们知道，比特币的转账交易其实有两种场景：

• A. 实时的买卖双方“收付款交易”，不论是网上的还是面对面的，双方都肯定实时在线（至少是可以同时在线）；
• B. 收款方无需即时确认付款的“汇款交易”——没有商品或服务被拿走，收款由系统正常确认（非即时）；

实时收付款无需考虑 B 场景，几十分钟的汇款时间基本上无关痛痒，而且收款方也必须等到转账完全确认之后才能使用收到的钱。

那么在 A 的场景中，我们如何实现即时的付款得到即时的“安全”呢？要知道，这些交易都尚未被 Bitcoin 系统初步认可，多花太容易了！

解决方案的原理其实很简单。

未确认的交易有如下特征：

• 顾客购买后的付款交易是已经广播了的，只不过还没有被正式确认（封装进区块）；
• 这个交易的有效性依赖于已有的区块链账本和该顾客之前尚未确认的其它付款交易；
• 如果商家知道顾客之前尚未确认的付款交易，那本次交易就可验证！
• 但是，暂无机制可验证未确认交易的合法性（有效性）。

如果：我们解决了未确认交易的合法性问题，那就保证了当前交易的实时验证是可靠的。

假设如下场景：

某甩男一个比特币账户上有 1000 mBTC，他向商家 X 买了一台价值 400 mBTC 的前卫电动车，然后 5 分钟内向商家 Y 买了一枚早已中意价值 500 mBTC 的钻戒，此时突然想起应该给情人先发一个比特币红包，于是掏出手机包了一个 214 mBTC 的比特币红包发到了一个新地址里……

10 分钟内，三笔交易发出了，都还处于未确认状态。或许你已发现，支出的总金额已经超了 114 mBTC。Bitcoin 系统会怎么处理这三笔由同一个地址发出来的超额交易呢（请忽略钱包有余额管理的功能，因为这个钱包可能有些问题，别把商家的安全寄托在顾客的客户端钱包上）？很明显，有一笔交易会被忽略，但会是哪一笔呢？不一定是发给情人的红包，有可能是骑在身下的前卫DD车～～呵呵，发财了……当然是不义之财。

有没有可能，被系统忽略的必然是那一笔红包交易（汇款）？并且珠宝店在卖出钻戒之前，还能知道该男子那个比特币账户实际上只剩 600 mBTC 了？如果两者都可能，那该男子就没法意外或不意外地“发财”了。于是，商家安心，交易实时进行。体验很好！

这里有两个要点：

• 未确认交易可以被商家知道；
• 无需商家付出商品的“非实时类”汇款交易被 Bitcoin 系统降低验证处理的优先级（优先处理和商家的实时交易）；

或许您已经看出来了，如果要实现第一点，只要商家有一个专用的“收款客户端”即可。收款客户端在收款时是开启的，它与其它收款客户端连接，并且在每一笔收款后广播该交易。收款客户端同样采用 P2P 式联网，每一个客户端都接收和维护那平均 10 分钟的全球未确认交易。于是，当甩男驾车到达珠宝店时，他的上一笔购车未确认交易记录已经在珠宝店的收款客户端里了。

对于第二点，实时交易可以由商家签名然后再转播，以区别于无需商家签名的普通“汇款”（即现有的转账交易）。要让 Bitcoin 系统优先处理实时交易（通过商家签名辨识），就需要 Bitcoin 的挖矿客户端升级了——无需修改已有的 Bitcoin 协议，只需矿工可以识别实时交易，并调整交易验证的优先级即可。

完了，问题解决。

若您富裕，欢迎打赏：
1Q7U45ZNLyYNYe6yWT7gaf6H6JNRB9Jeih（BTC）
PXheD3xDPu2ZXUmjrXSDFZ4Yi3YJM3kmTu（PPC）


PS：如果担心顾客可能有的上一笔未确认交易广播尚未到达，可以跟顾客先瞎聊一下天……@￥&#*%..


如果有什么存疑，欢迎讨论！

楼主对狗币和LTC的交易确认时间比BTC短得多视而不见，说了一大堆说不到点子上

文很差

支持这样的思考，中文论坛中广告和行情太多，有价值的讨论太少了。

GMTA

e.g. MINT (http://mintcoin-explorer.info/t/8u5DacQgpn)
 ;)

支持！！虽然区块并不区分是收款还是别的什么交易，但全网广播是无区别对待的，仅按时间来进行。因此，想法虽好，但在现行BTC协议下可能无法实现

多给些手续费不就可以了？

支付宝，Visa卡这些都能做到即时确认，比特币为啥不行？因为比特币没有一个可信任的中间方（去中心化？），技术上实现不难。但是相对传统的电汇，比特币对于外贸贸易还是有相当前途的，因为确认比银行快多了，而且不用怕对方赖账！

如果可以实现“零确认”的安全交易（相对的），那比10分钟更短的交易确认时间就没有意义了。相反可能还是一种浪费。

不懂！

这个“办法”行不通的。看来对 bitcoin protocol 和机制还是理解不到位。

不是很明白，建议加图

学习了。。。。

同意！

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

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

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

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

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

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

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

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

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

这个倒是没错。

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

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

谢谢讨论！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

调高手续费不可行

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

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

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

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

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

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

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

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

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

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