what is the meaning here "CURRENT_TRANSACTION_VERSION < version) return false;"

To reject txes with unsupported format.

so v12 is not supported

Oh. I thought you had v12 blocks, not txes.

one of the reason that new chain cant start with v12

new chain will have txes too....

Presumably not v12 txes though ?

is strange because if i pas this line i still have error and gdb says taht cant access txes memory!

so txes are not v12 format

If you did not change it from monero, currnet txes are v2.

gdb saying can't access memory is either a bug (ie, stray pointer) or optimized code where gdb can't find the correct pointer value.

where to change v2 txes

In the tx serialization code (cryptonote_basic.h)

version = 1; this one line 185

or size_t version; to make size_t version = 12;

which line to change

i change size_t version = 12;

You have no idea what you're doing, are you.

i dont have knowledge of c++

You said you changed *block* version earlier. Block and txes are independent versioning.

yes

The size_t version is the tx version.

Block version is uint8_t major_version;

(IIRC)

i change it both so is ok

Unless you originally changed tx version thinking it was block version. In that case changing tx version checks will indeed fix it :)

Why do you need to change version anyway ?

for chain to start with v12

If you start your own chain, you can just make the changes you need to the tx structure, and keep hte version as is.

Ah, yes, nvm.

is not fork is new chain

from block 1

what changes except version i can do to the tx structure

Well, anything you like in the serialization code (the BEGIN_SERIALIZE chunk).

howdy, if someone's running RandomX mining on MacOS could you please shoot me a message - cheers in advance.

Hello, is this a place to ask a support question?

yes

testing IRC connection, hello Monero users

hey can anyone please point me to a guide on how to set up a full node on tails?

or a local node that is, I have a large enough drive for it.

anyone around tonight?

So how come p2pool for Monero isn't a thing? If you'd have multiple chains in parallel, it should work

Also I've come up with a convoluted way to sort of implement PPS. Each block you mine, instead of having an address to credit you to encoded directly, gives you a coin, and when you get this coin you must specify an address to send the reward to.

yanmaani: did you see youtu.be/-IE8rkSx__k ?

But anyone in posession of the coin can change this address. So you could 'sell' your reward for Monero by cross-chain atomic swaps.

selsta: no, will watch

what's it about? p2pool?

pools in general and also touches p2pool topic

P2pool starts at 12:20

recommend watching at 1.25x

Hmm, so a way you could do it is that miners bid on which transactions to include, and get the fees from them.

So if I have a set of 1000 transactions, I'll put them to the chain, and say that I'll give this amount of money to whoever mines them

and in return, I get whatever transaction fees above that

Or, you just violently sync the transaction pool.

So, whenever someone gets a transaction, you send it to all your friends. You define your friends based on whoever send you the txn first. Crucially, you don't ask first

so there's no round-trip delay, where you say "I have TXN X -> Yeah give me it -> OK here", just "Here is TXN X"

It's O(n^2) but as long as the nodes have gigabit internet it should be fine

Or, you somehow determine what the txn fees 'should' be, and require for blocks to send that back

I'd looked at adding minisketch for this, but it'll only be worth it once we get larger txpools.

It has to be scalable from the onset, I think

cause otherwise you're betting against your own success

moneromooo: Minisketch might improve it, but it doesn't solve the txn inclusion problem

So, if you're in p2pool, and you see a mini-block that also is a valid mainchain block that pays all the previous miners their share, is it valid?

Yes, as long as it's a valid block and all that.

But nothing prevents miners from picking transactions themselves, without involving the pool, and collecting fees out of band.

As long as txn selection isn't on-chain, that can't be helped.

One solution may be to have the sub-blocks include transactions, so that the mempool is on the chain. That's a very ugly solution, but it might work

And then the txns can be chosen deterministically

Because fundamentally, this is the like the transaction censorship problem: just as a miner can censor transactions (bad), they can also steal fees (bad). With a pool, we trust them not to censor transactions and not to steal. Since the latter is easy to prove, we don't often think about it.

But if we replace 'pool' with 'random people on the Internet', the problem becomes clear.

What is the txn inclusion problem ?

It's the one I decribed four minutes ago

How do you pick what transactions to include?

How do you make sure the miners in p2pool don't charge fees out of band and only take the block reward?

like "transaction accelerators" when btc was getting spammed?

asymptotically: Would those have required fees out of band?

If so, yes, those

You pick transactions are you see fit. The fees you add are whatever the txes pay. They only take the block reward because the block would be rejected otherwise. Other p2pool miners will likely also check consensus to avoid being DoSed.

They also check their own address is paid what they should before mining on a block they got.

Right, but this isn't incentive compatible

I'm a miner. I can either charge standard fees, and get maybe 1% of them or whatever the share ratio is (e.g. 100 shares per block)

Or I can charge zero fees, share 1% of zero, and take transactions out of band, and I won't have to share them.

I'm no longer incentivized to include the transactions with the highest fee in the block.

Because you only get 1% of them (if you have 1% of the p2pool miners' overall hash rate)?

Thus, it can't be up to miners which transactions to include. This has to be a consensus rule, so that it's deterministic given the blockchain at height H which transactions to include.

moneromooo: correct.

You also get 1% of the coinbase award.

whereas for standard miners, it's indifferent whether the fees are direct (in block) or indirect (out of band)

Sure, but the transaction fee auction completely breaks down

By "indirect", do you mean a p2pool miner will also mine other blocks with juicy txes on the side ?

A rational p2pool miner will mine p2pool blocks, but get their transactions out of band, and charge zero fees on chain.

Oh I think I see what you mean.

In fact, this would even be parasitic. They only have 1% exposure to the block reward, right?

So what's to prevent them from adding in 0-fee transactions that cost them 1% of the penalty, but they get paid say 50% of the rational fee?

That's a problem that also exists for non p2poo, isn't it ?

Sure, but there the pool is trusted.

Here it's just "random clowns on the Internet"

the pool won't transparently screw over their miners

I do not understand hte difference.

But it's easy! youtube.com/watch?v=RXJKdh1KZ0w

So, as I see it, there's two solutions

1) make txn selection a part of consensus

e.g. keep the mempool on the chain

2) make txn selection decided by the highest bidder

e.g. I pay 1 XMR for the privilege to select ALL the transactions in the block, I get ALL of the txn fees, and it's entirely opaque to the miners

moneromooo: So, if you're a pool, the situation is kind of the same

You only get 1% of the reward, but if you take fees out of band, those won't be distributede

e.g. if you mine 2 XMR reward + 1 XMR fees, then miners will come knocking for their share of 3 XMR, but if you only have a reward of 2 XMR, then they'll just want their share of 2 XMR

But! If a pool consistently has suspiciously low txn fees, then miners will just use another one.

i think you overestimate how much miners care (there are still people using minergate...)

also with the lack of adoption with things like stratum self select

Here's a practical example in how pools might screw miners over in this way: some pools do merged mining with Namecoin; the pool might just take that money and not give anything back

But! I have missed an important point which undermines my entire argument! Miners only stand to gain from this if they actually mine the winning block

Well, as long as it doesn't pretend otherwise.

So it's equivalent to solo mining, in a way

And it's trivial to fix

Instead of having payouts be determined like (submitted_shares/total_shares)*block_reward

determine them like (mined_notional/total_notional)*block_reward

This would mean that miners would again have no incentive to take the zero fee txns

since in expectation, it reduces their rewards by as much as if they'd have done it solo mining

(which is to say, ±0)

in other words, this was an idiotic objection and isn't actually a problem

So, p2pool miner Bob has low hash rate. If Alice sends a tx with that system (pay tiny fee in the tx, but separate extra payment to Bob), Bob has to mine it for it work. The tx can't be relayed to other p2pool miners. So it'll take quite a while to be mined.

Like, months, mossibly.

moneromooo: That depends on Bob's hash rate. If he has 1% of the hash rate, and there's a block every 10 minutes, then in expectation that should be 1000 minutes or 16.7 hours

Also, Alice could do this with multiple miners.

If P2Pool has 100 miners, she could tell each one that she'll pay them the txn fee out of band.

I just heard about this HTC Exodus 1S monero mining phone.

What do people think of this? More nodes on a network just secures the network more. Seems a gimmick though

latest dload Monero CLI OS X daemon won't connect

W Failed to connect to any of seed peers, continuing without seeds

I 0Connect failed to [ip]

I Failed to connect to any, trying seeds

Is this the first time you are using Monero?

on current device, yes

Which version of the CLI, 0.15.0.5?

Monero 'Carbon Chamaeleon' (v0.15.0.5-release)

yup

You temporarily need to tell it to connect to a peer, as all the seeds it knows about are down:

how would I go about doing that

--add-peer 88.198.163.90:18080

This should be a one off thing. Once it's found the network, it'll build its own peer list and won't need that option again.

There'll soon be more seeds around.

how would I enter that command? (sorry)

Add this at the end of your usual monerod command line.

eg, ./monerod --add-peer 88.198.163.90:18080

thank you!

moneromooo: you sure that all seed nodes are down?

No.

at least 3 are up

according to community.xmr.to/xmr-seed-nodes

Among the ones already in 0.15.0.5 ?

yep

Odd. Could be shitty network then.

johnnycash: could try running again without --add-peer, but with --log-level 2 until it connects, then paste the log to some pastebin ?

That might give us some clues.

88.198.163.90 is in the list of seeds already so adding it on command line should not make any difference no? networking issue probably

88.198.163.90 is only in master

but still think it is some network issue as the others should be good too

I'm trying to read "Zero to Monero". On page 25, it says that EdDSA verification goes like:

sent too soon, my mistake

johnnycash: does it work with --add-peer?

are you using mobile internet / some kind of VPN?

I'm trying to read "Zero to Monero". On page 25, it says that EdDSA verification goes like:

isn't 0)

UkoeHB_: ^

I remember vaguely we once discussed using DHT to bootstrap Monero

so, you take the BitTorrent DHT port, and you generate random IPs. You then send out say 10k handshakes, and checks who responds.

And then from that, you can build nodes in the BitTorrent DHT network, and from that you can find Monero nodes

Was there any flaw with this?

Still think it is over engineered.

sweeper_mate: what's your question? Also the second edition is available web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf

well it's not too complex

although it's a bit goofy

but generally, sending out a bunch of udp packets, listening on a port, and then handing the IPs over to a library isn't tremendously hard

Is there any more particular place where discussion about codesign'ing the monero*.app for macOS would be preferred ?

curious if its in the plans to codesign the releases 

currently I do this myself after verifying the integrity of the binaries.

JtH: you codesign the .app ?

I would like to at least notarize the mac monero GUI

but I didn’t fully figure out how to do this yet

re discussion: github.com/monero-project/monero-gui issue tracker

yes I do. its pretty simple. let me grab the link I originally followed a couple years ago. Essentially you grab your cert from xcode, Add it to the system trust then you can "codesign -vfs 'U69YFA4G66' *.app"

so we would need a monero apple id?

e.g. U69YFA4G6 is my dev cert issued by apple

correct

ok, I think fluffy has one

can you post the exact command? and is there a difference between code sign and notarize?

I know the personal ones are free and issued by apple

unsure about "Group Keys"

yes. codesign'ing is essentially locking it down with the syst4m so the policies can/ or won't allow it to communicate or run depending

but yes looking for the link now

hello, i am unable to run monero-client-cli on my debian anymore

monero-wallet-cli

bb_runion: can you try github.com/monero-project/monero/releases/tag/v0.15.0.1 ?

i'll try it

selsta, essentially its this in reply #2 stackoverflow.com/questions/5269966…ve-codesign-to-enable-debugging-gdb

except instead of generating your own x509 you'll export your certificate directly from the XCode.app

nice, seems to work

how can I check if I signed it correctly?

under Settings >>> Account >>> Manage Certificates >> Right Click on the cert you want and export

(codesign -vvv ${OBJECT} )

okay, one more question, I signed it with my private apple id

if I share the file can others see my apple id?

codesign -dvvv gives more information

thats correct

okay, and if others download the gui

it'd help me out quite considerably having the gui signed. Policies for some of the macOS env are restritive and won't allow it to open.

does it still say unrecognised developer?

or is code signing the same as notarization

yes whatever your app was signed with will remain with it

assuming notary is the same as mac's CSC then yes.

looks like notarization requires code signing first

but I’m one step closer with this, thanks :D

anyone using xmrig-proxy?

your' welcome!

selsta, not such file or directory, when i try to run binary. Wrong architectore maybe (linux 32 bit)

selsta, im guessing here but, assuming you are involved with releases ;)

is it possible to use: xmrig-proxy --> xmrig-proxy -->pool

scanned: try #monero-pools

okay thanks

JtH: I’m a bit involved with releases

k googd that makes me feel better that we'll see it signed at some point ;)

and thanks for taking all that up

yep, will have to ask fluffy for the monero apple id and then I can experiment more :)

funny how when ya first start looking into codesign'ing stuff that its all so elusive

the problem is we don’t use xcode which means even less good documentation

yep that's esesentially where I was at about 3 years ago.

until apple started enorcing it for built in applications or policies that enforced only identified developers

had to learn real quick like

workflows with our devs changed drasticly

problem is also we can’t really sign CLI release because it does not play well together with reproducible builds

but GUI is not reproducible yet so we can sign it

while it'd be nice for the CLI its not neccesarily called for since it doesn't directly interact with the desktop. In this instance its easy to just permit the cli app to allow netwmork connectivity etc..

alot of times people are using Term.app or iTerm2.app in which they already permitted certain access and then everything run within just follows

i'm not sure who manages repo.getmonero.org but I'm unable to get a confirmation email from it

I get to this page but the email never arrives repo.getmonero.org/users/almost_there

netrik182[m], ? no script blocker or similiar ? ... all browsers used ? etc etc. .. ?

let me check

moneromooo: A problem with this p2pool idea is that it's also very vulnerable

sometimes just activating private mode will solve that to. Given this is github it would lean me to believe this is a client side problem.

if you pay out based on notional amount, then miners can make transactions with obscenely large fees, and only include them in their own blocks

netrik182[m]: I see a login from an account that matches your name.

i'm logged in, yes. It's that I changed my email

selsta, v0.15.0.1 works, i will now try to make transfer, thank you.

bb_runion: okay, the next release should work again

just skip v0.15.0.5

JtH moneromooo I just tested with a fresh FF profile w/o addons or custom settings

I found logs about this, and AFAICT the email was delivered. Maybe stuck in a spool file somewhere on the way.

yanmaani: and this opens what kind of vulnerability ?

Well, miners can do parasitic mining: they submit shares, but if they happen to solve a block they don't get anything.

moneromooo: thanks for checking. I'll wait some more days idk and get back here if needed

That said, they have to expose their transaction with obscene fees to the network

to collect the fees

so it maybe is not such a great deal

Feel free to write those things up precisely if you want them remembered. A github issue even maybe.

although if they're fast, they could perhaps do some sort of race condition

Well, the idea is that I discuss it with people on IRC, precisely so that if they do happen to be stupid, I don't have to remember them :)

(and if they are, I'll just go through the logs and rewrite them from there)

Sure, that works.

So, the attack I see is, if they have a winning block, they can create a transaction that relies on the winning block not existing (e.g. put a txn in the mempool which, if committed, would make it invalid)

and that spends say 100 XBT in fees

so, whenever they have found the winning block that spends some output they control, they create a transaction that spends the 100 XBT in fees, and solve a share for it

so if they have 1% of hashrate, they get 1% of the 100 XBT in fees

they then instantly send the block, causing the 100 XBT in fees to get invalidated

Unless the miners are going to start 51% attacking of course

seems a pretty minimal impact

e.g. hard to achieve

Well it's 1 XBT that they've managed to steal

You'd need to do tricky race condition stuff to trigger it, sure

but the general cost is not bad. You'll get paid for all your mining still, and you can submit the useless shares to p2pool to get paid for them

yeah not that any should be lost period but on a large scale it could grow. the race condition though ... the type of race condition would be pretty hard to achieve.

got a PoC ?

no, I don't have a mining facility

you'd need to create a bunch of outputs, and then start mining a block which spends one of them in secret. Any shares which aren't solutions, you put to the pool.

So far, you're just a normal miner, getting paid normal money for normal work

At one point, you'll find a block. You avoid broadcasting this, and instead start mining on the fee block. That fee spends the transaction with the obscene fee.

that block*

If you actually find a full block, you discard it

hmm

But the shares, you gather and submit

The ideal thing ought to be to mine until you have two shares, and then submit them at once, immediately followed by the block

So you'll get the fees for 2 shares' worth of XBT 110 notional reward, while being ~100% certain that this reward can't ever be collected

The crucial bit is this: As long as you don't find a block, you don't take any risks. The attack only begins after you've found a complete block.

what do you get by running monero node ?

increased privacy for yourself

you get to own monero

synaps3, if you don't run your own node then you are trusting someone else to verify all tx history and proof of work for you

which is most likely fine

you also lose some privacy using a remote node also when sending txs

In the same way than not being in jail means you don't rely on someone else to feed you. Which is most likely fine.

what, thin nodes don't verify PoW??

Nodes verify PoW. They're on about wallets.

Well, nodes verify PoW, but have a default fast mode where they rely on builtin hashes.

Well, you can run the monero-gui wallet with a remote node

Surely that verifies PoW?

The wallet ? No.

The *daemon* verifies the PoW.

Even if the daemon connects to a remote node?

If it's your daemon you connected to, you just shot yourself in the face.

Yes.

You are not supposed to connect to a stranger's yucky node.

Why not run your wallet on Amazon too.

Or use a VPN owned by facebook.

Because I don't have sufficient space to store the chain

That is your problem.

This is absurd - Electrum doesn't require you to store the chain

and does not have these problems

Then use that.

how come Monero wallet can't verify PoW?

Is it harder somehow?

It can. RUN THE FUCKING NODEl

Yeah but a thin wallet. Why are you so opposed to thin wallets? There's no other serious way to run Monero on mobile devices

you could connect to your own node on mobile

or connect to several remote nodes that you don't control and verify chains are the same

or that the one you connect to matches with several explorers or mining pools

jwinterm: The second suggestion is very sensible

or just say fuck it and trust any random remote node like I do

:P

You connect to N different nodes, ask them for the hash at height H, and make sure they're the same

not like I am holding much xmr on my phone anyway

You know what this sounds like?

A job that a computer should do! Querying servers from a list, getting back some data, and running strcmp()! It's the epitome of computer-friendly human-unfriendly business

But seriously now, is there any technical reason for why the daemon can't verify PoW if you use a remote node?

the daemon is the node

the wallet connects to a single daemon that is uses as a remote node

I mean if you use a random remote node on the internet

I think maybe one or two of the mobile wallets do verify that any remote node they list is in agreement with the others

not sure tho

In the desktop wallet, unless I've misunderstood, you can only even use one wallet

There is basically no reason to not run your own node. With pruning it only requires 27GB space and it can even run it on a raspberry.

no I think you've misunderstood

yanmaani, you don't know what the other nodes are verifying unless it's your node, so you can't trust it

only ever use one node*

selsta: I don't have 27gb of space, I use a bargain-bin laptop

well, you're supposed to use your node

tryphe: I can verify the PoW for myself.

I don't know how remote nodes are populated to choose from there

jwinterm: Right, but this is the case in Bitcoin as well. It's still possible to use Electrum, and it's not like people lose all their money doing so.

There is not Electrum like system with Monero yet.

selsta: Is it possible?

I don’t know.

they didn't lose all their money, just a bunch

is there any technological obstacle?

yea there have been some electrum mishaps for sure

yanmaani: see e.g. monero-project/research-lab #69

tryphe: has there ever in the history of mankind been a single person who has lost money from using Electrum?

yanmaani, a ton more than monero-wallet-cli or bitcoin-cli

how can i help with hosting .onion service

tryphe, jwinterm: Can you name one

yanmaani, i don't really know of any bugs where the monero or bitcoin wallets caused people to lose money, they just did silly things to lose it. otoh, electrum is historically full of silly bugs allowing coin theft

although, maybe from user stupidity as well, but easier to fall for

yea, it was more from the software allowing malicious nodes to push a software update

but it was electrum and people lost a lot of money

selsta: right, so what's what I was looking for

tryphe: Can you name one case?

yanmaani, sure, arbitrary popups with rich text

synaps3: What, just hosting in general? Install tor and edit /etc/tor/torrc

That's not due to it being a thin client though

no, it's due to being shit software

and nobody should use it

web.getmonero.org/resources/roadmap i saw that onion service is in plan, so im interested in how to help

use windows 95 if you want, i won't stop you

Well, it's written in Python, but I do submit it looks far nicer than Bitcoin Core.

tryphe: you can ask in #monero-site but I think no help is required

I don't get why you don't just pay the $3k arbitration fee to get monero.org

yanmaani, looks can be deceiving :)

But the architecture is sound?

Cause I've heard a lot about SPV being dangerous, but in practice it seems to be entirely flawless

Hmm, so back in 2015 Monero owned d/monero

monero.bit, I mean

the Namecoin domai

n

but since then it's changed hands several times