What

Continue full-time another 3 months in a similar capacity:

• Prioritize debugging any significant issues that arise, such as daemon connection issues, zmq missing publishing txs submitted to the daemon, recovering multisig wallets from seed, etc.
• Complete work stress testing how daemons handle a transaction pool under heavy load to both gauge daemon performance, and to help get PR 8076 - reduce wallet round trips to the daemon across the finish line after gauging its impact on pool processing performance.
  • The day leading up to the hard fork this summer, the transaction pool experienced heavier load than usual. Daemons that saw heavy traffic reported issues serving RPC requests. I would like to dig deeper into this.
• Start working through Seraphis and Jamtis wallet tasks piecemeal, picking up collaboration with @koe, @rbrunner7, and @dangerousfreedom. The first task I've gotten a handle on and have a decently fleshed out view of what work is needed is input selection. I intend to get @koe's naive input selection implementation to production-ready, ensuring it functions as close to the wallet does today. From @koe here: "a real implementation needs many more mechanisms and heuristics (e.g. filter for dust threshold to ignore, filter for origin statuses to permit, randomization and spread to mitigate timing analysis)"
  • The general plan with Seraphis/Jamtis is to start fresh with new wallet code that avoids the complexity and pitfalls of wallet2.cpp, which at the moment is a source of growing technical debt (discussed a bit here). Considering Seraphis and Jamtis would bring a number of changes to core wallet features (a new address scheme, new balance recovery algorithm, new fee calculation, etc.), the proposed plan currently on the table is to start fresh rather than factor the existing wallet2.cpp. Many of the features that users already expect (such as sweeps, tx key recovery, watch-only wallets, etc.) would be maintained, or improved where possible. The implementation of some existing features is still up for discussion, such as accounts.
  • I'd like to reiterate this point: Seraphis and Jamtis still need to undergo stringent review both from the community and by independent 3rd parties. At this time, @koe is still working on the technical paper describing the protocol in its current iteration, which will need to undergo review in the future. Further, feedback on the core feature changes is still strongly encouraged and desired.
• Review PR's.

Who

I've identified and patched several privacy issues with varying severity in the Monero ecosystem:

1. The reference wallet's decoy selection algorithm didn't select very recent spendable outputs in some cases. (source)
2. The reference wallet truncated integers in the decoy selection algorithm, which would have borked the decoy selection algorithm entirely if tx volume were to increase; in the normal case, it marginally weakened the algorithm. (source)
3. openmonero was still using the old proven weak decoy selection algorithm, also leaving a fingerprintable trail by decoy selection algo. (source)
4. MyMonero didn't use the updated CLSAG fee calculation which fingerprinted MyMonero txs on chain by tx fee. (source)
5. MyMonero's fee calculation->input selection logic differed ever-so-slightly from the reference wallet, resulting in a fingerprintable tx fee. (source)
6. monero-lws fee masking on the server caused ever-so-slightly different fee calculations from the reference wallet, resulting in a fee fingerprintable to monero-lws (a fingerprint distinct from MyMonero). (source)
7. In PR review on the latest hard fork's changes to the tx fee, identified the introduction of slightly different fee calculation logic that would have caused tx fees to be fingerprintable to either old or new version until the hard fork.

Other contributions:

• Implemented view tags to speed up wallet scanning.
• Implemented background sync initially proposed by @hyc so that wallets can scan for transactions in the background when the user is not active, without the spend key loaded in memory.
• Identified and patched daemon reliability issues (moved forward solving issues 8520, 6631, 6929, and 6938):
  • Tor/i2p daemons periodically send a peer list that gets itself dropped.
  • The daemon periodically drops outgoing tor/i2p connections.
  • Tx re-relay math was off.
• Implemented the changes needed for Ledgers to function for the latest hard fork:
  • monero repo
  • ledger repo

Prior CCS proposals:

• https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
• https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
• https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html

Proposal

253 XMR. 480 hours, 0.16 XMR/hr + $48/hr, $131/XMR from coingecko.

I'm requesting a raise from my prior CCS because I feel I have continued to demonstrate my work is worth a competitive market rate.

j-berman full-time development (3 months)

by j-berman

December 18, 2023

211 XMR

11 contributors

Completed

What

Continue full-time another 3 months in a similar capacity:

• Prioritize debugging any significant issues that arise, such as daemon connection issues, zmq missing publishing txs submitted to the daemon, recovering multisig wallets from seed, etc.
• Complete work stress testing how daemons handle a transaction pool under heavy load to both gauge daemon performance, and to help get PR 8076 - reduce wallet round trips to the daemon across the finish line after gauging its impact on pool processing performance.
  • The day leading up to the hard fork this summer, the transaction pool experienced heavier load than usual. Daemons that saw heavy traffic reported issues serving RPC requests. I would like to dig deeper into this.
• Start working through Seraphis and Jamtis wallet tasks piecemeal, picking up collaboration with @koe, @rbrunner7, and @dangerousfreedom. The first task I've gotten a handle on and have a decently fleshed out view of what work is needed is input selection. I intend to get @koe's naive input selection implementation to production-ready, ensuring it functions as close to the wallet does today. From @koe here: "a real implementation needs many more mechanisms and heuristics (e.g. filter for dust threshold to ignore, filter for origin statuses to permit, randomization and spread to mitigate timing analysis)"
  • The general plan with Seraphis/Jamtis is to start fresh with new wallet code that avoids the complexity and pitfalls of wallet2.cpp, which at the moment is a source of growing technical debt (discussed a bit here). Considering Seraphis and Jamtis would bring a number of changes to core wallet features (a new address scheme, new balance recovery algorithm, new fee calculation, etc.), the proposed plan currently on the table is to start fresh rather than factor the existing wallet2.cpp. Many of the features that users already expect (such as sweeps, tx key recovery, watch-only wallets, etc.) would be maintained, or improved where possible. The implementation of some existing features is still up for discussion, such as accounts.
  • I'd like to reiterate this point: Seraphis and Jamtis still need to undergo stringent review both from the community and by independent 3rd parties. At this time, @koe is still working on the technical paper describing the protocol in its current iteration, which will need to undergo review in the future. Further, feedback on the core feature changes is still strongly encouraged and desired.
• Review PR's.

Who

I've identified and patched several privacy issues with varying severity in the Monero ecosystem:

1. The reference wallet's decoy selection algorithm didn't select very recent spendable outputs in some cases. (source)
2. The reference wallet truncated integers in the decoy selection algorithm, which would have borked the decoy selection algorithm entirely if tx volume were to increase; in the normal case, it marginally weakened the algorithm. (source)
3. openmonero was still using the old proven weak decoy selection algorithm, also leaving a fingerprintable trail by decoy selection algo. (source)
4. MyMonero didn't use the updated CLSAG fee calculation which fingerprinted MyMonero txs on chain by tx fee. (source)
5. MyMonero's fee calculation->input selection logic differed ever-so-slightly from the reference wallet, resulting in a fingerprintable tx fee. (source)
6. monero-lws fee masking on the server caused ever-so-slightly different fee calculations from the reference wallet, resulting in a fee fingerprintable to monero-lws (a fingerprint distinct from MyMonero). (source)
7. In PR review on the latest hard fork's changes to the tx fee, identified the introduction of slightly different fee calculation logic that would have caused tx fees to be fingerprintable to either old or new version until the hard fork.

Other contributions:

• Implemented view tags to speed up wallet scanning.
• Implemented background sync initially proposed by @hyc so that wallets can scan for transactions in the background when the user is not active, without the spend key loaded in memory.
• Identified and patched daemon reliability issues (moved forward solving issues 8520, 6631, 6929, and 6938):
  • Tor/i2p daemons periodically send a peer list that gets itself dropped.
  • The daemon periodically drops outgoing tor/i2p connections.
  • Tx re-relay math was off.
• Implemented the changes needed for Ledgers to function for the latest hard fork:
  • monero repo
  • ledger repo

Prior CCS proposals:

• https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
• https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
• https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html

Proposal

253 XMR. 480 hours, 0.16 XMR/hr + $48/hr, $131/XMR from coingecko.

I'm requesting a raise from my prior CCS because I feel I have continued to demonstrate my work is worth a competitive market rate.

j-berman full-time development (3 months)

by j-berman

July 26, 2023

216 XMR

7 contributors

Completed

What

Continue full-time another 3 months in a similar capacity:

• Prioritize debugging any significant issues that arise, such as daemon connection issues, zmq missing publishing txs submitted to the daemon, recovering multisig wallets from seed, etc.
• Complete work stress testing how daemons handle a transaction pool under heavy load to both gauge daemon performance, and to help get PR 8076 - reduce wallet round trips to the daemon across the finish line after gauging its impact on pool processing performance.
  • The day leading up to the hard fork this summer, the transaction pool experienced heavier load than usual. Daemons that saw heavy traffic reported issues serving RPC requests. I would like to dig deeper into this.
• Start working through Seraphis and Jamtis wallet tasks piecemeal, picking up collaboration with @koe, @rbrunner7, and @dangerousfreedom. The first task I've gotten a handle on and have a decently fleshed out view of what work is needed is input selection. I intend to get @koe's naive input selection implementation to production-ready, ensuring it functions as close to the wallet does today. From @koe here: "a real implementation needs many more mechanisms and heuristics (e.g. filter for dust threshold to ignore, filter for origin statuses to permit, randomization and spread to mitigate timing analysis)"
  • The general plan with Seraphis/Jamtis is to start fresh with new wallet code that avoids the complexity and pitfalls of wallet2.cpp, which at the moment is a source of growing technical debt (discussed a bit here). Considering Seraphis and Jamtis would bring a number of changes to core wallet features (a new address scheme, new balance recovery algorithm, new fee calculation, etc.), the proposed plan currently on the table is to start fresh rather than factor the existing wallet2.cpp. Many of the features that users already expect (such as sweeps, tx key recovery, watch-only wallets, etc.) would be maintained, or improved where possible. The implementation of some existing features is still up for discussion, such as accounts.
  • I'd like to reiterate this point: Seraphis and Jamtis still need to undergo stringent review both from the community and by independent 3rd parties. At this time, @koe is still working on the technical paper describing the protocol in its current iteration, which will need to undergo review in the future. Further, feedback on the core feature changes is still strongly encouraged and desired.
• Review PR's.

Who

I've identified and patched several privacy issues with varying severity in the Monero ecosystem:

1. The reference wallet's decoy selection algorithm didn't select very recent spendable outputs in some cases. (source)
2. The reference wallet truncated integers in the decoy selection algorithm, which would have borked the decoy selection algorithm entirely if tx volume were to increase; in the normal case, it marginally weakened the algorithm. (source)
3. openmonero was still using the old proven weak decoy selection algorithm, also leaving a fingerprintable trail by decoy selection algo. (source)
4. MyMonero didn't use the updated CLSAG fee calculation which fingerprinted MyMonero txs on chain by tx fee. (source)
5. MyMonero's fee calculation->input selection logic differed ever-so-slightly from the reference wallet, resulting in a fingerprintable tx fee. (source)
6. monero-lws fee masking on the server caused ever-so-slightly different fee calculations from the reference wallet, resulting in a fee fingerprintable to monero-lws (a fingerprint distinct from MyMonero). (source)
7. In PR review on the latest hard fork's changes to the tx fee, identified the introduction of slightly different fee calculation logic that would have caused tx fees to be fingerprintable to either old or new version until the hard fork.

Other contributions:

• Implemented view tags to speed up wallet scanning.
• Implemented background sync initially proposed by @hyc so that wallets can scan for transactions in the background when the user is not active, without the spend key loaded in memory.
• Identified and patched daemon reliability issues (moved forward solving issues 8520, 6631, 6929, and 6938):
  • Tor/i2p daemons periodically send a peer list that gets itself dropped.
  • The daemon periodically drops outgoing tor/i2p connections.
  • Tx re-relay math was off.
• Implemented the changes needed for Ledgers to function for the latest hard fork:
  • monero repo
  • ledger repo

Prior CCS proposals:

• https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
• https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
• https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html

Proposal

253 XMR. 480 hours, 0.16 XMR/hr + $48/hr, $131/XMR from coingecko.

I'm requesting a raise from my prior CCS because I feel I have continued to demonstrate my work is worth a competitive market rate.

j-berman full-time development (3 months)

by j-berman

November 21, 2022

253 XMR

53 contributors

Completed

What

Continue full-time another 3 months in a similar capacity:

• Prioritize debugging any significant issues that arise, such as daemon connection issues, zmq missing publishing txs submitted to the daemon, recovering multisig wallets from seed, etc.
• Complete work stress testing how daemons handle a transaction pool under heavy load to both gauge daemon performance, and to help get PR 8076 - reduce wallet round trips to the daemon across the finish line after gauging its impact on pool processing performance.
  • The day leading up to the hard fork this summer, the transaction pool experienced heavier load than usual. Daemons that saw heavy traffic reported issues serving RPC requests. I would like to dig deeper into this.
• Start working through Seraphis and Jamtis wallet tasks piecemeal, picking up collaboration with @koe, @rbrunner7, and @dangerousfreedom. The first task I've gotten a handle on and have a decently fleshed out view of what work is needed is input selection. I intend to get @koe's naive input selection implementation to production-ready, ensuring it functions as close to the wallet does today. From @koe here: "a real implementation needs many more mechanisms and heuristics (e.g. filter for dust threshold to ignore, filter for origin statuses to permit, randomization and spread to mitigate timing analysis)"
  • The general plan with Seraphis/Jamtis is to start fresh with new wallet code that avoids the complexity and pitfalls of wallet2.cpp, which at the moment is a source of growing technical debt (discussed a bit here). Considering Seraphis and Jamtis would bring a number of changes to core wallet features (a new address scheme, new balance recovery algorithm, new fee calculation, etc.), the proposed plan currently on the table is to start fresh rather than factor the existing wallet2.cpp. Many of the features that users already expect (such as sweeps, tx key recovery, watch-only wallets, etc.) would be maintained, or improved where possible. The implementation of some existing features is still up for discussion, such as accounts.
  • I'd like to reiterate this point: Seraphis and Jamtis still need to undergo stringent review both from the community and by independent 3rd parties. At this time, @koe is still working on the technical paper describing the protocol in its current iteration, which will need to undergo review in the future. Further, feedback on the core feature changes is still strongly encouraged and desired.
• Review PR's.

Who

I've identified and patched several privacy issues with varying severity in the Monero ecosystem:

1. The reference wallet's decoy selection algorithm didn't select very recent spendable outputs in some cases. (source)
2. The reference wallet truncated integers in the decoy selection algorithm, which would have borked the decoy selection algorithm entirely if tx volume were to increase; in the normal case, it marginally weakened the algorithm. (source)
3. openmonero was still using the old proven weak decoy selection algorithm, also leaving a fingerprintable trail by decoy selection algo. (source)
4. MyMonero didn't use the updated CLSAG fee calculation which fingerprinted MyMonero txs on chain by tx fee. (source)
5. MyMonero's fee calculation->input selection logic differed ever-so-slightly from the reference wallet, resulting in a fingerprintable tx fee. (source)
6. monero-lws fee masking on the server caused ever-so-slightly different fee calculations from the reference wallet, resulting in a fee fingerprintable to monero-lws (a fingerprint distinct from MyMonero). (source)
7. In PR review on the latest hard fork's changes to the tx fee, identified the introduction of slightly different fee calculation logic that would have caused tx fees to be fingerprintable to either old or new version until the hard fork.

Other contributions:

• Implemented view tags to speed up wallet scanning.
• Implemented background sync initially proposed by @hyc so that wallets can scan for transactions in the background when the user is not active, without the spend key loaded in memory.
• Identified and patched daemon reliability issues (moved forward solving issues 8520, 6631, 6929, and 6938):
  • Tor/i2p daemons periodically send a peer list that gets itself dropped.
  • The daemon periodically drops outgoing tor/i2p connections.
  • Tx re-relay math was off.
• Implemented the changes needed for Ledgers to function for the latest hard fork:
  • monero repo
  • ledger repo

Prior CCS proposals:

• https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
• https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
• https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html

Proposal

253 XMR. 480 hours, 0.16 XMR/hr + $48/hr, $131/XMR from coingecko.

I'm requesting a raise from my prior CCS because I feel I have continued to demonstrate my work is worth a competitive market rate.

j-berman full-time development (3 months)

by j-berman

July 18, 2022

187.5 XMR

27 contributors

Completed

What

Continue full-time another 3 months in a similar capacity:

• Prioritize debugging any significant issues that arise, such as daemon connection issues, zmq missing publishing txs submitted to the daemon, recovering multisig wallets from seed, etc.
• Complete work stress testing how daemons handle a transaction pool under heavy load to both gauge daemon performance, and to help get PR 8076 - reduce wallet round trips to the daemon across the finish line after gauging its impact on pool processing performance.
  • The day leading up to the hard fork this summer, the transaction pool experienced heavier load than usual. Daemons that saw heavy traffic reported issues serving RPC requests. I would like to dig deeper into this.
• Start working through Seraphis and Jamtis wallet tasks piecemeal, picking up collaboration with @koe, @rbrunner7, and @dangerousfreedom. The first task I've gotten a handle on and have a decently fleshed out view of what work is needed is input selection. I intend to get @koe's naive input selection implementation to production-ready, ensuring it functions as close to the wallet does today. From @koe here: "a real implementation needs many more mechanisms and heuristics (e.g. filter for dust threshold to ignore, filter for origin statuses to permit, randomization and spread to mitigate timing analysis)"
  • The general plan with Seraphis/Jamtis is to start fresh with new wallet code that avoids the complexity and pitfalls of wallet2.cpp, which at the moment is a source of growing technical debt (discussed a bit here). Considering Seraphis and Jamtis would bring a number of changes to core wallet features (a new address scheme, new balance recovery algorithm, new fee calculation, etc.), the proposed plan currently on the table is to start fresh rather than factor the existing wallet2.cpp. Many of the features that users already expect (such as sweeps, tx key recovery, watch-only wallets, etc.) would be maintained, or improved where possible. The implementation of some existing features is still up for discussion, such as accounts.
  • I'd like to reiterate this point: Seraphis and Jamtis still need to undergo stringent review both from the community and by independent 3rd parties. At this time, @koe is still working on the technical paper describing the protocol in its current iteration, which will need to undergo review in the future. Further, feedback on the core feature changes is still strongly encouraged and desired.
• Review PR's.

Who

I've identified and patched several privacy issues with varying severity in the Monero ecosystem:

1. The reference wallet's decoy selection algorithm didn't select very recent spendable outputs in some cases. (source)
2. The reference wallet truncated integers in the decoy selection algorithm, which would have borked the decoy selection algorithm entirely if tx volume were to increase; in the normal case, it marginally weakened the algorithm. (source)
3. openmonero was still using the old proven weak decoy selection algorithm, also leaving a fingerprintable trail by decoy selection algo. (source)
4. MyMonero didn't use the updated CLSAG fee calculation which fingerprinted MyMonero txs on chain by tx fee. (source)
5. MyMonero's fee calculation->input selection logic differed ever-so-slightly from the reference wallet, resulting in a fingerprintable tx fee. (source)
6. monero-lws fee masking on the server caused ever-so-slightly different fee calculations from the reference wallet, resulting in a fee fingerprintable to monero-lws (a fingerprint distinct from MyMonero). (source)
7. In PR review on the latest hard fork's changes to the tx fee, identified the introduction of slightly different fee calculation logic that would have caused tx fees to be fingerprintable to either old or new version until the hard fork.

Other contributions:

• Implemented view tags to speed up wallet scanning.
• Implemented background sync initially proposed by @hyc so that wallets can scan for transactions in the background when the user is not active, without the spend key loaded in memory.
• Identified and patched daemon reliability issues (moved forward solving issues 8520, 6631, 6929, and 6938):
  • Tor/i2p daemons periodically send a peer list that gets itself dropped.
  • The daemon periodically drops outgoing tor/i2p connections.
  • Tx re-relay math was off.
• Implemented the changes needed for Ledgers to function for the latest hard fork:
  • monero repo
  • ledger repo

Prior CCS proposals:

• https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
• https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
• https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html

Proposal

253 XMR. 480 hours, 0.16 XMR/hr + $48/hr, $131/XMR from coingecko.

I'm requesting a raise from my prior CCS because I feel I have continued to demonstrate my work is worth a competitive market rate.

j-berman full-time development (3 months)

by j-berman

February 7, 2022

135 XMR

50 contributors

Completed

What

Continue full-time another 3 months in a similar capacity:

• Prioritize debugging any significant issues that arise, such as daemon connection issues, zmq missing publishing txs submitted to the daemon, recovering multisig wallets from seed, etc.
• Complete work stress testing how daemons handle a transaction pool under heavy load to both gauge daemon performance, and to help get PR 8076 - reduce wallet round trips to the daemon across the finish line after gauging its impact on pool processing performance.
  • The day leading up to the hard fork this summer, the transaction pool experienced heavier load than usual. Daemons that saw heavy traffic reported issues serving RPC requests. I would like to dig deeper into this.
• Start working through Seraphis and Jamtis wallet tasks piecemeal, picking up collaboration with @koe, @rbrunner7, and @dangerousfreedom. The first task I've gotten a handle on and have a decently fleshed out view of what work is needed is input selection. I intend to get @koe's naive input selection implementation to production-ready, ensuring it functions as close to the wallet does today. From @koe here: "a real implementation needs many more mechanisms and heuristics (e.g. filter for dust threshold to ignore, filter for origin statuses to permit, randomization and spread to mitigate timing analysis)"
  • The general plan with Seraphis/Jamtis is to start fresh with new wallet code that avoids the complexity and pitfalls of wallet2.cpp, which at the moment is a source of growing technical debt (discussed a bit here). Considering Seraphis and Jamtis would bring a number of changes to core wallet features (a new address scheme, new balance recovery algorithm, new fee calculation, etc.), the proposed plan currently on the table is to start fresh rather than factor the existing wallet2.cpp. Many of the features that users already expect (such as sweeps, tx key recovery, watch-only wallets, etc.) would be maintained, or improved where possible. The implementation of some existing features is still up for discussion, such as accounts.
  • I'd like to reiterate this point: Seraphis and Jamtis still need to undergo stringent review both from the community and by independent 3rd parties. At this time, @koe is still working on the technical paper describing the protocol in its current iteration, which will need to undergo review in the future. Further, feedback on the core feature changes is still strongly encouraged and desired.
• Review PR's.

Who

I've identified and patched several privacy issues with varying severity in the Monero ecosystem:

1. The reference wallet's decoy selection algorithm didn't select very recent spendable outputs in some cases. (source)
2. The reference wallet truncated integers in the decoy selection algorithm, which would have borked the decoy selection algorithm entirely if tx volume were to increase; in the normal case, it marginally weakened the algorithm. (source)
3. openmonero was still using the old proven weak decoy selection algorithm, also leaving a fingerprintable trail by decoy selection algo. (source)
4. MyMonero didn't use the updated CLSAG fee calculation which fingerprinted MyMonero txs on chain by tx fee. (source)
5. MyMonero's fee calculation->input selection logic differed ever-so-slightly from the reference wallet, resulting in a fingerprintable tx fee. (source)
6. monero-lws fee masking on the server caused ever-so-slightly different fee calculations from the reference wallet, resulting in a fee fingerprintable to monero-lws (a fingerprint distinct from MyMonero). (source)
7. In PR review on the latest hard fork's changes to the tx fee, identified the introduction of slightly different fee calculation logic that would have caused tx fees to be fingerprintable to either old or new version until the hard fork.

Other contributions:

• Implemented view tags to speed up wallet scanning.
• Implemented background sync initially proposed by @hyc so that wallets can scan for transactions in the background when the user is not active, without the spend key loaded in memory.
• Identified and patched daemon reliability issues (moved forward solving issues 8520, 6631, 6929, and 6938):
  • Tor/i2p daemons periodically send a peer list that gets itself dropped.
  • The daemon periodically drops outgoing tor/i2p connections.
  • Tx re-relay math was off.
• Implemented the changes needed for Ledgers to function for the latest hard fork:
  • monero repo
  • ledger repo

Prior CCS proposals:

• https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
• https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
• https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html

Proposal

253 XMR. 480 hours, 0.16 XMR/hr + $48/hr, $131/XMR from coingecko.

I'm requesting a raise from my prior CCS because I feel I have continued to demonstrate my work is worth a competitive market rate.

j-berman full-time development (3 months)

by j-berman

August 30, 2021

78 XMR

69 contributors

Completed

What

Continue full-time another 3 months in a similar capacity:

• Prioritize debugging any significant issues that arise, such as daemon connection issues, zmq missing publishing txs submitted to the daemon, recovering multisig wallets from seed, etc.
• Complete work stress testing how daemons handle a transaction pool under heavy load to both gauge daemon performance, and to help get PR 8076 - reduce wallet round trips to the daemon across the finish line after gauging its impact on pool processing performance.
  • The day leading up to the hard fork this summer, the transaction pool experienced heavier load than usual. Daemons that saw heavy traffic reported issues serving RPC requests. I would like to dig deeper into this.
• Start working through Seraphis and Jamtis wallet tasks piecemeal, picking up collaboration with @koe, @rbrunner7, and @dangerousfreedom. The first task I've gotten a handle on and have a decently fleshed out view of what work is needed is input selection. I intend to get @koe's naive input selection implementation to production-ready, ensuring it functions as close to the wallet does today. From @koe here: "a real implementation needs many more mechanisms and heuristics (e.g. filter for dust threshold to ignore, filter for origin statuses to permit, randomization and spread to mitigate timing analysis)"
  • The general plan with Seraphis/Jamtis is to start fresh with new wallet code that avoids the complexity and pitfalls of wallet2.cpp, which at the moment is a source of growing technical debt (discussed a bit here). Considering Seraphis and Jamtis would bring a number of changes to core wallet features (a new address scheme, new balance recovery algorithm, new fee calculation, etc.), the proposed plan currently on the table is to start fresh rather than factor the existing wallet2.cpp. Many of the features that users already expect (such as sweeps, tx key recovery, watch-only wallets, etc.) would be maintained, or improved where possible. The implementation of some existing features is still up for discussion, such as accounts.
  • I'd like to reiterate this point: Seraphis and Jamtis still need to undergo stringent review both from the community and by independent 3rd parties. At this time, @koe is still working on the technical paper describing the protocol in its current iteration, which will need to undergo review in the future. Further, feedback on the core feature changes is still strongly encouraged and desired.
• Review PR's.

Who

I've identified and patched several privacy issues with varying severity in the Monero ecosystem:

1. The reference wallet's decoy selection algorithm didn't select very recent spendable outputs in some cases. (source)
2. The reference wallet truncated integers in the decoy selection algorithm, which would have borked the decoy selection algorithm entirely if tx volume were to increase; in the normal case, it marginally weakened the algorithm. (source)
3. openmonero was still using the old proven weak decoy selection algorithm, also leaving a fingerprintable trail by decoy selection algo. (source)
4. MyMonero didn't use the updated CLSAG fee calculation which fingerprinted MyMonero txs on chain by tx fee. (source)
5. MyMonero's fee calculation->input selection logic differed ever-so-slightly from the reference wallet, resulting in a fingerprintable tx fee. (source)
6. monero-lws fee masking on the server caused ever-so-slightly different fee calculations from the reference wallet, resulting in a fee fingerprintable to monero-lws (a fingerprint distinct from MyMonero). (source)
7. In PR review on the latest hard fork's changes to the tx fee, identified the introduction of slightly different fee calculation logic that would have caused tx fees to be fingerprintable to either old or new version until the hard fork.

Other contributions:

• Implemented view tags to speed up wallet scanning.
• Implemented background sync initially proposed by @hyc so that wallets can scan for transactions in the background when the user is not active, without the spend key loaded in memory.
• Identified and patched daemon reliability issues (moved forward solving issues 8520, 6631, 6929, and 6938):
  • Tor/i2p daemons periodically send a peer list that gets itself dropped.
  • The daemon periodically drops outgoing tor/i2p connections.
  • Tx re-relay math was off.
• Implemented the changes needed for Ledgers to function for the latest hard fork:
  • monero repo
  • ledger repo

Prior CCS proposals:

• https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
• https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
• https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html

Proposal

253 XMR. 480 hours, 0.16 XMR/hr + $48/hr, $131/XMR from coingecko.

I'm requesting a raise from my prior CCS because I feel I have continued to demonstrate my work is worth a competitive market rate.