Topic: A decentralised peer-to-party fiat-bitcoin Nostr-like protocol. (Read 182 times)
Update: Im currently building such a system (working on it since ~1 year already). Stay tuned. Will post it here as soon as its finished and ready to roll out. Hopefully will be finished before April 2024.
I'm very interested in new ideas for decentralized trading, so I looked at your Github description. I've also had some (very early) ideas for a Nostr-based DEX protocol, but for a specific use case on a specific altcoin.
But already at the start I stumbled upon something I didn't like that much:
But already at the start I stumbled upon something I didn't like that much:
Quote
Every user has their Bank API and their Wallet connected to their open-source program.
I'm maybe a bit conservative regarding this, but I think with the scamming history on DEXes like Bisq in mind, a direct connection to a bank API may not be really a good idea - if hackers find any way to exploit that, they will. I think a human user should be the one to take the final decision about a transfer.Good point!
The part of the "sell request" is ok, I think that would be commonplace for all protocols based on decentralized/P2P chat/messaging networks.
It seems the basic idea for your protocol though is the division of the bought/sold amount into many small parts, so in the case of one of the participants being unresponsive, neither party loses much money - and on the Bitcoin side you use LN to be able to send microtransactions without having too much fees. In general the idea to use LN with that in mind is quite good.
But there's a problem: Many banks suspect if they see many small transactions in the accounts of their customers. Maybe instead of bank accounts, digital wallet services which are commonly used for microtransactions could be used (however, only in some countries these have an unified bank account scheme, like the CVU in Argentina).
Maybe one could combine your idea of a LN-based protocol with an existing protocol like Bisq, to have a new payment option to "onboard" new users.
Quote
B sends their bank information (suggestion: bank information = IBAN or IBAN + Name) to S
Here you should take an inspiration from Bisq: the account information on the "exchange network" should include a hash of the bank account information. So if you see a participant with an old account, then you can be sure that they operate with the same bank account for a long time. That's to avoid trading with parties using stolen bank accounts (they should never be able to operate for more than a month with the same bank account).It seems the basic idea for your protocol though is the division of the bought/sold amount into many small parts, so in the case of one of the participants being unresponsive, neither party loses much money - and on the Bitcoin side you use LN to be able to send microtransactions without having too much fees. In general the idea to use LN with that in mind is quite good.
But there's a problem: Many banks suspect if they see many small transactions in the accounts of their customers. Maybe instead of bank accounts, digital wallet services which are commonly used for microtransactions could be used (however, only in some countries these have an unified bank account scheme, like the CVU in Argentina).
Maybe one could combine your idea of a LN-based protocol with an existing protocol like Bisq, to have a new payment option to "onboard" new users.
First of all: thank you d5000, I appreciate your interest in this idea. I'm currently working on another Bitcoin project (first priority), AGI (second priority) and an engineering-book I'm writing since two years, so I hope someone else is interested in implementing this by himself. This should be very profitable and all you need is a bank account with API access (possible in EU), some Sats and trustworthy behaviour.
Regarding bank suspissions: Could be indeed a problem. Possible solution: keeping transaction volume under the banks radar (e.g. central europe: 600€ per person per year).
-Eli
User S wants to sell Bitcoin, while User D, E, and F (here summarised as “B”) want to buy Bitcoin. S sends a sell request on a Nostr-like protocol with a taker-fee for all potential buyers. B gets notified as soon as a new sell request arrives on their watching Nostr- like nodes. B sends their bank information (suggestion: bank information = IBAN or IBAN + Name) to S. S sends the amount of Bitcoin (via the Bitcoin Lightning Network) split up into P parts, equally distributed to the buyers and waits for T time. If, after T, the money from the mentioned bank information hasn’t arrived at the bank account of S, or if B hasn’t sent the agreed amount, S automatically marks their bank information on the Nostr-like protocol as delayed/red-flag, so future users won’t get scammed. Alternatively/Additionally, if preferred, the buyers' bank information can also get green-flagged on the Nostr-like protocol.
The higher P, the more buyer-participants are needed, but also the more secure in case one buyer acts in a bad way. To figure out which transaction has been sent by whom, the bank subject line can be used.
The higher P, the more buyer-participants are needed, but also the more secure in case one buyer acts in a bad way. To figure out which transaction has been sent by whom, the bank subject line can be used.
How is that any good?
All Crypto enthusiasts are not good, they are not bad neither just opportunity creates thieves or trying to do some good. How to protect against scammers is more important than connectivity. Best practice is to separate all things money is involved. I.e. not to have similar passwords on Wallets, sites where money flows is a modus operandy.
Banks log IP numbers and for users like @internetional, I'm pretty sure his accounts would get locked, let alone the suspicious attitude banks have against all things bitcoin/Crypto.
I have bank accounts in four different countries, and I’ve never heard about bank API for personal accounts. In electronic payment systems - yes. But not in banks. May be, in your country it’s a common case, but the service will definitely have geographical restrictions with such approach.
I'm very interested in new ideas for decentralized trading, so I looked at your Github description. I've also had some (very early) ideas for a Nostr-based DEX protocol, but for a specific use case on a specific altcoin.
But already at the start I stumbled upon something I didn't like that much:
The part of the "sell request" is ok, I think that would be commonplace for all protocols based on decentralized/P2P chat/messaging networks.
It seems the basic idea for your protocol though is the division of the bought/sold amount into many small parts, so in the case of one of the participants being unresponsive, neither party loses much money - and on the Bitcoin side you use LN to be able to send microtransactions without having too much fees. In general the idea to use LN with that in mind is quite good.
But there's a problem: Many banks suspect if they see many small transactions in the accounts of their customers. Maybe instead of bank accounts, digital wallet services which are commonly used for microtransactions could be used (however, only in some countries these have an unified bank account scheme, like the CVU in Argentina).
Maybe one could combine your idea of a LN-based protocol with an existing protocol like Bisq, to have a new payment option to "onboard" new users.
But already at the start I stumbled upon something I didn't like that much:
Quote
Every user has their Bank API and their Wallet connected to their open-source program.
I'm maybe a bit conservative regarding this, but I think with the scamming history on DEXes like Bisq in mind, a direct connection to a bank API may not be really a good idea - if hackers find any way to exploit that, they will. I think a human user should be the one to take the final decision about a transfer.The part of the "sell request" is ok, I think that would be commonplace for all protocols based on decentralized/P2P chat/messaging networks.
Quote
B sends their bank information (suggestion: bank information = IBAN or IBAN + Name) to S
Here you should take an inspiration from Bisq: the account information on the "exchange network" should include a hash of the bank account information. So if you see a participant with an old account, then you can be sure that they operate with the same bank account for a long time. That's to avoid trading with parties using stolen bank accounts (they should never be able to operate for more than a month with the same bank account).It seems the basic idea for your protocol though is the division of the bought/sold amount into many small parts, so in the case of one of the participants being unresponsive, neither party loses much money - and on the Bitcoin side you use LN to be able to send microtransactions without having too much fees. In general the idea to use LN with that in mind is quite good.
But there's a problem: Many banks suspect if they see many small transactions in the accounts of their customers. Maybe instead of bank accounts, digital wallet services which are commonly used for microtransactions could be used (however, only in some countries these have an unified bank account scheme, like the CVU in Argentina).
Maybe one could combine your idea of a LN-based protocol with an existing protocol like Bisq, to have a new payment option to "onboard" new users.
Came up with this idea today while sleeping. Let me know what you think 
https://github.com/DasDouble/Bitcoin-layer3
-Eli
https://github.com/DasDouble/Bitcoin-layer3
-Eli
Jump to: