Bitcoin Forum
November 09, 2024, 12:18:57 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: A decentralised peer-to-party fiat-bitcoin Nostr-like protocol.  (Read 217 times)
DasDouble (OP)
Newbie
*
Offline Offline

Activity: 5
Merit: 1


View Profile
July 13, 2023, 04:51:27 PM
 #1

Came up with this idea today while sleeping. Let me know what you think Smiley

https://github.com/DasDouble/Bitcoin-layer3

-Eli
d5000
Legendary
*
Offline Offline

Activity: 4088
Merit: 7534


Decentralization Maximalist


View Profile
August 01, 2023, 09:14:01 PM
 #2

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:

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.

█▀▀▀











█▄▄▄
▀▀▀▀▀▀▀▀▀▀▀
e
▄▄▄▄▄▄▄▄▄▄▄
█████████████
████████████▄███
██▐███████▄█████▀
█████████▄████▀
███▐████▄███▀
████▐██████▀
█████▀█████
███████████▄
████████████▄
██▄█████▀█████▄
▄█████████▀█████▀
███████████▀██▀
████▀█████████
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
c.h.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀█











▄▄▄█
▄██████▄▄▄
█████████████▄▄
███████████████
███████████████
███████████████
███████████████
███░░█████████
███▌▐█████████
█████████████
███████████▀
██████████▀
████████▀
▀██▀▀
internetional
Legendary
*
Offline Offline

Activity: 1638
Merit: 2080



View Profile WWW
August 02, 2023, 05:58:57 PM
 #3

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.
WillyAp
Member
**
Offline Offline

Activity: 868
Merit: 26

Looking for guilt best look first into a mirror


View Profile WWW
August 05, 2023, 02:47:29 PM
Last edit: August 26, 2023, 11:31:00 AM by WillyAp
 #4

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.


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.

Marketing in EN und DEES
DoubleDas
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
August 12, 2023, 10:22:41 PM
 #5

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:

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.

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
DasDouble (OP)
Newbie
*
Offline Offline

Activity: 5
Merit: 1


View Profile
January 08, 2024, 12:20:38 AM
 #6

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.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!