[bitcoin-dev] 2 step confirmation system

[bitcoin-dev] 2 step confirmation system

[rmcc4444]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

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.

and/or

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.

This 2 step system could work with both of these.

I apologize if this is the incorrect place to post this. I did not know
where else to share these thoughts.

Thanks for your time.



-- 


** This message was likely sent using voice to text. Please ignore any
typos.**

[-- Attachment #2: Type: text/html, Size: 1325 bytes --]

Re: [bitcoin-dev] 2 step confirmation system

[Rhavar]

[-- Attachment #1: Type: text/plain, Size: 2293 bytes --]

1. Bitcoin addresses contain a "checksum", which means it's pretty much impossible to fat finger any address. (Note: most altcoins don't seem to do this, so fat-fingering is very much a risk). If you can send to an address, you can be sure there is no mistake.

However, there is a real risk of malware. I see on a daily basis people who send to the *wrong* address, because for example they have malware on their computer which replaces a the intended address with one controlled by the malware author. So verifying you are sending to the correct address is very much still a concern, but there's no risk you type a 2 instead of 3 and send to the wrong place.

2.  Google "bitcoin multisig" and "bitcoin escrow". In the core bitcoin protocol there's a lot of support that enables stuff like that -- but nothing that is really commonly used. I've done some very large deals with bitcoin, with the use of "2 of 3 multisig" (basically 2 of: me, counter-party, arbitrator)  need to sign off on it. However it's a big pain in the ass, with poor tooling and expensive transactions. Unless you're dealing with 100+ bitcoin, it's a lot easier for everyone to just use a trusted (single party) escrow.

-Ryan

-------- Original Message --------
On January 23, 2018 7:42 PM, rmcc4444 via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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.
>
> and/or
>
> 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.
>
> This 2 step system could work with both of these.
>
> I apologize if this is the incorrect place to post this. I did not know where else to share these thoughts.
>
> Thanks for your time.
>
> --
>
> ** This message was likely sent using voice to text. Please ignore any typos.**

[-- Attachment #2: Type: text/html, Size: 3319 bytes --]

Re: [bitcoin-dev] 2 step confirmation system

[Weiwu Zhang]

[-- 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.