[11:01:39] @aguycalled I'm looking into the dao unit tests now. [11:01:39] Will post questions if I have them in a few hours [11:02:55] cool [11:03:16] they don't cover all the possible cases tho, they just show it works [11:03:35] for example, from the consensus parameters only the inflation is tested [13:50:00] It's a good start. We can expand it, I'll see what I can add later. [15:36:02] @aguycalled so regarding the dandelion testing, it only works with incoming connections? and When a Dandelion transaction arrives, the transaction MUST be added to the stempool and MUST NOT be added to the mempool. but i can still monitor the transactions with getmempoolinfo? [15:37:19] you can with getstempoolinfo if it did not move to the mempool yet [15:38:59] right, i meant that i thought im not supposed to, but i can see transactions with getmempoolinfo. [15:39:44] that should mean the tx broadcasted correctly [15:41:30] node 1 starts tx, sends it to node 2. node 2 put it on the stempool and rolls a dice, depending on this random number, node 2 sends the tx to another random (only 1) node (goes to the stempool) or to every node it is connected (goes to the mempool. if the tx goes to node 3 in the stempool the same process is repeated until it is broadcasted to every nodes mempool [15:41:33] does that make sense? [15:42:59] it does, i have been monitoring node 2, and i can always see it in mempool, or maybe getmempoolinfo takes data from mempool and stempool? [15:43:29] ill double check [15:47:20] another question, Dandelion routes are a map of inbound peers to Dandelion destinations but from what i've seen, it was more like the other way around, transactions are sent to inbound peers from nodes [15:48:14] i'll test 1 >2 >3 > 4 >5 >6 [15:48:26] and see if the transactions go out [15:49:46] this means that when a transaction comes from a concrete node [15:49:56] it will always be broadcasted to the same node [15:50:20] the dice is rolled only once every 10 minutes i think to choose which node the transaction will go to [15:51:41] Inbound peers consist of all currently connected peers that initiated the peer connection. Outbound peers consist of all currently connected peers that were connected to by this node. Dandelion destinations are a subset of outbound peers. [15:52:02] from this it seems to be it should only broadcast to outbound nodes. [15:53:43] i'm checking the tx is only added to the mempool if its a normal tx or if the dandelion tx already broadcasted completely (moved from stem to fluff phase). also getmempoolinfo shows only mempool not stempool [16:54:02] you can also use -debug=dandelion [16:54:12] to see some related things on the debuglog [17:23:03] testing now sending a transactino from 1 to 5 with setup 1>2>3>4>5 (> means the left addnode="the right") [17:23:47] transaction hangs [17:24:35] what does hangs mean? [17:24:47] just sits in the mempool of node 1 [17:24:59] stuck on stempool or mempool? [17:25:14] ok [17:25:17] ill try to reproduce it [17:25:26] https://cdn.discordapp.com/attachments/416000318149754881/628251062205153291/unknown.png [17:25:30] do you run manually the 5 wallets or have some script for it? [17:25:33] https://cdn.discordapp.com/attachments/416000318149754881/628251092693811211/unknown.png [17:25:34] both [17:26:07] manually, i just do while true; do ./navcoin-core/src/navcoin-cli getmempoolinfo; ./navcoin-core/src/navcoin-cli getstempoolinfo; date ; sleep 1 ; done for all the nodes in between [17:32:56] @aguycalled [17:33:12] Did that issue on compiling navcoin-core get resolved? [17:33:20] The one from the exchange? [17:33:30] did not hear back [17:41:26] do blocks broadcast between nodes @salmon3s ? [17:43:43] yup, same hash on node 1 and node 5 [18:02:09] so a node will have to launch with -dandelion to have it enabled right? can't launch normally and choose to have a dandelion transaction when creating one like in a toggle box? [18:02:44] it is enabled by default [18:03:12] nope, it does not work on an individual basis per tx [18:04:21] okay, so in the future, transactions will probably not be shown immediately 😛 kinda sad but i guess that's the trade off for having more privacy [18:04:39] the delay should be unnoticeable [18:05:07] @aguycalled Alright, so I guess they resolved it? [18:05:29] its monday and they are on the usa, probably they havent seen my msg yet [18:06:41] well from what i saw on devnet, normal transactions used to be instant but dandelion ones are usually around 15-30 sec [18:07:04] im checking that looks like they are not broadcasting as they should in the stem phase [18:07:18] oh okay [18:07:19] u are def good finding bugs 🙂 [18:07:26] haha [18:22:26] but seems like a bug in the original implementation [18:22:51] is it live on bitcoin now? [18:22:51] nope [18:22:54] i remember seeing some coin implementing it [18:23:08] yep, veil, zcoin, dgb [18:23:35] gotcha, probably saw an article on zcoin [18:24:08] node 1 tells an outbound node 2 i have dandelion tx with hash x. node 2 asks back for the tx to node 1. then node 1 only delivers the tx if the node is inbound, thats where the bug is [18:24:23] because it selected an outbound node it never delivers it [18:24:39] until the embargo expires and the tx is normally broadcasted [18:26:43] i thought from the article it should only deliver to outbound nodes, and in my case, why did it just stay in mempool and not broadcast as normal transaction? [18:30:52] @aguycalled if they are running ubuntu 16.04, they might have run into similar issue to @prodpeak [19:08:01] i just committed a patch @salmonskinroll [19:08:16] @mxaddict yeah i told them to try upgrading gcc or with disable-hardening [19:10:46] k, will test it [20:23:10] what's the expected time for a transaction to be reflected on the receiving side? @aguycalled [20:23:42] and the getbalance report unconfirmed amount? [20:27:14] in a small network it should be almost immediate [20:31:51] still taking around 20 sec [20:33:50] i've ran 5 nodes with ./src/navcoind -rpcport=2000{n} -port=3000{n} -addnode=127.0.0.1:3000{n+1} -dandelion=1 -printtoconsole -devnet -debug=dandelion -datadir=/Users/alex/navcoin-core/data{n} -rpcuser=user -rpcpassword=password -staking=false then ./src/navcoin-cli -rpcport=20001 -rpcuser=user -rpcpassword=password sendtoaddress node5address 1 and saw it broadcast instantly [20:35:21] yeah, im seeing the same thing now, getbalance doesn't show unmined transactions i guess. something really strange just happend though [20:37:14] for mempool, initially it should just be in stempool right? and then afte ra while it'll be in both stempool and mempool [20:40:57] yes but the while will be very short [20:41:23] in the order of milliseconds in ur setup [20:45:08] yeah trasanctinos become pending almost immediately but i just saw a transaction that was mined in a block but stayed in mempool and then later on mined again. just an orphan i guess, the total receiving amount is correct. [20:53:13] also if i send 3 transactions, they are not all mined in the same block, could even be 3 separate blocks. [21:45:55] are the blocks generated by the same node? [21:46:12] are the transactions going to addresses of different or same nodes? [21:46:42] 1 to 5, and node 1 and 5 staking disabled. not sure which node mined the blocks [21:47:03] some other with coins [21:47:54] right, so just wondering if it's normal that transactinos sent out in the same time are mined not by the immediately coming block but maybe a couple blocks later? [21:52:46] trying to replicate [21:58:54] for me out of 3 txs, 2 are confirmed instantly and the third the broadcast is delayed until the embargo finishes [22:05:03] for me, i send 3 txs and it took 10 blocks for the mempool to be cleared [22:06:25] edited: 10 txs [22:07:39] i think the issue is there are not many nodes in the networks we are testing [22:08:47] and only one connection per node [22:12:03] i connected all nodes with all nodes (5x5) and i see better performance [22:14:15] i'll try it, does it matter which is outoing and incoming? did you set addnode=? [22:14:39] i put all the other nodes as addnode= for every node [22:14:46] okay [22:17:09] https://cdn.discordapp.com/attachments/416000318149754881/628324471966793769/unknown.png [22:17:44] goes fine for me [22:18:13] i sent the txs immediately one after the other [22:21:09] yup, performance is great now with 5x5, but mempool and stempool always have the same size. is it normal? i thought the embargo will take a couple of seconds? [22:21:44] txs do not leave the stempool when added to the mempool [22:22:24] right, but when only connected to 1 node i would see something like this [22:22:24] https://cdn.discordapp.com/attachments/416000318149754881/628325796141858846/unknown.png [22:22:47] now the "size" is always the same on both mempool and stempool [22:23:12] https://cdn.discordapp.com/attachments/416000318149754881/628326000769499146/unknown.png [22:23:44] fine with me, just wondering if it's correct. transactions are just as fast as before now [22:24:59] because with a better network topology txs move to the mempool without having to wait for the embargo to expire [22:25:11] so both pools have the same size until the they are emptied cause the txs got in a block [22:25:37] okay, that sounds reasonable. [22:26:39] gonna try out a couple more things then im good with it. also tested with dandelion=0 as a middle single node and it worked just fine [22:27:29] 👌 [22:27:31] great work [22:27:36] sent u some coins from the bounty [22:27:56] thx man, appreciate it. [22:35:32] how does a forked node get back to the right chain? one of my node forked [22:48:25] and mempool is taking a while to be cleared again, 5-7 blocks to clear 10 txs, also a node forked again after i put them all on same chain. can txs in stempool be mined? [23:32:24] the node fills the block with txs from the mempool (not stempool) [23:33:10] if the txs did not move to the mempool from the stempool it might take until the embargo expires to get them there [23:33:23] how did they fork? [23:35:18] not sure, i initiated 10 txs at a time and usually it'll fork after a couple of tries. im guessing it's because the embargo time varies too much and then somehow they mined the same block with different txs included? [23:35:40] it's still in 5x5 web [23:36:44] maybe some connection between the nodes dropped and there were 2 sides [23:37:24] that can very well be the case as well, i don't understand why 8 connections often times include the same node? just incoming and outgoing? [23:37:47] i would see say 192.168.1.1 twice but one with a port designation [23:38:34] if all nodes are on the same computer they all share the same ip (?) [23:38:54] i have 6 computers running [23:39:13] physically different computers [23:39:23] wow u got a bunch 🙂 [23:39:42] yeah 🙂