-
spirobel[m]
i recently started to learn about monero and I came across the concept of integrated addresses. It makes it very convenient for merchants to accept monero and integrate it into an online shop. Am I stupid or is there nothing similar in the bitcoin world?
-
Inge-
can you stuff something into op_return?
-
Inge-
isn't the bitcoin way to just create a new address ?
-
Inge-
and you can do the same with Monero by providing a subaddress per customer
-
spirobel[m]
<Inge- "isn't the bitcoin way to just cr"> yaas i know....but it seems like way more complicated to implement. Also you need to watch all these addresses for transactions which you dont need to with integrated addresses. so it seems like if i want to achieve the same thing with btc that integrated addresses do for me with monero, its much more hassle to implement. true?
-
Inge-
I'll take a
-
Inge-
wild guess and ponder if something like btcpayserver manages that for you
-
spirobel[m]
<Inge- "wild guess and ponder if somethi"> but i want to integrate the wallet with discourse (forum software) meta.discourse.org
-
spirobel[m]
so i dont want to include this giant btcpayserver thing
-
spirobel[m]
monero seems much better at handling this with integrated addresses
-
Inge-
just be sure to use the short one
-
spirobel[m]
<Inge- "just be sure to use the short on"> `Monero integrated address obsoletes the former practice of using full 32-bytes payment ID in a transaction extra field (where it was not encrypted).` you refer to this?
-
spirobel[m]
-
Inge-
yeah
-
Inge-
I'm still not quite sure where the community is on the short form payment id - I don't think there are any plans to deprecate it, but at the same time there seems to be a recommendation to use subadresses instead
-
spirobel[m]
<Inge- "I'm still not quite sure where t"> what? i just read the docs and it seems like they recommend integrated addresses over subaddresses for this kind of use case and even say old extra payment id shouldnt be used.
-
Inge-
ah ok
-
Inge-
what documentation are you reading?
-
spirobel[m]
the amazing part is: there is no need to generate new addresses. just a new random number and the ux is the same to normal addresses
-
spirobel[m]
<Inge- "what documentation are you readi"> this:
monerodocs.org/public-address/integrated-address
-
spirobel[m]
here they clearly say: As individual running a wallet you should generally prefer subaddresses. However, if you happen to use integrated addresses, you should allow Monero software to generate integrated addresses for you (instead of forcing your own payment IDs).
-
spirobel[m]
that integreated addresses are exactly for this usecase
-
spirobel[m]
business bros with an online shop
-
spirobel[m]
consumer peasants can use the subaddresses ๐ผ
-
azy
you should allow Monero software to generate integrated addresses for you (instead of forcing your own payment IDs).
-
azy
i wonder why that is
-
spirobel[m]
<azy "i wonder why that is"> because you will probably mess up the code
-
azy
more likely to use deadbeef and other nonrandom ids i suppose?
-
spirobel[m]
<azy "more likely to use deadbeef and "> or something other big brained things i guess - when people get creative they get creative ๐
-
mechanimist[m]
I see this in my monerod log sometimes:
-
mechanimist[m]
`E Transaction spends at least one output which is too young`
-
mechanimist[m]
Does it mean the spender has a faulty wallet, or can it happen with with one of the "standard" wallets?
-
mechanimist[m]
Also, what ends up happening to these transactions? Does the network reject them?
-
sethsimmons
That's a sign that your daemon is properly rejecting them.
-
sethsimmons
<mechanimist[m] "Does it mean the spender has a f"> I'm not sure on this -- I would expect this is only possible with a non-standard wallet that has not properly implemented the output lock-times, but I could be wrong.
-
mechanimist[m]
hmm makes sense, ty