hello y'all

is everyone aware of the petition to add XMR to proton's payment systems? general manager of proton vpn said they'll add support to their summer roadmap if 1000 people sign the petition

(i really hope there are no rules against urls here)

<x​3cc:nope.chat> Thanks you remind me to check me email to confirm my vote

<l​oeasy68:matrix.org> Hi everyone! Does anyone have the link for the official monero space?

<l​oeasy68:matrix.org> Actually I've found it, Sorry!

<a​pecks:matrix.org> kyun

<a​pecks:matrix.org> wow, client doesnt even have a search function

test

oh nice my client is working

<a​shven:matrix.org> Can someone send me the link for the other node implementation

<a​shven:matrix.org> I forgot its name it was in test before

<a​shven:matrix.org> I want to stop monerod and try it

<a​shven:matrix.org> I remember now Cuprate

<a​shven:matrix.org> Can it be mined on and used with feather wallet

<3​21bob321:monero.social> github.com/Cuprate/cuprate

<3​21bob321:monero.social> WIP

<a​shven:matrix.org> I can’t use Cuprate to connect to my p2pool instance to be mind via XMRig?

<a​shven:matrix.org> This is very important imo as this is the only implementation that is not under core

<o​frnxmr:xmr.mx> correct

<o​frnxmr:xmr.mx> ?

<p​lowsof:matrix.org> because bitcoin core bad

<n​eromonero1024:monero.social> Is the private tx key deterministically generated (such that when restoring wallet from seed, the private tx key can be recovered given the recipient address)?

Private tx key is random when a wallet creates a transaction

<system> file image.png too big to download (3465960 > allowed size: 1000000)

<1​7lifers:matrix.org> image.png

<1​7lifers:matrix.org> average xmr miner #5

<1​7lifers:matrix.org> enjoying their unregulated residence ^_^

<j​effro256:monero.social> It *could* be deterministically generated, there is nothing stopping it from doing so, but it isn't with the reference wallet

<j​effro256:monero.social> There's the privacy trade-off that if someone got a hold of your seed phrase, they'd be able to see outgoing transactions to other addresses, whereas they can't do that now

<a​shven:matrix.org> I understand that different team is working on this node implementation. I said this is very important because more node implementation = more decentralization at the code level more teams to focus on different things. I wish we have at least 4-5 different nodes implementation

<a​shven:matrix.org> Not just Monero core team

<o​frnxmr:xmr.mx> I don't

<o​frnxmr:xmr.mx> Monero core team doesnr develop a damn thing

<a​shven:matrix.org> Who maintains that main node implementation?

<a​shven:matrix.org> I thought its Monero core

<o​frnxmr:xmr.mx> community

<o​frnxmr:xmr.mx> the same devs that work on cuprated, also help with monerod. The main difference is languages

<o​frnxmr:xmr.mx> One is rust, one is c++

<a​shven:matrix.org> Who is the community funding to maintain this ?

<o​frnxmr:xmr.mx> CCS funds cuprate and monerod

this = ?

<a​shven:matrix.org> I get you know so not different team

<o​frnxmr:xmr.mx> This = monerod, i think

3 devs are funded specifically for cuprate

<a​shven:matrix.org> Most nodes in decentralized crypto project are funded by CF

<o​frnxmr:xmr.mx> But either way, both projects are funded via ccs.getmonero.org

<o​frnxmr:xmr.mx> I wouldnt say specifically.

<o​frnxmr:xmr.mx> hinto's ccs includes fcmp implementation work, boog reviews and helps design monerod work, as well as vuln finding and reporting

<a​shven:matrix.org> Regardless this is always the case in decentralized project. But there is always anon maintainers and contributors team who request funds via ccs or volunteer to do the job

<a​shven:matrix.org> Like Selsta

<o​frnxmr:xmr.mx> What about selsta?

<a​shven:matrix.org> I am making a point of example

<a​shven:matrix.org> .

<o​frnxmr:xmr.mx> Example of what, is what im asking

4-5 node implementations seems unrealistic, i don't think even bitcoin has that

<a​shven:matrix.org> That even though things done via CCS there is always so one who do stuff

<a​shven:matrix.org> Team, contributors, or 2-3 devs etc..

<a​shven:matrix.org> Bch has that but regardless once Monero gets bigger it should be

<o​frnxmr:xmr.mx> Even bitcoin knots has a whole 1 person running the entire thing

<a​shven:matrix.org> Alternative node implementations protect Monero’s independence. Alternative teams resist social capture, alternative codebases resist protocol capture.

<o​frnxmr:xmr.mx> Like 98% of all commits are from luke dash jr. Hardly decentralized

<a​shven:matrix.org> I wouldn't say Bitcoin is a good example of many node implementation

<a​shven:matrix.org> But the idea it self still valid

<a​shven:matrix.org> I am basing based on this

<o​frnxmr:xmr.mx> bitcoin cash isnt either. Probably every implementation is understaffed and buggy, due to fragmentation

<o​frnxmr:xmr.mx> They dont resist social capture. Blockstream captured btc core. Instead of resisting, they created bible knots implementation

<a​shven:matrix.org> Wouldn't say that because each implementation has strength in very niche specific area where whales internetsted on this area fund it very heavily

<a​shven:matrix.org> Because that's after the fact

<o​frnxmr:xmr.mx> the only impl that matters, is the one that miners use.

<a​shven:matrix.org> If Bitcoin had many node distributed between miners and users that would be another story

<o​frnxmr:xmr.mx> Yeah, it would be unreliable af

<o​frnxmr:xmr.mx> you might send a tx that 8/10 miners wont confirm

<a​shven:matrix.org> I would disagree actually

the evil core team forced monero nodes to not relay mordinals and zero fee transactions

<a​shven:matrix.org> Based on wait each node would have same consensus rules

<a​shven:matrix.org> Based on what each node would have same consensus rules

<o​frnxmr:xmr.mx> So you think it would be a good idea is 80% of miners didnt accept segwit or rbf, but 100% of wallets used those?

currently alternate implementations help to find bugs that would mainly effect the nodes ability to stay online under load, rather than 'the evil core team have forced something'

are you suggesting that ashven?

<a​shven:matrix.org> The thing is that pools did the job and miners accepted nothing ever happen without miner approval UAF is a myth

<o​frnxmr:xmr.mx> Or if wallets allowed 0 fee transactions, but 9/10 miners require 0.001 btc/vkb minimum fee, but wallets allow 0.00001?

<a​shven:matrix.org> New York agreement?

<o​frnxmr:xmr.mx> Its not a myth. Miners (and pools) mine whatever they want.

<a​shven:matrix.org> Yeah not only that but specializing in a specific niche also is a great way like feature or APIs

<o​frnxmr:xmr.mx> Your tx is written to the blockchain aka confirmed by miners. Not by hope and dreams

<a​shven:matrix.org> I didn't disagree do you know what UAF mean?

<a​shven:matrix.org> I said UAF is the myth

<o​frnxmr:xmr.mx> oh, what is UAF

<a​shven:matrix.org> User activated fork mean a fork by non mining node with no hashing power like core lied

<a​shven:matrix.org> That's fantasy

<a​shven:matrix.org> And a myth

<a​shven:matrix.org> antpool just said yes to the SegWit just because they didn't want to look like the bad guy after core threatened to active it via UASF but that's a myth we know now

<a​shven:matrix.org> If antpool stick to their position we wouldn't see rbf and SegWit today

<a​shven:matrix.org> Hence after new York agreement the block size war begin

<a​shven:matrix.org> BTC won segwit is because antminer company allowed them to after the promises to increase the block to 2MB. they didn't want to be seen as the bad guy after all. yet they didn't deliver on their promises leading to BCH fork.

<a​shven:matrix.org> I would argue that people back then were willing for compromises they already accepted the compromises just to get only 2MB bigger block. And avoid splitting the network. Newyork agreement and HongKong were circuses

<a​shven:matrix.org> Monero solved this drama by implementing dynamic block size from the beginning like Satoshi anticipated the future would look like

<a​shven:matrix.org> I would argue bch took the idea from Monero

<o​frnxmr:xmr.mx> Oh, yeah, we agree here

<a​shven:matrix.org> Maybe I didn't deliver the right expressive words 💬 sorry

someone knows if `get_transfers` shows transactions with 0 height if using `filter_by_height` ?

if min_height is more than 0, there will be no mempool transactions in list?

do you have a testnet address to try?

pls share

idk how to use testnet, I sent on mainnet but it confirmed too quick multiple times xD

it's alright I guess I will just try 2 variants myself with and without filter and find out

run monero-wallet-cli with "--testnet" flag , and monero-wallet-rpc with --testnet flag too, thats the only difference, other than the coins being free to test with

if it works as described here then what you say is correct docs.getmonero.org/rpc-library/wallet-rpc/#get_transfers

Has anyone been able to install Cake wallet on Linux?

Compile instructions are missing, and it doesn't exist in Flathub.

<p​lowsof:matrix.org> is this it? github.com/cake-tech/cake_wallet/bl…b/workflows/pr_test_build_linux.yml

<r​avfx:xmr.mx> Cryptocurrencies adopt the "X" prefix in their ticker symbols to align with the ISO 4217 international currency code standard. This signifies their status as non-sovereign or supranational currencies, meaning they are not issued or controlled by any single country.

<o​frnxmr:xmr.mx> xau xag xmr

<o​frnxmr:xmr.mx> Btc switched from xbt to btc because its not a currency 👾

finally figured out that thing I asked about, if I set `pool: true` and can see incoming mempool transactions and also use `filter_by_height` simultaneously, monero-wallet-rpc is great 😊