xrplf / rippled Goto Github PK

rippled.cfg:
...
[websocket_ip]
127.0.0.1

[websocket_port]
6006
...

$ ./rippled --net

Dart code:

WebSocket.connect('ws://127.0.0.1:6006').then((WebSocket socket) {
print('Connected');
socket.listen((message) {
print(message);
},
onDone: () {
});
socket.send('{"command":"subscribe","id":0,"streams":["server", "ledger", "transactions"]}');
});

Expected:

Dart should start receiving streaming data.

Actual:

print('Connected') is not called. Interestingly if I shutdown rippled while keeping the Dart client running I get:

Uncaught Error: HttpParserException: Connection closed before full header was received
Unhandled exception:
HttpParserException: Connection closed before full header was received
#0 _FutureImpl._scheduleUnhandledError. (dart:async:349:9)
#1 Timer.run. (dart:async:2251:21)
#2 Timer.run. (dart:async:2258:13)
#3 Timer.Timer. (dart:async-patch:9:15)
#4 _Timer._createTimerHandler._handleTimeout (dart:io:5987:28)
#5 _Timer._createTimerHandler._handleTimeout (dart:io:5995:7)
#6 _Timer._createTimerHandler. (dart:io:6003:23)
#7 _ReceivePortImpl._handleMessage (dart:isolate-patch:40:92)

To add atomicity to changing an offer and to reduce the number of transactions submitted to the network add the option to cancel an offer to OfferCreate.

Some people run the server on nodes with terabytes of storage and are happy to keep tons of history. However, there are also people who are on VPS's or other systems where storage is at a premium.

Currently, we have no way to purge history other than deleting all your databases and refetching what you want. This works very well for validators, but it's awful for servers that handle clients.

As our transaction volume grows, this is going to be more and more of an issue.

We need to do "node scrubbing". Essentially, this means finding nodes that do not need to be kept given the server's data retention policy and removing them. This is complicated by two factors. First, nodes are not indexed except by hash. Second, a node that's not used has nothing happen to it, there's nothing to tell us it has fallen out of the ledger. Worse, it may be out of the ledger and then back in and thus need to be retained.

The fix is a bit painful. If a server has a configured retention time or number of ledgers, we need to identify nodes that need to be retained versus those that don't and remove the ones that don't. I propose this method:

1. Figure out a ledger such that this and all prior ledgers do not need to be retained according to the server's retention policy. Store that ledger's sequence number. Remove all ledgers prior to that from our local tracking of ledgers we have and ensure we don't add them back.

2. Walk all ledgers after the ledger identified in step 1 starting with the current ledger and ending with the ledger after the ledger we found in step 1. This means all transaction and metadata nodes, account state nodes, ledger headers, and so on.

3. For all nodes found during the walk and not in a local "suppression" cache, bump the node sequence in the node database to the ledger index in which the node was found (if it's less than that) and add the node index to the suppression cache (so we don't read it again).

4. Traverse the main node database. Remove all nodes whose node sequence is less than the sequence of the retention ledger selected in step 1. (LevelDB has some tricks to make this efficient.)

Note that this process should be done slowly at low priority.

I have had this issue for the past few days and have had some back and forth with Joel about it, but since I was running rippled out of a very low end machine, 32bits and all, I couldn't be sure that wasn't the reason.
Today I installed a fresh ubuntu 12.10 64bit on a good machine, built rippled, allowed it to catch back to the ledger that has been giving me grief and tried again, to no avail.

These commands all work fine when done against s1.ripple.com but on the local system I get the result as shown in the output at https://dl.dropbox.com/u/38488881/missing_ledger_details.txt

Ripple config is at https://dl.dropbox.com/u/38488881/rippled.cfg

The only thing I haven't tried yet is running ledger_history as full, which I will now.

Also document OfferCreate types like FOK/IOC. Moreover, please explain how one can 'take' the offer?

not returning the DYM path:

rippled ripple_path_find '{ "source_account": "rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E", "destination_account" : "rBiYVjzHRQxMDMdC5ynKsejqoy1qJMQ8zR", "destination_amount" : { "currency": "DYM", "issuer": "rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E", "value": "6.0751" } }'

Everything is failing just the same, I'm afraid.

So the workflow that is failing is, in a nutshell:

walletA trusts bitstamp for 1 BTC
walletB trusts bitstamp for 1 BTC
wallet A gets a 0.1 BTC transfer from bitstamp
wallet A cannot send any BTC to wallet B - Paths are calculated but when sending one of partial path or fee insufficient will be thrown.

Are you able to run the workflow described yourself?

[edit] - above is the simplified workflow that is failing now, the original issue was slightly more complicated:

walletA trusts bitstamp for 1 BTC
walletB trusts walletA for 1 BTC
walletB trusts bitstamp for 1 BTC
walletA gets a 0.1 BTC transfer from bitstamp
walletA sends 0.05 BTC to walletB - it appears as walletA BTC IOU
walletB cannot send any BTC to bitstamp - Paths are calculated but when sending one of partial path or fee insufficient will be thrown.

Could you please add some more details to the following wiki topic:

https://ripple.com/wiki/RPC_API#subscribe

Currently, if the server has even the briefest lost of synchronization with the network (uncertainty over precisely what the most current ledger is in the internal transaction processing and validation engine) the client reports itself offline until full synchronization of the validation process is restored.

Much of this logic was developed before the validation gate logic and is wrong under the new transaction and ledger security model. The server is in synch if it has a recent fully validated ledger. If the server has lost synch, it's back in synch when it fully validates another ledger that is very recent (or becomes convinced there has been no new ledger since the last one it fully validated).

That is, synchronization as far as clients are concerned, should be based on holding full copies of recent fully validated ledgers, not the status of the consensus process.

From a couple of days ago the web client appears to lose the websocket connection but not state it is offline. Instead it shows no balance on any currency and no history as if it had been opened with a new wallet.
The problem also shows up in a slightly different way, where balances and history are correct, except no XRP and that makes the client show the initial 'Welcome to Ripple' screen.

I've been seeing this on Chrome 25.0.1364.155, OSX 10.6.8

Can you write a unit test for this: ripple/ripple-client#23

• Implement rule change transactions
• Process rule change positions
• Complete tracking of rule change positions across server restarts
• Complete server tracking of actual rules changes
• Server stops processing transactions if unknown rule is adopted
• Add way to simulate passage of time in standalone mode.
• Test rule change process in simulation

better, faster, stronger

Steps to reproduce:

1. Create a new ledger, no peers.
2. God creates one order, buy 10 BTC/god for 15 USD/god each.
3. God creates another order, sell 10 BTC/god for 15 USD/god each.

Expected result:
Either the offers cancel each other with no effect, or perhaps an error stating that god does not have the necessary trust lines to pay himself.

Actual result:
Server stops because of assert.

Stack:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffeffff700 (LWP 8479)]
0x00007ffff5775425 in __GI_raise (sig=<optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff5775425 in __GI_raise (sig=<optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff5778b8b in __GI_abort () at abort.c:91
#2  0x00007ffff576e0ee in __assert_fail_base (fmt=<optimized out>, 
    assertion=0x100527c "false", 
    file=0x1005248 "src/cpp/ripple/LedgerEntrySet.cpp", line=<optimized out>, 
    function=<optimized out>) at assert.c:94
#3  0x00007ffff576e192 in __GI___assert_fail (assertion=0x100527c "false", 
    file=0x1005248 "src/cpp/ripple/LedgerEntrySet.cpp", line=96, 
    function=0x1009540 <LedgerEntrySet::entryCache(LedgerEntryType, uint256 const&)::__PRETTY_FUNCTION__> "SerializedLedgerEntry::pointer LedgerEntrySet::entryCache(LedgerEntryType, const uint256&)") at assert.c:103
#4  0x0000000000c1d05b in LedgerEntrySet::entryCache (this=0x150bc70, 
    letType=ltDIR_NODE, index=...) at src/cpp/ripple/LedgerEntrySet.cpp:96
#5  0x0000000000c20f1a in LedgerEntrySet::dirAdd(unsigned long long&, uint256 const&, uint256 const&, boost::function<void (boost::shared_ptr<SerializedLedgerEntry> const&)>) (this=0x150bc70, uNodeDir=@0x7fffefff7038: 4294967296, 
    uRootIndex=..., uLedgerIndex=..., fDescriber=...)
    at src/cpp/ripple/LedgerEntrySet.cpp:532
#6  0x0000000000e39460 in OfferCreateTransactor::doApply (this=0x7fffe0004eb0)
    at src/cpp/ripple/OfferCreateTransactor.cpp:434
#7  0x0000000000e35540 in Transactor::apply (this=0x7fffe0004eb0)
    at src/cpp/ripple/Transactor.cpp:220
#8  0x0000000000cbf0c9 in TransactionEngine::applyTransaction (this=0x150bc68, 
    txn=..., params=(tapNO_CHECK_SIGN | tapOPEN_LEDGER), 
    didApply=@0x7fffefffbd0b: false) at src/cpp/ripple/TransactionEngine.cpp:107
#9  0x0000000000c155ff in LedgerMaster::doTransaction (this=0x150bc40, txn=..., 
    params=(tapNO_CHECK_SIGN | tapOPEN_LEDGER))
    at src/cpp/ripple/LedgerMaster.cpp:123
#10 0x0000000000c7e067 in NetworkOPs::processTransaction(boost::shared_ptr<Transaction>, boost::function<void (boost::shared_ptr<Transaction>, TER)>) (
    this=0x150c060, trans=..., callback=...)
    at src/cpp/ripple/NetworkOPs.cpp:305
#11 0x0000000000c8a362 in NetworkOPs::processTransaction (this=0x150c060, 
    transaction=...) at src/cpp/ripple/NetworkOPs.h:168
#12 0x0000000000c7cfc2 in NetworkOPs::submitTransactionSync (this=0x150c060, 
    tpTrans=...) at src/cpp/ripple/NetworkOPs.cpp:182
#13 0x0000000000b9caac in RPCHandler::doSubmit (this=0x7fffefffe560, 
    jvRequest=...) at src/cpp/ripple/RPCHandler.cpp:1135
#14 0x0000000000ba61bb in RPCHandler::doCommand (this=0x7fffefffe560, 
    jvRequest=..., iRole=2) at src/cpp/ripple/RPCHandler.cpp:2518
#15 0x0000000000e15443 in WSConnection<websocketpp::endpoint<websocketpp::role::server, websocketpp::socket::plain, websocketpp::log::logger> >::invokeCommand (
    this=0x7fffc0022c30, jvRequest=...) at src/cpp/ripple/WSConnection.h:85
#16 0x0000000000e126e5 in WSServerHandler<websocketpp::endpoint<websocketpp::role::server, websocketpp::socket::plain, websocketpp::log::logger> >::do_message (
    this=0x7fffc001d370, cpClient=..., mpMessage=...)
    at src/cpp/ripple/WSHandler.h:201
[...]

more on this bug:

1. i set up 4 accounts.
2. acct 4 trusted all the other accts for 100 usd
3. acct 2 acted as a nexus for acct 1 and 3, was trusted by 1 and 3 for 100 usd
4. acct 2 sent acct 3 a 75 iou
5. acct 1 sent a 25 usd iou to acct 2

a path should go from 1 to 3 thru 2, the nexus; however,

instead, 1 shows an iou to acct 4 for 25 usd, this should show as an iou from 2, the nexus.
also, acct 3 showed initally no increase in its iou from 2 and incorrectly showed its dollar balance increasing by $100 (the trust granted amount) rather than the iou amount sent. when i logged out twice, the right balance and iou was shown.
the system incorrectly created an iou balance from 1 to 4 even thou nothing was sent to 4 and the nexus path of 1 to 3 was from 2. the system incorrectly created a path thru 4 instead of 2.

LoadManager.cpp, line 357: "dlTime < 180"

Tail of the log:

2013-May-14 14:36:55 src\cpp\ripple\TransactionAcquire:NFO Acquired TX set 21261661F6D1F75B8C00F4097E43A10A21D533EBC61CF966120D32CA162A8423
2013-May-14 14:36:55 src\cpp\ripple\LedgerConsensus:NFO We have acquired TXS 21261661F6D1F75B8C00F4097E43A10A21D533EBC61CF966120D32CA162A8423
2013-May-14 14:36:55 src\cpp\ripple\LedgerConsensus:DBG Transaction 084D983CD38AAD99399B536F2B7B5B29716C03DDD8324FF6ED286073E29BA2A2 is disputed
2013-May-14 14:36:55 src\cpp\ripple\LedgerConsensus:DBG Transaction 0E80F22610054589A67220006E805E57E58DF675DF77C41CED46DCD5637B20AE is disputed
2013-May-14 14:36:55 src\cpp\ripple\LedgerConsensus:DBG Transaction 2B86314CFE6C1818639B3904076DB2F77AAE19F7B0D0BC91EB29D4B23C7BE4CC is disputed
2013-May-14 14:36:55 src\cpp\ripple\LedgerConsensus:DBG Transaction 65559553750857F252AD2E83F10A089E4CE1C8CACD124D3E5A8A3073C0F87E2B is disputed
2013-May-14 14:36:55 src\cpp\ripple\LedgerConsensus:DBG Transaction 65DE367EB6F75CA67B29E6C351B6310752AF743571EE8FACF719E0FFFB603D5E is disputed
2013-May-14 14:36:55 src\cpp\ripple\LedgerConsensus:DBG Transaction 9B13BEBCA35970C872B68DAAC3AF64D30C1BFB3505E033AA40212AF5AC35D0AB is disputed
2013-May-14 14:36:55 src\cpp\ripple\LedgerConsensus:DBG Transaction AFCF142EA1DABE821741B91CCDEA769DA7D7B94C6BEE4FBD1FB44C944071B65D is disputed
2013-May-14 14:36:55 src\cpp\ripple\LedgerConsensus:DBG Transaction C19E0ABE56F0AE5A1CC79DF42AC753279AF3BC9831100B9A687457175647A041 is disputed
2013-May-14 14:36:55 src\cpp\ripple\LedgerConsensus:DBG Transaction C303701825D438F2B81B04BEF4D887E67B3A8E20F3A344499597A51F99EAAFF0 is disputed
2013-May-14 14:36:55 src\cpp\ripple\LedgerConsensus:WRN By the time we got the map 21261661F6D1F75B8C00F4097E43A10A21D533EBC61CF966120D32CA162A8423 no peers were proposing it
2013-May-14 14:36:55 src\cpp\ripple\TransactionEngine:NFO applyTransaction: terResult=tefALREADY : -198 : The exact transaction was already in this ledger.
2013-May-14 14:36:55 src\cpp\ripple\TransactionEngine:DBG Not applying transaction
2013-May-14 14:36:55 src\cpp\ripple\NetworkOPs:DBG Status other than success -198
2013-May-14 14:36:55 src\cpp\ripple\TransactionEngine:NFO applyTransaction: terResult=tefALREADY : -198 : The exact transaction was already in this ledger.
2013-May-14 14:36:55 src\cpp\ripple\TransactionEngine:DBG Not applying transaction
2013-May-14 14:36:55 src\cpp\ripple\NetworkOPs:DBG Status other than success -198
2013-May-14 14:36:55 src\cpp\ripple\TransactionEngine:NFO applyTransaction: terResult=tefALREADY : -198 : The exact transaction was already in this ledger.
2013-May-14 14:36:55 src\cpp\ripple\TransactionEngine:DBG Not applying transaction
2013-May-14 14:36:56 src\cpp\ripple\NetworkOPs:DBG Status other than success -198
2013-May-14 14:36:56 src\cpp\ripple\TransactionEngine:NFO applyTransaction: terResult=tefALREADY : -198 : The exact transaction was already in this ledger.
2013-May-14 14:36:56 src\cpp\ripple\TransactionEngine:DBG Not applying transaction
2013-May-14 14:36:56 src\cpp\ripple\NetworkOPs:DBG Status other than success -198
2013-May-14 14:36:56 src\cpp\ripple\NetworkOPs:DBG recvValidation B7FDADFF6E6CBD33D2237F9DAB765702E4E5DF191D4D1814EF8E3D22CE570758 from 192.198.89.250
2013-May-14 14:36:56 src\cpp\ripple\ValidationCollection:DBG Val for B7FDADFF6E6CBD33D2237F9DAB765702E4E5DF191D4D1814EF8E3D22CE570758 from n9LFzWuhKNvXStHAuemfRKFVECLApowncMAM5chSCL9R5ECHGN4V added trusted/current
2013-May-14 14:36:56 src\cpp\ripple\TransactionAcquire:WRN Got root TXS node, already have it
2013-May-14 14:36:56 src\cpp\ripple\LedgerAcquire:WRN Timeout(2) pc=2 acquiring 6FAAF035A7689D4B41F6FF0AF171764B4D5426B3E469509FC0E361ADBAFB3A0F
2013-May-14 14:36:56 src\cpp\ripple\TransactionAcquire:DBG Node in our acquiring TX set is TXN we have
2013-May-14 14:36:56 src\cpp\ripple\TransactionAcquire:DBG Node in our acquiring TX set is TXN we have
2013-May-14 14:36:56 src\cpp\ripple\TransactionAcquire:DBG Node in our acquiring TX set is TXN we have
2013-May-14 14:36:56 src\cpp\ripple\TransactionAcquire:DBG Node in our acquiring TX set is TXN we have
2013-May-14 14:36:56 src\cpp\ripple\TransactionAcquire:DBG Node in our acquiring TX set is TXN we have
2013-May-14 14:36:56 src\cpp\ripple\TransactionAcquire:DBG Node in our acquiring TX set is TXN we have
2013-May-14 14:36:56 src\cpp\ripple\TransactionAcquire:DBG Node in our acquiring TX set is TXN we have
2013-May-14 14:36:56 src\cpp\ripple\TransactionAcquire:DBG Node in our acquiring TX set is TXN we have
2013-May-14 14:36:56 src\cpp\ripple\TransactionAcquire:DBG Node in our acquiring TX set is TXN we have
2013-May-14 14:36:56 src\cpp\ripple\TransactionAcquire:DBG Node in our acquiring TX set is TXN we have
2013-May-14 14:37:03 TaggedCache:NFO AcceptedLedger is growing fast 9 of 4 aging at 26 of 60
2013-May-14 14:37:04 src\cpp\ripple\LoadManager:WRN Server stalled for 10 seconds.
2013-May-14 14:37:14 src\cpp\ripple\LoadManager:WRN Server stalled for 20 seconds.
2013-May-14 14:37:24 src\cpp\ripple\LoadManager:WRN Server stalled for 30 seconds.
2013-May-14 14:37:34 src\cpp\ripple\LoadManager:WRN Server stalled for 40 seconds.
2013-May-14 14:37:44 src\cpp\ripple\LoadManager:WRN Server stalled for 50 seconds.
2013-May-14 14:37:54 src\cpp\ripple\LoadManager:WRN Server stalled for 60 seconds.
2013-May-14 14:38:04 src\cpp\ripple\LoadManager:WRN Server stalled for 70 seconds.
2013-May-14 14:38:14 src\cpp\ripple\LoadManager:WRN Server stalled for 80 seconds.
2013-May-14 14:38:24 src\cpp\ripple\LoadManager:WRN Server stalled for 90 seconds.
2013-May-14 14:38:34 src\cpp\ripple\LoadManager:WRN Server stalled for 100 seconds.
2013-May-14 14:38:44 src\cpp\ripple\LoadManager:WRN Server stalled for 110 seconds.
2013-May-14 14:38:54 src\cpp\ripple\LoadManager:WRN Server stalled for 120 seconds.
2013-May-14 14:39:04 src\cpp\ripple\LoadManager:WRN Server stalled for 130 seconds.
2013-May-14 14:39:14 src\cpp\ripple\LoadManager:WRN Server stalled for 140 seconds.
2013-May-14 14:39:24 src\cpp\ripple\LoadManager:WRN Server stalled for 150 seconds.
2013-May-14 14:39:34 src\cpp\ripple\LoadManager:WRN Server stalled for 160 seconds.
2013-May-14 14:39:44 src\cpp\ripple\LoadManager:WRN Server stalled for 170 seconds.
2013-May-14 14:39:54 src\cpp\ripple\LoadManager:WRN Server stalled for 180 seconds.

• Don't allow unauthorized accounts to hold IOUs
  • As a result of rippling
  • Don't allow offer to be created without auth

Arthur has already fixed this, but for the sake of documenting I'll log it here.

Following a path from

Application (line 229)
WSDoor (line 148)
WSDoor (line 102)

Message comes in and is processed by
WSServerHandler (WSHandler.ccp )
on_message, then do_message

WSHandler.cpp line 185 calls WSConnection->invokeCommand

Which creates a RPC Handler on line 82 of WSConnection

I documented the above to demonstrate that untrusted users could gain access to the RPCHandler.
This in and of itself may be a separate bug.

I found that the db->escape function only performs a point recast, there is no real escaping performed.

For example, look at the code in Wallet.cpp for dataDelete on line 123
the key is passed to db->escape which simply recasts the pointer.
If I were to pass
1%20OR%201=1

to the WsService it would convert the %20 to a space. From there I would have

1 OR 1=1

If that was inserted into

DELETE FROM RPCData WHERE Key=%s;

I would end up with

DELETE FROM RPCData WHERE Key=1 OR 1=1;

which would delete all the rows in the RPCData

Where this is really powerful is if more than one SQL Statement could be executed in sequence. then the malicious string might close one statement and add another. which means any SQL String could be used to manipulate the database.

The key to fixing it is to use the proper SQL encoding (sqlEscape) method. for all String parameters being injected into a SQL Statement.

When following https://ripple.com/wiki/Build_instructions#Configure_sjcl and configuring the submodule 'sjcl', the script 'compress/compress_with_closure.sh' fails on line 8 if java is not installed.

The request:

{"command": "account_tx", "account": "rHx..9", "count": true}

yields the response:

{result: {account: rHx..9, count: 0, ledger_index_max: 465046, ledger_index_min: 465046, offset: 0, validated: false}, status: success, type: response}

Expected:

The response should include a 'transactions' field with the account transactions.

After a power failure my rippled was constantly going unavailable, server_info saying state was "full" and then "connected" and then "full" again and so on.

Looking closer at the logs I find this repeating:

2013-Mar-26 15:32:33 LedgerMaster:NFO Advancing accepted ledger to 412475 with >= 2 validations
2013-Mar-26 15:32:33 LedgerMaster:DBG Publishing ledger 412475
2013-Mar-26 15:32:33 LedgerMaster:DBG Ledger 412475 accepted :928B67A85986A12D4CE999B6A6E9FC16DFB3EB3DD27411F3E2EDAD353A18BAB5
2013-Mar-26 15:32:33 NetworkOPs:DBG recvValidation 928B67A85986A12D4CE999B6A6E9FC16DFB3EB3DD27411F3E2EDAD353A18BAB5 from 174.129.1
34.81
2013-Mar-26 15:32:33 ValidationCollection:DBG Val for 928B67A85986A12D4CE999B6A6E9FC16DFB3EB3DD27411F3E2EDAD353A18BAB5 from n9KPnV
Ln7ewVzHvn218DcEYsnWLzKerTDwhpofhk4Ym1RUq4TeGw added trusted/current
2013-Mar-26 15:32:34 Ledger:DBG no resume, too many pending ledger saves
2013-Mar-26 15:32:34 LedgerAcquire:DBG Done: complete 412475
2013-Mar-26 15:32:35 Application:NFO Root master seed: snoPBrXtMeMyMHUVTgbuqAfg1SUTb
2013-Mar-26 15:32:35 Application:NFO Root account: rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh
2013-Mar-26 15:32:35 LedgerMaster:NFO PushLedger: AB868A6CFEEC779C2FF845C0AF00A642259986AF40C01976A7F842B6918936C7
2013-Mar-26 15:32:35 LedgerMaster:NFO StashAccepted: AFC49AC1E7AA317C67E712EDBC3A2DD3C5040928F7B150BE1EF9025F24C9D341
2013-Mar-26 15:32:35 OrderBookDB:DBG OrderBookDB>
2013-Mar-26 15:32:35 OrderBookDB:DBG OrderBookDB<
2013-Mar-26 15:32:35 UniqueNodeList:DBG Validator fetch updated: 2013-Mar-26 15:32:20
2013-Mar-26 15:32:35 UniqueNodeList:DBG Validator score updated: 2013-Mar-26 15:32:24
2013-Mar-26 15:32:35 UniqueNodeList:NFO Bootstrapping UNL: loading from 'validators.txt'.
2013-Mar-26 15:32:35 UniqueNodeList:WRN validators.txt not found: "validators.txt"
2013-Mar-26 15:32:35 UniqueNodeList:NFO Bootstrapping UNL: loading from '"/home/cn/src/NewCoin/build/rippled.cfg"'.
2013-Mar-26 15:32:35 UniqueNodeList:NFO Node Public: n9KPnVLn7ewVzHvn218DcEYsnWLzKerTDwhpofhk4Ym1RUq4TeGw RIP1
2013-Mar-26 15:32:35 UniqueNodeList:NFO Node Public: n9LFzWuhKNvXStHAuemfRKFVECLApowncMAM5chSCL9R5ECHGN4V RIP2
2013-Mar-26 15:32:36 UniqueNodeList:NFO Node Public: n94rSdgTyBNGvYg8pZXGuNt59Y5bGAZGxbxyvjDaqD9ceRAgD85P RIP3
2013-Mar-26 15:32:36 UniqueNodeList:NFO Node Public: n9LeQeDcLDMZKjx1TZtrXoLBLo5q1bR1sUQrWG7tEADFU6R27UBp RIP4
2013-Mar-26 15:32:36 TaggedCache:DBG Validations target size set to 256

So after Ledger:DBG no resume, too many pending ledger saves it just restarts, and this continues in an infinite loop.

If we decide to go with an M-of-N scheme implemented directly as transactions, we need the following:

• Flag to disable the use of the master key to sign transactions for an account
• Transaction to enable and disable the "disable master key" flag
• Transaction to modify the quorum and access list for an account
• Transaction to propose a transaction for an M-of-N account
• Transaction to add/remove an M-of-N account to/from your owner directory (optional)
• Transaction to vote yes or no on a proposed transaction (or change your vote)
• Logic to execute a proposed transaction and create the correct txn/metadata structures.

Note that this is server support only, not client support.

Validation networks are needed to protect the network from validation spam.

In several places, ripple-lib subscribes to events automatically when an event listener is added.

To unsubscribe, it listens to the "removeListener" event. However, this is not officially supported: http://nodejs.org/api/events.html

Consequently, it's not implemented in webpack's port of the EventEmitter class, so it doesn't work in the browser version of ripple-lib.

The correct solution depends on whether Node.js developers wish to officially support this feature in the future or not. I asked them: nodejs/node-v0.x-archive#4977

In the meantime, the only practical effect of this bug is that the client stays subscribed to order books after the user has navigated to a different one. (It will not subscribe multiple times to the same order book.) I think this should be ok, since most people will only access a small number of order books over the course of a session. But if it does cause server load issues, please let me know.

OfferCreate should act as described: https://ripple.com/wiki/Accounts#Reserves

OfferCreate should succeed if it takes any offers.

OfferCreate should be a partial success if takes no offers and has insufficient reserves to create the offer.

OfferCreate should only create the offer if has sufficient reserves.

TrustSet should fail with an error if the line doesn't exist.
And with fail with a different error if the other party previously created the line.

Also consider playing with the quality options.

weex USD/XRP an ask of 3000xrp entered by A doesn't cross with a bid of 4000xrp entered by B.

Please consider renaming the field 'currency' within a transaction message

  'Amount' : { 
     'currency' : 'USD',
     'value' : '1',
     'issuer' : 'r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV'
  }

to something more generic, like resource, object, etc. AFAIU ripple could support non-currency resources/assets/instruments/whatever.

rippled must not connect to IPs not listed as peer IPs when in private mode.

This is required to protect validators from ddos attacks.

When following the test build procedures at https://ripple.com/wiki/Build_instructions#Running_CLI_tests the amount-test.js file returns an error about a missing config.js

I was able to fix this by symlinking to testconfig.js.

I guess there are issues with multiple scripts in that dir, and/or your documentation.

The current wiki page about the testnet (https://ripple.com/wiki/Testnet) is incomplete. For example, there is no information about how to use the web client (or the API?) to create a testnet account. Moreover, it's not clear how to receive testnet ripples.

./rippled --net

RPC call (through WebSocket):

{"command": "account_offers", "account": "r...h"}

Error:

{"error":"noNetwork","error_code":12,"error_message":"Network not available.","request":{"account":"r...h","command":"account_offers"},"status":"error","type":"response"}

The same happens with account_info, etc. Subscribe commands do work.

Currently every validator signs the new ledger it builds by applying the consensus transaction set to the consensus last closed ledger. This signature forms a validation.

This works great for servers. They wait for other validators to sign validations and when they get enough of them, they publish the ledger to clients. If they don't get enough, they know something went wrong and don't publish to clients.

However, this creates a problem for clients. Say the network splits 70/30 during a consensus process. The two portions of the network may reach different consensuses (consenses?). This is fine for servers, they'll reject the ledger on the 30% side because it won't have enough validations. But what about clients? A malicious server may have a significant set of validations from trusted validators to show the client to establish the validity of the ledger no honest server accepted.

The solution proposed is to add an additional step to the consensus process. We will add a new flag to validations to indicate they are full validations that clients should rely on. A validation without that flag set will not be stored by a server but only used to decide to fully validate a ledger. Servers will only store, or report to clients, validations with the new flag set. Clients will ignore validations that don't have the flag set.

(You can think of the old validation as an additional proposal, and that may be the simplest way to implement this.)

• Decide on and document the format for "fuller" validations.
• Correctly track validations of both types
• Use the semi-validations to decide when to fully validate a ledger
• Issue full validations only when a ledger is fully validated
• Offer "fuller" validations (only) to clients

https://ripple.com/forum/viewtopic.php?f=1&t=1721

An example says more than a thousand words:

https://gist.github.com/justmoon/06b562322ee00d29bf59

This is a transaction funding a newly-created account. Note that the CreatedNode metadata contains NewFields which shows any non-default fields. Note however that required fields, such as OwnerCount are not included with their default value.

Not sure if we should change this or leave it. Clearly, not including the fields saves a bunch of bandwidth, but it does mean that the client has to know what the fields are, whether they're required, what their types are and what those types' defaults are. In ripple-lib we're 90% of the way there to being able to provide that information, but third-party libraries may struggle to provide that information correctly if they do not have client-side signing/serialization support.

I zero the line and send away the balance and the line stays.

The server should page the results. only return the first N transactions and tell the client what ledger it stopped on. (ok to send slightly more so you send all the tx in a particular ledger)

When delivering USD in small amounts, there is no room for rounding down after going in reverse. Resulting in a path dry.

You may want to update:

https://ripple.com/wiki/Rippled_build_instructions

For Ubuntu (at least 12.10) there is no need for a custom ppa to install libboost. Just using:

sudo apt-get install libboost-all-dev

will do the trick.

Currently, if a transaction fails to process for some reason, such as "no network" errors, the transaction issuer can be in jam. For example, if transaction 8 is in limbo when 9 fails, issuing a new transaction 8 can make the old transaction 9 valid again. This leads to unpredictable and difficult to handle cases.

Two issues need to be decided:

1. If a transaction is locally submitted and it fails authoritatively, should the transaction be held or dropped? Dropping the transaction allows the transaction issuer to rely on the transaction never being processed. Holding the transaction increases the changes it will be processed.

2. Do we want to add an optional "prior transaction hash" field to a transaction. That way, if you issue transactions 8, 9, and 10 and then something happens, if you issue a new transaction 8, transactions 9 and 10 are forever invalidated (if they used this option) because the original transaction 8 can never be applied.

Regardless of these decisions, we need to make transaction retry a bit more predictable. If we do decide to retry a transaction, we should at least have a defined minimum hold time.

When the source and destination payment currencies are XRP, it is not possible to specify a Paths field. temBAD_SEND_XRP_PATHS is returned by PaymentTransactor::doApply even if the source and destination accounts are different.