Jump to content

F6FNU

Member
  • Content Count

    29
  • Joined

  • Last visited

1 Follower

About F6FNU

  • Rank
    Regular

Recent Profile Visitors

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

  1. From: https://ripple.com/company/board-of-directors/
  2. Thanks, I missed that. Also, a link to the discussion would be even better !
  3. DW ? You mean David Schwartz ? Also if you have a source, I'm interested.
  4. It won't, as Cobalt is a replacement for the Ripple Consensus Protocol Algorithm. It doesn't affect the functionalities of the XRPL, only its consensus mechanism ?
  5. @Kpuff, @lucky is correct to point that unlike LN, XRPL Paychans are native and don't involve third parties. As for the throughput, it is only limited by the hardware of the participants to the channel[1]. References: [1]: XRPL Dev Portal > Home > Docs > Concepts > Complex Payment Types > Payment Channels
  6. Paying is agreeing that ownership of an asset changes. Settling is actually moving[1] the asset into the custody of its new owner. A payment can exist without an immediate settlement. A settlement can only exist to fulfil a pre-existing payment, or as a single-operation duet of immediate payment+settlement. Operations colloquially referred to as "on ledger transactions" are settlements. I say colloquially because there are actually many more types of operations that are recorded on the ledger. Payment channels record payments that can be settled later[2]. Notes and references: 1: note that on the XRPL, there is no movement, as the unit of exchance, the drop, is not an entity, like a satoshi is. Drops (and therefore XRPs) only exist through their ownership. 2: XRPL Dev Portal > Home > Docs > Tutorials > Use Complex Payment Types > Use Payment Channels
  7. Welcome @CodeBoss. You will find useful resources on the XRP-Ledger Dev Portal. The XRP-Ledger is the product of the combined actions of rippled servers[1]. Rippled servers can be configured in several modes[2]: Standalone: the server doesn't communicate with other servers. This is for testing purposes. Stock: the server only relays transactions and maintains its local copy of the XRPL. This is what the server does if you "start a validator [server] right now". Validator: the server additionally partakes in the consensus process, the RCPA[3]. A server running in validator mode will validate. A second server that includes the first one in its UNL will listen to it. Validating is speaking. Being included in another one's UNL is being listened to. The validation process on XRPCharts has been discussed here and questions remain. In any case, being validated on XRPCharts is supposed to show trustworthiness, but it doesn't get you in Ripple's recommended UNL, or in anyone's UNL[3]. References: 1: XRPL Dev Portal > Home > Use Cases > Run a rippled Validator 2: XRPL Dev Portal > Home > Docs > Concepts > Rippled Server Modes 3: The Ripple Protocol Consensus Algorithm
  8. High quality write-up, thank you very much.
  9. Sure, I understand your sentiment. That consideration can be made for any transaction type. That is a possibility with any blockchain too. What you are thinking about touches on one of the deep implications of blockchain for society as a whole. What happens if I upload illegal content on a blockchain ? Do everybody with a copy of the ledger engage in illegal behaviour ? Food for thoughts. You can be absolutely certain that this topic will be in the media in a few years.
  10. You mean the EscrowCancel or EscrowFinish transaction memo. Like any other transaction, EscrowCancel and EscrowFinish transactions incur a cost. So does adding a memo. If someone wants to burn some XRPs to be the one who triggers the destruction of the escrow and do so in style, power to them.
  11. You can't do any mischief. You can only trigger the execution of what was initially decided by the escrow creator. EscrowCancel and EscrowFinish only trigger the destruction of the Escrow Object, they don't change the rules the original creator of said object set up initially. The originator of the EscrowCancel or EscrowFinish transaction only triggers the destruction, and that's it. The originator of the EscrowCancel or EscrowFinish transaction has no power whatsoever as to whom receives the fund. The originator of the EscrowCancel or EscrowFinish transaction cannot either destroy an escrow object that hasn't met its own conditions.
  12. You are not the first and not the last person to be surprised and that's understandable. Keep in mind though that only an escrow that has already met its own conditions can be released by anyone, and that the EscrowFinish transaction has no power over who receives the funds.
  13. Anyone who creates an escrow on the XRPL rely on either time-based unlocks and/or crypto-conditions to enforce the escrowing of the funds for the intended period. The originator of the releasing transaction has no power over who the funds go to. Whoever triggers the release, the funds will still move towards the initiator of the EscrowCreate (if the conditions of the escrow are not met: that's a refund) or towards the intended recipient (if the conditions of the escrow are met, that's a payment).
  14. An EscrowCreate transaction requires the initiator to have the required amount of XRP that is to be escrowed, otherwise the transaction will fail. Once an escrow reaches its end of life, be it due to its expiration date having passed or its crypto conditions being fulfilled, the escrow needs to be release. The release is not automatic, as the XRPL doesn't support time-based triggers. A specific transaction is needed to release the escrow, and anyone can initiate that release transaction. Reference XRP Ledger Dev Portal > Home > Docs > Concepts > Complex Payment Types > Escrow
×
×
  • Create New...