Oh man... why are we wasting bandwidth discussing/engaging about/with a well known troll?!? It saddens me to no end why whatever he does in our thread matters....
Are you talking to me? Unless you are pookie's alt... then no. |
|
|
|
|
Oh man... why are we wasting bandwidth discussing/engaging about/with a well known troll?!? It saddens me to no end why whatever he does in our thread matters....
|
|
|
|
Hello, is on this coin Proof-of-Stack ? ...if itīs possible I want to let my coins work for me  Yes, we are only POS now. 3.3% per year. Stake starts at 8 hour to 30 days. |
|
|
|
With stealth address, you need these steps. That's the whole point of the initial question of "how do you track and confirm a stealth transaction if the sender don't even know where the coins got sent to".
Step #4 can be shifted to the receiver side if you want. I guess the option is here for either the sender/receiver to do that anonymizing from the public blockchain, but the steps is not optional for both sides.
Well, there must be some other way to verify that coins arrived to the stealth address, otherwise it's inconvenient to do so many steps. I think special acknowledgement mechanism could be built into the protocol. My solution is only based on the current parameters that we have been revealed to so far. We don't even know how stealth transaction exactly work yet. Maybe when it's released, there is already a confirmation system in place. So, these are all just assumptions. I have faith that Dan and team will deliver us a really great stealth solution. |
|
|
|
If you MUST track it and still wants it to be anonymous, it's quite straightforward with XC. You just need to take some additional steps.
1. Receiver: Generate a new public address
2. Sender: Using XChat gets public address from receiver
3. Sender: Use private transaction to send to another address that sender owns to anonymize his coins
4. Sender: Use those anonymized coins to send to receiver public address. (This is the public transaction on the blockchain that can be used to verify transaction)
5. Receiver (optional): Send the coins received using private transaction to another address of his choice.
So, you can have best of both world with XC.
You don't need step #4 if in step #3 you send directly to the generated address. You can still see in the blockchain, I assume, that coins arrived there even though the transaction is private. You just can't track source. Also #2 is not usually necessary. With stealth address, you need these steps. That's the whole point of the initial question of "how do you track and confirm a stealth transaction if the sender don't even know where the coins got sent to". Step #4 can be shifted to the receiver side if you want. I guess the option is here for either the sender/receiver to do that anonymizing from the public blockchain, but the steps is not optional for both sides. |
|
|
|
And stealt addresses are comming:)
Great addition layer for anon but ....
If I pay someone anon. And not even the chain shows the coin's received how do you settle discussions between buyer and sender? What if that "whatever" seller claims they never received my payment?
Simply speaking, you can't verify anything with 100% anonymity. This makes sense though. I mean, if you want to verify something (trustlessly) then you have to make information public. If it's public it's not anonymous. My guess is that single-use publicly known addresses are the sorts of things that retailers will need to use. Stealth addresses are no good for both seller and buyer, since there's (generally) a mutual interest in payment confirmation or tracking. Ultimately the flexibility that XC will offer with its privacy solution will be something like: - separate control over disclosing amounts and addresses - either amounts or addresses (or both) can be made public, private, or known only to sender and receiver. This way we'll be able to provide appropriate solutions to any given use-case. If you MUST track it and still wants it to be anonymous, it's quite straightforward with XC. You just need to take some additional steps. 1. Receiver: Generate a new public address 2. Sender: Using XChat gets public address from receiver 3. Sender: Use private transaction to send to another address that sender owns to anonymize his coins 4. Sender: Use those anonymized coins to send to receiver public address. (This is the public transaction on the blockchain that can be used to verify transaction) 5. Receiver (optional): Send the coins received using private transaction to another address of his choice. So, you can have best of both world with XC. |
|
|
|
It depends on the firewall settings. If it does not allow incoming connections on 80 / 443, then what's the point?! (Usually firewalls are set to allow only outgoing connections.)
If you are behind a firewalled campus, then of course you can't be a relay XNode. That's where you need to make a http request or post to a node to request for relay. |
|
|
|
Dan's seen both my router's ports open and my firewall exceptions to not only the program but also ports specific to the program. Correct me if I am wrong, but didn't you say it doesn't work for you either due to being on a university network? Regardless, it doesn't work for everyone and whether all the bugs are suppose to be out by 2.5 or 3.0, it should still be something to focus attention on for mass adoption. Hell, if it doesn't work on university networks, a large portion of the demographic (18-35) interested in crypto could have issues.
If it was human error, then it should have been something extremely easy to fix on any number of the remote sessions Dan and I had. The end result is private transfers do not go out to the network/nodes but regular incoming/outgoing is fine. Whether it does nothing due to having it set as unlock for staking only and entering passphrase on sends or unlocking completely before initiating and getting the error 101, it doesn't work. Dan said it definitely shouldn't be doing the 101 error.
To truly say it's working should mean works for everyone. 99% is not 100%, especially as more and more users are downloading wallets and wanting to try out features. Any regular Joe should be able to download the wallet and send anon transfers and that simply isn't the case in its current state.
Thanks Even bitcoin-qt won't sync on a university network due to the firewall. I never found a way around that although I tried pretty hard - with a real live version of Dan. I imagine there would be issues with encryption and tor as well. (I'm afraid 18-35 year olds may have to pay for their own internet). I should add that depending on your network it may automatically flag peer-to-peer stuff as suspicious unless you add an exception. You should probably check. (Anyway I wouldn't class getting your crypto to work over university networks as regular Joe level.) Edit: on the other hand if Dan can get the XC wallet to work automatically behind university firewalls - which maybe he can - then that would be big bonus. I wonder if we can make a regular http port 80 type block sync where it just download the blockchain regularly without using any special RPC type call? It won't necessarily work for private transaction immediately nor XChat, but at least you can get the latest blockchain info? That might work so you could at least have the wallet functioning regardless of firewalls. That would be a big plus - I was imagining for the private stuff to behave like firefox when it adds exceptions - i.e. it figures out there's a firewall blocking it and brings up an option to add an exception. No idea if this is possible generally even - it would have to be able to access the relevant info about your system. Unless... private transaction when it's multipath, can be packaged as non blockchain data that can be sent out through port 80 to nodes that other XNodes wallets can then download and relay it out as RPC?!?? Then... all wallets can be used regardless of if it's behind a firewall. Of course, you will need XNodes that are not behind firewall to get those encrypted non RPC data and relay those out as RPC? So, non firewalled XNode wallets can always help out those that are behind firewall (non http port 80 blocked of course). This sounds like a good solution, however, I would opt to go out on 443 as that would usually be open if 80 is open. Tunnelling out on 443 is usually a good way to bypass firewalls. Ok, maybe I shouldn't have said port 80 for announcing a transaction, but all the common ports that usually won't be blocked, as long as we can send out that encrypted packet to the nodes. |
|
|
|
Dan's seen both my router's ports open and my firewall exceptions to not only the program but also ports specific to the program. Correct me if I am wrong, but didn't you say it doesn't work for you either due to being on a university network? Regardless, it doesn't work for everyone and whether all the bugs are suppose to be out by 2.5 or 3.0, it should still be something to focus attention on for mass adoption. Hell, if it doesn't work on university networks, a large portion of the demographic (18-35) interested in crypto could have issues.
If it was human error, then it should have been something extremely easy to fix on any number of the remote sessions Dan and I had. The end result is private transfers do not go out to the network/nodes but regular incoming/outgoing is fine. Whether it does nothing due to having it set as unlock for staking only and entering passphrase on sends or unlocking completely before initiating and getting the error 101, it doesn't work. Dan said it definitely shouldn't be doing the 101 error.
To truly say it's working should mean works for everyone. 99% is not 100%, especially as more and more users are downloading wallets and wanting to try out features. Any regular Joe should be able to download the wallet and send anon transfers and that simply isn't the case in its current state.
Thanks Even bitcoin-qt won't sync on a university network due to the firewall. I never found a way around that although I tried pretty hard - with a real live version of Dan. I imagine there would be issues with encryption and tor as well. (I'm afraid 18-35 year olds may have to pay for their own internet). I should add that depending on your network it may automatically flag peer-to-peer stuff as suspicious unless you add an exception. You should probably check. (Anyway I wouldn't class getting your crypto to work over university networks as regular Joe level.) Edit: on the other hand if Dan can get the XC wallet to work automatically behind university firewalls - which maybe he can - then that would be big bonus. I wonder if we can make a regular http port 80 type block sync where it just download the blockchain regularly without using any special RPC type call? It won't necessarily work for private transaction immediately nor XChat, but at least you can get the latest blockchain info? That might work so you could at least have the wallet functioning regardless of firewalls. That would be a big plus - I was imagining for the private stuff to behave like firefox when it adds exceptions - i.e. it figures out there's a firewall blocking it and brings up an option to add an exception. No idea if this is possible generally even - it would have to be able to access the relevant info about your system. Unless... private transaction when it's multipath, can be packaged as non blockchain data that can be sent out through port 80 to nodes that other XNodes wallets can then download and relay it out as RPC?!?? Then... all wallets can be used regardless of if it's behind a firewall. Of course, you will need XNodes that are not behind firewall to get those encrypted non RPC data and relay those out as RPC? So, non firewalled XNode wallets can always help out those that are behind firewall (non http port 80 blocked of course). |
|
|
|
Dan's seen both my router's ports open and my firewall exceptions to not only the program but also ports specific to the program. Correct me if I am wrong, but didn't you say it doesn't work for you either due to being on a university network? Regardless, it doesn't work for everyone and whether all the bugs are suppose to be out by 2.5 or 3.0, it should still be something to focus attention on for mass adoption. Hell, if it doesn't work on university networks, a large portion of the demographic (18-35) interested in crypto could have issues.
If it was human error, then it should have been something extremely easy to fix on any number of the remote sessions Dan and I had. The end result is private transfers do not go out to the network/nodes but regular incoming/outgoing is fine. Whether it does nothing due to having it set as unlock for staking only and entering passphrase on sends or unlocking completely before initiating and getting the error 101, it doesn't work. Dan said it definitely shouldn't be doing the 101 error.
To truly say it's working should mean works for everyone. 99% is not 100%, especially as more and more users are downloading wallets and wanting to try out features. Any regular Joe should be able to download the wallet and send anon transfers and that simply isn't the case in its current state.
Thanks Even bitcoin-qt won't sync on a university network due to the firewall. I never found a way around that although I tried pretty hard - with a real live version of Dan. I imagine there would be issues with encryption and tor as well. (I'm afraid 18-35 year olds may have to pay for their own internet). I should add that depending on your network it may automatically flag peer-to-peer stuff as suspicious unless you add an exception. You should probably check. (Anyway I wouldn't class getting your crypto to work over university networks as regular Joe level.) Edit: on the other hand if Dan can get the XC wallet to work automatically behind university firewalls - which maybe he can - then that would be big bonus. I wonder if we can make a regular http port 80 type block sync where it just download the blockchain regularly without using any special RPC type call? It won't necessarily work for private transaction immediately nor XChat, but at least you can get the latest blockchain info? |
|
|
|
Meanwhile.... the good stuff keeps on comin'. I agree, lets stop with the back and forth and get back on track in here. Ok now, someone hook me up with the paperwallet info please I wanna do some experimenting. Is there an XC equivalent of https://www.bitaddress.org ?? I want to print off a few XC paper wallets and give them as gifts. cheers. That would be cool. How many coins can we do this with? I suggested that 400+ pages back You can build it yourself or find someone that can  and yeah it would not take more then 1 day of coding (but I can't) But as always, it's safe to assume the team has this all planned out for launch Check out the thread here about a universal paper wallet generator. https://bitcointalk.org/index.php?topic=386670.0Not sure how well it works or how secure it is. I found it when doing a Google search.  This WORKS! I used 75 for the decimal version. Now, I can have BIP38 encrypted paper wallet for XC!! Totally awesome! When you need to import the key, just use importprivkey from Help->Debug Console to import the private key. Also note: You have to close and reopen the wallet to see the imported address. Of course you probably want to only use this for gifting since you will be missing out on staking if you store it completely cold. Remember the wallet can only import BIP38 address |
|
|
|
This WORKS! I used 75 for the decimal version. Now, I can have BIP38 encrypted paper wallet for XC!! Totally awesome! When you need to import the key, just use importprivkey from Help->Debug Console to import the private key. Also note: You have to close and reopen the wallet to see the imported address. Of course you probably want to only use this for gifting since you will be missing out on staking if you store it completely cold. [/quote] After you type in importprivkey do you then just type in the privite key? [/quote] Yes. Just go importprivkey [private key] |
|
|
|
Alright I finally get to try XChat on my Mac. Please someone send me something:
Address: XUHBQfuEMhxVZG76koBVHMyJ31VtMYVW9E
Public Key: 28EWoPmHj5PDfaJbU9mYebrL8KqRkF8uiHezxShyCvh9U
Trying to send synechist a message and getting error message 'message encryption failed'. What might be amiss? Has anyone received this error message when trying to send a message? Wondering why I'm getting it... No issues here. Been chatting with multiple people. Are you using RC3? |
|
|
|
Organiser, this issue's relevance to XC has been settled. Please acknowledge this and stop repeating yourself.
I've followed your remarks on the Litecoin thread and am not enamoured of your approach.
I'd appreciate it if you'd not transplant it here.
[Old-ish FUD] Turns out you were not even a customer of Jasin's ASIC project. And your allegations about Cache are neither substantiated here nor relevant to this thread. Substantiate them elsewhere and post a link here. In the meantime we'll continue to suspect your motives given you're not an affected party. If you look at his post history, you will see that he frequent DRK and Cloak coin thread.... The picture is beginning to clear. He's a clear troll. I suggest we delete all his posts from our thread. |
|
|
|
Totally irrelevant stuff to XC deleted for trolling
Ya, so go chat about that in the Cache forum? Not here? This is the XC forum. I will be reporting you to moderator soon to get you banned. Totally off topic to our investment in this coin. I suggest you all do the same to this troll. |
|
|
|
And that would have been fine but now there is another code review happening. How the hell does that relate to XChat? That's my point. If the sole focus is XChat, then XChat it is, but if you have time to take on another issue/product, then you have time to look into the issue I am having.
You don't get to decide Dan's priority list. Not saying I should have to. The priorities should be obvious. What's obvious is the number of people here who don't consider your view obvious. IMO code reviews are marketing gold for XC. And I'm the PR person, so my view counts in this respect. Because lack of functionality is good PR. *eyeroll* This wasn't meant to turn into what it has but if you can't see why someone in my position would be frustrated with extra time being devoted to outside projects, well, that just sucks. Nobody is saying your problem isn't an issue... Dan already said he will work with you this afternoon. You know, Dan has his own personal time too. Should he not go to pee because he didn't fix your issue? Should he not sleep? Should he not spend any time with his family? Should he not have any BREAKS? How do you know he's not doing it as pleasure during his breaks? That's what people are saying. He's not a slave. He's obviously working major hours on XC. Which part of the above do you not understand? |
|
|
|
|
Wow. that 391k dump at 96... wtf was that....
|
|
|
|
Devs don't owe us a god damn thing.
this +1000, I personally am tired of the self-entitled sentiment thats been going around. Not saying they are entitled to anything... but, you know people aren't given their btc for free to invest in any coin right? |
|
|
|
Our PR campaign is through PRweb and cost $500. In this case it was funded personally by Dan. The final Rev 2 release will be funded by the community's donations to the PR Fund! My point being; This shit ain't cheep! (PR and Marketing) Thanks Dan! I think that This latest release will raise some eyebrows. Also shows how dedicated Dan is to XC. Not only does he not dump, he funds the PR campaign personally. Such a fresh breath of air for the alt coin scene. |
|
|
|
|
Show Posts
