Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • monero-project/ccs-proposals
  • rehrar/ccs-proposals
  • DSal/ccs-proposals
  • el00ruobuob/ccs-proposals
  • TONGZHENGSHIJIE/ccs-proposals
  • SarangNoether/ccs-proposals
  • pwrcycle/ccs-proposals
  • onosendai/ccs-proposals
  • xeagu/ccs-proposals
  • b-g-goodell/ccs-proposals
  • xmrhaelan/ccs-proposals
  • moneromooo-monero/ccs-proposals
  • AcceptThisYouCensors/ccs-proposals
  • Needmoney90/ccs-proposals
  • erciccione/ccs-proposals
  • knueffelbund/ccs-proposals
  • xiphon/ccs-proposals
  • dsc/ccs-proposals
  • Codivorous/ccs-proposals
  • serhack/ccs-proposals
  • sgp/ccs-proposals
  • Kukks/ccs-proposals
  • gingeropolous/ccs-proposals
  • hyc/ccs-proposals
  • saumyabratadutt/ccs-proposals
  • kayront/ccs-proposals
  • rellis/ccs-proposals
  • Avantpay19/ccs-proposals
  • lazaridiscom/ccs-proposals
  • omani/ccs-proposals
  • JackBlack/ccs-proposals
  • Kyoto/ccs-proposals
  • Endogen/ccs-proposals
  • sri346/ccs-proposals
  • asymptotically/ccs-proposals
  • Avis/ccs-proposals
  • Monero/ccs-proposals
  • jtgrassie/ccs-proposals
  • Fudin/ccs-proposals
  • helloworld9998/ccs-proposals
  • lalanza808/ccs-proposals
  • TheCharlatan/ccs-proposals
  • atoc/ccs-proposals
  • randybrito/ccs-proposals
  • Ministo/ccs-proposals
  • objectorange/ccs-proposals
  • adrelanos/ccs-proposals
  • mj/ccs-proposals
  • MoneroAddict/ccs-proposals
  • h4sh3d/ccs-proposals
  • paulshapiro/ccs-proposals
  • pricode/ccs-proposals
  • naijaminer/ccs-proposals
  • niyiajayi/ccs-proposals
  • cryptosourov/ccs-proposals
  • Drowxes/ccs-proposals
  • Mon_icp/ccs-proposals
  • Madbu221b/ccs-proposals
  • suyash67/ccs-proposals
  • kdavid2008/ccs-proposals
  • xmrLovera/ccs-proposals
  • lh1008/ccs-proposals
  • jatinajwani/ccs-proposals
  • normoes/ccs-proposals
  • Wobole/ccs-proposals
  • lederstrumpf/ccs-proposals
  • AlexAnarcho/ccs-proposals
  • readifugly/ccs-proposals
  • binaryFate/ccs-proposals
  • oeAdgK01/ccs-proposals
  • nio21/ccs-proposals
  • michaelizer/ccs-proposals
  • janowitz/ccs-proposals
  • fleaw/ccs-proposals
  • gusan/ccs-proposals
  • Leo27/ccs-proposals
  • tobtoht/ccs-proposals
  • anon/ccs-proposals
  • panagot12/ccs-proposals
  • kysn/ccs-proposals
  • monerotesla/ccs-proposals
  • sahil07/ccs-proposals
  • xmronadaily/ccs-proposals
  • ClaytonBHooverIII/ccs-proposals
  • txstreet/ccs-proposals
  • Aron/ccs-proposals
  • jklein/ccs-proposals
  • wtii/ccs-proposals
  • alynoe/ccs-proposals
  • selsta/ccs-proposals
  • johnfoss67/ccs-proposals
  • benevanoff/ccs-proposals
  • op/ccs-proposals
  • cirocosta/ccs-proposals
  • ragazzo/ccs-proposals
  • 888/ccs-proposals
  • elibroftw/ccs-proposals
  • amr-monero/ccs-proposals
  • behash/ccs-proposals
  • AnonDev/ccs-proposals
  • Rucknium/ccs-proposals
  • rating89us/ccs-proposals
  • AdorableTanuki/ccs-proposals
  • neat/ccs-proposals
  • plowsoff/ccs-proposals
  • xmr_sale/ccs-proposals
  • escapethe3RA/ccs-proposals
  • DouglasTuman/ccs-proposals
  • Bl5ckj5ck/ccs-proposals
  • j-berman/ccs-proposals
  • CrypticEntertainments/ccs-proposals
  • Geroser/ccs-proposals
  • ava_haidang/ccs-proposals
  • pluja/ccs-proposals
  • msvblab/ccs-proposals
  • monerokage/ccs-proposals
  • noot/ccs-proposals
  • RogueMaven/ccs-proposals
  • xmrman/ccs-proposals
  • moneronews/ccs-proposals
  • spirobel/ccs-proposals
  • winstonsthiccbooty/ccs-proposals
  • help.ukraine/help-ukraine-to-use-monero
  • dangerousfreedom/ccs-proposals
  • moneroist/ccs-proposals
  • anon_/ccs-proposals
  • agustincruz/3-d-metal-printer-project
  • savandra/ccs-proposals
  • willk/ccs-proposals
  • max.zab/ccs-proposals
  • rimuru/ccs-proposals
  • CryptoMorpheus_/ccs-proposals
  • jeffro256_/ccs-proposals
  • m0n3r0d1c3/ccs-proposals
  • leonerone/ccs-proposals
  • marjorie69/ccs-proposals
  • monero_archive/monero-archive
  • forgotsudo/ccs-proposals
  • mikigrey321/ccs-proposals
  • anhdres/ccs-proposals
  • thelefterisjp/ccs-proposals
  • lescuer971/ccs-proposals
  • MoneroBro/ccs-proposals
  • rayatina/ccs-proposals
  • HoudiniSwap/ccs-proposals
  • nightwolf361/ccs-proposals
  • z00t/ccs-proposals
  • markofdistinction_/ccs-proposals
  • busyboredom/ccs-proposals
  • Mitchellpkt/ccs-proposals
  • Fierfek/p-2-p-publisher-monerotopia-mexico-city
  • BigmenPixel/ccs-proposals
  • cmiv/ccs-proposals
  • VOSTOEMISIO/ccs-proposals
  • valldrac/ccs-proposals
  • Titus/ccs-proposals
  • C0mradeBlin/ccs-proposals
  • kayabaNerve/ccs-proposals
  • Boog9001/ccs-proposals
  • 4rkal/ccs-proposals
  • binarybaron2/ccs-proposals-bb
  • ajs/ccs-proposals
  • sacatunquetun/ccs-proposals
  • vtnerd/ccs-proposals
  • 0xFFFC0000/ccs-proposals
  • Clodagh/ccs-proposals
  • mrcyjanek/ccs-proposals
  • detheforxmr/ccs-proposals
  • r4v3r23/ccs-proposals
  • janaka303/ccs-proposals
  • eyedeekay/ccs-proposals
  • Secrecy1337/ccs-proposals
  • rohanrhu/ccs-proposals
  • baldeagle/ccs-proposals
  • fengzie_mbz/mobazha-with-monero-in-privacy-ecommerce
  • freeross/ccs-proposals
  • DiosDelRayo/ccs-proposals
  • omnedeus/ccs-proposals
  • geonic/ccs-proposals
  • untraceable/ccs-proposals
  • ki9/ccs-proposals
  • monerobullgitlab/ccs-proposals
  • sybann/ccs-proposals-bb
  • hinto/ccs-proposals
  • HardenedSteel/ccs-proposals
  • Kewbit/ccs-proposals
  • plowsofff/ccs-proposals
  • mainnet-pat/ccs-proposals
  • SimplifiedPrivacy/ccs-proposal-carrot-animated-video
  • SimplifiedPrivacy/ccs-proposal-carrot-animated-video-b
  • SNeedlewoods/ccs-proposals
  • midipoet/ccs-proposals
  • soufiane/ccs-proposals
  • geonic1/ccs-proposals
  • v1docq47/ccs-proposals
  • fullmetalScience/ccs-proposals
  • FiatDemise/xmrchat
  • dadybayo/ccs-proposals
  • rottenwheel/ccs-proposals
  • napoly/ccs-proposals
  • techpopulus/marketplace-monero-techdaddi
  • hbs/ccs-proposals
  • acx/ccs-proposals
  • wallet-verse/ccs-proposals
  • N1co1asB1ancon1/monero-contract-system
  • SyntheticBird/ccs-proposals
  • NorrinRadd/ccs-proposals
207 results
Show changes
Showing
with 1287 additions and 6 deletions
---
layout: cp
title: selsta part-time monero development (3 months) (2)
author: selsta
date: 8 Jul 2021
amount: 90
milestones:
- name: July
funds: 33% (30 XMR)
done: 31 July 2021
status: finished
- name: August
funds: 33% (30 XMR)
done: 31 August 2021
status: finished
- name: September
funds: 33% (30 XMR)
done: 30 September 2021
status: finished
payouts:
- date: 17 August 2021
amount: 30
- date: 15 September 2021
amount: 30
- date: 15 October 2021
amount: 30
---
## What
- Smaller dev work on CLI and GUI
- Some things I worked on last proposal
- Remove outdated monero unbound submodule, update it for deterministic builds (CLI)
- Set up a depends package source backup (CLI)
- Fix clang warnings (CLI)
- Add support for outputs import / export (GUI)
- Set minimum Qt version to 5.12, cleanup codebase and cmake file (GUI)
- Fix small design inconsistencies (GUI)
- Re-add password strength meter (GUI)
- Put effort where necessary
- Testing and reviewing pull requests (CLI, GUI, site)
- Monero release engineering for CLI and GUI
- Organizing what goes into a release
- Compiling CLI and GUI, packaging for distribution
- Writing release notes
- Misc work (user support, issue tracker maintanace)
## Who
selsta, I have been contributing to monero since around 2018 with over 420 merged commits. Here is a list of my previous work:
- CLI contributions: https://github.com/monero-project/monero/pulls?q=is%3Apr+author%3Aselsta
- GUI contributions: https://github.com/monero-project/monero-gui/pulls?q=is%3Apr+author%3Aselsta
- Previous CCS: https://ccs.getmonero.org/proposals/selsta-1p.html
If funded I will provide monthly updates in the CCS comment section.
## Proposal
Work for 30 hours per week over the next 3 months (from Mid July to Mid September) at a rate of 45€ / hour. At 180€ / XMR (14 day EMA) this makes 90 XMR.
---
layout: cp
title: selsta part-time monero development (3 months) (3)
author: selsta
date: 7 Oct 2021
amount: 75
milestones:
- name: October
funds: 33% (25 XMR)
done: 31 October 2021
status: finished
- name: November
funds: 33% (25 XMR)
done: 30 November 2021
status: finished
- name: December
funds: 33% (25 XMR)
done: 31 December 2021
status: unfinished
payouts:
- date: 16 November 2021
amount: 25
- date: 19 December 2021
amount: 25
- date: 16 January 2022
amount: 25
---
## What
- Focus on preparing the next network update
- Release v0.17.3.0 with P2Pool changes and `--proxy` flag
- Smaller dev work on CLI and GUI
- Put effort where necessary
- Testing and reviewing pull requests (CLI, GUI, site)
- Monero release engineering for CLI and GUI
- Organizing what goes into a release
- Compiling CLI and GUI, packaging for distribution
- Writing release notes
- Misc work (user support, issue tracker maintanace, HackerOne)
## Who
selsta, I have been contributing to monero since around 2018 with over 470 merged commits. Here is a list of my previous work:
- CLI contributions: https://github.com/monero-project/monero/pulls?q=is%3Apr+author%3Aselsta
- GUI contributions: https://github.com/monero-project/monero-gui/pulls?q=is%3Apr+author%3Aselsta
- Previous CCS: https://ccs.getmonero.org/proposals/selsta-2p.html
If funded I will provide monthly updates in the CCS comment section.
## Proposal
Work for 30 hours per week over the next 3 months (from mid-October to mid-December) at a rate of 45€ / hour. At 216€ / XMR (14 day EMA) this makes 75 XMR.
---
layout: cp
title: selsta part-time monero development (3 months) (4)
author: selsta
date: 12 Jan 2022
amount: 95
milestones:
- name: January
funds: 33% (32 XMR)
done: 31 January 2022
status: finished
- name: February
funds: 33% (32 XMR)
done: 28 February 2022
status: finished
- name: March
funds: 33% (31 XMR)
done: 31 March 2022
status: finished
payouts:
- date: 22 February 2022
amount: 32
- date: 22 March 2022
amount: 32
- date: 18 April 2022
amount: 31
---
## What
- Focus on preparing the next network update
- Put out an update with multisig fixes
- Smaller dev work on CLI and GUI
- Put effort where necessary
- Testing and reviewing pull requests (CLI, GUI, site)
- Monero release engineering for CLI and GUI
- Organizing what goes into a release
- Compiling CLI and GUI, packaging for distribution
- Writing release notes
- Misc work (user support, issue tracker maintanace, HackerOne)
## Who
selsta, I have been contributing to monero since around 2018 with over 500 merged commits. Here is a list of my previous work:
- CLI contributions: https://github.com/monero-project/monero/pulls?q=is%3Apr+author%3Aselsta
- GUI contributions: https://github.com/monero-project/monero-gui/pulls?q=is%3Apr+author%3Aselsta
- Previous CCS: https://ccs.getmonero.org/proposals/selsta-3p.html
If funded I will provide monthly updates in the CCS comment section.
## Proposal
Work for 30 hours per week over the next 3 months (from mid-January to mid-March) at a rate of 45€ / hour. At 170€ / XMR (7 day EMA) this makes 95 XMR.
---
layout: cp
title: selsta part-time monero development (3 months) (5)
author: selsta
date: 18 Apr 2022
amount: 75
milestones:
- name: May
funds: 33% (25 XMR)
done: 31 May 2022
status: finished
- name: June
funds: 33% (25 XMR)
done: 30 June 2022
status: finished
- name: July
funds: 33% (25 XMR)
done: 31 July 2022
status: finished
payouts:
- date: 13 June 2022
amount: 25
- date: 6 July 2022
amount: 25
- date: 4 August 2022
amount: 25
---
## What
- Focus on preparing the next network update (Bulletproofs+, view tags, multisig fixes, ...)
- Smaller dev work on CLI and GUI
- Put effort where necessary
- Testing and reviewing pull requests (CLI, GUI, site)
- Monero release engineering for CLI and GUI
- Organizing what goes into a release
- Compiling CLI and GUI, packaging for distribution
- Writing release notes
- Misc work (user support, issue tracker maintanace, HackerOne)
## Who
selsta, I have been contributing to monero since around 2018 with over 525 merged commits. Here is a list of my previous work:
- CLI contributions: https://github.com/monero-project/monero/pulls?q=is%3Apr+author%3Aselsta
- GUI contributions: https://github.com/monero-project/monero-gui/pulls?q=is%3Apr+author%3Aselsta
- Previous CCS: https://ccs.getmonero.org/proposals/selsta-4p.html
If funded I will provide monthly updates in the CCS comment section.
## Proposal
Work for 30 hours per week over the next 3 months (from May to end of July) at a rate of 45€ / hour. At 214€ / XMR (14 day EMA) this makes 75 XMR.
---
layout: cp
title: selsta part-time monero development (3 months) (6)
author: selsta
date: 30 July 2022
amount: 110
milestones:
- name: August
funds: 33% (37 XMR)
done: 31 August 2022
status: finished
- name: September
funds: 33% (37 XMR)
done: 30 September 2022
status: finished
- name: October
funds: 33% (36 XMR)
done: 31 October 2022
status: unfinished
payouts:
- date: 5 September 2022
amount: 37
- date: 4 October 2022
amount: 37
- date: 6 November 2022
amount: 36
---
## What
- Focus on preparing the next network update (Testing Ledger and Trezor integration, prepare v0.18.1.0)
- Smaller dev work on CLI and GUI
- Put effort where necessary
- Testing and reviewing pull requests (CLI, GUI, site)
- Monero release engineering for CLI and GUI
- Organizing what goes into a release
- Compiling CLI and GUI, packaging for distribution
- Writing release notes
- Misc work (user support, issue tracker maintanace, HackerOne)
## Who
selsta, I have been contributing to monero since around 2018 with over 572 merged commits. Here is a list of my previous work:
- CLI contributions: https://github.com/monero-project/monero/pulls?q=is%3Apr+author%3Aselsta
- GUI contributions: https://github.com/monero-project/monero-gui/pulls?q=is%3Apr+author%3Aselsta
- Previous CCS: https://ccs.getmonero.org/proposals/selsta-5p.html
If funded I will provide monthly updates in the CCS comment section.
## Proposal
Work for 30 hours per week over the next 3 months (from August to end of October) at a rate of 45€ / hour. At 148€ / XMR (14 day EMA) this makes 110 XMR.
---
layout: cp
title: selsta part-time monero development (3 months) (7)
author: selsta
date: 5 November 2022
amount: 135
milestones:
- name: November
funds: 33% (45 XMR)
done: 30 November 2022
status: finished
- name: December
funds: 33% (45 XMR)
done: 31 December 2022
status: finished
- name: January
funds: 33% (45 XMR)
done: 31 January 2023
status: finished
payouts:
- date: 9 December 2022
amount: 45
- date: 13 January 2023
amount: 45
- date: 13 February 2023
amount: 45
---
## What
- Focus on setting up community node infrastructure: https://github.com/monero-project/monero/issues/8624
- Smaller dev work on CLI and GUI
- Put effort where necessary
- Testing and reviewing pull requests (CLI, GUI, site)
- Monero release engineering for CLI and GUI
- Organizing what goes into a release
- Compiling CLI and GUI, packaging for distribution
- Writing release notes
- Misc work (user support, issue tracker maintanace, HackerOne)
## Who
selsta, I have been contributing to monero since around 2018 with over 595 merged commits. Here is a list of my previous work:
- CLI contributions: https://github.com/monero-project/monero/pulls?q=is%3Apr+author%3Aselsta
- GUI contributions: https://github.com/monero-project/monero-gui/pulls?q=is%3Apr+author%3Aselsta
- Previous CCS: https://ccs.getmonero.org/proposals/selsta-6p.html
If funded I will provide monthly updates in the CCS comment section.
## Proposal
Work for 30 hours per week over the next 3 months (from November to end of January) at a rate of 45€ / hour. At 120€ / XMR this makes 135 XMR.
---
layout: cp
title: selsta part-time monero development (3 months) (8)
author: selsta
date: 28 January 2023
amount: 102
milestones:
- name: Februrary
funds: 33% (34 XMR)
done: 28 February 2023
status: finished
- name: March
funds: 33% (34 XMR)
done: 31 March 2023
status: finished
- name: April
funds: 33% (34 XMR)
done: 10 May 2023
status: finished
payouts:
- date: 14 March 2023
amount: 34
- date: 10 April 2023
amount: 34
- date: 11 May 2023
amount: 34
---
## What
- Focus on major release v0.18.2.0 (P2Pool hard-fork support, Dandelion++ fixes, RandomX refactor, RingCT cache, network stability improvements)
- Smaller dev work on CLI and GUI
- Put effort where necessary
- Testing and reviewing pull requests (CLI, GUI, site)
- Monero release engineering for CLI and GUI
- Organizing what goes into a release
- Compiling CLI and GUI, packaging for distribution
- Writing release notes
- Misc work (user support, issue tracker maintanace, HackerOne)
## Who
selsta, I have been contributing to monero since around 2018 with over 615 merged commits. Here is a list of my previous work:
- CLI contributions: https://github.com/monero-project/monero/pulls?q=is%3Apr+author%3Aselsta
- GUI contributions: https://github.com/monero-project/monero-gui/pulls?q=is%3Apr+author%3Aselsta
- Previous CCS: https://ccs.getmonero.org/proposals/selsta-7p.html
If funded I will provide monthly updates in the CCS comment section.
## Proposal
Work for 30 hours per week over the next 3 months (from Februrary to end of April) at a rate of 45€ / hour. At 159€ / XMR (14-day EMA) this makes 102 XMR.
---
layout: cp
title: selsta part-time monero development (3 months) (9)
author: selsta
date: 1 May 2023
amount: 117
milestones:
- name: May
funds: 33% (39 XMR)
done: 5 June 2023
status: finished
- name: June
funds: 33% (39 XMR)
done: 2 July 2023
status: finished
- name: July
funds: 33% (39 XMR)
done: 13 August 2023
status: finished
payouts:
- date: 8 June 2023
amount: 39
- date: 6 July 2023
amount: 39
- date: 16 August 2023
amount: 39
---
## What
- Start the planning of a network upgrade with RandomX changes (https://github.com/monero-project/monero/issues/8827) and Bulletproofs++
- Smaller dev work on CLI and GUI
- Put effort where necessary
- Testing and reviewing pull requests (CLI, GUI, site)
- Monero release engineering for CLI and GUI
- Organizing what goes into a release
- Compiling CLI and GUI, packaging for distribution
- Writing release notes
- Misc work (user support, issue tracker maintanace, HackerOne)
## Who
selsta, I have been contributing to monero since around 2018 with over 628 merged commits. Here is a list of my previous work:
- CLI contributions: https://github.com/monero-project/monero/pulls?q=is%3Apr+author%3Aselsta
- GUI contributions: https://github.com/monero-project/monero-gui/pulls?q=is%3Apr+author%3Aselsta
- Previous CCS: https://ccs.getmonero.org/proposals/selsta-8p.html
If funded I will provide monthly updates in the CCS comment section.
## Proposal
Work for 30 hours per week over the next 3 months (from May to end of July) at a rate of 45€ / hour. At 138.5€ / XMR this makes 117 XMR.
---
layout: cp
title: "koe: Seraphis Library Work 2"
author: koe
date: 26 Dec 2022
amount: 125
milestones:
- name: PoC
funds: 100% (125 XMR)
done: 31 March 2023
status: finished
payouts:
- date: 6 April 2023
amount: 125
---
## Intro
Hi all, I [closed out](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/338#note_20190) my previous [Seraphis Library Work CCS](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/338) after consuming all the hours. There are additional tasks I would like to work on. For background on this CCS, please see the links in the previous sentence.
In the previous CCS I finished adding new things to the seraphis library, and from here on mainly have cleanup tasks left.
## Continuing work
Here are the tasks I hope to finish by the end of this CCS.
- Complete the 'final draft' of my seraphis library (finish my cleanup and review pass).
- Update the [Seraphis paper draft](https://github.com/UkoeHB/Seraphis).
This CCS should be a long-term one, with intermittent hours spent on miscellaneous Monero R&D tasks and working with Monero devs on seraphis library reviews and PRs. I may also update the seraphis library to replace BP+2 with BP++ at some point.
## Funding
- Rate: 50 USD + 0.2 XMR
- Hours: 240hrs
- XMR equivalent: 48 + (50\*240)/USD\_EXCHANGE\_RATE XMR
- USD\_EXCHANGE\_RATE: set from 14-day EMA on a major exchange
- 155 USD/XMR at 2325 UTC 01/11/2023 w/ 14-day EMA on Kraken -> 125 XMR total
---
layout: cp
title: "koe: Seraphis Library Work"
author: koe
date: 18 Aug 2022
amount: 122
milestones:
- name: PoC
funds: 100% (122 XMR)
done: 26 December 2022
status: finished
payouts:
- date: 30 December 2022
amount: 122
---
## Intro
Hi all, I [closed out](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/314#note_18262) my previous [Seraphis Wallet PoC CCS](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/314) after consuming all the hours. There are additional tasks I would like to work on. For background on this CCS, please see the links in the previous sentence.
In the last CCS period I decided that an actual wallet proof-of-concept is too ambitious. My more modest/realistic goal is to complete the Seraphis library so wallets can be (relatively) easily built.
## Continuing work
Here are the tasks I hope to finish by the end of this CCS (a continuing refrain, maybe some day my list will have no more items). As before, these will be implemented in my [seraphis_lib](https://github.com/UkoeHB/monero/tree/seraphis_lib) branch.
- Legacy/Seraphis integration so old cryptonote-style enotes can be spent in Seraphis transactions.
- Seraphis-style coinbase transaction type.
- Test out tevador's [x25519 library](https://github.com/tevador/mx25519) for enote ECDH instead of ed25519, which may speed up enote scanning by a non-trivial amount (>10%). (big thanks to @tevador for putting that library together)
- Miscellaneous code cleanup (mostly update/add comments, cleanup TODOs).
- Update the [Seraphis draft](https://github.com/UkoeHB/Seraphis), which I have not touched for 6 months.
As usual, I will also lump all the miscellaneous Monero R&D tasks that I work on into this CCS (e.g. in the last period I did more review/work on multisig security patches, among other things).
## Funding
- Rate: 50 USD + 0.2 XMR
- Hours: 12 weeks @ 20hr/wk = 240hrs
- XMR equivalent: 48 + (50\*240)/USD\_EXCHANGE\_RATE XMR
- USD\_EXCHANGE\_RATE: set from 14-day EMA on a major exchange
- 163 USD/XMR at 0045 UTC 08/18/2022 w/ 14-day EMA on Kraken -> 122 XMR total
If I require more time, and the community supports it, then I may make another proposal to extend the hours.
---
layout: wip
title: "koe: Seraphis Ongoing Support"
author: koe
date: 31 March 2023
amount: 163.7
milestones:
- name: PoC
funds: 100% (163.7 XMR)
done:
status: unfinished
payouts:
---
### Deadline update: July 1, 2025
Prior to the deadline, the proposer MUST provide regular updates on their progress as per the CCS rules.
If the provided updates/progress (or lack thereof) is unsatisfactory, all remaining funds **can be** relinquished either before or after the deadline.
The community will then seek another person/team to take over. If this cannot be accomplished within a reasonable timeframe, the funds will be repurposed or reallocated to a similar proposal (subject to community consensus).
## Intro
Hi all, I [closed out](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/369#note_21022) my previous [Seraphis Library Work 2 CCS](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/369) after consuming all the hours. There are additional tasks I would like to work on. For background on this CCS, please see the links in the previous sentence.
In the previous CCS I refined the seraphis library to a satisfying state. It can now be considered in 'final draft' form.
## Continuing work
Here are the tasks I hope to finish by the end of this CCS.
- Update the [Seraphis paper draft](https://github.com/UkoeHB/Seraphis). I will split the current draft into two papers, one focused on the core Seraphis abstraction and the other focused on the current implementation using Jamtis. My goal is to get those papers to a place where I can collaborate with (as yet undetermined) security researchers to add proper security analysis.
- Support the seraphis migration workgroup with focused architecture design work, and possibly contribute development work to that effort.
- Build a demo for a secure and efficient escrowed market using Monero 2-of-3 multisig with the seraphis library.
- As usual, participate in ongoing Monero R&D discussions and tasks.
## Funding
It has been a year and a half since I opened my first Seraphis-related CCS. I feel I have reached a level of proficiency with Monero research and development to justify asking for a raise of `10 USD + 0.1 XMR / hr` in this CCS.
- Rate: 60 USD + 0.3 XMR
- Hours: 240hrs
- XMR equivalent: 72 + (60\*240)/USD\_EXCHANGE\_RATE XMR
- USD\_EXCHANGE\_RATE: set from 14-day EMA on a major exchange
- 157 USD/XMR at 2135 UTC 03/31/2023 w/ 14-day EMA on Kraken -> 163.7 XMR total
---
layout: cp
title: "koe: Seraphis Proof-of-Concept"
author: koe
date: 1 October 2021
amount: 92.6
milestones:
- name: PoC
funds: 100% (92.6 XMR)
done: 22 February 2022
status: finished
payouts:
- date: 25 April 2022
amount: 92.6
---
## Intro
Hi all, after some encouragement I decided to request funding for my ongoing work on Seraphis. Specifically, funding for future work on the Seraphis C++ proof-of-concept that I have been developing since the second week of September.
My goal is for this code to be 95% production-ready. It is appropriate to get large pieces of code funded if they have a strong potential to be merged into the master branch.
## What is Seraphis?
[Seraphis](https://github.com/UkoeHB/Seraphis) is a next-gen transaction protocol abstraction, which means it defines various high-level rules for a concrete transaction protocol. RingCT can be thought of as the current tx protocol abstraction, even though [the RingCT paper](https://web.getmonero.org/resources/research-lab/pubs/MRL-0005.pdf) specified concrete proving structures directly without abstraction.
The main innovation of Seraphis (and [Lelantus-Spark](https://eprint.iacr.org/2021/1173), a very similar protocol developed independently) is using _only_ simple commitments-to-zero for showing that a transaction input (an output being spent) exists in the ledger. This allows proofs about key images to be independent of membership proofs, which means one-time addresses and key images can be creatively designed. In particular, it is possible to avoid one of the main drawbacks of [Triptych](https://eprint.iacr.org/2020/018), namely a key image construction that makes multisig [much more complicated](https://github.com/cypherstack/triptych-multisig).
Seraphis has other potential benefits over RingCT and Triptych (depending on concrete design choices):
- membership proof delegation (allows transaction chaining, offloading proof construction to third parties, improved indistinguishability of multisig tx [construct membership proofs at the last minute to avoid leaking timing details], allows the 10-block lock time to be somewhat ignored when transacting with a trusted party)
- multi-tier wallet permissions (e.g. a view-only wallet that can detect spent outputs, a view-only wallet that can see received outputs but not their amounts)
The main costs of Seraphis compared to Triptych are:
- more implementation effort
- all users would have to generate new addresses from their private keys (don't need new private keys, seeds, or wallets); all old addresses would become unusable
- **note**: Replacing old addresses is an opportunity to deprecate 'normal addresses' in favor of 'subaddresses' only. A uniform address format would simplify UX and various implementation details.
## PoC
**Scope**: I am working on a core component library for Seraphis, which includes proof structures, transaction structure and validation, core transaction building pieces (both normal and multisig transactions), unit tests, performance tests. The scope is similar to the `ringct/` subdirectory. I currently do not plan to touch the `wallet/` subdirectory.
- The scope also extends to my efforts to performance test different variants of Seraphis, and Lelantus Spark. However, only the main parts of Seraphis will get high-quality attention until performance results are available.
Building a new transaction-builder component library is a good opportunity to both re-imagine how to architect component versioning (i.e. instead of spaghetti conditionals, which are rampant in some parts of the codebase after 13 hard forks), and to add various things from my wishlist.
Ultimately, I want to include the following in my PoC (found in the MRL and Monero GitHub Issues linked below):
- reorganized tx semantics (`tx_supplement` takes some stuff out of the `tx_extra`)
- view tags
- enforce 1 tx pub key for 2-out tx, 1 key per output for >2-out tx
- enforce sorted-TLV in the extra field
- Janus mitigation (one way or another - depending on the address scheme chosen)
### PoC: current progress
The PoC currently has:
- mock-up of RingCT with CLSAG (for performance comparisons)
- mock-up of Triptych (for performance comparisons)
- concise Grootle proof (with 'aggregation coefficients', like found in Triptych)
- plain Grootle proof (without 'aggregation coefficients', like found in Lelantus-Spark)
- **note**: The guys at Firo theorize this should have faster verification than concise Grootle proofs (using 'small scalar weighting'), but in my tests it is slower. This may be due to a limitation of Monero's crypto library, which contains no optimizations for small scalar EC multiplication, so future improvements may be possible.
- Seraphis composition proof
- unit tests for all of the above
- tx mock-up performance testing framework
### PoC: TODO
My immediate plans for the PoC include:
- core multisig functionality in Seraphis composition proof
- mock-up of 4 different Seraphis variants
- mock-up of Lelantus-Spark (probably... it turns out coding complex cryptographic algorithms like advanced signature schemes is a lot of work)
- unit tests for all of the above
- comprehensive performance testing of all tx protocol mock-ups
Once performance tests are complete, I will take a break of 1-4 weeks to finish the Seraphis paper. Then, after making various design decisions to narrow down the optimal tx protocol and address scheme (based on discussion in the Monero community - primarily IRC channels #monero-dev and #monero-research-lab), I want to add the following to the PoC (I will probably make a new branch for this, and cut out all the extra stuff from performance testing).
- mock-up of Seraphis addressing framework
- mock-up of Seraphis transaction builder framework (with multisig)
- the wishlist from [above](#PoC)
## Past and current Monero work
- [Seraphis paper](https://github.com/UkoeHB/Seraphis): in-progress
- [Seraphis PoC branch](https://github.com/UkoeHB/monero/tree/seraphis_perf): in-progress
- [ZtM2](https://web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf): complete
- [ZtM1](https://web.getmonero.org/library/Zero-to-Monero-1-0-0.pdf): complete
- [MRL issues](https://github.com/monero-project/research-lab/issues/created_by/UkoeHB): many are active/open (the fee issue is [close to merging on master](https://github.com/monero-project/monero/pull/7819))
- [Monero issues](https://github.com/monero-project/monero/issues/created_by/UkoeHB): tx semantics proposal is open
- [Monero PRs](https://github.com/monero-project/monero/pulls/UkoeHB): multisig address-generation rework is open
## Funding
- Rate: 50 USD + 0.2 XMR
- Hours: 6 weeks @ 40hr/wk = 240hrs
- XMR equivalent: 48 + (50\*240)/USD\_EXCHANGE\_RATE XMR
- USD\_EXCHANGE\_RATE: set from 14-day EMA on a major exchange when merging proposal
- 269 USD/XMR at 1800 UTC 10/13/2021 w/ 14-day EMA on Kraken -> 92.6 XMR total
If it takes me fewer than 240hrs, then I will allocate the extra hours toward whatever future Monero work I end up doing (or pass the left-over funds into the general fund if necessary).
If I require more time, and the community supports it, then I may make another proposal to extend the hours.
---
layout: cp
title: "koe: Seraphis Wallet Proof-of-Concept 2"
author: koe
date: 1 May 2022
amount: 155
milestones:
- name: PoC
funds: 100% (155 XMR)
done: 18 August 2022
status: finished
payouts:
- date: 24 October 2022
amount: 155
---
## Intro
Hi all, I [closed out](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/290#note_16046) my previous [Seraphis Wallet PoC CCS](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/290) after consuming all the hours. There are additional tasks I would like to work on. For background on this CCS, please see the links in the previous sentence.
## Continuing work
Here are the tasks I hope to finish by the end of this CCS. As before, these will be implemented in my [seraphis_lib](https://github.com/UkoeHB/monero/tree/seraphis_lib) branch.
- Add tx builder plumbing for _discretized_ tx fees (see the [04/20/22 MRL meeting](https://github.com/monero-project/meta/issues/691) for a discussion).
- Consider using 16-byte address indices (instead of 7), with 2-byte encoded address index MACs (instead of 1).
- Implement a robust 'input selection' solver that takes advantage of statically-determinable tx weights.
- Implement a maximally-efficient and generic enote-scanning workflow.
- Build a wallet proof-of-concept that demonstrates all the 'transaction engineering' capabilities and implementation modularity of Seraphis/Jamtis. My goal is to have unit tests representing all the main workflows possible with Seraphis, and all the main wallet implementations necessary (i.e. mock-ups of interfaces that could potentially be developed into full-fledged wallet software).
- Test out using x25519 for enote ECDH instead of ed25519, which may speed up enote scanning by a non-trivial amount (>10%).
- Miscellaneous code cleanup (mostly update/add comments, cleanup TODOs).
As usual, I will also lump all the miscellaneous Monero R&D tasks that I work on into this CCS (e.g. in the last period I did more review/work on multisig security patches, among other things).
## Funding
- Rate: 50 USD + 0.2 XMR
- Hours: 16 weeks @ 20hr/wk = 320hrs
- XMR equivalent: 64 + (50\*320)/USD\_EXCHANGE\_RATE XMR
- USD\_EXCHANGE\_RATE: set from 14-day EMA on a major exchange
- 175 USD/XMR at 0100 UTC 05/16/2022 w/ 14-day EMA on Kraken -> 155 XMR total
If I require more time, and the community supports it, then I may make another proposal to extend the hours.
---
layout: cp
title: "koe: Seraphis Wallet Proof-of-Concept"
author: koe
date: 23 February 2022
amount: 81.4
milestones:
- name: PoC
funds: 100% (81.4 XMR)
done: 25 April 2022
status: finished
payouts:
- date: 12 May 2022
amount: 81.4
---
## Intro
Hi all, after the [completion](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/256#note_15087) of my previous [Seraphis PoC CCS](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/256), there are additional tasks I would like to work on. For background on this CCS, please see the links in the previous sentence.
## New tasks
These tasks will be implemented in my [seraphis_lib](https://github.com/UkoeHB/monero/tree/seraphis_lib) branch. My ultimate goal is that, once this CCS is complete, I can hand off seraphis_lib to other Monero developers who can start working on/thinking about how to get Seraphis actually used in Monero.
- Build a wallet proof-of-concept that demonstrates all the 'transaction engineering' capabilities and implementation modularity of Seraphis/Jamtis. My goal is to have unit tests representing all the main workflows possible with Seraphis, and all the main wallet implementations necessary (i.e. mock-ups of interfaces that could potentially be developed into full-fledged wallet software).
- Test out using x25519 for enote ECDH instead of ed25519, which may speed up enote scanning by a non-trivial amount (>10%).
- Add validation code and plumbing for `tx_extra` fields.
- Add tx builder plumbing for tx fees.
- Add multisig tx builders for Seraphis (with unit tests) after the master branch is updated with PR #7877.
- Miscellaneous code cleanup (mostly update/add comments, cleanup TODOs).
I will also lump all the miscellaneous Monero R&D tasks that I work on into this CCS (e.g. in the last period I did a bunch of review/work on multisig security patches, among other things).
## Funding
- Rate: 50 USD + 0.2 XMR
- Hours: 8 weeks @ 20hr/wk = 160hrs
- XMR equivalent: 32 + (50\*160)/USD\_EXCHANGE\_RATE XMR
- USD\_EXCHANGE\_RATE: set from 14-day EMA on a major exchange when merging proposal
- 162 USD/XMR at 2100 UTC 02/23/2022 w/ 14-day EMA on Kraken -> 81.4 XMR total
If I require more time, and the community supports it, then I may make another proposal to extend the hours.
---
layout: wip
title: Monero Payment gateways Gateways part 3
author: SerHack
date: March 2020
amount: 11
milestones:
- name: Monero PHP library maintenance
funds: 4
done:
status: unfinished
- name: Monero Woocommerce payment gateway maintenance
funds: 7
done:
status: unfinished
- name: Others ideas
funds:
done:
status: unfinished
payouts:
- date:
amount:
- date:
amount:
---
### Deadline update: July 1, 2025
Prior to the deadline, the proposer MUST provide regular updates on their progress as per the CCS rules.
If the provided updates/progress (or lack thereof) is unsatisfactory, all remaining funds **can be** relinquished either before or after the deadline.
The community will then seek another person/team to take over. If this cannot be accomplished within a reasonable timeframe, the funds will be repurposed or reallocated to a similar proposal (subject to community consensus).
### What?
I am [SerHack](https://serhack.me), the author of [Mastering Monero](https://masteringmonero.com) and security engineer; I am one of the maintainers for [Monero integrations](https://monerointegrations.com) project. The project aims to provide a set of payment gateways and libraries (coded mainly in PHP, at the time of writing) for merchants and developers. As you might find on Github, the payment gateways are not in any third party companies, then no data is sent to any other website beside yours.
With this request, I would like to keep the two main repositories (PHP library and Woocommerce libraries) updated. I have set two main milestones.
#### Milestone 1: PHP library maintenance
I've listed all the possible issues I can fix or improve. Note that I would like to keep this library without any external dependencies (e.g. guzzle from composer) for security reasons. Honestly, I have some difficulties at trusting composer, but I'd like to discuss about this.
* [Enable SSL validation by default for non loopback connections](https://github.com/monero-integrations/monerophp/issues/11)
* [Daemon RPC Wrapper: "Other Methods"](https://github.com/monero-integrations/monerophp/issues/34)
* [Make stable version on packagist](https://github.com/monero-integrations/monerophp/issues/82)
* [Use code stype](https://github.com/monero-integrations/monerophp/issues/84)
* [Remove dead code](https://github.com/monero-integrations/monerophp/issues/85)
* [Library returns NULL when it receives a blank response or an error](https://github.com/monero-integrations/monerophp/issues/92)
* [PHP 7.2 - json_encode() breaks transfer submission of certain amounts](https://github.com/monero-integrations/monerophp/issues/100)
* [offline mnemonic support planned?](https://github.com/monero-integrations/monerophp/issues/103)
* [Make sure we support the latest PHP versions and do not support PHP < 7.2](https://github.com/monero-integrations/monerophp/issues/109)
* General improvement
If you have any additional idea, feature request, or issue, please let me know!
#### Milestone 2: Monero Woocommerce payment gateway maintenance
Monero Woocommerce Payment Gateway had only 40 installations from [Wordpress.org](https://wordpress.org/plugins/monero-woocommerce-gateway/#installation). This is partially my fault since the page was created to attract more merchants. As per Milestone 1, I have listed all the issues I would like to fix.
* [Switch to subaddresses](https://github.com/monero-integrations/monerowp/issues/56) – This has already been implemented, but in a cryptic way. It needs some review.
* [List of currencies vanishes](https://github.com/monero-integrations/monerowp/issues/67)
* [Improve the upcoming release 3.0](https://github.com/monero-integrations/monerowp/issues/74)
* [Decrypting payment id in Monero_Cryptonote results in infinite loop](https://github.com/monero-integrations/monerowp/issues/81)
* [Feature request: checkout shutdown on timeout](https://github.com/monero-integrations/monerowp/issues/83)
* [javascript disabled fall-back support](https://github.com/monero-integrations/monerowp/issues/84)
* [One payment will cause all pending orders with the same value to be marked as paid.](https://github.com/monero-integrations/monerowp/issues/85)
Any other idea is really appreciated!
### Why?
I would like to expand more this section since it is a subject close to my heart. Monero was created to be the most private cryptocurrency ever created; when I joined the Monero community, I had some difficulties at finding payment gateways that were private. Thus I've started this project.
### Costs
If milestones are not modified, I'll ask 11 XMR (~700 euros) - fixed price.
### Proposal transfer
This proposal will be transferred to recanman who will enjoy an exclusivity period of 5 months to show reasonable progress in completing this proposal. They will receive payments for completed milestones directly.
SerHack: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/402#note_22039
>To consider the CCS completed, all the issues mentioned in the CCS must be completed: recanman will need to push changes to monero-integrations repositories and after reviewing the PRs, I'll close the issues.
---
layout: wip
title: SolOptXMR - Solar Optimal mining of XMR
author: mj
date: Mar 26, 2022
amount: 110.55 XMR
milestones:
- name: 1 Initial setup
funds: 20.10 XMR
done: 29 May 2022
status: finished
- name: 2 Profitability calculator
funds: 16.75 XMR
done:
status: unfinished
- name: 3.1 Measurements mj
funds: 20.10 XMR
done: 22 July 2022
status: finished
- name: 3.2 Measurements Endor
funds: 16.75 XMR
done:
status: unfinished
- name: 4.1 Automation mj
funds: 20.10 XMR
done: 24 November 2022
status: finished
- name: 4.2 Automation Endor
funds: 16.75 XMR
done:
status: unfinished
payouts:
- date: 2 July 2022
amount: 20.1
- date: 28 December 2022
amount: 40.2
- date:
amount:
- date:
amount:
- date:
amount:
---
### Deadline update: July 1, 2025
Prior to the deadline, the proposer MUST provide regular updates on their progress as per the CCS rules.
If the provided updates/progress (or lack thereof) is unsatisfactory, all remaining funds **can be** relinquished either before or after the deadline.
The community will then seek another person/team to take over. If this cannot be accomplished within a reasonable timeframe, the funds will be repurposed or reallocated to a similar proposal (subject to community consensus).
# What
The goal is to create open-source software that aids people mining Monero with excess solar power in the most profitable way. It will accommodate for issues such as:
- Time of day
- Weather fluctuations
- Avoiding depleting batteries below a threshold, that would damage them
- Avoiding overheating the mining rig
- Leaving enough power for your daily use
# Intro
I promised I'd help out in the [Monero Recruitment Matrix Room](https://matrix.to/#/#monero-recruitment:monero.social).
Although there was just one direct request to me so far, recently I've also pro-actively proposed cooperation to the chat room members. I presented there 2 projects, that are on my mind, and don't require extensive crypto knowledge, typically not available to students. Yet the projects are still useful for Monero specifically. One of the projects that I have on mind is optimization of mining performance on a solar farm, depending on varying inputs. The member Endor ([endorxmr](https://github.com/endorxmr) on GitHub and endor00 on Matrix) signed up for being the main contributor to the project, while I would serve as a mentor: namely coordinator, reviewer and designer. Such a setup will guarantee, that I won't get dragged away too much from the maintenance of Monero, that I signed up for, while at the same time, Endor will be able to continuously have access to my years of experience in automatic control and object oriented design. Endor on the other hand is heavily involved in everything, that’s connected to mining profitability.
Should Endor not make it until the deadline, I guarantee, that I will finalize the project by myself until the coming winter.
Introducing the project: SolOptXMR – Solar Optimal mining of XMR.
# Why
The following [YT video](https://www.youtube.com/watch?v=7OpM_zKGE4o) is able to bring you more context why this idea has a chance for being a trending subject and is here to stay. The outline of this video is the following:
Because of high initial, as well as perpetual investments required for producing power from solar collectors in Sahara/Nevada and delivering it to northern states, such an investment, contrived in the previous decade under the name "DESERTEC", turned out to be not the best possible investment. The project's relative profitability decreased across the years even more. The reason is, that the costs of production of solar panels dropped so low, that now it makes more sense to place them exactly where the produced power is most needed, even though the solar irradiation is lesser at these places.
On a sentiment / geopolitical side of things, with the rising prices of heating gas, I expect many people will be wanting to save on their gas costs by switching to electrical heating. Since the majority of such heaters demand high power, ranging from 2kW to 2.5kW and since a given population will typically want to switch them on all at the same time, I predict that we'll be facing a decent wave of blackouts in the coming winter. This has motivated me to build my solar farm.
If you are an individual who likes to take the matters into your own hands, you might have considered building a small solar farm yourself. Although our system won't assume a given user's setup, my particular farm is configured as an isolated island. This means, that I don't sell my overproduction to the grid for the pennies, that the state offers, but rather use the production for mining and cooking, while the overproduction is temporarily stored in a pair of cheap but reliable car batteries. My farm serves as a perfect test bed for the system, that we're going to design and automate for you. Optimized mining of Monero on such a system amortizes the installation costs over the long run, will help you learn about electricity and motivate you to become more resilient. Further compatible extensions are possible, such as small wind generators as well as bikes with flywheels, that [recover kinetic energy](https://www.youtube.com/watch?v=MBW_2gUSMXc). Such systems are already available on the market, that tends to think ahead of the time, so you don’t have to DIY.
# System description
The dynamics of the system, that tries to optimize the mining efficiency has to take into account the following inputs and goals. Some of them are obvious while others maybe not so much.
- Static astronomic data, that describe the relative movement of the Sun across the sky in various latitudes and times of year - yielding the maximal expected power that can be reached
- Weather predictions - a cloudy sky can reduce the power output by more than 80%
- If the predicted power generation is off the measured generation, a warning might be issued to clean the panels
- Voltage (load state) of the batteries, as well as voltage that reaches the DC->AC transformer, as some of it might be lost in the cables, that are either too long or have accidentally formed an inductor
- Predicted load state of the batteries on the next day before the Sun rises and the charging starts, as emptying the chemical batteries below 50% tends to damage them
- Mining rigs' temperature readouts as it's not worth to meltdown your hardware for those couple of Piconeros being mined.
- A given computer's hashrate per Watt - use the most efficient ones first, but don't overheat them
- A given computer's idle power cost - sometimes it will make sense to switch on certain less efficient computers only if there's really way too much power production, and/or the most efficient ones overheat, or it's predicted that they'd overheat soon under the, also predicted, future conditions.
- Per core efficiency compared against multithreaded efficiency - for CPUs with smaller caches, the efficiency (in this case: hashrate) scales poorly with more threads working at the same time. In such cases it will make sense to spread the mining across longer periods of time on a single core.
- The owners' power usage habits - taking into account, that you might want to use a low powered, compatible electric heating system at a given time of day, by leaving some energy in the batteries for you to consume, before the predicted event – learned either from your usage habits, or from your manually scheduled input.
- The owners' setup – whether an isolated solar island is used, output connected to grid (for selling) or supplementing power losses from the grid (buying) or both of the last 2 options.
The control mechanisms of the system would be the following:
- Downclocking the CPUs - very easy to achieve under Linux with a high precision, thus allowing for a smooth control
- Restarting the mining with a smaller number of cores
- Putting computers to sleep and waking them up with Wake On LAN on the next day
While it would be easy enough to control the system via PID controller, and I know a lot about it, such a system would have little prediction power, delivered only by the first differential part of the controller (the D) and only between the current and the previous state. Using a Time Series Analysis and Prediction tool, such as the already available `tsqsim`, will give the system the ability to look ahead into the future (like at least 48 hours ahead) and plan accordingly to maximize the gain per the unit of energy used, while at the same time planning carefully against overheat of the hardware, under-voltage of the DC->AC transformer, leading to an immediate halt of the system, as well as against under-voltage (as in: capacity) of the batteries, which would otherwise quickly damage them.
The inputs to the system will come in a few forms – either assumed, input by the user or measured. The measurements can be easily supplied via smart plugs or measured directly. Ultimately it has to be left to the user to decide how much time to spend on providing additional inputs, that result in improvements of predictions, thus profitability. The goal here is however to keep the measurements optional, not to impose burden on the user.
# Who
mj – working for Monero since 2 years on the purely technical level. Speeding up compilation and Continuous Integration on GitHub, keeping an eye on overall efficiency, generating [Monero health report](http://cryptog.hopto.org/monero/health/), reviewing technical PRs, helping out new developers. Lately developing Time Series Analysis tool for Monero Research Lab, called `tsqsim`. [Here’s a list](https://github.com/search?q=is%3Apr+author%3Amj-xmr+archived%3Afalse+is%3Aclosed) of all my contributions to Monero and to the supporting software.
Endor – Aerospace Engineering student and a junior Python developer on the side. I already have a few small projects under my belt - one of which related to automation and monitoring of a live system. I've been following the Monero project for over 5 years, learning the ins and outs of cryptocurrency mining and moderating the Supportxmr chat and the Monero Mining room on Matrix (#xmrmine:matrix.org). I am currently developing a comprehensive economic model of mining, and I plan to publish a small paper/series of articles over the next few weeks that will (hopefully) serve as "the ultimate guide to mining" for newcomers and professionals alike. A glimpse into my work can be seen in [this minimalistic script](https://gist.github.com/endorxmr/07364dc54f277abf487574d455d67341), that dynamically calcylates the CPUs mining profitability and compares it across various other CPUs. An example output (though shortened) can be seen below:
```
python3 mining-profitability.py
Difficulty: 354634073114
Average blocktime @6500 H/s: 631 days, 11:18:08
Price: 201.98 - XXMRZUSD
Expected crypto income/s: 1.236e-08
Expected fiat income/s: 2.496e-06
Profitability: 38.2%
Miner efficiency: 100.0 H/s/W
ROI time: 12577.0 days to recover 750 USD
Breakeven efficiency @0.1/kWh: 72.3 H/s/W
Network power consumption @0.1/kWh: 40849693 W
+--------+--------+-------+--------+
| Period | Profit | Mined | Power |
+========+========+=======+========+
| Day | 0.060 | 0.001 | 0.156 |
| Week | 0.417 | 0.007 | 1.092 |
| Month | 1.789 | 0.032 | 4.680 |
| Year | 21.770 | 0.390 | 56.940 |
+--------+--------+-------+--------+
+-------------------------------+--------+-------+------------+--------+
| CPU | Speed | Power | Efficiency | Amount |
+===============================+========+=======+============+========+
| AMD EPYC 7763 (dual) | 100000 | 750 | 133.333 | 54467 |
| AMD Ryzen Threadripper 3990X | 65000 | 600 | 108.333 | 68083 |
| AMD Ryzen 3600X | 7500 | 70 | 107.143 | 583568 |
| Intel Xeon Silver 4216 (dual) | 16157 | 312 | 51.785 | 130929 |
| Intel Core i7-4720HQ | 1768 | 45 | 39.289 | 907771 |
+-------------------------------+--------+-------+------------+--------+
```
# Milestones
## 1 Initial setup
The initial setup, that is able to use static astronomic data inputs (let’s call it by its name used in the industry: seasonality) and simple weather forecasts (sunny/cloudy/in-between) to make predictions based mostly on user input as to how much power a given computer and its cores consume, taking into account how much power is expected to be consumed in house for other purposes, that have to be treated as of a higher priority. Initially a status message will be displayed about what to do manually to maximize the selected goals. Plots of the inputs and outputs will be displayed, that explain why such a suggestion was presented.
Will be done mostly by mj, since Endor shouldn’t be strained with too many foreign systems, only receive the system’s output signals. This will require about 2 weeks of work full time, that makes:
- 6 (Monday-Saturday) * 2 (weeks) * 8 (hours) = 96 work hours
- 96 work hours / 10h in a week = 9.6 weeks spread.
## 2 Profitability calculator
Profitability calculator, taking into account the power costs, grid’s buy-back prices (if available) and user’s price target, at which to sell the mined coins. Also a very important input will be the time-bound energy availability, delivered through the system from the Milestone 1
This milestone will be done mostly by Endor, due to his experience in the field. I will only support via tips such as obtaining user input and code reviews, design suggestions, etc. I won’t count my pay on this one. This can be started before milestone 1) is finished, on a basis of simple generated sinusoidal signals, that will soon enough be replaced with real data.
Endor’s:
- 6 (Monday-Saturday) * 3 (weeks) * 8 (hours) = 144 work hours
- 144 work hours / 15h in a week = 9.6 weeks spread.
## 3 Measurements
3) Support for various kinds of measurements – smart plugs, digital converters, software temperature readouts and even simple image recognition of LCD/LED displays of the DC→AC transformer and MPPT regulator.
Both of us have experience in various parts here and wish to take equal part in this milestone. I’ll create up to two examples of image recognition.
mj’s:
- 6 (Monday-Saturday) * 2 (weeks) * 8 (hours) = 96 work hours
- 96 work hours / 10h in a week = 9.6 weeks spread.
Endor’s:
- 6 (Monday-Saturday) * 3 (weeks) * 8 (hours) = 144 work hours
- 144 work hours / 15h in a week = 9.6 weeks spread.
## 4 Automation
Automation of the system, including remote CPU downclocking, selecting the number of threads, putting computers to sleep, and waking them up via the Wake On LAN technology. We will be promoting privacy oriented and non-controversial software, namely: [p2pool](https://github.com/SChernykh/p2pool) and [xmrig](https://github.com/xmrig/xmrig), accordingly.
Same as above, both of us have experience and ideas here. I already perform such tasks manually (via scripts) on my solar farm, so I know “the feel” of the system. Endor has many great ideas and a lot of expertise for this milestone as well, as this resonates with his prior experience with mining profitability and a variety of mining software + hardware.
mj’s:
- 6 (Monday-Saturday) * 2 (weeks) * 8 (hours) = 96 work hours
- 96 work hours / 10h in a week = 9.6 weeks spread.
Endor’s:
- 6 (Monday-Saturday) * 3 (weeks) * 8 (hours) = 144 work hours
- 144 work hours / 15h in a week = 9.6 weeks spread.
# Legal & privacy
The project shall be released under AGPLv3. It will send no telemetry by default, unless the user wishes to have their data uploaded and analyzed. The data will surely serve as a stabilization asset of the project and will be included in the automated system tests as one of many test cases. The complete data set to be sent will always be shown to the user for a review and approval.
As I’m familiar with the EU laws regarding solar panels a bit, I will be providing the users non-legally-binding relevant advice.
Even though I’m not strictly an electrical engineer, I know enough tricks in this field and I understand many nuances about the inner workings of such systems. I know what hardware are compatible with each other and how to calculate the supply and demand of the produced power. Therefore I can provide advice in this field as well, yet again: non-legally-binding.
# Proposal
As of 12 April, XMR/EUR is at 214.92 EUR.
## mj:
I will be able to spend about 10 hours / week on the project. An amount so low, that it doesn’t collide with my maintenance assignment, nor Monero Research Laboratory, once I switch there for a while. My rate per hour is 45 EUR. The total number of work hours is: 96 + 96 + 96 = 288.
288 [h] * 45 [EUR/h] / 214.92 [XMR/EUR] = 60.3 XMR
## Endor:
I will be able to spend about 15 hours / week on the project. My rate in my first ever proposal is at 25 EUR / h. The total number of work hours is: 144 + 144 + 144 = 432.
432 [h] * 25 [EUR] / 214.92 [XMR/EUR] = 50.25 XMR
Since in this case we are really talking about seasonal data, that doesn’t require a lot of readjustments, further maintenance will not be a burden for any of us. Unless many new features are requested, we will gladly maintain it for you without asking for compensation.
## Summary:
60.3 + 50.25 = 110.55 XMR is what we're asking for. Thanks in advance!
## Deadline calculation
A rough deadline calculation based on the spread of the hours and including the tasks that can be done in parallel:
9.6 [weeks] * 3 / 4.1 [weeks in a month] ~ 7 months.
This coincides with the promise to finalize the project until winter if all goes well with Endor’s plan. If not, I can take over most of the responsibilities, as there are always ~1-1.5 month breaks between my maintenance proposals.
Cheers!
# Expiration date
31 Oct, 2022
---
layout: cp
title: Robust and modular wallet-rpc library
date: Sep 10, 2024
author: Spirobel
amount: 100
milestones:
- name: Deved + prepayment for first month
funds: 20 XMR
done: 9 October 2024
status: finished
- name: First month
funds: 30 XMR
done: 23 December 2024
status: finished
- name: Second month + value commitment
funds: 50 XMR
done: 19 February 2025
status: finished
payouts:
- date: 16 October 2024
amount: 20
- date: 28 February 2025
amount: 80
---
# Robust and modular wallet-rpc library
## Who
**Spirobel**
References:
#### found and reported a "pay what you want" vulnerability in AcceptXMR
https://x.com/spirobel/status/1672479215512588288
https://github.com/busyboredom/acceptxmr/issues/64
#### open sourced a Patreon like tool for Monero
https://x.com/spirobel/status/1595949928634667008
https://github.com/spirobel/monero-discourse-subscriptions
#### open sourced a merchant focused wallet-rpc
https://x.com/spirobel/status/1596299822516285440
https://github.com/spirobel/monerochan-merchant-rpc
#### implemented a Monero Browser wallet extension
https://www.youtube.com/watch?app=desktop&v=4DLcsQ45zoE
Contact: twitter.com/spirobel
## What
Result: A robust and modular wallet-rpc library, implemented in Rust with WebAssembly (WASM) as the primary target. This library aims to provide a flexible foundation for Monero wallet functionality. The deliverable for this proposal will be:
1. the first part of the wallet-rpc library that can sync transactions and works reliably with remote nodes.
2. A checkout flow built with this library. This is meant to be used, not just to demonstrate the features.
3. Detailed documentation for the library, the relationship between nodes and wallets during the syncing process and a guide on how to use this to implement monero payment gateways.
### Implementation
list of initial tasks:
- create function to turn address and private viewkey into viewpair
- create function to scan transaction with sub functions
- verify that there is no timelock present
- calculate transaction amount
- clarify responsibility of burning bug prevention for the caller
- implement transaction fetching and storage
- implement burning bug prevention in the checkout flow
- write unit tests, document and publish the library
- implement UI for the checkout flow
this task list is not exhaustive and subject to change
## Why
As discussed as far back as two years ago: https://github.com/seraphis-migration/strategy/issues/2
The wallet2 Monero library is a 15k lines CPP file. The official monero repo does not contain a deliverable that is easily linkable from other programs. Every project that is a wallet or contains wallet-like functionality (payment processors, hardware wallets, point of sale terminals) needs to implement its own wrapper to expose a C ABI.
This results in collectively wasted hours and headaches. It increases supply chain risk and makes building things with Monero harder. As a result, projects get more expensive, take longer or don't happen at all.
This library aims to counteract the issues and limitations of wallet2.cpp by directly targeting wasm.
Using wasm as the main target means that this library is forced to be implemented in a way that meets the expectations outlined here: https://github.com/seraphis-migration/strategy/issues/1
The benefits of this approach:
### 1. It will be easily linkable
WASM is a very constrained target. There is no garbage collection and multi threading. Getting code to run there means having to write it in a way that is easy to interact with from any language and in any environment.
### 2. It will be more robust
The current monero wallet-rpc is at times unresponsive, because its concurrency mixes the responses of the local rpc with the network interacting with the node. More details in the [monero-playground repository](https://github.com/spirobel/monero-playground). The WASM target constraints ensure that this library decouples the concurrency and networking from the wallet code. The result will be more robust.
### 3. It will be more flexible and not tied to any platform / target
Wallet code deals with the most sensitive data. It should not have unnecessary dependencies or bloat. To give a practical example: monero currently vendors a 4000 lines of code [logging library](https://github.com/monero-project/monero/blob/master/external/easylogging%2B%2B/easylogging%2B%2B.cc) that introduces a dependency on signals. The WASM target constraint means that things like that can't and wont be introduced into this library.
## Milestones and Timeline
value commitment:
The 3 deliverables outlined in the **What** section are the promised outcome of this proposal. Any time left over from the time commitment will be used to further advance the road map. The value commitment is due for the milestone of the second month.
time commitment:
- 100 hours per month for two months (100 hours total)
- Compensation: 50 XMR per month (100 XMR total)
- Total compensation: 100 XMR
## Future Roadmap
The next step on the road map is to add transaction building and signing functionality to the library and migrate [the browser wallet](https://www.youtube.com/watch?v=4DLcsQ45zoE) to it.
My endgame is to **remove all friction from the privacy enabled web shopping experience**. Currently most **Monero shoppers** have to copy and paste addresses from the tor browser into their wallets. This opens the door to unnecessary opsec failures, as it is easy to get confused and intimidated by long strings of random numbers.
**A core part of staying private and safe online is to compartmentalize identities.** Qubes OS made some advancements in improving the UX of this activity by coloring different windows that are tied to different identities in a unique way.
The reality is, that installing a different operating system is a large ask for the average person. At the same time we need to onboard as many people as possible to these habits, so we can operate safely in the crowd.
The other venue of attack is **using the browser for compartimentalization.** And before anybody complains: no this does not involve untrusted javascript frontend code.
There is a big difference between a browser wallet and web wallet. A web wallet is a flawed experiment that is borderline custodial, as it runs wallet code inside the context of a website. This is not to be confused with a browser wallet.
**A browser wallet runs trusted code as a compartmentalized, constrained program inside of a sandbox.**
There is a massive opportunity here to reduce friction by making it easy to separate online identities. The TOR browser currently enables the use of one separate TOR circuit for each tab. **Imagine we have one monero address per tab that is used for login and to send and receive payments.** It makes it much harder to mess up.
One last concern that comes up is that there might be zero day exploits in the browser, as it exposes a potentially larger attack surface. This can be mitigated by making the wallet a multisignature wallet and **using a second device like an android phone or a monero seedsigner to authorize every transaction.**
This means two devices need to be compromised to capture funds, which is unlikely.
---
layout: cp
title: Translation and review of GUI Wallet, monero-site, Monero Means Money (subtitles) and Sound Money, Safe Mode (subtitles) to Italian.
author: staff91
date: November 18, 2020
amount: 28
milestones:
- name: Milestone 1 - Completion of GUI Wallet, monero-site Translation and review to Italian
funds: 4 XMR
done:
status: unfinished
- name: Milestone 2 - Completion of Monero Means Money (subtitles), Sound Money, Safe Mode (subtitles) Translation and review to Italian
funds: 24 XMR
done:
status: unfinished
payouts:
- date:
amount:
- date:
amount:
---
## Proposal Closure
The remaining funds (28 XMR) have been donated to the General Fund.
---
# About this Proposal
Translation and review of the [GUI Wallet](https://translate.getmonero.org/projects/monero/gui-wallet/), [monero-site](https://translate.getmonero.org/projects/getmonero/monero-site/), [Monero Means Money (subtitles)](https://translate.getmonero.org/projects/community/monero-means-money/) and [Sound Money, Safe Mode (subtitles)](https://translate.getmonero.org/projects/community/sound-money-safe-mode-subtitles/) to Italian.
Review of translation made by others (if any) of the [GUI Wallet](https://translate.getmonero.org/projects/monero/gui-wallet/), [monero-site](https://translate.getmonero.org/projects/getmonero/monero-site/), [Monero Means Money (subtitles)](https://translate.getmonero.org/projects/community/monero-means-money/) and [Sound Money, Safe Mode (subtitles)](https://translate.getmonero.org/projects/community/sound-money-safe-mode-subtitles/) for free to Italian.
# About the Translators
## staff91
Hello my name is Stavros Kilonis and I was a member of the RChain Cooperative Bounties Program. I am a translator and a developer. Created the Italian website and translated everything for the bounties to Italian.
### Links
- [Monero Project Translations (Weblate)](https://translate.getmonero.org/user/staff91/)
- [GitHub](https://github.com/staff91)
- [Monero's GitLab](https://repo.getmonero.org/staff91)
## Chris-Arv
I have worked with staff91 in the past for the same projects.
### Links
- [Monero Project Translations (Weblate)](https://translate.getmonero.org/user/Chris-Arv/)
- [GitHub](https://github.com/Chris-Arv)
- [Monero's GitLab](https://repo.getmonero.org/Chris-Arv)
# Milestones and Projected Timeline
## Milestone 1 - Completion of GUI Wallet, monero-site Translation and Review to Italian
Complete translation of the [GUI Wallet](https://translate.getmonero.org/projects/monero/gui-wallet/) and [monero-site](https://translate.getmonero.org/projects/getmonero/monero-site/).
Comprises of 4909 words, which equals to 4 XMR.
Timeline: 20/11/2020 - 30/11/2020
## Milestone 2 - Completion of Monero Means Money (subtitles), Sound Money, Safe Mode (subtitles) Translation and Review to Italian
Complete translation of the [Monero Means Money (subtitles)](https://translate.getmonero.org/projects/community/monero-means-money/) and [Sound Money, Safe Mode (subtitles)](https://translate.getmonero.org/projects/community/sound-money-safe-mode-subtitles/).
Comprises of 24093 words, which equals to 24 XMR.
Timeline: 01/12/2020 - 15/12/2020
**Proposal Expiration Date**: 30/11/2020
\ No newline at end of file
---
layout: wip
layout: cp
title: Surae Funding for Q2 2019
author: Surae N
date: 18 March 2019
......@@ -7,8 +7,8 @@ amount: 618 XMR
milestones:
- name: Research begins and payout occurs upon completion of funding round
funds: 100%
done:
status: unfinished
done: 30 June 2019
status: finished
payouts:
- date: 11 April 2019
amount: 618
......
---
layout: wip
layout: cp
title: "Continued funding for Surae for another quarter, Aug Sep Nov 2019"
author: suraeNoether
date: 20 July 2019
......@@ -11,8 +11,8 @@ milestones:
status: finished
- name: Work is done
funds: 0% (0 XMR)
done:
status: unfinished
done: 30 November 2019
status: finished
payouts:
- date: 23 September 2019
amount: 357
......