• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

v0.10.9.x Help test RC2 forking issues

Status
Not open for further replies.
I don't think yidakee looked for a local ip address on the list. If he had one masternode wallet with funds (local) "feeding" 2 remotes, and it worked, then we have an issue. But being able to start the second node, just means he started a second node, and it should have shown up on the list with his local ip address. Only the debug log would show if anything hooked up to the second remote masternode with the same masternode private key. After all, there is nothing on the remote computer that gives confirmation like "remote input received". So, I think because it's all so confusing, it was interpreted wrongly.

Been there, done that, LOL

No no Tante, the other way round... flare confirmed it. I had 2 local & cold wallets both pointing to masternode_A (by accident), and both cold wallets got payed. Daemon "maternode list" showed up my remote Masternode_A IP twice as :1 - "darkcoind masternode list pubkey | grep xx.xx." showed both cold addresses associated to same Masternode_A_IP.
So yes, it does work. The only puzzling thing is why Masternode_B went from "no input" to "successful" if there was no handshake. Maybe local.cold_wallet_B masternodeprivkey get propagated and activates the node, but does not get voted on?

I had

local_wallet_A -> key_A -> masternodeaddr=Masternode_A:19999
local_wallet_B -> key_B -> masternodeaddr=Masternode_A:19999 (by accident)

I then trashed wallet_B, created a new one (wallet_B2), created new genkey, pointed to Masternode_B, and masternode_B showed up on list fine and address got payed.

Original wallet_B still has the 1k deposit, but masternode_A dropped the second entry ticket and stopped getting payed.

So you cant exploit it, but multi-ticket seems to work in a buggy kind of way.
 
Last edited by a moderator:
So you cant exploit it, but multi-ticket seems to work in a buggy kind of way.

Yeah, more bug than multiticket feature - i had to restart my cold wallets regularly to keep the 3 hot masternode entries in the list, while your setup remained stable. Maybe it was because i was running all wallets (1x hot + 3x cold) alternating on one machine, one at a time. :grin:

So i would call this setup 'multiticket proxy wallet', as you actually can't shut down the (multiple) cold wallets but their IP addresses are not visible in the masternode list - just the IP of the 'proxy hot wallet'.
 
Last edited by a moderator:
Hate to ask this, but is more testing needed? It sounds like what yidakee did by accident could be exploitable.
 
Hate to ask this, but is more testing needed? It sounds like what yidakee did by accident could be exploitable.

No, it's not exploitable - you need multiple 1000DRK wallets for this. And as soon as you move the funds, the entry will be removed from the masternode list.

For me it's a glitch in the masternode, not checking if a IP is uniquely bound to a 1000DRK vin. Should be straight 1:1.

This was the original message where i confirmed this working:

But you are welcome to test/break/exploit it :)
 
Last edited by a moderator:
I see, sorry yidakee, I wasn't understanding?!

no need to be sorry, thats what where here for, to pick each other's brains out ;)

flare; I didnt actually move the second 1k deposit. I literally deleted the wallet, so its still on the blockchain on an address 0.
http://23.23.186.131:1234/address/mvdVPpgaLxZGv1ddWTKeAsELc7uxAhHuZ6 (this is local wallet B)

What I did with wallet_B was, delete testnet3 entirely, generate a new masternode key, new wallet address 0 (lets call it wallet_B2), point to masternode_B (now with fresh new B2 genkey in conf) with fresh IP also. I sent fresh 1k from and different testnet wallet_C to brand new wallet_B2 address 0. The only thing that remained the same was darkcoin.conf, except for new genkey and server IP.

Which puzzles me, because for all practical purposes, its an entirely new local wallet/masternode key setup. I dont get how the previous local_wallet_B1 was removed from masternode_A pubkey. I didnt start wallet_B1 and remove the funds (check link, 1k + profits still active), nor did I use the same B1 genkey to point to Masternode_B.

How on earth did the network detect that? I really should still be active, being cold storage... (that I simply decided to delete).

Dark magic? :eek:

Only logical answer would be RPC user/password, but that would be weird. What made the network decide to drop local_wallet_B? I believe something else might be pinging info? Its not my local IP, as I've opened SSH ports (recent work project makes me move around, so I didnt lock to my home IP this last week to be able to testnet).

EDIT: Aahh... hold on... Could it be that the local_B1_genkey propagated the network and made masternode_B active, but bound to masternode_A IP through the config file? Because it was only when I stopped masternode_B on EC2 to generate new IP that I stopped getting payments on local_B1. In essence, its a secondary and harmless ghosting effect... ? This makes sense to me
 
Last edited by a moderator:
Yeah, more bug than multiticket feature - i had to restart my cold wallets regularly to keep the 3 hot masternode entries in the list, while your setup remained stable. Maybe it was because i was running all wallets (1x hot + 3x cold) alternating on one machine, one at a time. :grin:

So i would call this setup 'multiticket proxy wallet', as you actually can't shut down the (multiple) cold wallets but their IP addresses are not visible in the masternode list - just the IP of the 'proxy hot wallet'.

hmmm... again, either I got you wrong, or I dont know.

I have 3 VM ubuntu's on my laptop. Local A, B and C. - I have a quad core, so each VM is given 1 core.
I usually run one at a time, but I ran 2 of them at the same time to activate the MNs at the same time, so I could see how long they would each take to get payouts, etc. I then shut them down, so they did go offline immediately. My VM's are configured to have an independent DHCP address.

It was only when I couldn't find the Masternode_B on chaeplin's list that I fired up one of the VM's and did "masternode list | grep xx.xx" ... and from there I couldnt see Masternode_B at all, but Masternode_A showed up twice. Since ghosting issue had been fixed, I saw something was up, so I checked the config files and noticed I had put masternodeaddr=Masternode_A_IP in config file of local_wallet_B

Sorry to be repeating myself, I know this is annoying, but I also know it can be very confusing. So I'm just trying to make it clear!
 
Last edited by a moderator:
hmmm... again, either I got you wrong, or I dont know.

I have 3 VM ubuntu's on my laptop. Local A, B and C. - I have a quad core, so each VM is given 1 core.
I usually run one at a time, but I ran 2 of them at the same time to activate the MNs at the same time, so I could see how long they would each take to get payouts, etc. I then shut them down, so they did go offline immediately. My VM's are configured to have an independent DHCP address.

It was only when I couldn't find the Masternode_B on chaeplin's list that I fired up one of the VM's and did "masternode list | grep xx.xx" ... and from there I couldnt see Masternode_B at all, but Masternode_A showed up twice. Since ghosting issue had been fixed, I saw something was up, so I checked the config files and noticed I had put masternodeaddr=Masternode_A_IP in config file of local_wallet_B

Sorry to be repeating myself, I know this is annoying, but I also know it can be very confusing. So I'm just trying to make it clear!

As you said 'mvdVPpgaLxZGv1ddWTKeAsELc7uxAhHuZ6' was payed, even ip wasn't listed.
http://tdrk.poolhash.org/blocks/masterlist/mvdVPpgaLxZGv1ddWTKeAsELc7uxAhHuZ6.txt

http://tdrk.poolhash.org/blocks/masterlist/19768.txt
No ip in the list, but picked for payee.
Code:
19631.txt: "payee" : "mvdVPpgaLxZGv1ddWTKeAsELc7uxAhHuZ6",
19706.txt: "payee" : "mvdVPpgaLxZGv1ddWTKeAsELc7uxAhHuZ6",
19768.txt: "payee" : "mvdVPpgaLxZGv1ddWTKeAsELc7uxAhHuZ6",
19808.txt: "payee" : "mvdVPpgaLxZGv1ddWTKeAsELc7uxAhHuZ6",



http://tdrk.poolhash.org/blocks/masterlist/mpv3jJQi9otaVTDhheHyKP7k8toLd73ott.txt
Code:
19620.txt:54.88.23.198:19999 1 mpv3jJQi9otaVTDhheHyKP7k8toLd73ott 1402793088442823 836 20285
19620.txt: "payee" : "mpv3jJQi9otaVTDhheHyKP7k8toLd73ott",
19631.txt:54.88.23.198:19999 1 mpv3jJQi9otaVTDhheHyKP7k8toLd73ott 1402794888619541 724 22085
19706.txt:54.88.23.198:19999 1 mpv3jJQi9otaVTDhheHyKP7k8toLd73ott 1402807489379089 361 34686
19724.txt:54.88.23.198:19999 1 mpv3jJQi9otaVTDhheHyKP7k8toLd73ott 1402809289523923 1275 36486
19724.txt: "payee" : "mpv3jJQi9otaVTDhheHyKP7k8toLd73ott",
19768.txt:54.88.23.198:19999 1 mpv3jJQi9otaVTDhheHyKP7k8toLd73ott 1402816490035813 1244 43687
19798.txt:54.88.23.198:19999 1 mpv3jJQi9otaVTDhheHyKP7k8toLd73ott 1402821890365379 467 49087
19798.txt: "payee" : "mpv3jJQi9otaVTDhheHyKP7k8toLd73ott",
19808.txt:54.88.23.198:19999 1 mpv3jJQi9otaVTDhheHyKP7k8toLd73ott 1402823690501551 208 50887
19885.txt:54.88.23.198:19999 1 mpv3jJQi9otaVTDhheHyKP7k8toLd73ott 1402836291595087 386 63488
19885.txt: "payee" : "mpv3jJQi9otaVTDhheHyKP7k8toLd73ott",
20039.txt:54.88.23.198:19999 1 mpv3jJQi9otaVTDhheHyKP7k8toLd73ott 1402859693239768 180 86890
20039.txt: "payee" : "mpv3jJQi9otaVTDhheHyKP7k8toLd73ott",
20040.txt:54.88.23.198:19999 1 mpv3jJQi9otaVTDhheHyKP7k8toLd73ott 1402859693239768 686 86890
20041.txt:54.88.23.198:19999 1 mpv3jJQi9otaVTDhheHyKP7k8toLd73ott 1402859693239768 1037 86890
20042.txt:54.88.23.198:19999 1 mpv3jJQi9otaVTDhheHyKP7k8toLd73ott 1402859693239768 1050 86890
20042.txt: "payee" : "mpv3jJQi9otaVTDhheHyKP7k8toLd73ott",

I don't know, is this part of multi ticket ?
 
As you said 'mvdVPpgaLxZGv1ddWTKeAsELc7uxAhHuZ6' was payed, even ip wasn't listed.
http://tdrk.poolhash.org/blocks/masterlist/mvdVPpgaLxZGv1ddWTKeAsELc7uxAhHuZ6.txt

http://tdrk.poolhash.org/blocks/masterlist/19768.txt
No ip in the list, but picked for payee.
Code:
19631.txt: "payee" : "mvdVPpgaLxZGv1ddWTKeAsELc7uxAhHuZ6",
19706.txt: "payee" : "mvdVPpgaLxZGv1ddWTKeAsELc7uxAhHuZ6",
19768.txt: "payee" : "mvdVPpgaLxZGv1ddWTKeAsELc7uxAhHuZ6",
19808.txt: "payee" : "mvdVPpgaLxZGv1ddWTKeAsELc7uxAhHuZ6",

[...]

I don't know, is this part of multi ticket ?

I had the same effect once, with a address i took offline after beeing online for a week.

The payments continued to come in for some hours (2 payments), but then stopped and never came back.
http://tdrk.poolhash.org/blocks/masterlist/mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1.txt
Code:
18926.txt:184.73.179.148:19999 1 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402682282433720 1480 437402
18927.txt:184.73.179.148:19999 1 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402682282433720 1635 437402
18928.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 160 439202
18929.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 173 439202
18930.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 376 439202
18931.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 500 439202
18932.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1069 439202
18933.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1081 439202
18934.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1254 439202
18935.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1310 439202
18936.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1419 439202
18937.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1454 439202
18938.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1632 439202
18939.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1771 439202
18940.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 2178 439202
18941.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 2605 439202
18942.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 2783 439202
18943.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 2969 439202
18944.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 3100 439202
18945.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 3286 439202
18961.txt: "payee" : "mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1",
19055.txt: "payee" : "mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1",

I never found the reason why this happened, but now i think the culprit was the flaw in the masternode election code in versions prior 0.10.10.1/0.9.10.1, which caused inactive nodes to be selected. In combination with the confirmed flaw in RC3 (Issue #7) that the inactive IPs get agressively cached (only pruned after daemon restart), it makes perfectly sense that this is a issue we had in version <v0.10.10.1/0.9.10.1.

So as long as there are miners with version < 0.9.10.1 it's still possible to see this effect.
 
Last edited by a moderator:
No, it's not exploitable - you need multiple 1000DRK wallets for this. And as soon as you move the funds, the entry will be removed from the masternode list.

For me it's a glitch in the masternode, not checking if a IP is uniquely bound to a 1000DRK vin. Should be straight 1:1.

This was the original message where i confirmed this working:


But you are welcome to test/break/exploit it :)
Were you getting double the chance of a payment when this was done?
 
I had the same effect once, with a address i took offline after beeing online for a week.

The payments continued to come in for some hours (2 payments), but then stopped and never came back.
http://tdrk.poolhash.org/blocks/masterlist/mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1.txt
Code:
18926.txt:184.73.179.148:19999 1 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402682282433720 1480 437402
18927.txt:184.73.179.148:19999 1 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402682282433720 1635 437402
18928.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 160 439202
18929.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 173 439202
18930.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 376 439202
18931.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 500 439202
18932.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1069 439202
18933.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1081 439202
18934.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1254 439202
18935.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1310 439202
18936.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1419 439202
18937.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1454 439202
18938.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1632 439202
18939.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 1771 439202
18940.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 2178 439202
18941.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 2605 439202
18942.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 2783 439202
18943.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 2969 439202
18944.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 3100 439202
18945.txt:184.73.179.148:19999 0 mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1 1402684082600939 3286 439202
18961.txt: "payee" : "mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1",
19055.txt: "payee" : "mrG4cTKi1Luewv3WWu8rQfT6mTosTybRS1",

I never found the reason why this happened, but now i think the culprit was the flaw in the masternode election code in versions prior 0.10.10.1/0.9.10.1, which caused inactive nodes to be selected. In combination with the confirmed flaw in RC3 that the inactive IPs get agressively cached (only pruned after daemon restart), it makes perfectly sense that this is a issue we had in version <v0.10.10.1/0.9.10.1.

So as long as there are miners with version < 0.9.10.1 it's still possible to see this effect.
Oh holy cow, what version are we on now? I thought we were all on 10.10.1! Is there a newer version now? Ugh, I fall behind so quickly!
 
Were you getting double the chance of a payment when this was done?

Exact, this causes your IP to show up multiple times - with different wallet adresses. So basically the way a multiticket system ought to work: Multiples of cold 1000DRK for one hot masternode.

It's up to the user/dev to decide if this is a bug, or a feature and works as designed :grin:
 
Oh holy cow, what version are we on now? I thought we were all on 10.10.1! Is there a newer version now? Ugh, I fall behind so quickly!

No, 0.9.10.1 (client) and 0.10.10.1 (masternode) are current - some people leave out the heading 0. for convenience: 9.10.1 and 10.10.1

I will be happy when darksend code gets open sourced, this dual versioning is still a pain in the ass.....
 
Ah good, thank you.

Does anyone know if, when newer versions do come out, we can just update the remote server? Or will we have to pull out our local nodes and start them up again as well? LOL. It'd be nice if we could just update the remote wallet, as it'd really make things easier (I'm a lazy person as well as an easily confused person- I keep forgetting what I'm in the middle of doing, ROFL, so the easier the better! LOL)
 
Does anyone know if, when newer versions do come out, we can just update the remote server?

Updating remote is enough. I did it between 0.10.10.0 and 0.10.10.1 and my cold wallet setup stayed active after the stop, update and restart.
 
Status
Not open for further replies.
Back
Top