Author Topic: ripple rally  (Read 44826 times)

0 Members and 1 Guest are viewing this topic.

Offline alexkravets

  • Full Member
  • ***
  • Posts: 81
    • View Profile
But you can't just have every node with their own completely different list of validating nodes. How could you possible get a consistent view of the shared database otherwise? I imagine there needs to be enough overlap for everyone's view to be consistent (to not fork). The dynamics of how the shared UNL can evolve while avoiding forks isn't clear to me. It seems like it requires nearly all of the nodes currently in charge of validating the database to approve of any additions to the UNL for things to work well. And if that is true, that is what leads to issues for me...

Indeed, you can create your own UNL island (think about nodes on Mars on behind the Great Firewall of China) and they will be on a fork. 

Keep in mind key difference between CONNECTIVITY of the network vs. authoritative set of signers to achieve consensus.
For simplicity's sake let us assume that the network is fully connected, then consensus will occur if there is agreement from a sufficiently interconnected UNL-wise (NOT network connection wise) set of nodes.

The issues are subtle and I refer you to the Ripple Consensus white paper: https://ripple.com/consensus-whitepaper/

Quote
This is the problem. The people in power (the ones in the UNL already) are the ones who need to add Joe Schmo for him to have any participation in the database modification process. If he and others like him do get added, perhaps then they can slowly exclude some of the other incumbents and gradually change the set of members in UNL across different nodes. But what if they are kept out of the process to begin with because the old guard doesn't welcome the change they bring?

The ones who get to control whether Joe Schmo gets any power to begin with to bring about change in the system are the ones already in power. If they are not following the desires of the masses, the masses have no mechanism to take power away from them other than giving up on the entire system and switching to another system which is not compatible with contracts/debts/IOUs of the previous system and whose tokens are nonfungible with that of the previous system (a significant barrier which might keep them complacent with the old flawed system). With DPOS, changing the set of entities who control the database modifications that get through (or control what hard forks are accepted) is as easy as changing the delegates you vote for and pressing the vote button.

This is correct, one must DESERVE to be taken seriously enough and be considered a well-connected stable node enough for others to be added to others UNL list, but this is NOT necessarily a bad thing.

This WILL however likely to create a cartel-like YET DECENTRALIZED spider-web similar to the spider web of routing autonomous domains.

Ideally in the long run, "the average UNL" list should contain KGB, Chinese Intelligence, CIA, NSA, Bank of Whatever, etc ... it doesn't actually matter how malevolent the entries are on the list as long as THEY DON'T COLLUDE to CENSOR transactions

(CENSORING Transactions or failing to sign valid transaction to stifle consensus are really THE ONLY two avenues of attack open to arbitrary conspiracy of attackers, i.e. the worst possible damage is to PAUSE the network, i.e. ledgers will close but they'll be empty at which point nodes responsible for this are easily detected and commented out of the UNL lists)

i.e. the perfect two entries would be form Itchy & Scratchy Simpson's characters :-)

 
« Last Edit: December 18, 2014, 07:27:59 pm by alexkravets »

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Another common misconception about Ripple's UNL.  Although, when building / downloading the server, it does come with a DEFAULT list of nodes in the UNL (a.k.a ar RL1 through RL 6), each node operator can do WHATEVER they want with their own LOCAL UNL list ...

But you can't just have every node with their own completely different list of validating nodes. How could you possible get a consistent view of the shared database otherwise? I imagine there needs to be enough overlap for everyone's view to be consistent (to not fork). The dynamics of how the shared UNL can evolve while avoiding forks isn't clear to me. It seems like it requires nearly all of the nodes currently in charge of validating the database to approve of any additions to the UNL for things to work well. And if that is true, that is what leads to issues for me...

That being said, nobody stops Joe Schmo from both running a rippled node AND from TRYING to get others to add HIS node's public key to THEIR UNL list ...

This is the problem. The people in power (the ones in the UNL already) are the ones who need to add Joe Schmo for him to have any participation in the database modification process. If he and others like him do get added, perhaps then they can slowly exclude some of the other incumbents and gradually change the set of members in UNL across different nodes. But what if they are kept out of the process to begin with because the old guard doesn't welcome the change they bring?

The ones who get to control whether Joe Schmo gets any power to begin with to bring about change in the system are the ones already in power. If they are not following the desires of the masses, the masses have no mechanism to take power away from them other than giving up on the entire system and switching to another system which is not compatible with contracts/debts/IOUs of the previous system and whose tokens are nonfungible with that of the previous system (a significant barrier which might keep them complacent with the old flawed system). With DPOS, changing the set of entities who control the database modifications that get through (or control what hard forks are accepted) is as easy as changing the delegates you vote for and pressing the vote button.
« Last Edit: December 18, 2014, 07:12:01 pm by arhag »

Offline alexkravets

  • Full Member
  • ***
  • Posts: 81
    • View Profile
Such txs do indeed exist in the "open but unvalidated ledger" however, only next validated ledger becomes "authoritative" and in Blockchain like systems, the block solving or singing central node can decide to INSERT last moment transactions that allow it to "have a final say" on what becomes authoritative. Such transactions allow it to front-run or do other kinds of manipulation.

This is not possible in Ripple since no transaction that has not already gathered the signatures of the 80%+ of the validators network can be included, such transactions are deferred in Ripple, ie punted for possible inclusion into subsequent ledgers

This discussion about distinctions between Ripple consensus and other blockchain systems is interesting to me. To me the major important difference between the consensus systems is not the particular mechanics of how official changes to the distributed database are authorized. The most important difference to me is what determines the entities who get to authorize these changes.

In Ripple, this is controlled by the UNL. In DPOS, this is controlled by set of active delegates. The problem I have with Ripple is that the control of UNL is not decentralized to masses. I have serious concerns with an oligarchy that would naturally form due to the structure of the UNL. But if they fixed the number of nodes in the UNL to 101 and used a mechanism within the consensus technology to let XRP holders vote on the members in UNL, it could essentially recreate the most important parts of DPOS. Similarly, DPOS could be modified to allow the delegates to coordinate on their own private network for each block, and a block would only be considered valid if it had at least 81 of the 101 active delegate signatures, which would make it more similar to Ripple consensus.


Another common misconception about Ripple's UNL.  Although, when building / downloading the server, it does come with a DEFAULT list of nodes in the UNL (a.k.a ar RL1 through RL 6), each node operator can do WHATEVER they want with their own LOCAL UNL list ...

You can think of Ripple Labs running 6 clusters across major continents as SEEDING the network, but each Gateway usually adds itself and others to their own UNL list ...

That being said, nobody stops Joe Schmo from both running a rippled node AND from TRYING to get others to add HIS node's public key to THEIR UNL list ...

So far the common practice has been to add long-running reliable non-RL nodes such as Bitstamp or SnapSwap to custom UNL lists ...

To see some UNL lists look at "well known" ripple.txt files atop of web sites of running node domains, i.e.

https://snapswap.us/ripple.txt
https://www.ripplecn.com/ripple.txt

Some, like Bitstamp, choose NOT to publish their UNL lists but only their own public key, i.e.
https://www.bitstamp.net/ripple.txt

« Last Edit: December 18, 2014, 06:44:48 pm by alexkravets »

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Such txs do indeed exist in the "open but unvalidated ledger" however, only next validated ledger becomes "authoritative" and in Blockchain like systems, the block solving or singing central node can decide to INSERT last moment transactions that allow it to "have a final say" on what becomes authoritative. Such transactions allow it to front-run or do other kinds of manipulation.

This is not possible in Ripple since no transaction that has not already gathered the signatures of the 80%+ of the validators network can be included, such transactions are deferred in Ripple, ie punted for possible inclusion into subsequent ledgers

This discussion about distinctions between Ripple consensus and other blockchain systems is interesting to me. To me the major important difference between the consensus systems is not the particular mechanics of how official changes to the distributed database are authorized. The most important difference to me is what determines the entities who get to authorize these changes.

In Ripple, this is controlled by the UNL. In DPOS, this is controlled by set of active delegates. The problem I have with Ripple is that the control of UNL is not decentralized to masses. I have serious concerns with an oligarchy that would naturally form due to the structure of the UNL. But if they fixed the number of nodes in the UNL to 101 and used a mechanism within the consensus technology to let XRP holders vote on the members in UNL, it could essentially recreate the most important parts of DPOS. Similarly, DPOS could be modified to allow the delegates to coordinate on their own private network for each block, and a block would only be considered valid if it had at least 81 of the 101 active delegate signatures, which would make it more similar to Ripple consensus.

Offline alexkravets

  • Full Member
  • ***
  • Posts: 81
    • View Profile
Such txs do indeed exist in the "open but unvalidated ledger" however, only next validated ledger becomes "authoritative" and in Blockchain like systems, the block solving or singing central node can decide to INSERT last moment transactions that allow it to "have a final say" on what becomes authoritative. Such transactions allow it to front-run or do other kinds of manipulation.

This is not possible in Ripple since no transaction that has not already gathered the signatures of the 80%+ of the validators network can be included, such transactions are deferred in Ripple, ie punted for possible inclusion into subsequent ledgers

You don't need to be the block producer to front run:

*) Observe incoming marketable order as unconfirmed transaction A
*) Insert your own better priced unconfirmed transaction to buy up/sell up all the orders in the book which A would have bought/sold
*) Insert a new, opposite order to sell up/buy up at the full price of A
*) Profit by giving A exactly what he asked for, instead of the best price which he would have got

This is prevented from being possible in bitshares because the blockchain matching engine only gives the buyer/seller what they asked for, never the best price. In NXT it is possible to front-run.

What you say is also true ! However, you can NEVER observe those transactions which the singing node decides to insert at the very last moment before signing and broadcasting the block


Offline monsterer

Such txs do indeed exist in the "open but unvalidated ledger" however, only next validated ledger becomes "authoritative" and in Blockchain like systems, the block solving or singing central node can decide to INSERT last moment transactions that allow it to "have a final say" on what becomes authoritative. Such transactions allow it to front-run or do other kinds of manipulation.

This is not possible in Ripple since no transaction that has not already gathered the signatures of the 80%+ of the validators network can be included, such transactions are deferred in Ripple, ie punted for possible inclusion into subsequent ledgers

You don't need to be the block producer to front run:

*) Observe incoming marketable order as unconfirmed transaction A
*) Insert your own better priced unconfirmed transaction to buy up/sell up all the orders in the book which A would have bought/sold
*) Insert a new, opposite order to sell up/buy up at the full price of A
*) Profit by giving A exactly what he asked for, instead of the best price which he would have got

This is prevented from being possible in bitshares because the blockchain matching engine only gives the buyer/seller what they asked for, never the best price. In NXT it is possible to front-run.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline islandking

  • Sr. Member
  • ****
  • Posts: 378
  • The king of the island
    • View Profile
Ripple has some really good videos. We should start producing some high quality videos as well.
I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party. - Satoshi

Offline alexkravets

  • Full Member
  • ***
  • Posts: 81
    • View Profile
Ripple consensus has no temporary leader node which signs a new ledger and therefore there is not even a temporary centralization where the updates to the global state are visible to a single node.

Compare this to PoW or [D]PoS blockchains, where the block solver or signer "knows the future" ahead of other nodes on the network

You don't have mempool type unconfirmed transactions?

FYI unconfirmed transactions are visible to everyone, not just the block producing nI odes in PoW/[D]PoS blockchains.

Such txs do indeed exist in the "open but unvalidated ledger" however, only next validated ledger becomes "authoritative" and in Blockchain like systems, the block solving or singing central node can decide to INSERT last moment transactions that allow it to "have a final say" on what becomes authoritative. Such transactions allow it to front-run or do other kinds of manipulation.

This is not possible in Ripple since no transaction that has not already gathered the signatures of the 80%+ of the validators network can be included, such transactions are deferred in Ripple, ie punted for possible inclusion into subsequent ledgers

Offline alexkravets

  • Full Member
  • ***
  • Posts: 81
    • View Profile
How much swift payment system is currently worth?

Find out what the daily amount of fiat transferred by swift is, compare to the daily XRP transaction volume, then scale the market cap of XRP according to that ratio.

Sir,

You are misinformed about Swift. Swift does secure messaging which allows correspondent banks to communicate intended transfers. It does not do Settlement of payments, that happens on legacy mutual ledgers between say BofA and Mitsubishi bank. This settlement is the error prone, often manual step that requires physical actions by bank employees.

Ripple specializes in standardized, zero counter-party risk near instant settlement of funds, where banks offload mutual legacy ledgers onto Ripple ledger, while offloading ALL risk onto market makers who must first obtain said banks IOUs and thereby immobilize their "cash deposits" before they can engage in currency pair spread seeking

For intro, see https://ripple.com/building-the-internet-of-money-video/
For details, read https://ripple.com/integrate/executive-summary-for-financial-institutions/



Offline monsterer

Ripple consensus has no temporary leader node which signs a new ledger and therefore there is not even a temporary centralization where the updates to the global state are visible to a single node.

Compare this to PoW or [D]PoS blockchains, where the block solver or signer "knows the future" ahead of other nodes on the network

You don't have mempool type unconfirmed transactions?

FYI unconfirmed transactions are visible to everyone, not just the block producing nodes in PoW/[D]PoS blockchains.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline alexkravets

  • Full Member
  • ***
  • Posts: 81
    • View Profile
I've got one for you, alex: what stops front-running from being possible in ripple?

Ripple consensus has no temporary leader node which signs a new ledger and therefore there is not even a temporary centralization where the updates to the global state are visible to a single node.

Compare this to PoW or [D]PoS blockchains, where the block solver or signer "knows the future" ahead of other nodes on the network

Offline monsterer

I've got one for you, alex: what stops front-running from being possible in ripple?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline kisa

  • Sr. Member
  • ****
  • Posts: 240
    • View Profile
Quote
Ok, I misunderstood your answer. I thought you were saying swift only transferred $22M / day! So, what is the true daily volume?

I don't know that answer but still... even if it is trillions a swift message will  cost you $20 irrespective of how much money you transfer..

The whole argument here is I am trying to compare "swift" as a company with "ripple" as a company (which obviously will provide a better and much cheaper service than swift in the future) and Bitshares company..

So if "swift" as a company is worth now $20 - $40 bil then "ripple" as a company worthing $2.5 bil is overvalued..
BTS as a company worth anything below $500 mil is way undervalued... Now which one of these have the most upside potential with the least risk? that is the question to be answered and i think the answer is obvious...

I think that's over complicating matters; to get a ballpark idea of the relative valuations, just using transaction volume alone will give you some idea. Then you can use the same metric to compare bitshares current valuation to what it would be if it replaced n% of the transaction volume of swift/ripple.

I don't think ripple XRP will replace Swift anytime soon, if ever. Swift is evolving and adapting, and the shareholders of Swift are the very institutions that use it. And if the value of replacing Swift with ripple ever grew large enough to make it worthwhile, institutions would just create their own fork rather than give up all the value.

good argument, I'd leave it at that! it's time to move on :)

as BitShares obviously don't get intimidated, the (not mutually exclusive) alternatives are:
1. Fight Ripple with a better product/flexibility/community and/or criticism
2. Ignore Ripple and push BitShares own independent agenda as before
3. Study Ripple and learn certain techniques which would be most beneficial to BitShares
4. Create BTS gateway in Ripple and so try to establish synergies (who could work on that?)
5. Propose a wider cooperation plan to RL which is beneficial to both platforms
6. ---?

- should we conduct a poll or is it pointless?

« Last Edit: December 18, 2014, 05:15:24 pm by kisa »

Offline alexkravets

  • Full Member
  • ***
  • Posts: 81
    • View Profile
Ripple network in the future will likely converge into the same "cartel" as current Internet Autonomous Systems Cartel
(i.e. backbones that route traffic to each other "for free" while charging "downstream" ISPs and corporations for "internet connections")

If you consider Internet itself decentralized then that's your answer to whether or not Ripple will be decentralized in the long run.

Thanks for the info, alexkravets.

Do you think that it will ever be possible to have a market pegged asset exchange on Ripple, using XRP as collateral (like BTS)? Or do you think this is something that would clash with the banking services they are trying to provide?

It would be possible in theory, but given their prior comments and deeds I don't see RL going there ever

Offline mf-tzo

  • Hero Member
  • *****
  • Posts: 1725
    • View Profile
How far are the developers in getting BTC to be directly sent to a BTS address?

I'm working on it :)

Check my progress here: https://bitsharestalk.org/index.php?topic=12317.0

 +5% +5% +5%