Move coins to new key, send old key?
With my method, there are no keys exchanged at all. So apart from getting free coins, you also get anonymity as a bonus. He is saying that you would move your coins to a new key, wait for the snapshot then move your coins back to your primary key and use the snapshotted key to prevent you/others from getting your primary key I think more explanation is needed for example when you claim your coins do you have them under the same address but in the project x chain? If you happened to be holding NRS before our snapshot you could have a live demonstration, no, the address changes to fit the prefix of the new chain,, it does not remain the same. Ok now this is actually a technical question, how does 1 private key produce multiple public keys? Or does it? I am confused because I don't quiet understand how if we import a private key into your blockchain how will the blockchain be able to know the private key for another chain's public key? I mean I did participate in converting my noirstake to noirstake 2.0 but I just imagined that was because of the same code base. |
|
|
|
|
Someone should build a p2pool like system for burst that would actually be very helpful for a lot of people and would help decentralize the pools power
|
|
|
|
|
What we really need is a p2pool for burst or something like that
|
|
|
|
can the OP be update with direction on how to get NEW NRS from the OLD NRS wallet ? i have just read the last 18 pages and this is getting a little long winded
can we also moderate the forum to keep it short , or create a "information page" and lock is so only Development team can add updated information
Remove all the post - " i am going to bed" , "Soooooo tired" , "scam" in bed red text
if you want to have a personal conversation talk in IRC
HOW TO CLAIM YOUR NRB AND NRS In your OLD NRS wallet
HELP-> DEBUG window -> CONSOLE
type dumpprivkey "insertyouraddresshere"
Copy the result and
in the NEW NRS wallet
HELP-> DEBUG window -> CONSOLE
type importprivkey "resultofdumpprivkey"
Your balance as of snapshot date should show up in the new wallet.
ALWAYS REMEMBER TO BACK UP YOUR WALLET
Please remember that those who have locked wallets you need to unlock them in order to dump your private key |
|
|
|
Move coins to new key, send old key?
With my method, there are no keys exchanged at all. So apart from getting free coins, you also get anonymity as a bonus. He is saying that you would move your coins to a new key, wait for the snapshot then move your coins back to your primary key and use the snapshotted key to prevent you/others from getting your primary key I think more explanation is needed for example when you claim your coins do you have them under the same address but in the project x chain? |
|
|
|
I don't know if this has been said or not. Tired, long day and don't want to read every sentence. 1) Snapshot is taken. 2) Move your coins to another wallet. 3) Use private keys from original wallet that had your coins during the snapshot. Problem solved.  Yeah I already figured out that this was a decent solution however I am unclear whether or not every address is being implemented from all included coins because having to do something like that poses its own problems not to mention the inconvience of having to move coins that would otherwise receive PoS and now resetting your coin age |
|
|
|
ah, i see
it will not work, can you guess why based off my post above or should i explain?
Well I have my notions but an explanation would be nice to understand things from your view also yes I do understand how private keys work and no you haven't answered what i said before about being able to use dumprivkey after unlocking the wallet to get access to all the imported private keys for all addresses |
|
|
|
Couldn't users just sign a message proving ownership of their address in a particular coin? There is no need to expose users private keys.
If there is a rock solid way of doing it, lets find it and i will use it. I promise to search diligently. But my understanding of how proof of ownership works with BTC based currencies, is that you need private keys in order to claim and control your coins, there is no way of getting around this since it is the backbone of the security which prevents arbitrary claiming of coins by any random individual. I suggested this earlier Basically I agree that using private keys for anything other than their original intended software is a bad idea, I mean for one thing it makes this project a lot higher of a target for keyloggers given that they now only need 1 password to access EVERY private key you have imported. It would be better if we could just sign a message using our original wallets and somehow use that as a private key that way everyone is one step removed risk wise and still able to prove ownership.
Also no you can prove you own an address by signing a message which requires you have the private key to sign but anyone can decode , like this I own this account ^message HzKTKv/Ym/lbvi+XE2kCD4EtHcK5btub5utEyIsOXMUS8WPNGSlbJ+5ipvBI1Pq0f2iQLyx/XZ7bJCUtfPvRrgU= ^black coin signature for message BJXcS2aaN6yyDenZXujmk7puMKRzzmNgTc ^black coin public address anyone running blackcoin can go in their wallet go to file verify message and enter what i just gave to prove i own that account because it requires a private key to generate that signature You really arent reading. That proves you own the address so ok, now the chain is active and i planted coins in that address. How are you going to retrieve them?Umm lets take this from the top, I am not suggesting that anything I am saying will work with whatever you have currently planned, HOWEVER, I am suggesting you see if there is a way to implement something that can bridge the gap between your goal and people's concerns. Also are you setting what addresses have what coins in them manually? Or are you scanning other blockchains? Also I think I discovered a potential problem, couldn't someone claim their coins by submitting their private key for an account that has coins in it and then move their coins to another address and then claim those same coins again at infinitum due to the fact that each address has a unique private key? Or the reverse happens where someone tries to claim their coins but you already set the values for the network and their coins are locked in some other address(es)? |
|
|
|
Couldn't users just sign a message proving ownership of their address in a particular coin? There is no need to expose users private keys.
If there is a rock solid way of doing it, lets find it and i will use it. I promise to search diligently. But my understanding of how proof of ownership works with BTC based currencies, is that you need private keys in order to claim and control your coins, there is no way of getting around this since it is the backbone of the security which prevents arbitrary claiming of coins by any random individual. I suggested this earlier Basically I agree that using private keys for anything other than their original intended software is a bad idea, I mean for one thing it makes this project a lot higher of a target for keyloggers given that they now only need 1 password to access EVERY private key you have imported. It would be better if we could just sign a message using our original wallets and somehow use that as a private key that way everyone is one step removed risk wise and still able to prove ownership.
Also no you can prove you own an address by signing a message which requires you have the private key to sign but anyone can decode , like this I own this account ^message HzKTKv/Ym/lbvi+XE2kCD4EtHcK5btub5utEyIsOXMUS8WPNGSlbJ+5ipvBI1Pq0f2iQLyx/XZ7bJCUtfPvRrgU= ^black coin signature for message BJXcS2aaN6yyDenZXujmk7puMKRzzmNgTc ^black coin public address anyone running blackcoin can go in their wallet go to file verify message and enter what i just gave to prove i own that account because it requires a private key to generate that signature |
|
|
|
Giving up private keys for multiple coins to one untrusted source?   Do you even understand what i said? Noone except you knows your private key, you are not giving them up to anyone. If I am confused then perhaps you can help. Are you saying that you don't need to input private keys into a XUC wallet which communicates with to the internet? How is that different from moving your BTC keys from one wallet to another  In that case we should completely abolish the whole idea of private keys from crypto altogether. If you have doubts, how about looking through the source code when it's available, else all this is is FUD. There is a BIG difference. BTC has been around a long time and I would be moving keys between trusted wallets. However, I don't know you, your coin, your software, or your full intentions. Also, when I ask reasonable questions and you seem to get frustrated, that is a bad sign. Basically I agree that using private keys for anything other than their original intended software is a bad idea, I mean for one thing it makes this project a lot higher of a target for keyloggers given that they now only need 1 password to access EVERY private key you have imported. It would be better if we could just sign a message using our original wallets and somehow use that as a private key that way everyone is one step removed risk wise and still able to prove ownership. I think that only applies if you use a wallet other than the one i will provide. The risk is there for those who go outside the prescribed directions, the keys are only imported and no other copy is kept, so if your wallet is kept secure there will be no problems. As for key loggers if a user opens themselves up to it then there is little we can do to help , it's no different a situation from right now, you could be unfortunate enough to have one on your machine already trying to get at your keys, how is that in anyway related to this project? This is a crypto currency that will be based off Bitcoin code, securing your wallet is your job , how have you been keeping them safe all this time and how does this project change that? Again this is just FUD since all the security issues are on the users end not the actual app itself. As for using your suggested method, i agree that would be great IF it was possible, but we are not worried about ownership in this case. we are concerned about your balance to use to calculate your % stake. The method you described above still requires you to have a way to redeem the coins attached to your address, which plain and simple is still your private keys. Wait, so you are saying that after we import using our private keys we/someone can't use dumpprivkey after unlocking the wallet? |
|
|
|
Giving up private keys for multiple coins to one untrusted source? Do you even understand what i said? Noone except you knows your private key, you are not giving them up to anyone. If I am confused then perhaps you can help. Are you saying that you don't need to input private keys into a XUC wallet which communicates with to the internet? How is that different from moving your BTC keys from one wallet to another In that case we should completely abolish the whole idea of private keys from crypto altogether. If you have doubts, how about looking through the source code when it's available, else all this is is FUD. There is a BIG difference. BTC has been around a long time and I would be moving keys between trusted wallets. However, I don't know you, your coin, your software, or your full intentions. Also, when I ask reasonable questions and you seem to get frustrated, that is a bad sign. Basically I agree that using private keys for anything other than their original intended software is a bad idea, I mean for one thing it makes this project a lot higher of a target for keyloggers given that they now only need 1 password to access EVERY private key you have imported. It would be better if we could just sign a message using our original wallets and somehow use that as a private key that way everyone is one step removed risk wise and still able to prove ownership. |
|
|
|
I keep getting lines in my log that look like Running BitcoinMiner with 1 transactions in block (233 bytes)
Gen Mid Hash A: 04000000c78e55883eb5b3160f1e02788cdf75e85e8d4ff37967616d0688930f154b0100000000000000000000000000000000000000000000000000000000000000000095e41c54a09800200100000000000000000000000000000000000000000000000000000000000000000000000000000000000000010100000095e41c54010000000000000000000000000000000000000000000000000000000000000000ffffffff0c026f020104062f503253482fffffffff010000000000000000232103071ea2703ea670c0e1e9b687d621800c0b519cd1c23108bf13f20e6f211adb81ac0000000000
Gen Mid Hash B: d8a790425225482f9603b8ec8d1a77c77cd51ab12a0fe2b6af757b855ede548d
Create Block, 623
After grant ...
Create Block, 623
After grant ...
Create Block, 623
After grant ...
Gen Mid Hash C: 20032883 51411080
Gen Rng Hash A: 0400000032f474d473d9f7c4d3c2761d6584497eda8ecaa3f6285a551ec6e52859102900000000000000000000000000000000000000000000000000000000000000000089e41c54a1d6002004000000000000000000000000000000000000000000000000000000000000000000000073ad310188781003010100000060e41c54010000000000000000000000000000000000000000000000000000000000000000ffffffff0c026e020103062f503253482fffffffff010000000000000000232103071ea2703ea670c0e1e9b687d621800c0b519cd1c23108bf13f20e6f211adb81ac0000000000
Gen Rng Hash B: 21bbc88f63f14a1056799a8d63846ebcdfd0dd5e0b2ed3c3ed9be24ce0455f9e
Gen Amt Rewd A: 22.222
testHash 4a0d047af771fcf14be099436e67879d8b5d3b2e5a459e550bb282b985f09f90
Hash Target 00d6a10000000000000000000000000000000000000000000000000000000000
Create Block, 623
After grant ...
Running BitcoinMiner with 1 transactions in block (233 bytes)
Gen Mid Hash A: 04000000c78e55883eb5b3160f1e02788cdf75e85e8d4ff37967616d0688930f154b0100000000000000000000000000000000000000000000000000000000000000000097e41c54a09800200100000000000000000000000000000000000000000000000000000000000000000000000000000000000000010100000097e41c54010000000000000000000000000000000000000000000000000000000000000000ffffffff0c026f020104062f503253482fffffffff010000000000000000232103071ea2703ea670c0e1e9b687d621800c0b519cd1c23108bf13f20e6f211adb81ac0000000000
Gen Mid Hash B: b61c04e60aca0342442ff4d993129419530e19f575b8c40fa33a5573e1ae8e66
Create Block, 623
After grant ...
Create Block, 623
After grant ... is this normal because I never seem to actually get any blocks even though it says I am generating them and gives a reward amount? |
|
|
|
How come I had a higher score and didn't get in the top 5? |
|
|
|
So far only 200 assets have sold for BMPOOL. If the community does not want the idea of community owned hardware to continually create buy pressure, then I will not press it. God knows I am busy enough already with the hashrate NXT community pool. The asset # on the Burst AE is 11375670541237055652 Unless there are some more sizable investors soon, the idea will be abandoned and I will issue buy orders to buy back every share that was sold. (the pool would not be investing in hashlets or the same Scrypt/SHA ASIC hardware that anyone else can buy and get hosted - we would be purchasing additional Scrypt-N FPGA hosted equipment the same way the Hashrate pool has recently invested (as it has an absolutely amazing ROI - less than 6 weeks). no, I won't post the FPGA provider or manufacturer either.  You should probably make a separate thread that is NOT in the burst coin ann thread that way people have a way to easily ask questions and you can update asset holders plus it is easier to market that way Also consider taking non burst currencies as not that many people actually own burst |
|
|
|
BurstMultipool.com was unexpectedly restarted by OVH and offline for a short time - it is back online now. Please point your miners and help generate buy pressure. Completely optimized, automated payouts.
I have also set up the startup scripts so in the future restarts by the VPS provider will result in the pool coming right back online
The pool has issued shares for fractional ownership of it. Dividends will begin once a portion of the shares have sold. The asset number is 11375670541237055652 I just bought the first share  |
|
|
|
BTW how is the uray deadline limiting handled cause from my brief look over at the github it looks like you cant submit things that are lower than your lowest deadline submitted, which while fair from a pool manager perspective the vast majority of other miners are submitting lots of low deadlines that aren't necessarily all lower than their current lowest but regardless of this it positively affects their score. Point being that you should either just slowly scale the threshold or simply use the algo provided by the site to calculate if the share should be uploaded deadline value from miner is converted into share value using this equation
share = 1000 / ( NetDiff * Deadline + 1 ) 0.75
where NetDiff (network difficulty) is calculated by Block0-BaseTarget / Block#N-BaseTarget
note : to prevent user spamming low share, we implement share penalty of -0.001 on each submission for miners who submit nonce that has higher deadline than their (current round) own best deadline, as spamming low share is no use since pool will always pick one best deadline for every submitted nonce per round. IE if your value isn't greater than 0.001 it definetly shouldnt be uploaded but something more reasonable would be to simply assume the -0.001 is in effect and not allow shares that would be worth less than 0.01 safely preventing scores from being lowered and slowly increasing the necessary deadline as needed |
|
|
|
|
Also for some reason my larger plot (which is about 3 times larger) produces 1/2 the shares of the smaller plot which makes no sense at least conventionally
Is this a bug or can you explain this?
|
|
|
|
|
If you try to view the logs in the web gui it then causes some kind of error and stops mining for a bit in the command line and the gui
It then restarts and the number of shares and times mined resets...
|
|
|
|
|
Show Posts
