The priority queue is not public. Every node has their view of it. They can of course publish that, as any rouge node could.
But there is no way for someone to copy a trade/transfer. Even with a potential multi-currency payment net, everything is blinded. Well, can’t say for sure how that would look like now, but as it seems like from here at least
Also, when you spend, you might go to another part of the network, than the rogue node is in who gave you their view of their queue. Depends on the id of the dbc you want to spend.
(I won’t say that it’s impossible, we will have to see how it unfolds and what further development might be needed. But the basic level is fundamentally different and it is at a quick glance not easy to replicate those mentioned issues.)
Quick question: Does this mean that its possible that if you have too small a fee then in a busy network it may never (or long long time) get processed. Really I am asking is if there is any sort of mechanism that will raise the priority of a payment request according to the “time” it has been waiting. Time being some measure of events or whatever.
Will be more info in the dev update, it’s soon out. But yes it’s possible to update a pending tx. So if you see that it’s not being processed and you can see fees are not going down, then you can update that one. So it won’t get stuck there.
Also, there is a natural “expiry” as Elders do not gossip this around. So as Elders come and go very old transactions with fee levels that were never revisited, would just be dropped.
They need to query for the spend proof to build the output dbc.
So that’s what they do after a spend is in. When the spend proof has enough signatures (enough Elders processed it), then the tx is completed.
If they combine that with querying for the fee, they can deduce what the status is with their payment (and update fee if they wish).
A query api for more details is of course possible. Seems it could be useful.
The tx getting dropped would basically require the fee to keep rising, and the client not caring to update their fee. All they need to do then is to send it in again.
What they would need to be careful with though, is to send in a different tx for same input when their current one is close to being processed.
Because that could look like a double spend, and that would kill the dbc (i.e. the punishnent for such an attempt is that the tokens are burned).
So, updating the fee is something you’d want to do when the queue is long and your spend is fairly low.
But there are many more details there (the punishnent isn’t even implemented yet) so it’s not necessarily something they would actually risk. Can probably be mitigated there.
the incentive is huge, something like a billion dollars has been “extracted” this way in 3 years. So if there is a way it will be found.
Sounds like we are definitely in a better place though!
@JimCollinson - meant to post this earlier. You might be interested in this project if you haven’t seen it already. It uses a neural network to model guitar amp sounds & can run on a raspberry pi.
Can theoretically also model other effects (distortion, etc.), but better for ones that don’t vary through time.
The guy has several different projects on his GitHub site & some sample Jupyter / Colab examples for training the networks.
the incentive is huge, something like a billion dollars has been “extracted” this way in 3 years. So if there is a way it will be found.
