About current condition of small settlement

Technical Discussion
#1

Currently in Japan, the settlement stores by NEM have increased considerably.
Look at that situation and write the problems I felt.

・There are stores that considers payment to be completed with Unconfirm.

  • Payment is made from the multi-sig account, in fact it is not added signature and payment is not made.
  • If you wait until Confirmed, payment will take time.

So, recently, some stores have banned payment from multi-sig accounts.

On these issues, in Japan, software has recently been created to let you know whether you have been paid from a multi-sig account.

So far in Japan, a lot of people are understanding.

What is more problematic is the problem of the blockchain structure.
Even if you do settlement by waiting for confirm, it is possibly a fork chain and it is not secure.
In addition, waiting 10confirm like an exchange is a fatal problem in small amount settlement.

I think that the best thing in the current situation would be to change the number of confirms according to payment amount.
Then, prepare two settlement terminals with the same address, each referring to a different super node and reduce the risk.

Is there anything else you can do fundamentally to improve the convenience of small payment?
In the future, I want you to have something different.

Thank you.

8 Likes
#2

In non-centralized, there is always this problem.
The problem really stands out really now.
It is a problem I want to solve as soon as possible.
Do you still need an off-chain solution such as lightning network?

Thank you.

1 Like
#3

With current options I would implement “monitor more NIS” approach. 2 of 3 or n of m in general. Analogy to error-detection and error-correction codes as in data storage area.

1 Like
#4

It would be easier if there was a way to judge if the chain was in a Fork situation. Currently, there is no choice but to look at more than one NIS.
I think that I am grateful if the API can provide it.

Was the SN 7 blocks? Block delay is allowed. I think that there is a problem only by referring to a normal SN.
It may be necessary to have a mechanism that can refer to the most advanced SN.

Thank you very much.

1 Like
#5

https://bitcoin.org/en/glossary/payment-protocol

This, but for NEM.

Send the transaction directly to the store’s NIS instead of to a different one.

1 Like
#6

If you install BIP70 in NEM, it seems to be possible.
If you tell the payment side which store the NIS refers to, there is concern that the attack method may exist.

#7

Hello, Rin!
I’m sorry for talking in english though I am Japanese.
Thank you for your problem presentation.

I thought up a idea. This idea doesn’t consider
technical problem and practicality, but only considers economics incentive.

In short, I propose a deposit system.
If a buyer wants to pay with xem, a seller impose a deposit transaction. Then, the buyer send a normal transaction.
In case the buyer do double-spending, the seller don’t return the deposit xem.
In case the buyer do double-spending, the seller return the deposit xem.
The probability of succeeding two double-spendings is low.

Cases of profits for the buyer are these:

Don’t DS…0(criteria)
DS deposit transaction only…0①
DS payment transaction only…+(subtotal)-(deposit)
DS both transactions… +(subtotal)②

where DS…double-spend

①Because if the buyer behave himself, the deposit will be returned.
②But the probability of this phenomenon is very low. Therefore, we can think that the expected profit is low.
Please regard the transaction fee as nothing here.

Thanks
Yu Kimura (twitter: @ltd_exp_kyu)

1 Like
#8

Could even just write a proxy for NIS that does data validation/etc before sending anything to the NIS itself.

#9

You could add a flag to nis to represent multisig wallet. Let wallets test the flag and show if multisig or not. Merchants can choose to accept the flag or not. Customer can keep their long term funds in multisig and transfer to normal account to be used for spending. Put the risk on sender for their internal transfers and the choice to merchants to accept or not.