marcinx

For what it's worth, we have also been seeing op_too_few_offers situations recently, which basically never occurred in the past. Unfortunately I cannot provide more detail without digging deep into the...

PS: We have also seen a noticeable spike in op_under_dest_min for strict send payments on smallish amounts where it is unlikely that the liquidity changed significantly from one ledger to...

Hey! Thanks so much, guys. I will check it out.

Hey Jake, Thanks for your follow up. > we should discuss first is whether or not these additional payments should be defined as first-order transactions. I think they have to...

Hey. I think the following examples illustrate the issue pretty well: **Current SEP-6 way:** - SEP-6 returned deposit address bc1qnppjqj7s9a3rdht279pfgyqk0jztpeckhxavgxdkveyan72dzz0sfp3mep for SEP-6 id 6fd27b34-8e48-46a3-ad80-b5d629ff8eae - User made two txs: https://blockchair.com/bitcoin/address/bc1qnppjqj7s9a3rdht279pfgyqk0jztpeckhxavgxdkveyan72dzz0sfp3mep...

What happened to this issue? Are we just going to let it go stale? It's been a year. SEP-6 still does not understand how to handle multiple txs per /deposit...

Hey @JakeUrban, Thanks for your follow up and taking the time to write down your thoughts on this. There are many obvious reasons why listing all payments is necessary, for...

PS: In our case the format for the list in /transactions is `request_id-hash` where hash consists of 10 alnum chars followed by another dash and a vout index. Other anchors...

Hey @JakeUrban, Thanks for your follow up. > I think we are on the same page with the problem statement, which is that users don't always adhere to the one-payment-per-transaction...

Hey @JakeUrban (and everyone), I would like to introduce some ideas, if that's ok. Let's just consider them a simple thought experiment for a more flexible but imaginary SEP-6 transaction...