dogecoin VS rippled

🧾 Whitepaper

It already has the "fix" inherited from the Bitcoin code they reuse. Though you shouldn't count on that feature to not have bugs: the Dogecoin codebase is old and poorly maintained. If you run it on a cloud service, always turn on billing limits. https://github.com/dogecoin/dogecoin/blob/master/doc/reduce-...

not theoretical https://github.com/dogecoin/dogecoin/issues/3243

>to cause a specific target networked Bitcoin node to consume quite a bit of bandwidth by returning blockchain data to the attacker.

correct

>It doesn't seem like this would have any effect on the Bitcoin network at large

until a botnet or botnets make huge swaths of the mining network unprofitable

>While I don't doubt that there exists an obscure client vulnerability that could be patched, it seems far-fetched and alarmist to categorise this as a "bitcoin exploit".

it meets all of the criteria to be called, bluntly, a remote financial attack/exploit that much of the network is vulnerable to

that's actually not correct. apples and oranges. we're talking about mining rigs - not websites and apps maintained by sysadmins who can apply a simple fix or waf during an upstream overage attack. if this was a not issue they wouldn't be patching it https://github.com/dogecoin/dogecoin/issues/3243

> that's actually not correct. apples and oranges. we're talking about mining rigs - not websites and apps maintained by sysadmins who can apply a simple fix or waf during an upstream overage attack.

Bitcoin mining rigs don't even use bitcoin p2p protocol themselves, they typically use stratum protocol(https://braiins.com/stratum-v1/docs) and don't accept incoming connections from the public internet generally. They usually connect to mining pool servers which have long had various forms of ddos attack mitigation systems in place.

> if this was a non-issue they wouldn't be patching it https://github.com/dogecoin/dogecoin/issues/3243

They added an integrated basic bandwidth limiter from the looks of it, one can do something like that using external tools already. Hardly a real vulnerability.

read this dogecoin issue for more info (it also works with doge) https://github.com/dogecoin/dogecoin/issues/3243

This example is interesting in that it sheds light on the true cost of running a cryptocurrency node. In the normal case without hackers a transaction takes up about 300 bytes. Each transaction must reach each node in the network. Each node will have to receive it and will receive it once, so on average each node will send it once. So a node will use about 0.3 GB of bandwidth to process a million transactions. At the Digital Ocean rates this will cost the node operator $0.003. So even if there were a million nodes, the total bandwidth cost to process one transaction would still be a fraction of a penny. These costs would be at data centers, and would be higher in residential locations. Don’t run a node over a cell service!

If you want a short introduction to Conan as a CMake user, I wrote this document.

You can read more about the proposal here. And the actual pull request containing the code changes can be tracked here as XLS-30d.

It used to be 80% but was fixed to >80%. See here.

An incorrect SQL query during startup could result in an apparent failure to persist amendment votes across restarts, even though the vote was properly persisted.

> Consensus is only really nessisary for solving problems like payments or namespacing (e.g. namecoin)

That is the only credible use-case(s) that the cryptocurrency folks should be looking at. I can see a few projects surviving like Stellar [0], Ripple (XRP) [1], Algorand [2] and Nano [3], ENS [4], Handshake [5] and Skiff [6].

Unlike the other project that are rife of scams that you see reported daily from web3isgoinggreat, there are a few that are not silly meme coins / tokens, or vaporware but stuck to their goals / whitepaper(s) and seem to be still useful and have a use-case.

This is what these skeptics won't tell you and just ignore and filter it out.

[0] https://stellar.org

[1] https://xrpl.org

[2] https://algorand.com

[3] https://nano.org

[4] https://ens.domains

[5] https:/handshake.org

[6] https://skiff.com

Here's the contributor list for rippled, the XRP blockchain. https://github.com/ripple/rippled/graphs/contributors

Ripple | REMOTE or ONSITE | full-time

Hi, I'm a C++ software engineer at Ripple. I work on the Ripple XRP Ledger, a peer-to-peer decentralized payment server (see https://github.com/ripple/rippled).

If you like working with C++, you'll be very happy here. We use `17 and intend to move to `20 soon.

Our software is cross platform, and you're welcome to use your preferred tools. The team is split pretty evenly across Windows, Linux, and Mac.

We're a "remote first" team, spread across the U.S. Almost all communication is done through slack/email.

Ripple is growing fast. We've got great funding, and a great team. Feel free to email me with any questions: determan at ripple.com (My name is Scott).

Our open jobs are listed here: https://boards.greenhouse.io/ripple/ and we're looking to hire many roles, not just C++ roles (although I have less visibility into the non-C++ roles).

I truly like the people I work with - we're a great place to work. Come join us!

In May, RippleX invited the developer community to provide feedback on our proposal to enhance NFT support on the XRP Ledger (XRPL).