* To simplify submit transaction requests by having only one version of them that supports both signed/unsigned transactions, the signed versions of them (submitSigned(), submitSignedReliable()) are deleted.
* Their signed logic is merged into submit() and submitAndWait() (renamed from submitReliable()).
* Change order of submit method params to be consistent.
* Add a SubmitOptions method param to include options for wallet to sign a transaction, and booleans to autofill/failHard a transaction.
We renamed the Google Group to xrpl-announce. In the future, the same list may be used for releases of other client libraries as well. It's a small list (less than 60 subscribers) and not very noisy, so it should be okay to include release announcements about libraries in other languages, especially since many developers are polyglots. Of course, we hope the list will grow in the future.
Per https://github.com/ripple/rippled/issues/3214
The following fields are deprecated and may be removed without further notice: accepted, hash (use ledger_hash instead), seqNum (use ledger_index instead), totalCoins (use total_coins instead).
- Suggest XRPLF's public cluster; this is a better starter experience since
it's full-history and blocks known scam accounts
- Update the Node.js compatibility language to match the README.
- Remove dated language about ES5/ES6 Promises.
- Re-gen docs (this seems to have added a memo field that was previously
modified in some other PR)
Add the following missing specifications to the list of transactionType
specifications:
- Ticket Create
- Account Delete
- Deposit Preauth
Rearrange the transaction type specifications to be in alphabetical
order.
Using request('submit', ...) allows the ripple-lib API to be effectively
identical to the underlying rippled API. Whereas submit() returns only
certain fields from rippled, using request('submit') gives you rippled's
full response, including the new fields added in rippled v1.5.0.
The documentation previously just stated that any array of integers
was acceptable for providing as entropy, but it must be an array of
length 16 where the values are from 0-255 (uint8) to ensure we have
16 bytes of entropy.
Being able to fetch the WalletLocator field opens up new use-cases. The field can store for example a transaction hash, referencing a transaction with memos containing useful data.
