From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E6C39FAB for ; Tue, 30 Jan 2018 01:23:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com [74.125.83.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 637012F1 for ; Tue, 30 Jan 2018 01:23:25 +0000 (UTC) Received: by mail-pg0-f51.google.com with SMTP id m136so5890131pga.12 for ; Mon, 29 Jan 2018 17:23:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=realss-com.20150623.gappssmtp.com; s=20150623; h=sender:from:date:to:subject:message-id:user-agent:mime-version; bh=5gFvsho2aLXgUOlGysql0sLXYDlKI8Xbj0tTr2B7o3E=; b=A4dTqkKqoWmOfYVstvBygdoDGoFZb49m6kL1nKdE3GnQ6yvhThG9231dPcf1F+bLMh 7410vlYXL003N0ZnGCeS1Wye6f9Hsc1WBC7mIkfHktCx6sETUW2llyFqR6oRpfrrb+nr qk39ElcCGh+dPhpf/dxTgry9zb8+YiESMrvxLNZsEio/rr7b7UjlRa6lnIH2OPXUIQjb Dp2mOeeO3BBOCSiGhGuTYLJvY3sakUXGP+NdM95D9XKeBoIxvSxHoP67JSGQNL2iFNc4 Lf4Z8X8XBiz/0B73rjzF7mwm3e1JeZY3rQNMgn1rLRTNW6EVsz2D/gLdxNQs/Yk7GmDF z6jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:date:to:subject:message-id :user-agent:mime-version; bh=5gFvsho2aLXgUOlGysql0sLXYDlKI8Xbj0tTr2B7o3E=; b=gVgrk5Mdo7MkZthvhToiMOJFbb/xFWz3nUghhjyWlIRqKXy8pcikJ6iMG39R046O/5 UtFJ7ZcB8Vvo727cQTIyfL9K62fzlZ75UYIijlmRycuBKwkB6C8MsbLYh6CBSWDcRtkl 5sJZyifbIMTqM6ehGCi3g2H1zXeRmEPn9JgvQSAlFZ4sZsNn0UWVU1vq0WOUk/L4jfsd Hl4R8qCRx9TquqdFAlqUJCk2iO1yOtht/UGRFajXBUwkp56NUEo3BkszrqZJRFkOTgcc YB38KjIw0CBcDrZAuhrvU2nD3+NQe/D9kfWpoFqKJJQ2w38PxhR/cXerIIwDWZGJBnV2 KjMw== X-Gm-Message-State: AKwxytd5X81QUhSVww+lup27HleTt9Q6PnYJk906O1Iezim5IG7ahKEt 0q9Wav2kaQ9gtc18qtiIIm8AYg== X-Google-Smtp-Source: AH8x224xTsUGg/s7P5RwAN5LbBVEN4aq2EDFk7nqX/kezr85BoYgqohy739GSbJfiQj/drHvKPUkUw== X-Received: by 10.98.190.11 with SMTP id l11mr28823163pff.32.1517275404653; Mon, 29 Jan 2018 17:23:24 -0800 (PST) Received: from notCBApc ([66.96.208.58]) by smtp.gmail.com with ESMTPSA id p25sm31283553pfj.29.2018.01.29.17.23.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jan 2018 17:23:23 -0800 (PST) Sender: Weiwu Zhang From: Weiwu Zhang X-Google-Original-From: Weiwu Zhang Date: Tue, 30 Jan 2018 09:23:13 +0800 (+08) To: rmcc4444 , Bitcoin Protocol Discussion Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1635907999-1517275403=:27227" X-Spam-Status: No, score=0.5 required=5.0 tests=ADVANCE_FEE_4_NEW,BAYES_00, DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 30 Jan 2018 03:08:08 +0000 Subject: Re: [bitcoin-dev] 2 step confirmation system X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 01:23:26 -0000 --8323329-1635907999-1517275403=:27227 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 24 Jan 2018, rmcc4444 via bitcoin-dev wrote: > I know from speaking to my friends not involved with Bitcoin that two of > their major concerns are as follows:  > 1. They are afraid if they fat finger the address there is nothing they can > do about it and not get their Bitcoin back. I can empathize with this. A friend of mine, an artificial intelligence expert of the biggest bank in our country with a degree in math and IQ of 150, copied his merchant's Bitcoin address as his and sent to a colleague to ask for a repayment. As a result, the merchant got paid twice. That was back a few years ago when Bitcoin could be used for purchasing goods. There are a few ways to address this issue. For starter, the beneficiary's wallet can generate a signed payment request instead of just an address. The AI expert, in his case, wouldn't be able to generate a payment request for the merchant because he doesn't have the merchant's key. The payment request can have a timestamp for the sender to spot the reuse of old request. There are advanced methods to go down this route, e.g. in the cases where there is an invoice, or buyer's public key is known, these can be associated with the payment request or be used in some homomorphic magic to generate very special addresses to receive the money. Then, there is the option of sending the transaction (in a private channel) to the beneficiary instead of broadcasting the transaction. The beneficiary, we trust, will not broadcast the transaction if he would not receive money as a result of it or he sees the transaction wasn't constructed correctly to his wish. In fact, he may not be able to even see the transaction without the right private key to generate a decoding session key. This method solves another use-case: deniable payment. It's not unusual for a WeChat user to deny another WeChat user's Red Packt ("I don't take bribes, sir!"). If it is with Bitcoin, the beneficiary certainly does not want to pay the transaction fee again just to nullify the previous payment to him. In a more illustrative example, I like to give away free Bitcoins after my lectures, but many of the students won't redeem their share because money isn't the only motivation for their studies. I admit that money is my motivation after all and I wish to reclaim the money that was not redeemed by students. (I stopped this practise when giving away Bitcoin costs more than the amount given.) Finally, there is multi-sig. I'll cover that in answering the 2nd section of your email. > 2. They would like to at least have the option to use some sort of 2 step > confirmation system when dealing ith people they do not know. For example, > after sending the Bitcoin to a seller they would like to be able to do a > final approval of the tm transaction. If the 2 people involved in the > transaction approve of it within X hours, the coin returns to the original > person. This system would basically act as an escrow. There is the case of escrow with an arbitrator and escrow without an arbitrator. We know that the beneficiary can always send the money back by looking up the input address. Given that he alone has this power, whether or not the other person agrees, to reimburse, it is a moot point to require two people to co-sign anything. Therefore, the case without arbitrageur is usually depended on time or revealing an x to a known hash. This can go complicated so I'll turn around and talk about the case with arbitrageur. The case with an arbitrator was explained by Rhavar. It can be elaborately built in a sheltered model, where a compromised arbitrator can only revert transactions, not to steal. You can build fine-tuned features with Rhavar's model, like setting a 90-day grace period where the beneficiary cannot claim the money, in order to leave ample time for the arbitrator to revert the transaction should he need to do so. As Rhavar pointed out, it's too costly to be practical for daily transactions. Back in 2012 when I learned about multi-sig, I hopped multi-sig grew popular before the blockchain gets full so that people have the opportunity to witness the power of Bitcoin. It unfortunately didn't happen. All of the methods I mentioned does not require any change to the Bitcoin network or Bitcoin Blockchain. The wallet is the weakest link in this chain. A wallet developer can go ahead and implement all these without negotiating with Bitcoin developers. P.S. I remark that I consistently use the word beneficiary because the other choices like "receiver" or "recipient" are often meant for the receiving of messages (e.g. in a private channel), who doesn't have to be the beneficiary (e.g. an arbitrator receives a lot of messages). I check mail lists weekly so, sorry for the late reply. --8323329-1635907999-1517275403=:27227--