Jump to content

Search the Community

Showing results for tags 'amendments'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • XRP
    • Please Read Before Posting
    • Press
    • General Discussion
    • Technical Discussion
    • Codius and Smart Contracts
    • Marketplace
    • Problem Solving
  • Interledger Protocol
    • Interledger Protocol Discussion
  • Other Technology
    • Alt-Coins and General Fintech
  • More
    • Fan Submissions
    • Off-Topic
    • Meta
    • Languages
  • Canadian Zerpers's Topics
  • Vegemite Ripplers's Topics
  • 2 the Moon! For Real. The Club's Topics
  • NY Zerpers - aka bitlicense island's Topics
  • Brackish Waters Club's Topics
  • Trading Places's Topics
  • Anti-Club Club's Topics
  • The Irish Brigade's Topics
  • Saloon's Request
  • XRP Trading And Price Speculation's Topics
  • The Crypto Buffett's Topics
  • Alt-Coin Trading And Price Speculation's Topics
  • Super serious Ripple club's Topics
  • Making Millions!'s Topics
  • Ripple - India's Topics
  • SWELL's Topics
  • Gospel Hour's Topics
  • Korean XRP Holders's Topics
  • Strayans lovin your work XRP!!!'s Topics
  • Technical Analysis (TA) Area's Topics
  • BTC diving deep club's Topics
  • Ripple Enamel Pin Club's Topics
  • XRP Wave Surfers's Topics
  • FUDster's retreat's Topics
  • Cooking with Snoopy's Topics
  • How it's all going to happen..'s Topics
  • Chocolate Fish's Topics
  • The Round Table's Topics
  • UK Hodlers's Topics
  • ˜”*°• Zerpmania •°*”˜'s Topics
  • XRP YouTube Videos's Topics
  • CRY ROOM's Topics
  • Night's Watch's Topics
  • CasinoCoin's Topics
  • XRP Think Tank's Topics
  • Allvor's Topics
  • NightClub's Topics
  • TeXRP's Topics
  • COIL Think Tank's Topics
  • Bob's Book Club's Topics
  • XRP FAQS's XRP Q an A’s

Calendars

  • Ripple Events
  • Vegemite Ripplers's Events
  • NY Zerpers - aka bitlicense island's Events
  • Brackish Waters Club's Events
  • Trading Places's Events
  • Anti-Club Club's Events
  • The Irish Brigade's Events
  • Saloon's Calendar
  • XRP Trading And Price Speculation's Events
  • The Crypto Buffett's Calendar
  • Alt-Coin Trading And Price Speculation's Events
  • Super serious Ripple club's Events
  • Making Millions!'s Events
  • Ripple - India's Events
  • SWELL's Events
  • Gospel Hour's Events
  • Korean XRP Holders's Events
  • Strayans lovin your work XRP!!!'s Events
  • Technical Analysis (TA) Area's Events
  • BTC diving deep club's Events
  • Ripple Enamel Pin Club's Events
  • XRP Wave Surfers's Events
  • FUDster's retreat's Events
  • Cooking with Snoopy's Events
  • Chocolate Fish's Events
  • The Round Table's Events
  • UK Hodlers's Events
  • XRP YouTube Videos's Events
  • CRY ROOM's Events
  • XRP Think Tank's Events
  • Allvor's Events
  • NightClub's Events
  • TeXRP's Events
  • COIL Think Tank's Events
  • Bob's Book Club's Calendar

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Interests


Location


Occupation


Country


Ripple Address


Biography


Location


Interests


Occupation

Found 10 results
Minimum search term is 4 characters long. Can't find what you want? Click here for the custom google search instead.

  1. Stellar just released Protocol 11 and there is an interesting thing in there that I cannot find on the dev ripple site... Current situation: for each transaction on the XRP Ledger you'll need to specify an amount of XRP that needs to be destroyed to pay the transaction cost. The minimum that you can select is 1e-5 XRP or 10 drops. For now, I'm discarding multi-signed and escrow transactions that have a bit higher fees. This is done to prevent the network from being spammed/DDoS-ed. There's an amendment called "FeeEscalation" that makes sure (when network is under heavy load, and by heavy load I assume more than 1500 Tx/s) that the consensus process selects transactions that pay higher cost and queues other transactions with lower cost which will be inserted in the later ledger versions. Looking at Stellar they had : " Before Protocol 11, fees were fixed: you submitted the amount you were willing to pay to add your transaction to the ledger, and that was that. You paid the fee you specified, or, if that fee was too low, ran the risk of getting squeezed out by surge pricing. " The updated version is: "After Protocol 11, fixed fees are replaced with a version of a VCG auction. You now choose the maximum fee you’re willing to pay, but you’re actually charged the lowest possible fee. If network activity is light, you’ll pay the absolute minimum. If it’s heavy, you’ll pay up to the amount you specify, but no more. As a result, you can choose the highest fee you’re comfortable with safe in the knowledge that you’ll only pay that fee if required by circumstance. " Maybe a fix to "FeeEscalation" amendment can apply the similar "Stellar trick"? References: https://www.stellar.org/blog/protocol-11-improvements-stellar https://developers.ripple.com/transaction-cost.html https://developers.ripple.com/known-amendments.html#feeescalation
  2. Two announcements to the dev blog today: rippled 1.2.4 has been released. Yes, it's another hotfix. This one should hopefully fix the validator list expiry problem noted in this thread once and for all. The MultiSignReserve amendment is now enabled, so you can go and update your signer lists to save a few sweet, sweet XRP. Depending on how many signers you have on your multi-signing list, this cuts the reserve requirement down by 10 to 45 XRP! (Used to be 15-50 XRP; now it's always 5 XRP.)
  3. ... and that means the Known Amendments page has been updated. rippled 1.2.0 will introduce (at least) 3 new amendments, which (if enabled following 2 weeks of support from 80+% of validators) introduce transaction processing changes. In this case, the changes are pretty small: fixTakerDryOfferRemoval fixes a bug where dry offers sometimes weren't properly removed when autobridging. Thanks to GitHub user demonstefan for contributing the code that eventually became this amendment! fix1578 makes fill-or-kill offers return a new tecKILLED code (as requested on this very forum) when they're killed. It also makes TrustSet transactions fail when they can't set the NoRipple flag, instead of "succeeding" without changing the flag. Both of these changes are meant to make the transaction engine just a little less tricksy. MultiSignReserve reduces the reserve requirement for signer lists so they occupy less XRP for just sitting there. Stay tuned for more information about the upcoming release and the features in it!
  4. In today's blog, the retrospective of XRP and Ripple finishes with a closer look at our prior year, 2017. We've come a long way, and 2017 demonstrates that in spades. This blog will cover key code updates for XRP, the controv ersial topic of anonymous payments, community promotions, and XRP's own version of the "Bitcoin Pizza Guy," which is known more as the "XRP Jacket Guy." (He knows who he is!) And for those of you that are new, I wax nostalgic about the old RippleTrade wallet - something only fellow XRP veterans will appreciate. No retelling of 2017 for Ripple and XRP would be complete without discussing SWELL and the Central Bank Summit on Blockchain hosted by Ripple. I hope you enjoy the read - please leave any feedback below! Feel free to share my blog with a friend or on any other platform - and thank you for doing so! Twitter Reddit r/Ripple Reddit r/CryptoCurrency Reddit r/CryptoMarkets Reddit r/xrp Reddit r/RippleTalk Bitcointalk - alt coin sub forum Bitcointalk - XRP speculation thread
  5. The momentum behind XRP and Ripple has quickly built into the size of a freight train. I make a good-faith attempt to cover all the news items of the last seven days, including The AMA (Ask Me Anything) session that David Schwartz held on Reddit. The other news items are extensive as well, including updates to xRapid customers, general Ripple technology adoption, and community updates. In addition, throw in two interviews with Ripple executives and you have a very busy week indeed. Hope you enjoy the read - please leave any feedback below. Also, feel free to share my blog with a friend or family member, or share it on any other forum or platform - and thank you for doing so! Twitter Reddit r/Ripple Reddit r/CryptoCurrency Reddit r/CryptoMarkets Reddit r/xrp Reddit r/RippleTalk Bitcointalk - alt coin sub forum Bitcointalk - XRP speculation thread
  6. Hey! it seems we have had a lot of newcomers to the forum lately. Nice! Anyway, regardless of the recent re-popularization of XRP, I am opening this thread about a great technical feature for RCL that is expected to be enabled this week. As you can deduct from the title of the thread, I am talking about PayChan. The thing is, unlike the Escrow amendment, which is also expected to be enabled next Thursday and I totally understand, I have some doubts about PayChan. In particular, I would like to know if PayChan not only offers the possibility of off-ledger payments, but also off-line payments. That is, would it be possible to send those "Claim" messages through any other type of network/connection (e.g. Bluetooth, NFC...) outside the Internet to later distribute them to RCL and redeem them? I asked this question on the chatbox some days ago but got no response. Can anyone clarify this doubt? Thanks!
  7. There are a few amendments announced that I'd like to try to get more information on. Has there been any mention of when the network will be voting on the PayChan and/or SusPay amendments? SusPay has been on the TestNet for a while now so I am speculating that feature may become available sooner than the former. I'm quite excited to begin testing payment channels once available, the pertinent information is how transaction fees will be handled. I know that the OwnerPaysFees amendment deals with the Issuer paying for the payment processing of an OfferCreate or Payment transaction. What I really want to know is if that feature's philosophy is going to be extended to the issuer of a payment channel, so that a freshly created Ripple account will have its Claim transaction paid for by the owner of that channel, or if the claimant will have to have enough XRP to process a claim transaction? Last, Tickets... Only mention of this feature is that it is still in development. This new method seems is most likely being worked on for creating more fault tolerance. If there is anything out there that anyone knows about Tickets, please do tell.
  8. This notice is for all validator operators, and may be relevant to gateways that utilize the Authorized Account feature. The new TrustSetAuth amendment is open for voting now. This amendment allows pre-authorization of accounting relationships (zero-balance trust lines) when using Authorized Accounts. With this amendment enabled, currency issuers can authorize other addresses to hold their issued currencies without waiting for the other addresses to take action. Without the amendment, currency holders must first create the accounting relationship with the issuer by setting a limit with a TrustSet transaction. Ripple’s validators will vote in favor of the TrustSetAuth amendment, and we expect the new feature to become active by 2016-07-19. For more information, see the following articles in the Ripple Developer Center: Authorized Accounts: https://ripple.com/build/gateway-guide/#authorized-accounts Amendments: https://ripple.com/build/amendments/ To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: https://groups.google.com/forum/#!forum/ripple-server
  9. Just today I published the documentation for a bunch of new feature stuff that's coming in rippled 0.31.0. (Right now we're still tracking down the last few bugs in the release candidates, but the feature set is finished and the release will be out probably any day now.) It's been a long road for multi-signing in particular, with the first preview promising that it was "coming soon" as of March 24, 2014. Yeesh! But this time, we really mean it: multi-signing is getting real. We're not... quite... there yet, though, and part of the reason is that 0.31.0 is the first time we're going to truly use the Amendments system for rolling out new network features in a decentralized fashion. This is a big step in our roadmap towards encouraging a decentralized web of trust in the validation network, because it means that the network will be able to smoothly roll out new features without interruptions or a central authority managing them. You can read more about Amendments on the Ripple Dev Center. But! There's one other thing before Multi-Sign happens, and that's an amendment called "Fee Escalation." We haven't talked it up as much, but this change has also been in a long time coming. A while back, you may recall that the cost to send a transaction increased from a typical price of of 10 drops to 10,000 drops of XRP. That's because we realized that, with the network as it was, it had become possible to intermittently DDoS the network without spending a fortune in XRP -- the transaction cost reacted slowly enough to changes in conditions that the network was already in trouble by the time the costs became unbearable. For many months, we've been running our validators with a band-aid fix, with the "load" multiplier artificially cranked up to 1000× in order to maintain network stability. That's why the first Amendment we support will be Fee Escalation -- a change that makes it actually possible to pay a higher transaction cost to make sure your transaction gets processed sooner. Now, when there are a lot of transactions in the current ledger, the server will start queuing up additional transactions for the next ledger instead of trying to squeeze them all in at once -- and the order will be determined by how much XRP those transactions destroy. Not only that, but you can still squeeze into the current open ledger if you pay even more XRP -- but the requirement scales exponentially, so it won't be worth it for long! The long and short of it is that the network should be more resilient against DDoS attacks, while affording more flexibility in the amount of XRP you spend sending transactions (based, presumably, on how urgent your transactions are). With any luck -- and this is not a guarantee, but I'm pretty sure it'll happen -- we'll be able to turn off the artificial "1000×" load knobs and return the minimum transaction cost back down to a truly miniscule amount. See the "Open Ledger Cost" section in the documentation for the details. That finally brings us back to Multi-Signing. It's going to be a few weeks out even after the release gets finalized, so you'll have plenty of time to figure out how it works in order to start multi-signing the instant the feature goes live. In fact, if you're really excited to try it out, you can practice how to multi-sign a transaction using rippled in stand-alone mode. You can also test out other stuff in stand-alone mode, without having to interact with the real network, whether you want to replay old ledgers or test out new features. (Stand-alone mode is not a new feature, but the new documentation should make it much easier to use.) This has been a big project (over 40 commits just to documentation!) and there are a few more changes not even mentioned here. (There might even be some minor improvements to rippled 0.31.0 that haven't made their way into the docs yet.) So, let's not quite declare victory before the release is live -- but get your funny hats and party poppers ready, because version 0.31.0 is going to be a big deal. As always, feedback is deeply appreciated, and I'm glad to offer clarifications for anything that doesn't make sense to you. And, just like rippled itself, our documentation is open-source, so you don't have to be a Ripple employee to contribute!
×
×
  • Create New...