Jerrybo

I'm also with @JoelKatz. Runinng a validator brings some costs. I like to compare it to running a mail server. Of course I could run an instance and some really do that, but is it worth the effort? I think we need to separate parties here: As an individual person I'd like to receive an incentive, because running a validator isn't really a "hobby" for me. At least I don't want to have any costs. A profit would even be better of course. I mean, it also costs some effort. As an organisation I don't care about these costs, because compared to other positions it's not really worth to mention. My tech department running our mail & internet servers, domain controllers, etc. now just has to maintain an additional device (validator). Just some additional work for them. The advantage of having my own direct validator access brings me enough advantages. Therefore i think the real question is: Who should mainly run validators? If the response is individual people, then I think there needs to be an incentive. If the response is organisation, then nope. I don't see a need for a change. In my opition, that's just a temporary situation until enough organisations are running their own validators.

It's hard to establish a seriously revenue generating fintech/business in this space. Wish you guys all the best and hope you reach your goals!

The Swiss National Bank (SNB) is open to the use of digital central bank money for the business activities of banks among themselves. As part of a cooperation with the SIX Swiss Exchange, the central bank is examining whether and to what extent digital central bank money can be integrated into new distributed systems (distributed ledger technology), said SNB President Thomas Jordan at an event on Tuesday evening. This could simplify the transfer of assets. The project is part of an innovation center operated by the Bank for International Settlements (BIS) in several financial centers around the world. The results are therefore relevant to all central banks. The idea of a digital franc for consumers Jordan, however, again denied a rejection. This would involve too much risk, he said. Source1 (german): https://www.tagesanzeiger.ch/wirtschaft/geld/snb-prueft-digitales-geld-fuer-banken/story/14500243 Source2 (english): https://www.bis.org/press/p191008.htm

I agree here (again ) with @Sukrim: I'd like to see something concrete. We need to unterstand a current issue that needs to be solved. As he said "...that's not currently possible". Without a specific issue we could tend to just implement a solution for a problem that doens't really exist.

Very frustrating, I know your situation. More than once I've started a project and invested a lot of time, just to be too late. Seeing another team/company publishing a solution that match’s your own target is hard. They have more manpower, are further in the project... quite disappointing. But that’s entrepreneur’s life. I do the following in such situations: - Test and understand the other solution. You need to get a feeling if your solution is still better and if it's worth to work on it. - Evaluate if you're able to integrate parts of your solution into the other. Merge features you have into the other ones. It's often too much work, but I try to think about improve other's solution as well. - If I don't see any future to my solution, I'll just stop and go on. Not funny, but everything other is often just a waste of time. Sad to hear, but such things happens all the time. It's always hard if you invested such amount of time and it happens to you. Head up and go on for a new project!

counteractions: - starting a validator requires an XRP reserve. Running more nodes is getting expensier. - new nodes have a low score. Score increases over time in the meaning of they gained trust from the network Basically we could implement the same mechanisem and rules, that exists today to get an entry on the default UNL. Of course, every node can configure his own UNL at anytime. Thinking of a blacklist feature like in other network systems.

I agree with others, that a separation between account types would create additionalal hurdles for devs and consumers. The network should keep as easy understandable as possible. Also here again: What is the root problem that needs to be solved? If there were no XRP reserve, would there still be a need for light accounts? If yes, why? I like @Sukrim's approach with feature flags. We could understand them like a configuration for specific wallet use cases. Ex. one wallet could only be used for multi sign. To give the receiver of that specific wallet a "free signing key without reserve" the reserve could be increased at the creator's wallet.

Ok, agree. Understood the idea as "send back to sender in separate trx". A deduction before sending wouldn't increase network traffic, thanks for clarification. Anyway, that idea would just solve the problem, that the dev/user is too lazy to care about correct fees. In my eyes it would be basically just an optimization for those wo don't care about fees anyway. If it would be really a problem, participants wouldn't just pick a value known to be large enough.

Interesting idea. The underlying problem for me seems to be, that too many validators have the same UNL. Imaging everyone had a complete different list. The network halt due 20% fail would be a lot less likely, due there aren't "the top validators". In that assumption of the underlying problem (plz correct me if I'm wrong), the aim should be to get a lot more different UNLs being used. Approach: Dynamic UNL Like in the torrent network, an initial UNL would be just to start to join the network. Every network node maintains his own UNL list dynamically based on known peers. Every node on that list gets a calculated score. The score is getting better based on validators past successfully validations. The dynamic UNL to be used is the result of the top-scored validators. Issue with approach: It should be avoided, that every validator gets the same dynamic UNL due same calculation metrics. Maybe additional metrics such as response time, geo location, etc. could be considered.

I assume "delete" means "balance of 0". What is the problem that needs to be solved here? Your suggestion of deletable account sounds more like a concrete solution for a specific problem to me. I don't know exactly the problem that needs to be solved. Could you elaborate the problem please? I aim to keep all participants to speak of the same problem. If I assume the problem is the locked 20 XRP, I don't see any need for a change for the ledger. As a solution for that problem, I think we should discuss possibilities to reduce that fee. Why don't the validators just vote and change for a reduction to 5 XRP for example?

What is the goal of that change? What is the current problem that needs to be solved? I'd like to clarify that first for every change. Every change should solve a specific problem. I like the Idea of Trx fee tracking. From an API consumer side I would like to set a correct fee. Due additional work to get that, I think too often a larger amount is set just "to be sure". With your proposal, it would be easy to get the fee that was used for last 80% succeeded trx for example. Despite that, I think it is still too much effort for many devs/users due the fees are that low. I like the proposal as an easy way to get recent fees, but I cannot see the problem that needs to be solved. From a practical standpoint, @DutchBeetle 's idea first looks interesting. However, why should the unused amount be returned? I could imaging in reality that would effective double network traffic, due a lot of people choose too large fees. 50% additional "noise" on the network doesn't seem desirable to me. Due the Devs/User decision to not care about current fee, he or she decides in my eyes to ignore the fee costs. I think that’s mostly because they are so tiny. I don't see a problem that needs to be resolved here.

I just used magicSwords for easier understanding. In practical Use-Cases the item should be exchangeable between users and not dividable. Aaa... missed the trustline topic, good point. The infrastructure should be (almost) free to use for NFT items.

Maybe your suggested way seems strange in the first view, it doens't look bad at the second. According to "Nonstandard Currency Codes" (https://xrpl.org/currency-formats.html) one issuer could issue a unique item with a UUID as currency code with a total available amount of 1. Thats not really human readable, but we could create a viewer tool for that and map the issued UUID to a description in a centralized DB. Need to think more about that way. Further ideas welcome

Thought about that idea too. But dismissed it, due creating a currency per item ("magicSword_1", "magicSword_2", "magicSword1_n") seems more like a hack than a real way to me. A solution should be able to create thousand of unique items. Is there anyone in our space that spent some time on that topic and likes to share knowledge?

Hi there Does anyone knows any resources, tutorials, etc for creating NFT (non fungible tokens) on the XRP ledger similar to ERC721? Thanks and have a nice day