Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


KarmaCoverage last won the day on August 3 2016

KarmaCoverage had the most liked content!


About KarmaCoverage

  • Rank
    Advanced Member
  1. Paychans are one way, but there is not a shared key between payer and payee. The payer creates the paychan on ledger, then funds it, then sends the payee a series of receipts, which the payee knows they can cash in at any time. Then there is a PayChan Close TX type to close the channel and refund the unclaimed balance to the payer. Unrelated, but, regarding "but a key is shared", there is this... https://interledger.org/rfcs/0016-pre-shared-key/ The only thing you can do is "top up" or close a paychan, and reissue a new paychan to reduce the amount originally funded into the channel. I think there should be some way to have a wallet subject to MofN issue a paychan, then have a smart contract dapp be one of the signers. I'd have to check on how MofN exactly works and how or what that could enable. If the goal is to offset price swings, you can always have the receiving party create a paychan in the opposite direction. Then have a smart contract be MofN for both paychans, and each receiver can sign (but only if the dapp does also) to send a receipt to them selves for the amount that would net out the effect of the FX change. At first thought, I bet this set up could probably be used with some dapp business logic to create a type of XRP derivative, will think on this, (maybe this could be used to help peg value of an IOU on another blockchain, like discussed in the decentralized exchange thread?)
  2. IDK always wondered how they got the 50k number, if part of the assumption is the payment channel's TX speed. Maybe I'm wrong about the 1500 Pay Chan TXs to get to 50k, but I think that was claimed after the PayChan amendment.
  3. 50,000 TPS would be by putting TXs through Payment Channels. So I think 1500 Payment channel TXs could get up to 50,000 TPS. Also, not all TX types cost the same amount. Payment Channels for example require higher fees https://ripple.com/build/known-amendments/#paychan I cant tell exactly how much a PayChan costs, but I think it can vary based on how its set up. I guess they are like trustlines, some of the "cost" is really just due to increased account reserve, and if you remove those objects / trustlines, then the additional reserve is freed back up?
  4. Do you care how much postage stamps go up and down, well up and up? No, you just figure the cost of the stamp into the cost of sending your package at the time. Same goes for banks, or anyone who is paying TX fees in XRP.
  5. Here is a thought. There are some holes in this, but I do think there is some way to skin this cat, at lease RCL-to-RCL. This is a very ILP-ish question flow, but I think the order of operations is in the opposite direction, and the method needs to use a series of transactions that enable the methods to circle back on themselves (for bidirectionality) The basic idea is To use the Hot wallet's trustline balance to limit the outstanding BTC.blackhole available for trading on ledger. To use an Orderbook and preset TXs to get the value out of the blackhole wallet without it having to sign any TXs after being blackholed To use the Dapp and Multi-Sig to create some decentralized mechanism that can receive the value, and wait for the receiver to sign a TX to get the value. Items used Issuing Wallet, blackholed Hot wallet (Dapp / multi-sig) Orderbook Payments Trustlines (Restricted and Balance changes) I also had a question spurred by this thread on cross currency rippling... Can a Trustline set TX be a Multt-sig TX? Maybe Rippling would be better worked into a step of this, instead of an orderbook or a payment TX. --- Inbound Goal 1. If you are re-issuing the other blockchain's coin from a blackholed wallet on ledger, then you dont need to worry about exchange rates, until you get the coin into the receiver's wallet on the ledger of the decentralized exchange. 2. You need a method of verifying that the deposit has been made into the corresponding wallet on the ledger of the sending blockchain. Then after that, a method of getting the same amount of value into the receiver's wallet on the decentralized exchange's ledger, ready for trading. Outbound Goal 1. You need a way to get the already issued coins back into the blackhole wallet, this way the pair of wallets on each blockchain can maintain a mirror balance. --- Setup On the inbound, Issue BTC coins > set orderbook TX to sell issued coins on an orderbook against IOU's issued by a second Hot/bot wallet > then blackhole the issuing wallet. (restricted trustline only Hotwallet approved) Create a 2nd wallet, to act sort of like a Hot/Warm wallet with starting trustline balance $0, and by employing multi-sig and some trustline balance reset transactions, I think it can help maintain/restrict the outstanding "tradable" IOUs to the be equal to the amount in the corresponding wallet on the originating blocichain. Must not let the wallet pair's get out of balance. There would obviously have to be an application interface to hide a lot of these steps. I'd imagine this as a Dapp, or something. Inbound Trade User sends BTC to corresponding wallet pair on that blockchain. Once confirmed, the TX hash is sent to the Dapp. The Dapp confirms the transaction and increased balance in the corresponding wallet, and the Dapp confirms the recipient's wallet has a trustline set to the Hot wallet. Dapp increases trustline balance to the max of the corresponding wallet, and a buy order TX on the orderbook between BTC.blackhole and BTC.Hotwallet for the same amount. (I was thinking about Rippling here, but not sure that makes sense?) Now, the Hot wallet has the BTC.blackhole, and can do a multi-sig payment to the receiver, requiring the receiver and the Dapp to be the 2 of 3. Outbound Trade Receiver has done their trading, and is now the Sender, and they hold BTC.hotwallet , while BTC.Hotwallet holds BTC.blackhole. So, Sender redeems BTC.hotwallet, which triggers Dapp to send redeem BTC.blackhole, and decrease it's trustline balance by the same amount. Now, ILP back to the other other ledger, assuming the other ledger is an RCL, the same methods would work in both directions.
  6. I think any ledger that can do ILP, and has escrow, could work, bitcoin, eth, etc. Then IPL connect back to XRPL, or the decentralized exchange's own RCL ledger. 1. Establish a wallet pair for each ledger to connect to the decenteralized exchange with a fixed 1-to-1 exchange rate.... For example, BTC you might issue 21mm BTC on the decentralized exchange's ledger. 2. Once all the various ledgers' coins are issued on the decenteralized exchange's ledger, then orderbooks can be used to make the markets, and pathfinding would do cross orderbook TXs automatically. The issue left in my mind is, how to both 1. Blackhole the issuing wallet for the 21mm BTC ... while 2. Still having that wallet be able to send individual payment TXs out to the correct user's wallet on the exchange's ledger. This may require multi sig (signers dont have to be funded accounts) or some other method for the value to be directed (or redirected for a fee, rippling) to the right wallet, almost like a Gateway would have done with Destination tags. (Side thought, you could mimic the bitcoin blochchains release timeframe with a series of escrows, then blackhole the issuing acct) I think the trick is to have all the coins issued by the same wallet, or else you cant get a cohesive orderbook going? Mayby a cold & blackholed wallet could issue, and a warm/hot wallet could be run by a codius or eth dapp?
  7. Gateways a thing of the past?

    Gateways issue IOUs, at this point it seems IOUs are not part of payment paths, only XRP is (at leaste on ledger), and XRP does not have a gateway/acct acting as an issuer.
  8. Tokens – Trust on the XRP Ledger

    @Amigo Fugger's original thoughts around a mutual credit system are excellent, and could compete with abusive CC companies, in theory. I have not thought about a credit card company using an RCL. This could certainly be done, and if you mixed in some of Fugger's ideas around IOUs, and interest rates on those IOUs, then I can see a different type of P2P lending system. One using different financial methods than the weighted average approach of all the major P2P lending platforms. This could be interesting. What if people identified folks they would be willing to hold that person's IOU, and at what rate. Then the system can get a sense of how risky individuals are based upon the summation of those actually willing to hold and IOU. Each IOU/Lender could have it's own rate. Credit Card companies are more than Credit companies though, they do lots of data and have their payment networks, etc, so I dont know if you could compete strictly based on improved credit extension methods alone. However, I do think RCL has the ability to be a game changer in P2P Credit. P2P Credit was essentially what Fugger originally had in mind when designing the original "Ripple". All the Byzantine General's problem and decentralized stuff came many years later. Edit: http://ripple.ryanfugger.com/
  9. Tokens – Trust on the XRP Ledger

    I think this is an issue that will have significance in the crypto industry. Enabling leverage matters... over leverage matters (as we saw in '08), but under leverage also has a cost.
  10. Tokens – Trust on the XRP Ledger

    Right, but the problem with crypto is that to lend $100 crypto, the loan must be fully collateralized by $100 in crypto...if not, the borrower cant withdraw $100 crypto from the system, so it's not a funded loan. The leverage creation that accompanies Credit Extension, enables the system to expand. Important. We can trust in crypto escrow, including across a series of moments, or multi legs of a TX... this method can address momentary cross ledger Trust ... but they do not enable the creation of leverage... amd they do not enable trust across a long duration of time, just transactional trust, till the end of the Tx.
  11. Tokens – Trust on the XRP Ledger

    Been thinking about this.. trustlines, escrow, rippling, ilp connectors, routing/pathfinding... Then the whole idea about 'credit in crypto' which doesn't, and almost cant actually exist. Maybe credit sits on top of a foundation of governance.
  12. What is the fair market cap of Ripple Inc (not XRP) ?

    I wrote about this a while ago on Quora https://www.quora.com/How-did-the-VCs-value-Ripple-Labs/answer/Ron-Ginn
  13. Codius and XRP What it is?

    Both are for coding & running business rules in a decentralized mannor.
  14. Investopedia now explains how to buy XRP

    As someone who seriously looked at doing the CFA, which Investopedia is a key info source for, XRP being on there a bit surreal, but cool. As a financial engineer, I am very disappointed that Investopedia's first mention is about "how to buy xrp"... and includes no explination of the systemic level innovation and financial brilliance that Ripple has built around xrp. If anyone from Investopedia sees this and wants help articulating RCL, ILP, Ripple Net, and XRP Ledger, and how they combine to make an IoV, message me.