Jump to content
mDuo13

Multi-Signing, Amendments, Fee Escalation changes published

Recommended Posts

What's your thought about exploiting the new fee escalation and queue policy to submit transactions before previously submitted transactions?

Don't you think it will be a big issue?

Share this post


Link to post
Share on other sites
6 minutes ago, tulo said:

submit transactions before previously submitted transactions

RBF in Bitcoin, Replace By Fee. Highly controversial feature there. The problem that bitcoin has, however, is that in order to deal with the 10 minute confirmation time in retail scenario's (buying your coffee with Bitcoin), retailers depend on trusting unconfirmed transactions. Transactions seen by the network but not included in a valid block yet. The RBF advocates say to this: "you should not do this!! go buy your coffee with something else, bitcoin was not designed for that!" (to which many argue that bitcoin was designed for that, and RBF is a big mistake).

Since Ripple has a much faster block size interval, dealing with unconfirmed transactions is still a non-issue. That could change when the network gets serious load. But even for Ripple, the same argument could be made: "don't transact your coffee purchase on the ripple blockchain, and never trust an unconfirmed transaction".

Share this post


Link to post
Share on other sites
1 hour ago, lucky said:

RBF in Bitcoin, Replace By Fee. Highly controversial feature there. The problem that bitcoin has, however, is that in order to deal with the 10 minute confirmation time in retail scenario's (buying your coffee with Bitcoin), retailers depend on trusting unconfirmed transactions. Transactions seen by the network but not included in a valid block yet. The RBF advocates say to this: "you should not do this!! go buy your coffee with something else, bitcoin was not designed for that!" (to which many argue that bitcoin was designed for that, and RBF is a big mistake).

Since Ripple has a much faster block size interval, dealing with unconfirmed transactions is still a non-issue. That could change when the network gets serious load. But even for Ripple, the same argument could be made: "don't transact your coffee purchase on the ripple blockchain, and never trust an unconfirmed transaction".

My point was different...I was talking about the possibility to keep a previously submitted transaction in the queue submitting high fee transactions...

Share this post


Link to post
Share on other sites

This is a phenomenal improvement to the protocol. 

"......

  • You can require keys from different devices, so that a malicious actor must compromise multiple machines to send transactions on your behalf.
  • You can share custody of an address between multiple people, each of whom only has one of several keys necessary to send transactions from that address.
  • You can delegate the power to send transactions from your address to a group of people, who can control your address if you are unavailable or unable to sign normally.

......."

This will mean adding real technological teeth to legal agreements - this is really, really big news. 

Share this post


Link to post
Share on other sites

@mDuo13, thanks for the update, these are great news indeed, major releases.

6 hours ago, tulo said:

What's your thought about exploiting the new fee escalation and queue policy to submit transactions before previously submitted transactions?

Don't you think it will be a big issue?

Looks like it wont be a big issue:

https://github.com/ripple/rippled/blob/release/src/ripple/app/misc/FeeEscalation.md#transaction-queue

Quote

A transaction in the queue can stay there indefinitely in principle, but in practice, either

it will eventually get applied to the ledger,

its last ledger sequence number will expire,

the user will replace it by submitting another transaction with the same sequence number and a higher fee, or

it will get dropped when the queue fills up with more valuable transactions. The size limit is computed dynamically, and can hold transactions for the next 20 ledgers. The lower the transaction's fee, the more likely that it will get dropped if the network is busy.

But I would like to hear more too if you elaborated on possible scenarios.

After the transaction is included in the open ledger, the ordering works as usual?

Share this post


Link to post
Share on other sites
4 hours ago, RafOlP said:

After the transaction is included in the open ledger, the ordering works as usual?

Yes, that's correct.

 

10 hours ago, tulo said:

My point was different...I was talking about the possibility to keep a previously submitted transaction in the queue submitting high fee transactions...

I don't think it works the way you're thinking. Basically, it's as RafOlP said. If you submit a transaction with a really low fee, your transaction might sit around in the queue for a long time, but that's only because everyone else is paying higher fees than you. That's a direct result of the transaction cost value you chose when you submitted the transaction. If you want the transaction to be processed right away... well, set a higher value. You can replace your existing queued transaction with an equivalent one -- same sequence number, different transaction cost value -- or you can wait for the network to be idle enough that your transaction finally makes it out of the queue.

Keep in mind, ordering transactions from the same sender according to Sequence number hasn't changed. So you can't get more transactions into a ledger if you're still waiting on one from the same address to leave the queue -- you have to either give up on the transaction in the queue and replace it with a new transaction with the same Sequence number (and a higher transaction cost, presumably) or wait for it.

 

10 hours ago, lucky said:

Since Ripple has a much faster block size interval, dealing with unconfirmed transactions is still a non-issue. That could change when the network gets serious load. But even for Ripple, the same argument could be made: "don't transact your coffee purchase on the ripple blockchain, and never trust an unconfirmed transaction".

Even under serious load, that should be a non-issue. The FeeEscalation stuff is designed to shrink the size of the expected ledger if consensus takes more than 5 seconds. That'll increase the transaction cost dramatically until the load subsides -- and charging a higher transaction cost should make the load subside, one way or another. And, in Ripple, you really shouldn't ever trust an unconfirmed transaction. If the transaction's in a validated ledger, you're good; otherwise, wait it out. (Unlike with Bitcoin, that should only take a few seconds.)

 

tulo's first question also made me think about the potential to use the queue for front-running / flash trading. There is some potential there -- basically, if you make a big buy with a low transaction cost (which gets you queued for a later ledger), it's possible someone may pay more XRP to rush ahead of you into the current ledger to buy and then re-sell the asset you're buying at a profit. The solution is, if you're making big purchases, make sure you pay a high enough transaction cost to get into the current ledger, in which case it's very difficult for others to front-run you.

Share this post


Link to post
Share on other sites
12 minutes ago, mDuo13 said:

tulo's first question also made me think about the potential to use the queue for front-running / flash trading. There is some potential there -- basically, if you make a big buy with a low transaction cost (which gets you queued for a later ledger), it's possible someone may pay more XRP to rush ahead of you into the current ledger to buy and then re-sell the asset you're buying at a profit. The solution is, if you're making big purchases, make sure you pay a high enough transaction cost to get into the current ledger, in which case it's very difficult for others to front-run you.

That's a point, but the damages are still limited to a condition the order's owner agreed too, so its no big deal IMO. If there are people who pay the time to take these little advantages, good for them, and the overall volumes will just grow.

It seems to me that the average transaction cost is not a number that will change fast enough to cause big surprises, so reasonable fee choices should suffice to a healthy trading/payment experience, but lets see it in practice :)

Edited by RafOlP

Share this post


Link to post
Share on other sites

To what extent is the fee escalation scheme a scalability solution, and can Ripple start providing benchmarks anytime soon? Will it require a more mature and decentralized topography before scalability/capacity can be quantified?

Sent from my iPad using Tapatalk

Share this post


Link to post
Share on other sites

Multi-signing is great and makes it a kind of corporate account....Let's say there is also a smart contract feature for Ripple (as a completely independent additional module). Then a smart contract can be utilized that locks an account/address unless it is unlocked with a kind of security device mechanism. This way a secondary log-in mechanism could be established for Gatehub, for instance. It would not be enough for an attacker to log into/hack Gatehub. There would be some kind of "guarantee" for an account holder that there is a second line of low level defense regardless any security deficiencies a gate implementation/front end might have. The security mechanism would disable itself after some period of time unless extended to avoid an infinite lock-out situation.... If Ripple/Gatehub had smart contracts, then all kind of payment integrators could be obtained from external providers, like ATM/credit cards or NFC payment...There would be endless possibilities and useful features with smart contracts. It would beef up Gatehub and Ripple as an application development platform that can do the same as Ethereum much better. Nearly every project for BTC and ETH will have its version on Ripple. That's what can impress non banking customers who are the ones that buy XRP....

Edited by yandel

Share this post


Link to post
Share on other sites
16 minutes ago, mDuo13 said:

With rippled 0.31.0 coming out today, we have preliminary dates that we expect the new Amendments to apply:

 

In other words, the countdown is on!

Any update on the market making incentive program?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...