Author Topic: ripple rally  (Read 44815 times)

0 Members and 1 Guest are viewing this topic.

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander
BTS got pumped in late august.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline fuzzy

Are we going to be overtaken by Stellar too?

IMHO, Stellar is really a pump and dump on a single btc38 exchange of the extremely low float otherwise thinly traded and sterile pseudo asset.

STR will crash and will crash hard, as soon as the btc38 pumping crews are done with it



It will crash and crash hard, but I seriously think it could go far above our marketcap and "crash" to be close to it.  I DO NOT own Stellar btw..  (So deep in BTS I can't see straight)

Currently sitting at a price ratio of 39:1 for stellar to ripple.  Looks like the silver to gold analogy might stick!
« Last Edit: December 19, 2014, 12:19:15 pm by fuzzy »
WhaleShares==DKP; BitShares is our Community! 
ShareBits and WhaleShares = Love :D

Offline Riverhead

damn.Big players behind btc38 pump the altcoins one by one except BTS.

Good. I don't want any part of that.

lzr1900

  • Guest
damn.Big players behind btc38 pump the altcoins one by one except BTS.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
What is behind the BC jump?
I speak for myself and only myself.

Offline donkeypong

  • Hero Member
  • *****
  • Posts: 2329
    • View Profile
Yeah, that's pump stuff. Stellar may have the fundamentals to succeed; I wouldn't know. But when I saw all that BTC38 volume, I thought the same thing: major pump action. It'll dump before it ever succeeds. 

Offline Riverhead

Are we going to be overtaken by Stellar too?

IMHO, Stellar is really a pump and dump on a single btc38 exchange of the extremely low float otherwise thinly traded and sterile pseudo asset.

STR will crash and will crash hard, as soon as the btc38 pumping crews are done with it


Offline Riverhead

https://wiki.ripple.com/How_to_Build_a_Gateway#Building_a_Gateway_in_Phases
We could fill this entire matrix for anyone to use BTS as the bank. BTS exchanges can become both BTS gateways and Ripple gateways. I think integrating with Ripple helps accelerate the vision of BTS holders becoming a self-selected trust/capital/credit group that can outperform the market.

Now we're taking ...

Bravo !

 +5%

We need to spend more time/effort figuring out how different crypto technologies can collaborate and have a whole greater than a sum of its parts rather than CMC pissing contests.

Offline fuzzy

https://wiki.ripple.com/How_to_Build_a_Gateway#Building_a_Gateway_in_Phases
We could fill this entire matrix for anyone to use BTS as the bank. BTS exchanges can become both BTS gateways and Ripple gateways. I think integrating with Ripple helps accelerate the vision of BTS holders becoming a self-selected trust/capital/credit group that can outperform the market.

Now we're taking ...

Bravo !

Agreed Toast.  The one question I have is "how will the bitshares voting features effect gateways as compared to ripple's?

I saw this coming a mile away tbh....Not necessarily as Ripple being the new reserve currency, but the "decentralized internet banking" infrastructure. 

BitShares will be the businesses and exchanges that interact with it.  We will be forced to use their gateways or watch someone else fork and do it themselves.

I STILL am concerned about Ripple though.  Any platform whose initial ownership was so absolutely, ridiculously skewed toward a tiny number of people is going to be easily corrupted.  Just like those who have the most $$ can buy off companies who run the "decentralized" internet today.

We can talk algorithms all day, but it always comes down in the end to whoever has the most value to be able to create the strongest group of insiders.  Can't disagree with the briliance of how Ripple has accomplished all this though.  And as for the CIA, KGB...etc all using the network, this just gives them more reason to work together to ensure their collective viability in the "New World Order". 

If I am missing something I would love to know.  I do NOT care about getting rich nearly as much as I care about us building a world that is truly capable of protecting people's lives and liberty...so if Ripple accomplishes this, I will go give my baby a kiss on the head and be glad Ripple is around.

*EDIT*  One thing is for certain in my mind--Ripple is better than POW.  This means working with Ripple essentially puts BitShares directly in a place where the users who quickly realize the benefits of 5 second transaction times and scalability will begin understanding just how innovative a platform this one is. 
« Last Edit: December 19, 2014, 03:58:08 am by fuzzy »
WhaleShares==DKP; BitShares is our Community! 
ShareBits and WhaleShares = Love :D

Offline alexkravets

  • Full Member
  • ***
  • Posts: 81
    • View Profile
https://wiki.ripple.com/How_to_Build_a_Gateway#Building_a_Gateway_in_Phases
We could fill this entire matrix for anyone to use BTS as the bank. BTS exchanges can become both BTS gateways and Ripple gateways. I think integrating with Ripple helps accelerate the vision of BTS holders becoming a self-selected trust/capital/credit group that can outperform the market.

Now we're taking ...

Bravo !

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
https://wiki.ripple.com/How_to_Build_a_Gateway#Building_a_Gateway_in_Phases

We could fill this entire matrix for anyone to use BTS as the bank. BTS exchanges can become both BTS gateways and Ripple gateways. I think integrating with Ripple helps accelerate the vision of BTS holders becoming a self-selected trust/capital/credit group that can outperform the market.


中文翻譯:
https://wiki.ripple.com/How_to_Build_a_Gateway#Building_a_Gateway_in_Phases

我們可以同樣填寫這些表格, 來將BTS視為銀行看待. BTS交易所可以同時成為BTS網關以及Ripple網關. 我認為整合Ripple將會加速BTS持有人成為一群自我選出的信任/資本/信用團體, 並在市場上取得優勝.
« Last Edit: December 19, 2014, 11:11:18 am by cn-members »
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline alexkravets

  • Full Member
  • ***
  • Posts: 81
    • View Profile
Are we going to be overtaken by Stellar too?

IMHO, Stellar is really a pump and dump on a single btc38 exchange of the extremely low float otherwise thinly traded and sterile pseudo asset.

STR will crash and will crash hard, as soon as the btc38 pumping crews are done with it

Offline Empirical1.1

  • Hero Member
  • *****
  • Posts: 886
    • View Profile
Are we going to be overtaken by Stellar too?

Offline alexkravets

  • Full Member
  • ***
  • Posts: 81
    • View Profile
This WILL however likely to create a cartel-like YET DECENTRALIZED spider-web similar to the spider web of routing autonomous domains.

(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)

Let's say all clients share the same UNL at first. Now let us say 5% of the nodes are censoring transactions and therefore not reaching the same updated state of the ledger as the other 95% nodes. This shouldn't be a problem in terms of allowing the network to continue since the ledge will still close (more than 80% still agree with the new ledger). However, if this grows this can eventually lead to more than 20% of the UNL not complying, in which case consensus stops.

This is correct.

Quote
Trying to fix the problem at that point would be difficult. Everyone would need to update their UNL to remove the problematic nodes, but it is important to do it in a way that is consistent with everyone else so that people don't end up on different forks. However, since the consensus engine has paused, they have no convenient way to reach a consensus on the new UNL. This is similar to the case in DPOS where more than 50% of the delegates do not include any vote changing transactions and so clients cannot vote out delegates and have to use some alternative way (hard fork) to change the delegates.

This argument WOULD be valid, however its hidden assumptions are not true, so it's not.  Let me explain.
Your hidden assumption is that the UNL list is somehow large or quasi-random, it's far from either !
It has taken over a year of reliable operation and 99%+ availability for *some* of the nodes to begin adding it to their UNL lists.
It's an inherently slow social process of REPUTATION BUILDING. 

Now, what you describe above would be completely analogous to some global backbones just NOT routing packets that come from their peer backbones, in this kind of scenario, their long sought and fought for reputation would be instantly destroyed and their would be removed from ACL lists in the routing tables thereby wasting the entire investment.


Quote
To avoid this, the problematic nodes (or delegates in DPOS) need to be continuously removed from their privileged position before the problem grows out of hand. I understand how this is done in DPOS. The transactions that change the approval voting of delegates are included in the consensus blockchain itself. The same consensus technology that keeps track of who has what funds also determines the changes in the set of active delegates (block producers). But how are these desirable (in the sense that it is beneficial for the future reliability of the network) changes to UNL decided in the case of Ripple and how do they get propagated to all Ripple clients? As far as I see in the whitepaper, there is no mechanism to propagate these changes as part of the consensus algorithm or allow the UNL to dynamically change without user intervention.

This is because there is no need for such, again you assume a pseudo-random initial UNL list, it's far far from it.
It's a very slowly curated and carefully controlled list similar to backbone-to-backbone peering agreements between huge networks.

Quote
I worry that this means users are forced to rely on the default node list that comes with their client, which just centralizes power to the developers of the client. Or even if there is some procedure for updating the UNL, it will likely only be accepted by the public if it is approved by more than 80% of the current members of the UNL (the ones who would not be removed by the changes to the UNL). Users want to be sure that there is agreement in the network (no forks) and that ledgers continue closing. If an update to the UNL doesn't have the support of 80% of the current UNL, some users may end up on different forks. So because the Ripple consensus algorithm doesn't include (as far as I can tell) a mechanism for updating the UNL consistently across all users, users will likely have to just go with whatever updates are approved by the vast majority of current UNL members.

Indeed, if you've decided to participate in Ripple consensus, you will not find yourself unsynced and unable to advance only if you include a default curated list as shipped by RL possibly adding a few other well known sites.

But do not confuse USERS with node operators, users simply want to issue digitally signed transactions and have assurance that only such transactions will be reflected in the ledger and those users who ACCEPT payment want finality and irreversibility of such payments.  This is similar to web sites and surfers just wanting to exchange some TCP/IP packets while the transport is provided by backbone operators.

Quote
This is basically equivalent to DPOS where the only people who get to vote on the delegate candidates are the top 101 active delegates (who each get one vote).  Even if a good non-colluding set of of initial members was chosen, can we guarantee that they remain that way over time when the only entities who get to vote for changes to the set are the members in the set themselves? My intuition says that this group can slowly become corrupted over time, and when it does, it becomes very difficult to replace them. In this case corruption would mean that they end up becoming a colluding group that selectively censors transactions to serve the interests of themselves (or the more powerful forces that control them). The check on their power needs to come from outside the set. I think the way to do that is by considering the votes of masses that depend on and use the system. But to avoid Sybil attacks, the only sensible voting power to consider is that of stake in the system. Otherwise, Ripple is only as decentralized as the number of individuals who control the 1000 or so nodes in the UNL. But with delegation of stake, the decentralization can expand to all of the individuals who own the stake (such as BTS). This could eventually become millions or even billions of individuals, whereas we can pretty much guarantee that millions of nodes are not going to be in the UNL because scaling out the validators to that many servers makes the consensus algorithm very inefficient.

Ripple Consensus does not use ownership of XRP or any IOU for voting to arrive at consensus, it simply considers every VALID and digitally signed transaction signed by the supermajority of validators "retired" or admitted into the history inside a particular ledger.

In this regard it's very different from DPOS, the assumption underlying Ripple is that it's relatively inexpensive to run a full rippled node and there will be enough sites doing it simply for the benefit of having lower level latency access to the consensus ledger stream and indeed, it's never been a burden to run such a node ... even though there's been over 10 millino ledgers and total storage is already well over 100 Gigabytes ... after scanning the chain of ledgers once (in memory even) every node can prove the legitimacy of the latest ledger and never need to store the entire ledger chain, although some archival nodes, i.e. the once run by RL will always store the entire chain.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
This WILL however likely to create a cartel-like YET DECENTRALIZED spider-web similar to the spider web of routing autonomous domains.

(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)

Let's say all clients share the same UNL at first. Now let us say 5% of the nodes are censoring transactions and therefore not reaching the same updated state of the ledger as the other 95% nodes. This shouldn't be a problem in terms of allowing the network to continue since the ledge will still close (more than 80% still agree with the new ledger). However, if this grows this can eventually lead to more than 20% of the UNL not complying, in which case consensus stops.

Trying to fix the problem at that point would be difficult. Everyone would need to update their UNL to remove the problematic nodes, but it is important to do it in a way that is consistent with everyone else so that people don't end up on different forks. However, since the consensus engine has paused, they have no convenient way to reach a consensus on the new UNL. This is similar to the case in DPOS where more than 50% of the delegates do not include any vote changing transactions and so clients cannot vote out delegates and have to use some alternative way (hard fork) to change the delegates.

To avoid this, the problematic nodes (or delegates in DPOS) need to be continuously removed from their privileged position before the problem grows out of hand. I understand how this is done in DPOS. The transactions that change the approval voting of delegates are included in the consensus blockchain itself. The same consensus technology that keeps track of who has what funds also determines the changes in the set of active delegates (block producers). But how are these desirable (in the sense that it is beneficial for the future reliability of the network) changes to UNL decided in the case of Ripple and how do they get propagated to all Ripple clients? As far as I see in the whitepaper, there is no mechanism to propagate these changes as part of the consensus algorithm or allow the UNL to dynamically change without user intervention.

I worry that this means users are forced to rely on the default node list that comes with their client, which just centralizes power to the developers of the client. Or even if there is some procedure for updating the UNL, it will likely only be accepted by the public if it is approved by more than 80% of the current members of the UNL (the ones who would not be removed by the changes to the UNL). Users want to be sure that there is agreement in the network (no forks) and that ledgers continue closing. If an update to the UNL doesn't have the support of 80% of the current UNL, some users may end up on different forks. So because the Ripple consensus algorithm doesn't include (as far as I can tell) a mechanism for updating the UNL consistently across all users, users will likely have to just go with whatever updates are approved by the vast majority of current UNL members.

This is basically equivalent to DPOS where the only people who get to vote on the delegate candidates are the top 101 active delegates (who each get one vote).  Even if a good non-colluding set of of initial members was chosen, can we guarantee that they remain that way over time when the only entities who get to vote for changes to the set are the members in the set themselves? My intuition says that this group can slowly become corrupted over time, and when it does, it becomes very difficult to replace them. In this case corruption would mean that they end up becoming a colluding group that selectively censors transactions to serve the interests of themselves (or the more powerful forces that control them). The check on their power needs to come from outside the set. I think the way to do that is by considering the votes of masses that depend on and use the system. But to avoid Sybil attacks, the only sensible voting power to consider is that of stake in the system. Otherwise, Ripple is only as decentralized as the number of individuals who control the 1000 or so nodes in the UNL. But with delegation of stake, the decentralization can expand to all of the individuals who own the stake (such as BTS). This could eventually become millions or even billions of individuals, whereas we can pretty much guarantee that millions of nodes are not going to be in the UNL because scaling out the validators to that many servers makes the consensus algorithm very inefficient.
« Last Edit: December 18, 2014, 08:33:25 pm by arhag »