Project development - BANK RUN!

[k99]

This is the open project development thread for the BANK RUN! project and it is not intended for discussion or questions regarding the project. Please use the existing dedicated thread for that (https://bitcointalk.org/index.php?topic=462236.0).

Anybody who wants to participate to the project (development, concept, legal advice, design, funding,…) is welcome to join.
It is intended as an open and transparent channel, but will be protected against misuse (We will delete spam, trolls, inapplicable posts,…).

PLEASE RESPECT THESE RULES!

[1715086046]

1715086046

[1715086046]

1715086046

[1715086046]

1715086046

[1715086046]

1715086046

[k99]

Reserved.

[k99]

I would like to present a bit of my background and the area where I think I can contribute to the project.

I was >10 years mostly in GUI/Web-app development involved (Flex, Flash) and did a bit of Java development.
Last half year I was working on iOS projects, but due the unbearable politics of Apple (BTC apps ban) I stopped with that.
I am following BTC since 2011 and I am dedicated fulltime to BTC stuff since 2 month.

I can contribute to the project in these areas:
- Concept (paper)
- GUI development (depends on the chosen technology)
- Design (I am not a professional designer, but have some experience in that field)
- Software architecture (was an important part in my last jobs)
- Organization/Project management/Team building (once had a role as tech-lead)
- Community building
- Testing
- ....?

[k99]

My next steps:

From the feedback in the forum/reddit it seems that a few parts are difficult to understand.
I will expand those parts, describe them better, as well as adding more examples.
There are also 2 new ideas to add as well as investigation regarding reversibility of Bank transfers.

TODO list:
- Lay out/test idea for legal contracts
- Lay out/test idea for protection against system attacker
- Describe the attack scenarios better
- Price swings
- Investigate on reversibility of Bank transfers
- FAQ

[dansmith]

This is how I see BANKRUN!'s Bitmessage communication workflow between buyer and seller in the case
when the Seller places an offer to sell.


------------------------------BEGIN BITMESSAGE COMMUNICATION----------------------
Seller:
A. Unique id (uid) of the offer. The buyer must use this uid when responding.
B. Communication pubkey. The buyer will encrypt all of his communication with this key.
C. The offer itself (price, minimal sale amount, total BTC being sold, time when offer ends etc.)

Buyer:
A. uid.
B. The rest of the message is encrypted with the Seller's communication pubkey:
   B.1 communication pubkey. The seller will encrypt his next message with this key.
   B.2 Buyer's bitcoin pubkey which the seller will use later to create a multisig address. (In case if the seller accepts this Buyer's offer).
   B.3 Amount of BTC that the Buyer wants to purchase.
   B.4 Reputation related information.
      e.g. A statement signed by a mutually trusted 3rd party ascertaining that the Buyer is the legitimate owner of the bank account.

Seller: (if he chooses to accept the Buyer's offer)
A. uid.
B. The rest is encrypted with the Buyer's communication pubkey:
   B.1 "Offer accepted".
   B.2 Seller's bitcoin pubkey which the buyer must use to create a multisig address and fund it with the collateral.

------------------------------END BITMESSAGE COMMUNICATION----------------------

Further actions:
The Seller waits for the Buyer to fund the multisig address.
Upon which the Buyer waits for the Seller to fund the multisig with the BTC-to-be-sold + the collateral
Upon which the Buyer starts the bank transfer.


P.S. Optionally all those BM messages can be signed by each party with a key tied to their identity. This way in cases when parties use a third-party escrow, the signed messages will serve as the contract.

[mcduder1]

I am a web developer and desktop app developer. I have done desktop apps for 3 years and web development for 2-3 years. I know HTML, CSS, JS, Java, C++, Ruby on Rails, node.js, PHP, and SQL.

What I can help with: the website, the desktop app, organizing, and getting the work out.

[waxwing]

This is how I see BANKRUN!'s Bitmessage communication workflow between buyer and seller in the case
when the Seller places an offer to sell.


------------------------------BEGIN BITMESSAGE COMMUNICATION----------------------
Seller:
A. Unique id (uid) of the offer. The buyer must use this uid when responding.
B. Communication pubkey. The buyer will encrypt all of his communication with this key.
C. The offer itself (price, minimal sale amount, total BTC being sold, time when offer ends etc.)

Buyer:
A. uid.
B. The rest of the message is encrypted with the Seller's communication pubkey:
   B.1 communication pubkey. The seller will encrypt his next message with this key.
   B.2 Buyer's bitcoin pubkey which the seller will use later to create a multisig address. (In case if the seller accepts this Buyer's offer).
   B.3 Amount of BTC that the Buyer wants to purchase.
   B.4 Reputation related information.
      e.g. A statement signed by a mutually trusted 3rd party ascertaining that the Buyer is the legitimate owner of the bank account.

Seller: (if he chooses to accept the Buyer's offer)
A. uid.
B. The rest is encrypted with the Buyer's communication pubkey:
   B.1 "Offer accepted".
   B.2 Seller's bitcoin pubkey which the buyer must use to create a multisig address and fund it with the collateral.

------------------------------END BITMESSAGE COMMUNICATION----------------------

Further actions:
The Seller waits for the Buyer to fund the multisig address.
Upon which the Buyer waits for the Seller to fund the multisig with the BTC-to-be-sold + the collateral
Upon which the Buyer starts the bank transfer.


P.S. Optionally all those BM messages can be signed by each party with a key tied to their identity. This way in cases when parties use a third-party escrow, the signed messages will serve as the contract.

I haven't delved into it in detail (not that it's so hard to understand) but - would it be possible to somehow use a single pubkey (bitcoin pubkey) for everything? No doubt bitmessage keypairs are different from bitcoin ones, but I'm curious as this could help to simplify the architecture. Maybe a single seed/privkey can be used to create a BM compatible and a bitcoin compatible key?

[k99]

...
I haven't delved into it in detail (not that it's so hard to understand) but - would it be possible to somehow use a single pubkey (bitcoin pubkey) for everything? No doubt bitmessage keypairs are different from bitcoin ones, but I'm curious as this could help to simplify the architecture. Maybe a single seed/privkey can be used to create a BM compatible and a bitcoin compatible key?

Yes that was my approach as well. In the paper/RCP example I used only one address for Alice/Bob for sending and receiving the BTC as well as for the messaging (to keep it simple). But I assume the real implementation will need to deal with more complex setup (input merge, change, diff. addresses and probably different a Bitmessage address, if BM will be used).

[k99]

I know that this topic is a bit out of date, but just in case you are still interested in a P2P Fiat-BTC exchange, I wanted to post an update of our project and announcement for our crowd funding campaign which will end in a few days (on February 9th).

Bitsquare released an alpha version in December and it can be tested at our regular testing sessions with other traders (testnet).
Today 17:00 CET we have such a session. Feel free to join us on our IRC channel #bitsquare-trading on Freenode.
Further information can be found here:
https://github.com/bitsquare/bitsquare/wiki/Bitsquare-WAN-Parties

Regarding the crowd funding campaign:
We are using Lighthouse as decentralized crowd funding solution to iteratively fund the development of every milestone, leading to a fully functional version 1.0.
The funding goal is 120 BTC for the next milestone and the campaign ends in a few days on February 9th. 
Please visit our web page for more details:
https://bitsquare.io/crowdfunding

If you like to support that project please help us to spread the word.

Best regards,
Manfred