01:15:57 .merge+ 6770 01:15:57 Added 01:44:29 .merge+ 6600 01:44:29 Added 01:45:21 Yaaay 08:01:39 .merges 08:01:39 -xmr-pr- 6600 6770 15:40:46 "embargo" in dandelion is the timestamp at which a stem tx becomes "fluffable", right ? 18:16:15 -xmr-pr- xiphon opened pull request #6789: net: fix get_tcp_endpoint, boost address_v4 ip in host byte order 18:16:15 -xmr-pr- > https://github.com/monero-project/monero/pull/6789 18:18:16 yeah, mostly. embargo is the per-node timeout that triggers a "fluff". It is "canceled" if the node sees the tx fluff before the timeout is reached (reach end-of-stem phase or another embargo timeout expired first) 18:19:08 there is no coordination, its selected randomly by each node that correctly forwards the tx in the stem phase 18:19:09 btw vtnerd could you take a look at 6757? 18:30:15 ty 18:35:20 i just caught a incoming transaction to a subaddress that has a payment_id set ( not 0000...), i though that was not possible with the monero-wallet? 18:36:15 It is not possible with monero-wallet-cli. It's possible some poeple want to try being assholes I guess. 18:38:34 ok i will see if i can figure out with which software that was send, thanks moneromoo 22:15:55 moneromoo: I'd guess it's a remnant rather than guessing it's malicious. It's a pretty stupid annoyance. 22:18:13 What is ? 22:19:26 Including a payment ID in a subaddress? 22:19:35 *in a transaction to asubaddress 22:20:13 I suppose it could be old custom code, true. 22:20:53 Or it's for internal tracking of outgoing payments, even though payment IDs are generally used for tracking incoming... 22:21:25 Anyways. It sounds, and is, stupid. Just don't get how someone would do it to be an ass :P 23:47:48 which rpc method is generally used for incomming deposits..get_bulk_payments or incoming_transfers