“条件支付”是目前最急迫需要的功能

[bitcrab]

正是天街团队做的事情，
还包含：
1.账户的全局标贴，
       

Code: [Select]

        enum class AccountLabel{
            //role 0x00~0xFF
            Shop=0x00,
            Arbitrator＝0x01,
            Guarantee＝0x02,
           
            //taobao 0x0100~0x01FF
            ShopType=0x100,
            ShopName=0x0101,
            ShopDescription=0x0102,
            DealAmounts=0x0103,
            GoodDeal＝0x0104,
            BadDeal=0x105,
           
           
            //Arbitrator 0x0200~0x02FF
            ArbitratorName=0x0200,
            ArbitratorDescription=0x0201,
            ArbitrationAmount=0x202
           
        };
2.单独的加密传输协议，
3.加密仲裁协议，

很快就可以看见测试版本了；

天街是否不改底层，只是象@abit描述的那样借助现在账户中的多重签名实现？

[skyStreet]

 正是天街团队做的事情，
还包含：
1.账户的全局标贴，
       

Code: [Select]

        enum class AccountLabel{
            //role 0x00~0xFF
            Shop=0x00,
            Arbitrator＝0x01,
            Guarantee＝0x02,
           
            //taobao 0x0100~0x01FF
            ShopType=0x100,
            ShopName=0x0101,
            ShopDescription=0x0102,
            DealAmounts=0x0103,
            GoodDeal＝0x0104,
            BadDeal=0x105,
           
           
            //Arbitrator 0x0200~0x02FF
            ArbitratorName=0x0200,
            ArbitratorDescription=0x0201,
            ArbitrationAmount=0x202
           
        };
2.单独的加密传输协议，
3.加密仲裁协议，

很快就可以看见测试版本了；
 

[abit]

这个事需要改底层，那么就连带之前审计出的几个bug，还有几个其他的需求，一起把底层更新一版吧。真是太久没更新了。

我感觉，底层加新需求的事，目前没人有这个 能力+精力+意愿+社区认可。

[abit]

我想，还是应该追求链上原生实现，应该每个人都可以用自己的常用账户来直接进行这种交易，而且GUI钱包里就该直接集成交易界面。
看了一下steem的流程https://golosim.ru/escrow/index.html，感觉有点问题：

1.escrow在绝大部分正常交易中应该不需要参与，就像基本所有的淘宝交易都不需要找淘宝做仲裁，而steem的方案中要求escrow每次都要approve，没有道理。

2.应该只有一个expiration time，比如30天，如果买方发起“条件支付”之后B也进行了“交付”操作，之后再无操作的话那么30天后资金自动从买房发送到卖方，就像淘宝一样。

感觉与这种交易配套，最好每个账号有一些字段储存个人信息，如微信账户，电话，支付账户等等，只有条件支付的对手方能看到这些信息，不过这样复杂性似乎又高了

Steem 里 Approve 动作一开始的设计里也没有，是后面加的。目的是为了保证中间人是活动账户、并且愿意作为中间人，避免出现有争议无法处理的情况。对于有意愿的中间人，可以用一个脚本来监控，自动同意；也可以设置黑名单，不接受某些账户的支付。最初设计见 https://steemit.com/sip/@ dan/escrow-sip-steem-improvement-proposal

Steem 里几个超时的设计也是有道理的。

账号专用字段存储个人信息并不复杂，用Custom操作即可。但是要做到只有对手方可以看的话，就比较难；可能也不太实用，比如某账户存了个人信息，其他人创建个0.01BTS的虚假交易，是不是就能拿到该信息？直接用MEMO方式可能可以。

[ripplexiaoshan]

这个事需要改底层，那么就连带之前审计出的几个bug，还有几个其他的需求，一起把底层更新一版吧。真是太久没更新了。

[bitcrab]

我想，还是应该追求链上原生实现，应该每个人都可以用自己的常用账户来直接进行这种交易，而且GUI钱包里就该直接集成交易界面。
看了一下steem的流程https://golosim.ru/escrow/index.html，感觉有点问题：

1.escrow在绝大部分正常交易中应该不需要参与，就像基本所有的淘宝交易都不需要找淘宝做仲裁，而steem的方案中要求escrow每次都要approve，没有道理。

2.应该只有一个expiration time，比如30天，如果买方发起“条件支付”之后B也进行了“交付”操作，之后再无操作的话那么30天后资金自动从买房发送到卖方，就像淘宝一样。

感觉与这种交易配套，最好每个账号有一些字段储存个人信息，如微信账户，电话，支付账户等等，只有条件支付的对手方能看到这些信息，不过这样复杂性似乎又高了

[abit]

链上原生实现，可以参考 Steem ： https://steemit.com/escrow/@ xtar/open-source-standalone-gui-for-steem-escrow-transactions


不改底层的话，目前可以用 2/3 多重签名来搞，虽然流程稍微有点复杂，但是可以自动化完成，也就是说，需要做个 UI 。

设想流程如下：

1. 中介组织 A 创建一批账号，比如A1~A100，拥有完全权限。账号数量决定可以同时进行的交易数量。
2. 卖方B在系统外比如taobao上挂单，比如卖 1 BTC，要价 10000 BITCNY，BTS账号为 B
3. 买方C看到卖方的挂单，发起包含如下几个操作的提案（提案一）：
a) 预付中介费
b) 从A1-A100中选择一个空闲账号比如 AX，修改AX权限为 A+B+C 的2/3多重签名
c) 将货款付到 AX
4. 买方C批准提案一，对a、c操作授权
5. 中介A批准提案一，对b操作授权

如果AX和C账号余额足够，则操作完成，货款到达AX；如果余额不足，则所有操作不生效。

6. 中介A或者买方C通知卖方B发货

7. 卖方B发货后，发起包含如下几个操作的提案（提案二）：
d)从AX支付款项到B
e)将AX权限设置为A完全控制

8. 卖方B批准提案二，对d、e操作部分授权

9. 买方C收到货，批准提案二，对d、e操作完成授权。

正常情况下，交易完成，AX账号回收到A所有，可以后续使用。

如果发生意外，B和C可自行协商款项去向，无需中介参与。

发生争议的情况下，由中介仲裁，决定多少货款返回C，多少付给B

有个情况是买卖家可能合谋“偷走“中介账号。这个问题，一开始可以多收点中介费，包含一个押金，这样交易双方有动力归还账号。退押金的操作需要中介参与。

交易量大的买家、卖家可以自备多个账号，这样的话，只有在发生争议的时候，才需要中介参与。

理论上中介可能和任何一方合谋欺骗另一方。这个采用系统外的口碑、第三方监测来尽量避免发生。同时，单笔交易标的不宜过大。也可以采用中介交押金到理事会、或者威望更高的第三方组织用多重签名的方式来管理。

以上，望抛砖引玉。

[华探长]

自己做费时，如果能找到现成的网站合作那是最简单的，比如localbitcoins，和他们合作，请他们增加一个bts，然后给予他们一些bts作为报酬，这是最快的。

[bitcrab]

我强烈地感觉到，在所有讨论过的新功能中，“条件支付”是目前最急迫需要的功能。

我们先看一下以下两个最适配也最需要解决方案的场景：

1：人人网关
2：BTC场外交易

还有以下不是最紧要但也可能适配的场景：

1.跨境商品交易
2.全球任务外包

作为交易，这些场景能够抽象出一种最基本的特点，就是在链上完成一个方向上的支付，然后另外一个方向上的交付在链下完成。

自然，这种交易没法直接在链上实现原子化，必须依靠某种确认+仲裁的机制才能保证正常进行，A先“条件支付”一定数量链上资产（如bitCNY）给B，同时在memo中描述清楚无异议的交易条件，选择仲裁账户C，支付，此时支付的链上资产被系统锁定。

B看到A发起的条件支付交易，在认可交易条件的前提下，在链下完成约定的交付，并且对条件支付交易进行“交付”操作（类似淘宝卖家的发货）

A对链下的交付结果无异议，对条件支付交易再进行一次“确认交付”操作（类似淘宝买家的“确认收货”操作），则锁定的资产将释放给B。交易完成。

如A条件支付后因某种原因需要取消交易，则进行“取消交易”操作，经B确认后锁定的资产退还给A，类似淘宝交易中的退货。

如果交易中发生争议，则有仲裁者C来选择支持某一方的立场，最终锁定的资产按改方立场分配。

当A发起条件支付交易时，交易对手方可以是空的，比如人人网关的场景下， A可以支付1000bitCNY给一个空账号，同时注明：995元出售，支付宝账户***，此时任何人可以选择接受此交易并通过支付宝支付995元来获得1000bitCNY，这就是人人网关。

随着BTS价格的增长，人人网关的意义越发凸显，很明显在承兑的需求快速增长的情况下两条路可以选，一是象transwiser这样的网关选择公司化运营，做大做强，二是把承兑服务的提供方也给去中心化了，由用户群体自身来提供服务。我相信，这两种方式可能都需要，而人人网关尤其需要。

而且，有了条件支付功能，BTS直接就是一个去中心化的BTC场外交易平台，这意味着什么不用多说了吧？

还有象跨境商品交易，国际任务外包，都有可能适配成条件支付支持的场景。

几个月前我发过一次帖子讨论这问题，结果是都觉得不错，然而最后还是感觉无从落地。。。https://bitsharestalk.org/index.php/topic,23800.msg302876.html#msg302876

这次希望中国的开发者们先能提供一些意见，尤其是在开发和实施的可行性和难度，成本等方面，先给出一些意见，我也会在国际社区推进讨论，希望能逐渐选定合适的开发者来开发这一功能。