Search results

It seems like a consensus is forming around 1. IMO, this is acceptable because compromising the speed/robustness of the MN network for half-baked anonymity makes little sense. However, my question relates to non-MN clients... Evan, does going with option 1 preclude normal clients from having...

Just worked for me. It took about 5 seconds. :smile: Also, the sender side also showed "verified by Instantx" just like the receiving end.

Maybe I am confused (someone that knows for sure please help), but doesn't the popup message mean you need 6 POW confirmations for the inputs used in IX. Thus IX 5 + POW 1= 6 confirmations would not be sufficient. I thinks that explains your bug 2 maybe 3 as well depending on what inputs were...

It doesn't work absolutely 100% of the time. I have had most of mine go through, but a couple fail as well. Just try it again later. Also don't forget that all of the network is not yet updated...

Is IX supposed to work with Darksend? ...because it doesn't in my case. IX without the DS box checked seems to work without any issues. After about 10 seconds... Normal Send & IX: Status: 5/confirmed (verified via instantx), broadcast through 21 node(s)Date: 2015/02/09 23:08To: test...

Hey guys, can I get a couple thousand coins? yBdkFvwAUpW5GWtHKEjrYMTCt4r6wYqFfp

Thanks. As I suggested earlier something simple like changing the color of the icon in recent transactions may be enough. Anything that lets the user know "HEY! you just used this awesome new tech and it worked!" without having to dig around would be great. :wink:

This happened to me too, but only when I sent an input belonging to a denomination that had been through some number (not necessarily the required number) of mixing rounds. Is this also the case for you?

About the GUI, I agree that the transaction tab can be improved later, BUT I think it is important to know at a glance of the overview screen (of the sender and reciever) whether or not instantX was successful. My fear is that with the current implementation "laymen" will not know that it...

Yeah something like "confirmed via Instantx" would be nice.

Well it just happened again at 00:38. Here is a screenshot and the debug... very odd. Link to debug(cropped to only last couple hours): https://drive.google.com/file/d/0BznoXlKqUVrPdXVZVHR3VDlXWlk/view?usp=sharing

Hmm, something unusual happened on the network I think. I got hit by a ton of conflicting txs right at 22:20 (GMT +9) as well as had 10 "payment to yourself" of varying amounts between 22:04 and 22:41. DS was enabled at the time. Some sort of attack? Forking? My client acting up?

Having a similar problem with stuck transactions.

Anybody else having denominations get stuck as unconfirmed. They don't make it into a block unless I restart the wallet...

Nice! So next is InstantX? Or are we going back to testnet for further DS improvements?

Isn't forking usually caused by enforcement? I thought Evan could just turn it off and issue a checkpoint to get everybody back on the right chain. Or is this a more serious problem?

Had this issue as well. A restart of the wallet fixed it. In my case (running as a liquidity provider), it seems to get stuck once or twice a day.

Anybody else notice that Darksend get occasionally stuck? It will run great for 6-8 hours then get stuck with the message "Last successful darksend was too recent" until I restart the client. While it is stuck I get a lot of "DoAutomaticDenominating : Too little to denominate" in the debug log.

Agree with the unlocking of any inputs via the reset button. Not sure why inputs are getting locked/stuck in the first place, but given that it has happened to me several times a one-click way to get the client to resume mixing would be a good feature.

Bug: I have found on several occasions that inputs randomly get locked and stay that way (not denominating) until I restart the client.