06:37:19 <Maximxxx100> hello! can anyone help me with a monero-rpc-wallet problem? Set up daemon node with a rpc-wallet for the woocomerse wordpress plugin. everything is connected and seems to be working, but when people try to pay to the address they keep getting "address is invalid"
06:37:57 <Maximxxx100> for sub-addresses starting with 8
09:22:38 <dEBRUYNE> Maximxxx100: Have you verified the address already?
09:23:29 <dEBRUYNE> You can use, for instance, this site -> https://xmr.llcoins.net/addresstests.html
09:24:04 <Maximxxx100> yes, azy already tried it there, it's not valid
09:24:27 <azy> #monero
09:24:28 <Maximxxx100> here is an example of one of the addresses, 85FmGKEmkNwc3WyqjEynjgYrRSzAFboZ4M5ihpmQkeQ35ha9u3ZGXmvEhbQGDLFCfjW5r33xS12LU9aAJrgD4VLt2SQDnX
09:26:09 <dEBRUYNE> Let's continue in #monero
13:24:06 <sarang> Research meeting in #monero-research-lab today at 17:00 UTC
13:28:57 <woodser> is it possible to publish a second transaction which uses outputs from a first unpublished transaction?  Global output indices are not assigned until mining, so I think it is not possible.  If global output indices were changed to use tx hashes, could it be possible?
13:33:54 <woodser> this would be necessary to achieve a decentralized exchange like Bisq with a 2/2 multisig between the traders and an "emergency transaction" which transfers the 2/2 balance to moderators if there is a dispute
13:39:10 <woodser> also, testing that this thing is working?
14:17:17 <moneromooo> Your intuition is correct AFAIK.
14:18:49 <sarang> I happen to like the idea of using hash references to fixed ring sets (epochs)
14:18:55 <sarang> or at least partial hash references
14:19:37 <sarang> Since the shuffling operations needed to form them are deterministic, it's a good check that a node performed the shuffle correctly and has the same view of the chain as peers
14:27:09 <woodser> any way seen to construct a second tx using outputs of an unpublished first tx, such that if the first tx is published, the second can be too?  perhaps by switching to hash references or another method?
14:29:01 <sarang> Given hash references (and depending on how fixed ring sets are/aren't used), presumably nodes could establish rules on this
14:29:12 <sarang> However, this is affected by reorgs of course
14:29:26 <sarang> and would require adjustment to how locks are handled
14:32:53 <woodser> such an ability would permit a properly decentralized exchange with xmr base pair.  but both unpublished txs would need to remain valid including across re-orgs
14:46:52 <woodser> if txs remain valid across reorgs, that would negate much of the need for the 10 block lock as well ?
14:47:01 <woodser> depending if there were other privacy implications
14:49:49 <woodser> (we talked about that some time ago)
14:54:50 <woodser> it is problematic that perfectly good transactions can fail per the protocol, any way
14:56:08 <sarang> Well, it's a limitation that outputs referenced in any transaction must either be valid or discounted (and it's not possible in general to know if they're decoys or actual spends), and this depends on chain view
14:58:27 <woodser> i guess the issue would be if an output is only valid after published to the chain, where we need unpublished outputs to be valid for tx creation
14:59:08 <woodser> which transparent chains support
16:20:33 <sarang> Meeting in #monero-research-lab today at 17:00 UTC (about 40 minutes from now)
17:06:07 <Guest_79> hello
17:07:13 <Guest_79> how to plugin cryptocurriencies to my exchange platform?
18:22:57 <selsta> moneromooo: your CCS update includes "speedups in wallet and daemon sync", which PR is that?
18:28:04 <moneromooo> 6358
18:28:49 <selsta> ty, nice
21:18:45 <binaryFate> CLI binaries for v0.15.0.5 are online
21:38:02 <dEBRUYNE> Nice one! Do we have some release notes too?
21:38:30 <selsta> yes
21:39:06 <selsta> dEBRUYNE: can send you in 5 mins
21:39:39 <selsta> binaryFate: I think we messed something up
21:39:49 <binaryFate> what?
21:40:04 <selsta> we usually rename the binaries, sorry I didn’t think about this
21:40:17 <selsta> the archives
21:40:35 <selsta> monero-x86_64-unknown-freebsd-v0.15.0.5.tar.bz2  -> monero-freebsd-x64-v0.15.0.5.tar.bz2
21:40:53 <selsta> and others the same
21:41:35 <binaryFate> so I also need to resign hashes
21:41:47 <selsta> do you want to change it?
21:42:25 <binaryFate> yes, can you give me the list of A -> B changes?
21:42:32 <selsta> yep, will do
21:45:44 <selsta> binaryFate: https://paste.debian.net/hidden/5e89177a/
21:46:05 <binaryFate> great thanks
21:51:18 <dEBRUYNE> selsta: Thanks
21:51:36 <dEBRUYNE> Guess I will do the release thread tomorrow, as binaryFate has to perform the final tweak and resign the hashes
21:51:43 <selsta> dEBRUYNE: luigi1111: https://paste.debian.net/hidden/8c55604e/
21:51:46 <dEBRUYNE> ErCiccione[m]: Do you intend to create a blog entry on the website for the release
21:51:49 <dEBRUYNE> selsta: thanks
22:06:09 <binaryFate> Note that it's possible there's some caching issues again, with some people hitting redirects to old binaries instead of new ones
22:06:37 <selsta> until fluffy flushes CF?
22:06:37 <binaryFate> I'm not sure if that will happen. But after fluffypony flushes will be good for sure
22:06:40 <selsta> ok
22:07:43 <selsta> `curl https://web.getmonero.org/downloads/hashes.txt -s | shasum -c --ignore-missing`
22:07:48 <selsta> works well now :)
22:11:07 <binaryFate> great
22:15:24 <binaryFate> file names are fixed