BotC Overview issueshttps://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues2024-03-04T11:40:45Zhttps://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/108BotC Tech role description and proposed transition to new admin2024-03-04T11:40:45ZRamaxxBotC Tech role description and proposed transition to new admin*We are looking at someone or a team to take the tech head role. This process must be completed by the last day of March 2021 where current role will fully drop responsibilities and stop getting paid*
BotC Tech could mostly decomposed i...*We are looking at someone or a team to take the tech head role. This process must be completed by the last day of March 2021 where current role will fully drop responsibilities and stop getting paid*
BotC Tech could mostly decomposed in the 3 following areas:
- Software development/maintenance
- Sysadmin
- Crypto nodes management
Only after having experienced the tasks, learnt and documented as much as possible, I realized about the level of complexity in BotC project.
It's normally hard to find a person to cover both profiles reasonably, so it should be worth considering 2 roles as a team to cover the requirements. It's also advised against having only one fully responsible person. Two are the minimum recommended for better resilience.
### Profile Requirements
Given the nature of any Fintech project, where an admin will have a high level of responsibility for keeping people's funds safe, it's important to find someone, or a team who can be fully trusted, and of course trust each other in order to share the responsibility and have more eyes on the software and infrastructure.
Ideally, you will want people who already have a reputation, assuming they will not want to burn it.
A candidate will ideally have the following experience, or ability to learn and catch up quickly with:
#### Software
BotC codebase is built on top of a deprecated verson of Symfony and is composed of one Symfony app for the frontend and one for the backend.
- 5 years of solid PHP knowledge
- 3 years of experience with Symfony or any similar web development framework
- Strong experience on troubleshooting, debugging and reverse engineering
- Experience with cryptos will help
#### Sysadmin
BotC infrastructure is mainly based on Libvirt virtualization plus some extra VPS servers on various providers.
- 5 years experience as sysadmin on production sites/software
- Solid experience with Debian/Ubuntu servers
- Virtualization
- Networking
- Security
- Bash and Python scripting
- OS release upgrades
- Backups maintenance, restore
- RAID 1 management
#### Crypto nodes management
Currently supported crypto nodes are Ethereum, Bitcoin and Faircoin.
- Experience as node operator will help: check balances, move funds between accounts, etc
- Setup and maintain remotely accessible RPC calls (for wallet API operation)
- Experience upgrading or migrating nodes software or servers if needed
### Best practices
Collaborating with Holytransaction/Flypme, I've learnt some essential practices to keep everything as secure as possible:
* Sysadmin full paranoia mode on
* All laptops/workstations holding sensitive access, code or data must have full disk encryption
* When leaving secure locations, laptops must be turned off and **not suspended** to avoid certain physical attacks which could help gain critical infrastructure access.
* No third-party providers for sensitive information (ie, run your own Gitlab)
* One ssh key per server, passphrase protected
* Never leave a terminal unlocked+unattended if at unsafe locations (ie set autolock to a low value like 1min and force lock if you leave the keyboard)
### Additional general recommendations
* Implement role isolation as much as possible: one dev, one sysadmin, one or many crypto admins, one per node. This will be useful only if a wrapper is included around each node, to allow only mandatory RPC calls for the wallet to operate, including logging and maybe notifications)
* No access for developers to production infrastructre (as part of role isolation)
* Keep encrypted backups off-site at controlled and undisclosed locations.
## Proposed transition procedure
- Prepare a public call with the requirements.
- It is advised that candidates are validated at least by two reputable people from the Assembly.
- Create a transition telegram group where people from imMunitech will be invited to have the final say on the candidate or team.
- Candidate or team gets access to development infrastructure to learn and practice.
- Once candidates are approved and ready to take over, hand over credentials (see checklist below)
#### Handing-over credentials checklist:
- [ ] One of the remaining root admins will remove credentials from all servers for leaving role.
- [ ] One of the remaining root admins will add credentials for the new roles.
- [ ] The new role will take care of re-creating the crypto nodes' private keys and place old ones on autoforwarder node, to forward funds arriving at any of the old (compromised) addresses.
- [ ] The new role will take care of changing all passwords to critical infrastructure or sensitive data must be changed.
**From the time credentials are removed from leaving admin and private keys are replaced, leaving admin automatically drops responsibility for any issues happening, including unauthorized operations or loss of funds. Please, make sure to check the items on the list above as they are completed, to close down a potential attack vector.**https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/107Continuity of Ethereum operations2024-03-04T11:40:46ZRamaxxContinuity of Ethereum operationsEthereum operations require manually recharging the payout address (incorrectly called "hot-wallet") each time a user needs to cashout.
As announced on #106, I'm dropping responsibility of manually moving funds to payout address.
There...Ethereum operations require manually recharging the payout address (incorrectly called "hot-wallet") each time a user needs to cashout.
As announced on #106, I'm dropping responsibility of manually moving funds to payout address.
There is a proposal of having @santi take care of these recharges.
This will break the proposed transition steps which would guarantee a smooth hand-over to the new role as described on the wiki page: [BotC-Tech-role-description](BotC-Tech-role-description)
It must be decided by the assembly, or whoever wants to make him/herself responsible for taking this step.
From my side, I can guarantee I won't touch the cryptoservers or their wallets anymore unless there is any technical issue on the server side which could produce downtime, which will be properly notified in advance to the relevant teams (probably core and imMunitech). That is, I will only take care of the servers and daemons to remain running until my credentials get finally removed. Of course backups are part of the sysadmin responsibility which I will take care of.
The assembly can only trust my word that I don't keep a copy of any private keys anywere else other than the cryptonodes and the backup server, infrastructure belonging to BotC, under administrative access by @enric. After the private keys get regenerated (as explained on #108), it will be 100% guaranteed that any unauthorized movement of funds couldn't be linked to the leaving admin.
In other case, from the moment it's decided that someone else (in this case @santi) will become ETH node operator, I will automatically become exempt of any responsibility related to any sort of issues with funds (blocked, lost or stolen) from **any** of the cryptonodes.https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/105Extract and visualize data from Wallet database for analysis2024-03-04T11:40:46ZRamaxxExtract and visualize data from Wallet database for analysisWe are looking at extracting different data from our wallet database to be analysed in order to get a better picture of the current and historical operation of BotC.
Some data visualzation would help to understand better what's going on...We are looking at extracting different data from our wallet database to be analysed in order to get a better picture of the current and historical operation of BotC.
Some data visualzation would help to understand better what's going on.
For that end, we've reached out a friend who specializes on dataviz topic since years and is providing some guidance.
It would help to know which kind of information could be useful, to craft the corresponding database queries and pull that info in order to feed the visualization tools and produce some final outputs to be shared.
It's important to produce meaningful outputs while respecting members privacy.
Anyone who believes there is some specific information to be pulled, please share your thoughts so we evaluate them together and if approved, include their data representation.Release 2020https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/104Fix failed ETH cashouts2024-03-04T11:40:47ZRamaxxFix failed ETH cashoutsSome months back we've received a report from Xavi Zambrana regarding failed outgoing ETH txs:
![image](/uploads/8ff16952784e50d27a8a639ef8e442f8/image.png)
Coincidentally, that day, September 27th 2020, there was a peak of 0.30265 eth...Some months back we've received a report from Xavi Zambrana regarding failed outgoing ETH txs:
![image](/uploads/8ff16952784e50d27a8a639ef8e442f8/image.png)
Coincidentally, that day, September 27th 2020, there was a peak of 0.30265 ether on the fee price:
![image](/uploads/dfbe92b25a396ce382826afa818fca11/image.png)
As a first step to debug this issue, we decided with the tech team to switch from the old version of parity we were running as our node, to the latest stable version of `geth`, which after a careful process we've managed to complete recently. See #94
We've been experimenting the fee cap (geth --rpc.txfeecap <ethers>) to limit the fee our node would pay to the network for tx's and noticed it won't help as in case the network requires a higher fee exceeding the cap, the tx would fail and just not happen.
This was an intent to overcome the situations when fee costs peaks (like what happened when @xavislow reported the issue), but it seems we would be introducing a new issue trying and not actually succeeding to solve another one, which is avoid failing txs from our wallet.
It seems we should live with it, as fees prices fluctuate all the time.
A potential solution is to always have some spare eth on the node's payout address (the default geth txfeecap is 1 ETH actually)
Another part of the fees story to understand for us is how BotC handles the fees, and review the whole eth cashflow, as there is a middle step involved when a member wants to cashout, where we have to manually move funds from their account to the main (payout) address which is of course undesirable. But we'll create a separate issue for that.
An idea could be to create a cronjob to collect the funds from the different addresses and store them on the payout address, capped to a max amount to keep funds safer, as they cannot leave the node if not on the main address.
Let's get some feedback and take a decision.Release 2020RamaxxRamaxxhttps://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/103Add the account token to more places.2024-03-04T11:40:47ZGrows SporosAdd the account token to more places.It would be practical to have the account token handy in more screens than the unique https://wallet.bankofthecommons.coop/company/account?tab=profile.
A good place would be in both or either cash-in and/or wallet2wallet screens.
(Sugg...It would be practical to have the account token handy in more screens than the unique https://wallet.bankofthecommons.coop/company/account?tab=profile.
A good place would be in both or either cash-in and/or wallet2wallet screens.
(Suggested by Rama :))https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/102SEPA cash-out process optimisations2024-03-04T11:40:48ZEmil DanielSEPA cash-out process optimisations1.) Cash-out-Email: add "Sent-Flag"-Set-Link
Admin get the cashout requests in the email
An option could be a link on the same email, which would flag as sent,
if you click on it
Admin: this would help yes.
2) Bulk button:
Also it wo...1.) Cash-out-Email: add "Sent-Flag"-Set-Link
Admin get the cashout requests in the email
An option could be a link on the same email, which would flag as sent,
if you click on it
Admin: this would help yes.
2) Bulk button:
Also it would be good to be able to "success" at once all the older oneshttps://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/101Dev Logs - Rama2024-03-04T11:40:48ZRamaxxDev Logs - RamaWe discussed in the BotC internal dev group that it could be helpful that every developer create an own issue and write some logs of his/her work. It makes the monthly reporting easier and everybody can follow the developers work.
In th...We discussed in the BotC internal dev group that it could be helpful that every developer create an own issue and write some logs of his/her work. It makes the monthly reporting easier and everybody can follow the developers work.
In this issue I will comment all my work regularly.RamaxxRamaxxhttps://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/100Exchange: No funds enought2024-03-04T11:40:48ZZambrana XavierExchange: No funds enought![photo_2020-10-18_15-10-11](/uploads/268d920a64da15c3898d287922022219/photo_2020-10-18_15-10-11.jpg)
When using the exchange feature of the wallet, it looks like some times you might get this bug. That is, you get a red message saying ...![photo_2020-10-18_15-10-11](/uploads/268d920a64da15c3898d287922022219/photo_2020-10-18_15-10-11.jpg)
When using the exchange feature of the wallet, it looks like some times you might get this bug. That is, you get a red message saying 'No funds enought'. Now, the message is misspelled (it should be 'not enough funds', or 'non-sufficient funds'). But the message is also false, as you might be able to go on with the exchange. In particular, I was able to do the 4eur exchange that it is reported in this attached image. I had enough euros, and Enric verified that there were enough ETH in the exchange wallet. Anyway, I completely ignored the message, and it was all good. But that message should not pop up like that :)https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/99Multicurrency Wallet - tx with status "sending" not shown and not available i...2024-03-04T11:40:49ZGampe SebastianMulticurrency Wallet - tx with status "sending" not shown and not available in filter optionsTx with status "sending" will not shown in the /company/wallet transactions history list but shown in the Wallet overview / dashboard.
Solution:
- add the status "sending" to filter options!?Tx with status "sending" will not shown in the /company/wallet transactions history list but shown in the Wallet overview / dashboard.
Solution:
- add the status "sending" to filter options!?Release 2020Gampe SebastianGampe Sebastianhttps://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/98Development goals and strategy2024-03-04T11:40:49ZEmil DanielDevelopment goals and strategyThere is a lack of mid and long-term goals,
which development should meet.
those can be articulated from a vision,
which than needs to be architectured
and broken down into milestones.
this shall be started here.There is a lack of mid and long-term goals,
which development should meet.
those can be articulated from a vision,
which than needs to be architectured
and broken down into milestones.
this shall be started here.https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/96Dev Logs - Sebastian2024-03-04T11:40:50ZGampe SebastianDev Logs - SebastianWe discussed in the BotC internal dev group that it could be helpful that every developer create an own issue and write some logs of his/her work. It makes the monthly reporting easier and everybody can follow the developers work.
In t...We discussed in the BotC internal dev group that it could be helpful that every developer create an own issue and write some logs of his/her work. It makes the monthly reporting easier and everybody can follow the developers work.
In this issue I will comment all my work regulary.Gampe SebastianGampe Sebastianhttps://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/95Report 2020/092024-03-04T11:40:50ZEmil DanielReport 2020/09BOTC - Tech report 2020/09
===============================================
Link to this as online version plus details: https://board.net/p/botc_tech_report_assembly_2020_09
Link to this as online issue: https://git.fairkom.net/fairc...BOTC - Tech report 2020/09
===============================================
Link to this as online version plus details: https://board.net/p/botc_tech_report_assembly_2020_09
Link to this as online issue: https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/95
BOTC Overview // Issue-List: https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues
________________________________________________
SUMMARY:
1) New solution for a pending issue we couldnt solve,
"Design screens for new wallet frontend". We are lacking
of human resources and skills to complete this task.
2) opportunity for a perfectly fitting "hire: frontend developer",
with the right skills and fair budget expectancies,
who would like to work with us within a reasonable budget.
There is a high probability of success in this cooperation.
3) Discussion about "onboarding" of new hired/voluntary helpers/devs.
Online bank robbery is a thing, and so security is too.
There is not yet a trust mechanism, but consideration
to compartmentalize critical code.
4) A "testing team" is needed. For new testing releases,
helping with bug reports, creating documentation,
there would be place for voluntary help. Good entrance point,
for learning or improving development skills.
5) Reporting: improving some methodology and habbits,
from developers platform (technical discussions),
to publicly interested audience (BotC Tech) - maybe more frequently,
to general audience (BotC assembly).
6) Technical Updates:
- bug-fixing in ethereum and fairpay, sysadmins routine
- removing code and wallet_v2 develoment
- further containerization for development (wallet frontend v1 done!)
________________________________________________
DETAILS:
---------------------------------------
1) Existing issue: "Design screens for new wallet frontend"
Link: https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/88
While raising the frontend technology now on modern level,
the graphical screen designs and UX concept is lacking.
There has been no solution found.
---------------------------------------
2) New frontend freelancer
[x] posting to BotC tech
Draft: proposal for the assembly regarding the web-wallet v2 development.
please take a look, make edits, add your comments, suggestions, etc...
so that we could
https://git.fairkom.net/botc_sources/wallet-frontend/-/issues/9
[ ] present it to the next assembly
[ ] agreement for onboarding of Marcelo
Next step:
[ ] service agreement with the developer, and
[ ] a signed NDA, so that he has the necessary access needed to do his work.
[ ] there is a model we used in the past which could probably be re-used. (ask Enric for it)
-----------------
3) Security considerations on Onboarding
- restricting access to internal dev team and repositories
- how to integrate new devs without risking revealing source code of parts of the highly critical infrastructure?
- internal dev group for sensitive communication:
- keep this group strictly and highly technical.
- to accept people in this group only after proven as a need and some level of trust gets built through interaction
- using gitlab for communication interface with developers (frontend/backend)
- splitting critical infrastructure (server and api code) from less critical developement (frontend/etc)
related points from last months:
- from previous security considerations: concep like key holders, for accessing backups/server's data.
----------------------------
4) Testing team
New devs could for instance start a testing team together, for example with Maro who is working professionally,
and they could probably start with the new wallet frontend.
==> both new devs onboarding together
==> testing team!!!
----------------------------
5) Reporting procedure
- developers report over the month progress and issues
via Gitlab's issue list: https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues
- role "reporter"
-- 1) compiles relevant issues (in a issue or/and pad )
-- 2) summarize and reports to BotC tech (in short form with link to details)
--- maybe two weekly, if a more frequent rhytmn is welcomed
-- 3) sends report to BotC general assembly in a short form
-----------------------------------------------
6) Technical Update / Progress report:
* investigate ethereum cashout issues
* Upgrade Ethereum node: https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/94
* BotC deployment: ( legacy ) wallet frontend done.
* wallet backend and orchestration of frontend and backend is still in work.
(Should be hopefully done in October)
* fix tier permissions for certain accounts
* debugging the Fairpay incoming tx problems
* coordinate the new frontend design implementation with external collaborator (Marcelo) (already reported in point 2)
* routine sysadmin tasks (check logs, backups, update servers)
* also *remove* some code, because there are a bunch of third-party services not needed anymorehttps://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/94Upgrade Ethereum node2024-03-04T11:40:51ZRamaxxUpgrade Ethereum nodeBotC core tech team discovered a general issue which may affect some outgoing ETH transactions.
It's still not clear the reason why some cashouts fail.
After some investigation, we've realised the version of Ethereum node we are runnin...BotC core tech team discovered a general issue which may affect some outgoing ETH transactions.
It's still not clear the reason why some cashouts fail.
After some investigation, we've realised the version of Ethereum node we are running is quite old, so it's necessary to upgrade it in order to do debugging on a current latest stable version.
Upgrading Ethereum node may require changes on the wallet code, so we should evaulate if the process could be tracked publicly or on our internal tools.
**Update:** we've decided to migrate to `Geth` since it's a very mature and well developed software, and after our tests we've discovered it's a drop-in replacement for `Parity` and no changes to our code are needed.
Migration checklist:
- [x] Ensure that API code does not use Parity-specific namespace methods
- [x] Ensure that Wallet code does not use Parity-specific namespace methods
- [x] Ensure that API code does not use Parity-specific response fields
- [x] Ensure that Wallet code does not use Parity-specific response fields
- [x] Ensure that API code does not rely on Parity-specific API responses for bad requests
- [x] Ensure that Wallet code does not rely on Parity-specific API responses for bad requests
- [x] Ensure that API code does not rely on Parity-specific error codes
- [x] Ensure that Wallet code does not rely on Parity-specific error codes
- [x] Set up Geth infrastructure
- [x] Set up Geth software to run on a different port, in parallel with the Parity node
- [x] Notify users about maintenance window
- [x] On maintenance window, point the BotC API to the Geth port (change API config) and verify
- [x] On maintenance window, import private keys from Parity
- [x] On successful traffic, switch over all traffic to Geth and monitor for a period (weeks)
- [x] After successful switch, shut down Parity nodeRelease 2020Gampe SebastianGampe Sebastian2020-12-22https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/93Dockerization of deployment2024-03-04T11:40:51ZEmil DanielDockerization of deploymenthaving access to deployment-repo ,
i thought right now, "good, so i can test 'somewhen myself",..
but without access to API submodules, locally this is not possible.
So I had the IDEA, to use something like that:
docker-compose.yml
```...having access to deployment-repo ,
i thought right now, "good, so i can test 'somewhen myself",..
but without access to API submodules, locally this is not possible.
So I had the IDEA, to use something like that:
docker-compose.yml
````
api-endpoint: stage.botc.org
api-port: 80
````
docker-compose.yml.local
```
api-endpoint: localhost
api-port: 8081 #example
```
i guess this switch could be made with environment variables too, but switching the docker-compose.yml file may be the easiest way...
so we could achieve:
```
a) new frontend devs can develop via docker
```
further on
```
b) full devs can hack on the complete system with api
```
didnt thought about this setup now awfully a lot, it may also be easier to have two different docker-setups, 'botc.docker.backend' and 'botc.docker.frontend', maybe merging them into 'botc.docker' for full development.
surely, this needs more thoughts, but i could see some benefits in a split (local docker for frontend-dev against API would also give hobbyist a helping hand to develop against their own BOTC wallet...).
if this sounds reasonable, i would dive into it a bit more :)Gampe SebastianGampe Sebastianhttps://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/92FairCoin tx history incomplete in botc wallet2024-03-04T11:40:52ZGampe SebastianFairCoin tx history incomplete in botc walletSome FairCoin tx history incomplete in botc wallets.
It seems happen when the faircoin wallet is down while payments will processed!?Some FairCoin tx history incomplete in botc wallets.
It seems happen when the faircoin wallet is down while payments will processed!?Gampe SebastianGampe Sebastianhttps://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/88Design screens for new wallet frontend2024-03-04T11:40:53ZRamaxxDesign screens for new wallet frontendThere is some ongoing work to complete the new wallet frontend based on React.
We should start with the design of all the screens to replace current frontend.
For this to happen, we should probably prepare a document which includes all...There is some ongoing work to complete the new wallet frontend based on React.
We should start with the design of all the screens to replace current frontend.
For this to happen, we should probably prepare a document which includes all current screens and some graphic guidelines like fonts, colors, etc.
Once that document is ready we could issue a call for people to propose estimates to do that work, along with provable experience on this task (ie show a portfolio or recent works).
Once this task is approved, I could take care of all the screenshots and details to produce such document.
I think this is high priority unless there is something really more urgent.
Waiting for feedback and confirmation in order to proceed produce the document with the requirements.Release 2020https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/87Improve ETH payout address recharge mechanism2024-03-04T11:40:54ZRamaxxImprove ETH payout address recharge mechanismCurrently, in order to cashout ETH, it's necessary to recharge the payout address, which is configured on the backend. This is per design by Chipchap.
We need to review how and why it's like this and how this can be improved either auto...Currently, in order to cashout ETH, it's necessary to recharge the payout address, which is configured on the backend. This is per design by Chipchap.
We need to review how and why it's like this and how this can be improved either automating or allowing funds admins to self-manage these recharges.
For now it's @rama doing this recharge on request by @enric, but this may introduce delay and is a bit inefficient and probably unnecessary.
It's not high priority as there seems to be an average of 1 ETH cashout per week or less, but making the process more fluid without depending on manual intervention could make the service more usable and bring more volume.Release 2020RamaxxRamaxxhttps://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/86Implement Fairchains to hold BotC members shares2024-03-04T11:40:54ZRamaxxImplement Fairchains to hold BotC members sharesWe've been discussing on a smaller BotC Tech working group about alternatives to replace the funcionalities provided by OCP to BotC.
At least @tonyford and @santi who are the most experienced with blockchain and have tried Fairchains, a...We've been discussing on a smaller BotC Tech working group about alternatives to replace the funcionalities provided by OCP to BotC.
At least @tonyford and @santi who are the most experienced with blockchain and have tried Fairchains, agree that it would be a proper option to hold the shares.
The membership would move to current BotC (Symfony) thus eliminating the requirement to register on two different sites (wallet and OCP). Essentially any user registering on the wallet and purchasing the shares to be stores on a Fairchains backend, becomes a premium member. Otherwise, they would be regular users with access restricted only to the use of Faircoin.
We would deploy a very simple Fairchains setup as BOTC coin, and would supply it with the purchased amounts on a 1 BOTC = 1 EURO basis.
This would mean we should deploy at least 2 genesis nodes or more, where the partners would ideally be BotC partners like Dyne, Dezentrale or others as well as BotC itself.
Not sure if this would mean we also need to deploy a CVN network too. To be discussed.
Another approach we've been discussing is using the current Faircoin network, but I guess all servers should be upgraded to Fairchains in order to benefit form Omnilayer in order to create BOTC coin as a coloured coin, but this might require extra work than an autonomous setup.
Please, add your comments to discuss and agree what would be the best approach.Release 2020https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/85Explain OCP functions and requirements for BotC2024-03-04T11:40:55ZGampe SebastianExplain OCP functions and requirements for BotCPost from BotC telegram group
> I intend, first, that someone who knows it well explain all the OCP functions that are currently required for BotC to work. Don't you think this would be a good start? Moreover, the current lead developer ...Post from BotC telegram group
> I intend, first, that someone who knows it well explain all the OCP functions that are currently required for BotC to work. Don't you think this would be a good start? Moreover, the current lead developer and BotC sysadmin has expressed his opinion on OCP several times recently.Release 2020https://git.fairkom.net/faircoop/BankOfTheCommons/BotC_Overview/-/issues/84Allow for a dynamic control of the btc cash out fees2024-03-04T11:40:55ZZambrana XavierAllow for a dynamic control of the btc cash out feesRight now, the btc trasnaction fee that pays to the the miners is set to 20sats/byte for all transactions. It would be cool if this could be controlled by the member who was doing the transaction. The best case scenario would be if it co...Right now, the btc trasnaction fee that pays to the the miners is set to 20sats/byte for all transactions. It would be cool if this could be controlled by the member who was doing the transaction. The best case scenario would be if it could be totally controlled, but the service would be very improved even if 3/4 options were given. For example, 20sat/byte, 14sat/byte, 7sat/byte and (1 or 2)sat/byte (the numbers are just an example).
PS: I think that the cash out fee could be adapted accordingly too - say if the transaction fee paid to the miners is x, then the cash out fee for a member is 10x, or 7x or whatever. But anyway, this should be discussed in an assembly. For now, I think that it would be good to just have in mind the improvement that I described. I wouldRelease 2021+