07:23:03 <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?
08:03:23 <Inge-> can you stuff something into op_return?
08:03:37 <Inge-> isn't the bitcoin way to just create a new address ?
08:03:52 <Inge-> and you can do the same with Monero by providing a subaddress per customer
08:07:02 <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?
08:07:44 <Inge-> I'll take a
08:07:57 <Inge-> wild guess and ponder if something like btcpayserver manages that for you
08:08:45 <spirobel[m]> <Inge- "wild guess and ponder if somethi"> but i want to integrate the wallet with discourse (forum software) meta.discourse.org
08:09:01 <spirobel[m]> so i dont want to include this giant btcpayserver thing
08:09:22 <spirobel[m]> monero seems much better at handling this with integrated addresses
08:09:47 <Inge-> just be sure to use the short one
08:11:09 <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?
08:11:12 <spirobel[m]> source: https://monerodocs.org/public-address/integrated-address/
08:20:01 <Inge-> yeah
08:21:18 <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
08:23:02 <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.
08:26:33 <Inge-> ah ok
08:26:53 <Inge-> what documentation are you reading?
08:27:25 <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
08:28:39 <spirobel[m]> <Inge- "what documentation are you readi"> this: https://monerodocs.org/public-address/integrated-address/
08:28:55 <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).
08:29:12 <spirobel[m]> that integreated addresses are exactly for this usecase
08:29:35 <spirobel[m]> business bros with an online shop
08:30:04 <spirobel[m]> consumer peasants can use the subaddresses 😼
08:31:17 <azy> you should allow Monero software to generate integrated addresses for you (instead of forcing your own payment IDs).
08:31:20 <azy> i wonder why that is
08:31:51 <spirobel[m]> <azy "i wonder why that is"> because you will probably mess up the code
08:32:50 <azy> more likely to use deadbeef and other nonrandom ids i suppose?
08:33:42 <spirobel[m]> <azy "more likely to use deadbeef and "> or something other big brained things i guess - when people get creative they get creative 😀
14:55:14 <mechanimist[m]> I see this in my monerod log sometimes:
14:55:14 <mechanimist[m]> `E Transaction spends at least one output which is too young`
14:56:12 <mechanimist[m]> Does it mean the spender has a faulty wallet, or can it happen with with one of the "standard" wallets?
14:56:25 <mechanimist[m]> Also, what ends up happening to these transactions? Does the network reject them?
14:59:22 <sethsimmons> That's a sign that your daemon is properly rejecting them.
14:59:37 <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.
15:00:00 <mechanimist[m]> hmm makes sense, ty