Jump to content

jbjnr

Bronze Member
  • Posts

    631
  • Joined

  • Last visited

  • Days Won

    2

jbjnr last won the day on January 21 2019

jbjnr had the most liked content!

About jbjnr

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

jbjnr's Achievements

  1. You appear to have referred to the safe harbour proposal - but the question is about the effect of the SEC open letter in reference to the coinschedule settlement, where pearce and roisman state 'on the record' that there is no clarity provided by the SEC and leaves the question of which tokens are securities unanswered. This plays 100% into the hands of ripple's fair notice defense and I can't see how you would say what's quoted above. If it has no bearing at all on the case, then why did Ripple file it immediately as a brief to the judge in support of their dismissal of charges against Brad and Chris? Secondary question (to anyone) - this letter appear on the SEC website - could they have done this without the approval of Gensler?
  2. What the live twitter feed doesn't convey, is just how well the ripple lawyer managed to put the case in favour of deposition - in contrast to the SEC lawyer who ummed and aaaahed and "you know" all the way through. If I was ruling on this, I'd have been quite convinced by the ripple arrgument - particularly in terms of how "special" this case in within the context of an entire new industry segment. EDIT: The SEC lawyer is rebutting now and doing a much better job at objecting to the deposition
  3. I suspect ripple are too savvy for this. If they win outright against the SEC, then they set a precedent (no fair notice etc), that other cryptos can use against the SEC afterwards. Ripple want/need clarity for XRP, but despite them saying for years that a rising tide lifts all boats, when you get a chance like this to rise on your own - and let the other boat stay in the doldrums - then their best strategy may be to go for a settlement that leaves XRP in the clear, pay some fines, but not set any legal precedent that allows other cryptos to simply cite this case and "get out of jail free". Best plan (IMHO) = go for a nice settlement and leave all the other cryptos to fight their own battles afterwards.
  4. Well, it has been fun watching these flare threads over the last few months, they didn't know/publish numbers for fees for minting/wrapping/voting/delegating, they didn't explain how you'd stake and claim multiple income streams, only to realize it wouldn't work how they expected and you'll have to trust agents to vote for you and return your rewards. They claimed to have spoken to tax experts, but now they are just going to let morons decide on the distribution. There are still unanswered questions and we're a month(?) away from launch. At some point you might wake up and realize that they're not necessarily smarter than you are. They're people just like you and me and they made a bunch of claims that turned out to be harder to deliver on than expected. That's crypto!
  5. Quite good news for @Seouliteif that happens, since he has been stacking up on FLR IOUs and once converted into FLR when the network is launched, should they decide to burn the rest, he'll have a truck load of FLR purchased at "we thought this was 15% of the total" price, instead of "this is all there will be" price.
  6. Well, I wrote Because I'd like to know the same thing. Personally, I'd love to see something like airline flight insurance done on smart contracts, Pay a premium of P when booking your flight to cover delays/cancellations if your flight is delayed by N hours, receive payment proportional to N x P If your flight is cancelled, receive a larger payment proportional to P Oracle is data feed from flight info systems globallly. there are companies who provide reliable data streams for this kind of thing. I would use this every time I (used to before the pandemic) fly. AXA the big insurance firm actually tried this and cancelled it https://finance.yahoo.com/news/axa-drops-ethereum-based-flight-160027248.html but it seems like it would be an absolute winner to me and I am amazed that a massive insurance company couldn't make it work. (I'd happily work on something like that to make it viable on flare if it was ethereum that was the problem) Stuff like this that would actually bring value into a blockchain would be great, but I do not know of many examples of real world usage. For me ODL is a killer app, but xrpl is fine for that, FX swaps might benefit from flare to hedge your ODL traffic.
  7. Anyone can get FTSO rewards without locking up their FLR anyway, so that is irrelevant. And no, I'm not thinking retail. I'm not sure why you two are trying to lecture me on arbitrage. You've just locked up $250k of FLR and got $100K of XRP in return. Now you can trade your $100k of XRP for $101k of FXRP and then redeem the original $250k of FLR, and make a profit. (But now there is no FXRP in circulation any more). Everyone else can do this anyway, by just trading FXRP and XRP directly (assuming someone else has paid to create it), there is no need to lock up FLR, when you can sit back and let someone else do it. What I actually was saying is that to make it worthwhile to lock up huge amounts of FLR is that the minting costs of XRP->FXRP, DOGE->FDOGE will have to be quite high to make it desirable. Originally we saw 5% quoted in the whitepaper (I forget where?), and then it became a market rate. This market rate will in effect be set by the level of utility of F-assets, because only when people actually need F-assets for their smart contracts will they be willing to pay the fees to turn tokens into F-tokens and thereby give the incentive to anyone to lock up funds and do the arbitrage (ok, there will be rewards for holding F-assets from the rewards pool granted essentially by devaluation of FLR for everyone else, so this will offset the high minting costs a little, but this is just making sure that everyone else (not holding F-assets) devalues faster than you do by holding them - though it may work well enough to inflate the price of FLR initially. I have not modeled the balance between minting costs, F-asset rewards, arbitrage costs (we don't know the fees for trading yet do we?) and the cost of having FLR locked out of circulation, but I find the system very curious indeed. [You will both be glad to know that I have been writing arbitrage software recently and applied to the xrp grants project to turn it into an open source market making tool for cross ledger/exchange trading. In the unlikely event that it is funded, you can both contribute your knowledge to the rules needed for providing liquidity and earning from xrp/flr/others].
  8. The agent can free up his FLR by buying FXRP and redeeming the sum he has locked up, but the point I wanted to make is that for every $1B worth of XRP that is circulating as FXRP, there must be $2.5B worth of FLR locked up (for the entire lifetime of the FXRP). It may not be the same FLR that was used originally when the FXRP was minted, but someone has to provide that collateral, and that means that for every $ circulating as F-assets (any of them), there is 2.5x as much locked away. The irony of this is that Flare was created "to free up all the liquidity in tokens that don't have Turing complete smart contracts". Whilst it will do that, it does it at the cost of locking up 1.5x worth of the equivalent funds. To make that cost worthwhile - someone'd better be doing something really amazing with those F-assets. Agents put up FLR and receive your XRP/DOGE/LTC/etc and you get the F-asset. A self operating agent can put up his own FLR and swap his own XRP for FXRP, but then that FXRP must really be the dog's bollocks to make it worthwhile to lockup 2.5x to do it. I wonder how many people will want to lend $2.5 worth of FLR to get $1 of DOGE in return. I can imagine a lot of DOGE holders wanting to get rid of DOGE and receive FDOGE (because it will have more uses in theory), but then minting fees will have to be quite high to incentive people to lend their FLR for it. I look forward to seeing how much these F-assets actually get used for real-world business uses that generate the income needed to make them successful and cover the costs (and not just the F-Asset rewards being pumped out that in effect 'devalue' the system). Can anyone point me to a good resource that shows how ethereum smart contracts are used in the real world to facilitate business (not counting just trading useless tokens against other ones)?
  9. I think I misunderstood what you were asking. In general, yes what you say is quite reasonable. However, if an agent known that he has issued X FXRP at a price of $X and the price of XRP drops, he can buy back those FXRP any time and then redeem them against himself. When you transfer your coins to an exchange, all you are doing is transferring them to an exchange. When you exchange XRP for FXRP you are buying new tokens (you pay a fee), and get new tokens that have (at least in theory) new uses and utility that the old ones did not. (You would only do this if the new use cases that your FXRP can be used for are worth paying the fees for). The fees are going to need to be quite high as well. Why would I lock up a million FLR for a one time fee of (say) 0.5% when they may remain locked up indefinitely. They have to remain as collateral until the FXRP minted using them are redeemed and if they never are ....
  10. The price of FLR isn't fixed, the price of XRP, DOGE, LTC, others are not fixed. Any agent will want to buy back the XRP/DOGE/LTC when FLR rises, or they fall. Doing it automatically would remove one degree of freedom from the decision making process.
  11. Hard to know for certain until the network goes live and is being used actively, but the current test network is producing blocks every minute or so (with unexplained gaps) There is a balance. Consensus means that every node needs to know what all the transactions are, so they need to be exchanged. This messaging/exchanging of information is a major bottleneck, then you need to wait for everyone to vote/decide. Meanwhile each transaction has to be executed and applied to the ledger before deciding if it can go in or not. XRPL has path finding which can in principle be an expensive operation (though for short paths and small graphs, it's trivial). Flare is going to run smart contracts, these will (in general) be much more compute intensive than simple payments, so we can expect the balance to shift from consensus to ledger operations as being the limiting factor. I don't have numbers of how long it takes the ethereum network to execute all the contracts it runs, but once the number of them active starts to grow, this will become the dominant factor. (Oracles will be providing feeds for prices and I think I saw something like 3s quoted somewhere as the frequency, so that should give you an idea of expected ledger close time - i.e similar to xrpl - but not consistent with above snapshot). Because ripple is actually live and being used at reasonable scale and has not had significant downtime for N years. Because they have payment channels integrated, IOUs integrated and the DEX running (and they can create custom permissioned xrp ledger-like networks for central banks we presume) As above. but factor in liquidity. Unless the token is globally traded and liquid, it won't be much use as a collective exchange mechanism. If you can send FXRP as fast as XRP then you can send FDOGE as fast as well, all that happens is people have to start trading and trusting F-assets as much as the originals. You'll need to upgrade your ODL toolchain to use F-Assets and then hope nobody shuts down the underlying network. If FDoge as good as FXRP and both are better than XRP and people choose FDOGE over FXRP, then the XRP ledger will die, FDOGE will become dominant and FXRP will disappear too (after all, you can't create an FXRP without supplying XRP initially). If FDOGE is as liquid as DOGE (and FXRP as liquid as XRP) then they'll be used. F-assets are expected to be redeemable for their underlying assets, FDOGE, FLTC will be "better" than their underlying networks from the start of the flare network operation, so what will happen to their underlying networks? nothing really. They just sit there and be "valuable" (and redeemable). Of course. It would involve quite a lot of rewrite of code, but ultimately consensus consists of "should I accept this set of transactions yes/no" and the part of the code that makes that decision can be swapped out and replaced. One of the reasons cobalt wasn't developed further AFAIU is that there just isn't any great need for it. When the ledger becomes stressed to the point that transaction throughput is being limited by the code, then the code can be upgraded, but if it ain't broke, don't fix it. You seem to be missing the point that company/bank X wants to make payments to company/bank Y and they couldn't give a toss which consensus method is used by the payment provider's underlying blockchain. What they care about is whether the provider can setup a cloud based network node for them to interface to, whether their internal network can integrate with the payment network, whether the system has been vetted/tested/approved by regulators, is compliant with money transmitting rules. Whether the network has hundreds of other payment providers, companies etc connected to it and are discoverable and how interconnected they are and what features they provide. How do you know they haven't been working on it for years? Ripple were working with Central banks to trial CBDC's before anyone else was even thinking about it. You can be sure they knew that these walled gardens would need to connect to external ledgers and networks. They most likely have a much better idea of how to integrate these networks into both ripplenet and to XRPL than the competition. You and I could sit down and put together a payment network based on avalanche and your favourite token, we could make it as fast as anything and super awesome. Who's going to buy it and use it for their central bank network or for their payments? Even R3 who've been in this game for years, funded by banks, trialed and tested by banks are still not being used on a commercial scale yet (correct me if I'm wrong here). The point I'm trying to get at is that the blockchain ledger itself is just one tiny part of a much bigger game of integration into systems. When those avalanche networks are integrated into everyone's systems, they'll have value too.
  12. Strange because you wrote a couple of months ago ... and Why the change of tune?
  13. (That would be "amount of USD" not XRP). You can't make ledger trades on bitstamp, but what you would do is Step 1, create a wallet address. I've never used xumm, but maybe you can do it with that. I've just realized there is a flaw in my plan, because you'd need to fund your wallet with 20xrp to activate it and since you can't buy xrp, you can't do that. But let's suppose you have a friend who will give/lend you 20xrp for a bit. Create a wallet address using some tool. I can't suggest which because I have my own tool which generates wallet addresses, but if you search this forum, you'll find suggestions. Step 2. fund the wallet by sending 20xrp to it (or find soomeone who can send 20xrp to it, it can be from any account) - you will have a private key you must keep secret and a public one that you send the 20xrp to. On receipt of 20xrp the account is now activated and 'live' on the ledger. When you send you your own wallet, you can ignore the destination tag. You can check your wallet on the ledger using xrpscan or bithomp etc. Step 3. I use my own software for making trades, but you can use this. https://github.com/Bithomp/bithomp-tools it is no longer supported, but works fine. Download the index.html file and load it into your browser locally, once done, you can enter your secret key and make a buy of xrp. practice with tiny amounts to start with, like buying $1 worth with the rate set to whatever the going price is (say $1.05 right now), the fees are just 0.0001 xrp for example, so don't worry about wasting cash. When you buy on ledger with USD from bitstamp, you have to put currency=USD and issuer = rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B which is the wallet that "creates" USD for bitstamp - check that issuer address before making a payment. step 4, after you have bought xrp, go back to bitstamp and look at the address where you deposit xrp and destination tag number for your account, then using the bithomp tool, you can make a payment (send) the xrp to your bitstamp account and it will appear there. The destination tag is super important when sending to bitstamp because thhey use one wallet for everyone and a differet tag for each account - the tag is your identifier. caveat. If you screw up, you can easily lose all your money. Note that if you withdraw USD from bitstamp to your xrp wallet, then change your mind and want to send the USD.bitstamp back to bitstamp, it will apppear in your account again, but the address you send it to is not the same as the one you send xrp to, look in the bitstamp docs step 5 - Don't trust me, don't trust anyone else that you don't normally trust. If the above instructions confuse you, then stop and spend some time learning all this properly. Experiment with small amounts. If necessary, experiment with making payments and purchases using the test ledger. I wrote this after coming in from working in the garden and it's all from memory (except the USD bitstamp address that I looked up) and may have mistakes. Tomorrow I'll be on vacation and won't be offering further help. If you don't think you know what you're doing, then you probably shouldn't do it. Good luck!
  14. What you are describing, sounds like a 'transaction' that must be submitted to the network. Does the delegation process burn/cost any kind of fee? if not, how will you stop spam bots from continuously submitting thousands of delegation requests from one provider to another in an attempt to disrupt the network?
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.