-
jeffro256[m]
.merges
-
xmr-pr
8736
-
ypavtv97lx[m]
-
selsta
ypavtv97lx[m]: yes, will link it
-
ypavtv97lx[m]
thanks!
-
selsta
8677/8678
-
selsta
the RandomX integration in monero not RandomX itself
-
ypavtv97lx[m]
oh kk
-
ghostway[m]
Question, when I send someone some monero, I can't know if they spent it because I can't calculate the key image, but I can see if they were used with a ring signature right?
-
ghostway[m]
Because the one time key is still included in the ring
-
ghostway[m]
* the ring (possibly not by them)
-
UkoeHB
ghostway[m]: yes
-
dEBRUYNE
ghostway[m]: Yes
-
ghostway[m]
Cool
-
someoneelse49549
Could someone explain to me the purpose of the get_blocks_from() function in blockchainDB. I don't get how flexible this function is nor why it isn't even use, except for one assert?
-
moneromooo
faster fetching of consecutive txes
-
someoneelse49549
i understand no
-
someoneelse49549
* i understand now
-
selsta
.merge+ 8737 8738
-
xmr-pr
Added
-
sgp[m]
Hey, weird question/observation. I'm using an alpha test build of Cake Wallet, and I was able to observe the following:
-
sgp[m]
I asked ofrnxmr to send me XMR with a 20 block lock. He did in tx `a8c3c7828eac61bfc228d894378e8417330e181b3a15a88770ccf0d6ede6b0f2`
-
sgp[m]
I waited 10 blocks, then I attempted to spend the funds before the 20 block lock time expired. I appear to have been able to do so in tx `d777250fcba14ad70fb4b656c2a5b584f6926b5ce90051b405794c7f56532487`
-
sgp[m]
Do you have any idea how this is possible? The wallet was fresh and is only associated with those 2 transactions.
-
sgp[m]
-
sgp[m]
ahhhh, 20 is the absolutely block height isn't it. So it's spendable after block height 20, which it's well past then ofc
-
selsta
"unlock_time": 0,
-
selsta
it isn't locked
-
sgp[m]
s/absolutely/absolute/, s//`/, s/,/`,/
-
Rucknium[m]
-
sgp[m]
the first transaction was unlock_time:20
-
sgp[m]
okay so 20 blockheight not additional block
-
sgp[m]
s/block/blocks/
-
sgp[m]
sorry, I knew this, just got caught up in the moment while testing
-
selsta
I checked the wrong txid but what you said should explain it
-
sgp[m]
thanks, all solved now
-
ghostway[m]
Another question, with ristretto points. Why are prime order groups harder to implement algorithms for?
-
ofrnxmr[m]
🫡 ofrnxmr didnt know how to lock funds
-
ofrnxmr[m]
#RTFM
-
ofrnxmr[m]
To be fair, I was mislead
-
ofrnxmr[m]
```
-
ofrnxmr[m]
unlock_time - unsigned int; Number of blocks before the monero can be spent (0 to not add a lock).
-
ofrnxmr[m]
```
-
smathy[m]
That can still mean an absolute block.
-
smathy[m]
(not like it said "number of blocks from now"...)
-
ofrnxmr[m]
Yeah, I read it as "number if blocks before the Monero can be spent", ignored the unsigned int part.
-
ofrnxmr[m]
An easier way to describe it would be "Height to unlock"
-
selsta
.merge+ 8720 8721
-
xmr-pr
Added
-
selsta
if anyone runs a seed node please check
monero-project/monero #8720, I have removed the ones that are offline
-
selsta
if the node can be brought back online I'll re-add the IP
-
jeffro256[m]
> Another question, with ristretto points. Why are prime order groups harder to implement algorithms for?
-
jeffro256[m]
They both have different challenges. When the number of possible elliptic curve points is not prime (e.g. Curve25519), you have to constantly worry about sanitizing curve points that are not in the correct subgroup, hence the existence of Ristretto. When you do not use prime subgroups (e.g. secp256k1 in BTC) you have to worry more about Pohlig–Hellman algorithm attacks