From: Weiwu Zhang <a@colourful•land>
To: rmcc4444 <rmcc4444@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] 2 step confirmation system
Date: Tue, 30 Jan 2018 09:23:13 +0800 (+08) [thread overview]
Message-ID: <alpine.DEB.2.20.1801300801330.27227@notCBApc> (raw)
[-- Attachment #1: Type: text/plain, Size: 4772 bytes --]
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.
next reply other threads:[~2018-01-30 1:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-30 1:23 Weiwu Zhang [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-01-24 0:42 rmcc4444
2018-01-24 2:05 ` Rhavar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1801300801330.27227@notCBApc \
--to=a@colourful$(echo .)land \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rmcc4444@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox