Jump to content

Dsimmo

Member
  • Content Count

    263
  • Joined

  • Last visited

  • Days Won

    2

Dsimmo last won the day on June 7 2016

Dsimmo had the most liked content!

About Dsimmo

  • Rank
    Regular

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks for the clarification. My mistake.
  2. What I don't understand is why there is capacity for unlimited memo size per transaction in the first place. The XRP ledger is a payment network, not a storage network. In my view, the ledger should have a small per transaction memo limit. Any hash of data could be stored, if need be, but keep the underlying off the chain... Storage networks can then be tied to the XRP ledger of need be, without necessary cost to the ledger
  3. I'm not sure what to respond to this. Anyway, my core position is that, the only truly neutral way to distribute transaction fees is *equally among all node operators*, regardless of Ripple unl membership. But if you're doing this, you incentivize people to spin up nodes for the sake of fee collection, not to provide benefit to the ecosystem. Fees received per node would be driven to zero, and the network would be worse off ...
  4. If fees are distributed to any validator, what's to stop me spinning up <insert very large number> of validators to collect as much of the fees as possible? Everyone would be doing this... It would just become a mess. Yes, Ripple could reward validators with their own XRP chest, I guess. But this wasn't what we were talking about. We were talking about redirecting burnt fees.
  5. Are you claiming we XRPL should give transaction fees to validators? If so, tell me which ones?
  6. Which validators though? If it's any validator, then Sybil like attacks would occur to accrue as much of the fees as possible. If it's only those on the unl then it provides incentive not to decentralised the unl; decentralisation would provide less fees for those currently in the unl. I believe that fees being directed toward validators is not a good idea for the above reasons. Tipping validators, as far as I can tell, appears to be a better idea
  7. Hi all. One of our greatest fud fighters on Twitter was @XRPTrump. Unfortunately, he seems to have disappeared lately. Anyone know where/why?
  8. Ok, so this is specific to checks, rather than a general property of amendments (although, presumably many amendments may have to be treated this way)
  9. @nikb I'm very interested in your comment that "once you activate [the amendment], you have to to carry it forever ...". It is very unclear to me why this is the case. Why can amendments not be entirely undone via a new amendment? What is the fundamental issue here? Is this property of amendments documented somewhere? I hope you have the time to respond, and would appreciate a detailed explanation :-)
  10. Where are the technical details of NikB's amendment?
  11. Brilliant. Thanks for this response. Are there any currently known issues with implementing account merge?
  12. 1) ability to reduce the number of deserted addresses on XRP ledger 2) the ability to spend those XRP you used to activate one of your N accounts @nikb @JoelKatz Would be good to get your input here. What are the pros and cons of adding an account merge feature like that used in XLM ledger?
  13. Hi XrpCommunity. I was reading this https://www.lumenauts.com/guides/how-to-merge-multiple-stellar-accounts, which describes a feature of the XLM network allowing accounts to be merged. My question is simple: Will account merging be implemented on the XRP ledger at some point? If so, when? If not, why?
×
×
  • Create New...