I will post on 1 September a list of coins and update everyday, it will be available in the OP. |
|
|
|
When you release it, I recommend commenting out smsg, voting, etc.
Right now we just need a stable merged chain that is mineable and can do basic transactions.
Oh, and a block explorer that lets us check blocks and transactions.
That's all.
This way if new features cause a problem, you can checkpoint back if necessary and have people revert to the previous client (as much as I hate to think of that happening).
Most of all, we'll have a block explorer to verify if our nodes are current, etc. Launching a new chain with no block explorer is pretty weird and confusing.
Well I agree about voting and talk, but hope that lotto will be implemented soon, as the GF holders are waiting for that feature to be implemented. BTW I have been keeping silent about the questions I am having about the mining operation and the money that still needs to be accounted for for the GF holders (there are still 23 bitcoins unaccounted for, and I guess the mining operation is still making money, so it is getting more), but only because I wanted to give Barwizi time to solve the problems with the blockchain. The question about the accounting Barwizi has to do for at least 23 bitcoins is still standing and should also be answered asap. I have had to make a few modifications whose implications i am trying to test out, i have soomeone who helps but their free time is limited. You want an in-wallet block finder? I can work that in, but that's probably on Thursday, with wallets available friday (unless i get a day off) Current status
Mineable ✔
Chat ✔
Voting ✔
Lotto (mining) ✔
Lotto (tickets ) X As for GF stuff, i agree we need to work on it and close the book on it asap. |
|
|
|
This is actually just a new coin with 1% premine which airdrops on some of the existing coins in various ratios. Unless the scheme is such that the original coins have to be burned to get the new ones I do not see much future. All the successful chains will just continue running as usual and they will see as some free coins to sell.
Quite true. I have been thinking of ways to make it interesting and so far i am considering 1) Limited redeem time 2) anti- PoS , ie when coins reach "stake age" they actually reduce instead of increasing 3) Live reactive minting, is instead of a set PoW reward, it actually fluctuates based on multiple variables such as as i) Tx volume ii) Mint volume iii) (maybe a external feed) either real world indices or from exchanges, likely the first as they are less likely to be manipulated. Burning is the only way to go, it will make sure that all those who get it are actually committed. Its just free coins otherwise. Project is somewhat interesting, but I think its too immature and this version will not be anything. Will still keep an eye out to see how it fares. Convincing people to burn is a huge hurdle and you are right, this is an immature idea, but it takes shape everyday as i get feedbck from community members and the occasional dev says a word or two. for now i have focused my energy on getting all the necessary snapshots and mapping them, once that is done i can start tinkering with all the ideas that have passed through since most are modifications to tx behavior. |
|
|
|
I know rite! I've never been scammed.  LOL .. Experienced traders know what that means. Actually If you had read my posts that were deleted I asked the OP to refute the thread calling him a scammer (I.E. research). rather than doing so he continually deleted my posts asking for such. therefore I have concluded he is in fact a scammer. Pretty simple logic. Even if he is not his actions are to shady to ignore. As I said I have never been scammed. I do do my due diligence.  I know it's pretty tough for someone like you to come in late in a thread that has been selectively pruned and form a informed position. So I wasted my time with this post and we will see if it gets deleted. Seems the op gave up trying to delete so that is a good thing. May save some people their hard earned cash. PMing this just in case it disappears. You'll note that i did refute it with documented proof, however you seem to ignore that completely, which makes your statements false. You must have done that after deleting all the posts to that thread. Maybe if you quoted me or one of the other posts and linked to your rebuttal it might have gotten read. And if you had done that rather than just deleting every post the link spam would have stopped. And possibly the scammer accusations as well. Now why don't you link to your rebuttal and I (and I'm sure others) will read it. It's in the NoirShares thread where it belongs, and i wont apologize for deleting stuff that does not belong here, similarly they made at least 5 threads on the matter, was i to now patrol the forum looking for those threads? I responded In the NRS thread and people independently verified what i said, some agreed some did not. Either way, this thread is for XUC and posts not relating to it are just not welcome, i dont like moderating and you'll notice that some people i did moderate, i sent PMs telling them why i deleted their posts. Let's stay on track in this thread and if you have questions about the accusations and my response, it's all there https://bitcointalk.org/index.php?topic=770744.0that is thread with the people i am answerable to. |
|
|
|
I know rite! I've never been scammed. LOL .. Experienced traders know what that means. Actually If you had read my posts that were deleted I asked the OP to refute the thread calling him a scammer (I.E. research). rather than doing so he continually deleted my posts asking for such. therefore I have concluded he is in fact a scammer. Pretty simple logic. Even if he is not his actions are to shady to ignore. As I said I have never been scammed. I do do my due diligence. I know it's pretty tough for someone like you to come in late in a thread that has been selectively pruned and form a informed position. So I wasted my time with this post and we will see if it gets deleted. Seems the op gave up trying to delete so that is a good thing. May save some people their hard earned cash. PMing this just in case it disappears. You'll note that i did refute it with documented proof, however you seem to ignore that completely, which makes your statements false. |
|
|
|
I think I have some problem.
My address is 9hWttyc1RSwY8FHG6BfTYAwTgphDqxtJyv and I had 7273.916572 NRS.
In the previous NRS, I type dumpprivkey 9hWttyc1RSwY8FHG6BfTYAwTgphDqxtJyv and I got
Private key for address 9hWttyc1RSwY8FHG6BfTYAwTgphDqxtJyv is not known (code -4)
Can you help me?
You shouldn't have to dump any keys to switch to the new NRS chain. Just use your old wallet file as though it were the wallet for the new chain. (Be sure to back it up first, though.) Thanks. I just replaced old wallet.dat to new one. However, I found this error and qt wallet didn't run. "Warning : error reading wallet.dat! All keys read correcly, but transaction data or address book entries might be missing or incorrect." The wallet is not running at this moment because the database of the main server got corrupted, there was a fork at 238, you will have to wait until Barwizi comes with an update. since i have fixed inter-client connectivity that wont be an issue. For now i am just trying to test every possible scenario with transactions to ensure they dont cause a hang. |
|
|
|
I now have daily snapshots of 78 coins
Is there a list of which coins you have snapshots of and the dates you took them of? Yes : A regular update post with the full list of coins would help you to generate interest in this thread. List the coins with their abbreviations (tickers) as well as full names. Snapshot dates for each blockchain , and extra detail can be added later. I will do this asap, havent had much time the past two days. |
|
|
|
...
2) anti- PoS , ie when coins reach "stake age" they actually reduce instead of increasing
...
Or simply they flow back to network instead of being burned. This will ensure both interest rate and unused accounts get "clean" from blockchain. I like this one: 3) Live reactive minting, is instead of a set PoW reward, it actually fluctuates based on multiple variables such as as
i) Tx volume
ii) Mint volume
iii) (maybe a external feed) either real world indices or from exchanges, likely the first as they are less likely to be manipulated. I would complete: add "tx Volume"/"tx's" per block. This way the network will be more secure against overflow of small transactions and will protect the minting against monopolizing techniques. Thanks, i'll definitely look into this |
|
|
|
This is actually just a new coin with 1% premine which airdrops on some of the existing coins in various ratios. Unless the scheme is such that the original coins have to be burned to get the new ones I do not see much future. All the successful chains will just continue running as usual and they will see as some free coins to sell.
Quite true. I have been thinking of ways to make it interesting and so far i am considering 1) Limited redeem time 2) anti- PoS , ie when coins reach "stake age" they actually reduce instead of increasing 3) Live reactive minting, is instead of a set PoW reward, it actually fluctuates based on multiple variables such as as i) Tx volume ii) Mint volume iii) (maybe a external feed) either real world indices or from exchanges, likely the first as they are less likely to be manipulated. |
|
|
|
When can we start to mine?
In a few days. It takes longer to see issues on the net when i do it alone. ? You are saying someone is helping you with the code and now you are saying you do it alone? What was happening at block 238? Why did things go wrong? I have someone helping me with the code, that says nothing about network testing. UPNP is fixed and so is the last IRC issue. there was a fork @ block 238 caused by transactions and corruption of grant database on the central node we were using I decided that i should go it alone until further notice. |
|
|
|
When can we start to mine?
In a few days. It takes longer to see issues on the net when i do it alone. |
|
|
|
Any good news Barwizi?
Well, for one thing i'm not working alone anymore. I will update you on progress in 24 hours. |
|
|
|
In the process of deleting files, starting again, adding files etc I also saw this message several times trying to start and crashing:
************************
EXCEPTION: St13runtime_error
CDB() : can't open database file smsgPubKeys.dat, error -30973
NoirShares in ProcessMessages()
I tend to get the message if I delete all in .NoirShares except for NoirShares.conf and wallet.dat. Deleting wallet.dat seems to solve that, and after that I can replace the wallet with my old wallet again.
Seems we are still stuck at block 238?
I found that starting NoirSharesd -nosmsg helped to keep it from crashing. So we ran for all those blocks fine, until some person out there decided to play with the secure messaging functions of the wallet, which every node began crashing. There are evil people out there that will deliberately exploit holes in code for to gain mining advantages or to steal private keys, etc. Taking a wallet, stuffing it full of features, and hoping it works, is a terrible design idea. Even if it did work for a week or two, and got on exchanges, all it would take is some hacker sending out malicious smsgs messages to crash the wallet at will. It would have affected the stock price and more. I think Barwizi should not be developing alone. We need to find him a code auditor of some sort to find these bugs before the wrong person does. Just because a wallet appears to kind of run, does not mean it isn't exploitable. So the real issue here is to find a proper dev team. I think Barwizi should not be developing alone. You are right that i do need help. That exception is one of many , all centered around the wallet and transactions, specifically clashes with standard way they are meant to operate, a non-conbase tx requires a tx.in, which was not considered here. and is why you get that annonying "the transaction was rejected " message :- the result of tx.in - tx.out being a negative value. since transactions are the basis of the protocol and features, i cant just disable the check, i need to make sure the generation is compatible. all the features work, the problem is in the tx area. |
|
|
|
|
Sorry, had to take a break a bit. Lol, the house seems to be on fire.
I'm afraid you will all have to wait. There will be no more updates until i fix everything. I have taken a snapshot of the small balances you all hold and will pay you all personally.
In that regard i will not be responding as much here until i have everything under control. I'm sorry for all this, but i think i'ts best this goes back on the table.
This may take a while as the errors seem to be runtime erros, and rather than to just keep patching, i will work on every known issue first,.
|
|
|
|
weird thing though is that the log file isn't showing the normal signs of mining IE there are no Gen Mid Hash A: 04000000c78e55883eb5b3160f1e02788cdf75e85e8d4ff37967616d0688930f154b01000000000 00000000000000000000000000000000000000000000000000000000095e41c54a0980020010000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 000010100000095e41c540100000000000000000000000000000000000000000000000000000000 00000000ffffffff0c026f020104062f503253482fffffffff010000000000000000232103071ea 2703ea670c0e1e9b687d621800c0b519cd1c23108bf13f20e6f211adb81ac0000000000
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: 0400000032f474d473d9f7c4d3c2761d6584497eda8ecaa3f6285a551ec6e528591029000000000 00000000000000000000000000000000000000000000000000000000089e41c54a1d60020040000 00000000000000000000000000000000000000000000000000000000000000000073ad310188781 003010100000060e41c540100000000000000000000000000000000000000000000000000000000 00000000ffffffff0c026e020103062f503253482fffffffff010000000000000000232103071ea 2703ea670c0e1e9b687d621800c0b519cd1c23108bf13f20e6f211adb81ac0000000000
Gen Rng Hash B: 21bbc88f63f14a1056799a8d63846ebcdfd0dd5e0b2ed3c3ed9be24ce0455f9e
Gen Amt Rewd A: 22.222
testHash 4a0d047af771fcf14be099436e67879d8b5d3b2e5a459e550bb282b985f09f90
Hash Target 00d6a10000000000000000000000000000000000000000000000000000000000 ^from old version just After grant ...
After grant ...
After grant ...
After grant ...
After grant ...
After grant ...
After grant ...
connection timeout
After grant ...
trying connection 107.170.52.105:33333 lastseen=364312.0hrs
After grant ...
After grant ...
connection timeout
After grant ...
trying connection 24.67.29.246:33333 lastseen=1.0hrs
After grant ...
After grant ...
After grant ...
After grant ...
After grant ...
After grant ...
connection timeout
After grant ...
trying connection 41.78.78.2:33333 lastseen=364312.0hrs
After grant ...
After grant ...
connection timeout
IRC got join
After grant ...
That is the log of the alpha versioon, i have commented out the output lines. Those are used to monitor activity of the code, specifically for debugging purposes. Since the RNG, PoW and verification are working, that part is no longer required. For example, now i am debugging transactions, you'll see my debug log is full of transaction related outputs |
|
|
|
How does having people import their private key make it any easier to calculate the coins due to them? The coins due for each account should be calculated when the snapshot occurs and doesn't require user input so I don't see why a script that securely enables users to provide evidence of ownership and provide an address to receive their coins is any different. You still need to calculate the coins that are due to each account either way. Infact it would be easier to not store every address on your chain and instead have a script that looks at your snapshot data when they go to claim their coins and then sends the correct allocated amount from a pool of redemption coins that is entirely automated removing trust altogether from the system. Plus this way you could keep the redemption system going for far longer and if you wanted have it send you 1% to your address which can be documented on the blockchain this way
I think you need to read all the posts I've made in this regard and the ones on the page and the last from various groups that have already used the same method. You keep hopping from one area to another Find a method since you seem to believe there is one that meets the following criteria : 1) Static balances for all addresses in each and every chain (should be scalable to 200 or 400 coins) 2) Easy proof of ownership and redeeming without any need for technical input, just a few instructions 3) Method of redeeming should be scalable up to 200 or 400 coins 4) Balances should be easily verifiable from block 1 5) anyone can redeem offline, and maintain their privacy Explain to me how what I proposed is not applicable to every single point you mentioned because I seem to be the only one laying out any sort of comprehensive solution. Or better yet explain how your solution fits your own criteria because last time I checked you need to be online in order to sync your wallet that you redeemed signing a message prove ownership on chain A, and we want to redeem on chain B so you want me to write a script that sends coins to chain B when chain A signs a message? here is problem number 1 , this means i have to mine all the coins in advance leaving them in my possession, which means i have to take responsibilty for them NO, I REFUSE. not only is it extra work it means anyone who fails to redeem their coins will begin bothering me about it. And considering the sheer number of possible addresses, that will take the rest of my life. 2) your method is highly inefficient and requires that there be a server that automatically pays out, meaning if someone gains access or plain just DDoS it then redeeming is messed up. 3) Your method requires that i remain on hand and become a help desk for everyone yet a simple do it yourself method that is proven exists 4) Your method requires that users be online to redeem their coins, mine doesn't5) Your method is NOT scalable at all as it requires running every single client of every coin involved 6) in your method balances are not easily verifiable from Block 1 Let me explain How my method trumps yours 1) Once you download the wallet, even if it syncs just the first block, your balance will appear that instant and you are free to move it if you wish. 2) There is no need for proof of ownership, you just redeem your coins and go about your business and even the most technically inept can follow two lines of instructions. 3) It is easily scalable, i already have + 30 Block chain with up to date balances, running a script for a few seconds will compile all the balances and format them ready for inclusion, and if the code is ready, even the genesis block will be mined without any intervention from me. 4) A brand new wallet will reflect your balance 5) you can redeem offline by simply having a copy of the client, no hassle, all security issues got out the window. Ok so are you saying that your blockchain will contain an address for ever single address in every blockchain we can import from? Also point 5 your solution requires that you get the private key from the client which also needs to be running in order to get it. Also if you plan to not control the horde of coins then how will you claim any unclaimed coins? If you can access unclaimed coins from accounts then you could just as easily claim coins from activated accounts. Also how is signing a message any less complicated than dumping a private key? Your point about being online is invalid as it doesn't matter if you are offline when you redeemed because you can't do anything with offline coins so you will have to go online to effectively redeem them. You are correct that the weakness of my system is that you need an online server but it could be feasible to build the system into the actual network. You clearly dont get my explanation. I think you should pick a coin that you may hold and set aside a few coins in a separate address, a few days from now the source code will be opened for review then i can throw you a test client where you can see how very simple abnd straight forward it is. The concept of proving ownership and the ability to redeem in a trivial manner have eluded you. If you have a BTC address that existed since before CLAMS, go and try import your key in that wallet, or in LottoShares. You are correct that the weakness of my system is that you need an online server but it could be feasible to build the system into the actual network. Start a topic on that in development sub forum. |
|
|
|
Barwizi is more than 2 hours that my wallet stopped mining...
"blocks" : 160,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.00000021,
"errors" : "",
"generate" : true,
"genproclimit" : 3,
"hashespermin" : 13.60976274,
"networkhashps" : 5,
"pooledtx" : 0,
I dont see any transactions since 22.50 (now 00.30) from 19.52 to 22.50 I had 8 transactions of 2,22NRS ... I have 1 active connection and wallet is up to date
Lol, its the difficulty, it's gone pretty high. Your wallet is mining "hashespermin" : 13.60976274, |
|
|
|
How does having people import their private key make it any easier to calculate the coins due to them? The coins due for each account should be calculated when the snapshot occurs and doesn't require user input so I don't see why a script that securely enables users to provide evidence of ownership and provide an address to receive their coins is any different. You still need to calculate the coins that are due to each account either way. Infact it would be easier to not store every address on your chain and instead have a script that looks at your snapshot data when they go to claim their coins and then sends the correct allocated amount from a pool of redemption coins that is entirely automated removing trust altogether from the system. Plus this way you could keep the redemption system going for far longer and if you wanted have it send you 1% to your address which can be documented on the blockchain this way
I think you need to read all the posts I've made in this regard and the ones on the page and the last from various groups that have already used the same method. You keep hopping from one area to another Find a method since you seem to believe there is one that meets the following criteria : 1) Static balances for all addresses in each and every chain (should be scalable to 200 or 400 coins) 2) Easy proof of ownership and redeeming without any need for technical input, just a few instructions 3) Method of redeeming should be scalable up to 200 or 400 coins 4) Balances should be easily verifiable from block 1 5) anyone can redeem offline, and maintain their privacy Explain to me how what I proposed is not applicable to every single point you mentioned because I seem to be the only one laying out any sort of comprehensive solution. Or better yet explain how your solution fits your own criteria because last time I checked you need to be online in order to sync your wallet that you redeemed signing a message prove ownership on chain A, and we want to redeem on chain B so you want me to write a script that sends coins to chain B when chain A signs a message? here is problem number 1 , this means i have to mine all the coins in advance leaving them in my possession, which means i have to take responsibilty for them NO, I REFUSE. not only is it extra work it means anyone who fails to redeem their coins will begin bothering me about it. And considering the sheer number of possible addresses, that will take the rest of my life. 2) your method is highly inefficient and requires that there be a server that automatically pays out, meaning if someone gains access or plain just DDoS it then redeeming is messed up. 3) Your method requires that i remain on hand and become a help desk for everyone yet a simple do it yourself method that is proven exists 4) Your method requires that users be online to redeem their coins, mine doesn't5) Your method is NOT scalable at all as it requires running every single client of every coin involved 6) in your method balances are not easily verifiable from Block 1 Let me explain How my method trumps yours 1) Once you download the wallet, even if it syncs just the first block, your balance will appear that instant and you are free to move it if you wish. 2) There is no need for proof of ownership, you just redeem your coins and go about your business and even the most technically inept can follow two lines of instructions. 3) It is easily scalable, i already have + 30 Block chain with up to date balances, running a script for a few seconds will compile all the balances and format them ready for inclusion, and if the code is ready, even the genesis block will be mined without any intervention from me. 4) A brand new wallet will reflect your balance 5) you can redeem offline by simply having a copy of the client, no hassle, all security issues got out the window. |
|
|
|
How does having people import their private key make it any easier to calculate the coins due to them? The coins due for each account should be calculated when the snapshot occurs and doesn't require user input so I don't see why a script that securely enables users to provide evidence of ownership and provide an address to receive their coins is any different. You still need to calculate the coins that are due to each account either way. Infact it would be easier to not store every address on your chain and instead have a script that looks at your snapshot data when they go to claim their coins and then sends the correct allocated amount from a pool of redemption coins that is entirely automated removing trust altogether from the system. Plus this way you could keep the redemption system going for far longer and if you wanted have it send you 1% to your address which can be documented on the blockchain this way
I think you need to read all the posts I've made in this regard and the ones on the page and the last from various groups that have already used the same method. You keep hopping from one area to another Find a method since you seem to believe there is one that meets the following criteria : 1) Static balances for all addresses in each and every chain (should be scalable to 200 or 400 coins) 2) Easy proof of ownership and redeeming without any need for technical input, just a few instructions 3) Method of redeeming should be scalable up to 200 or 400 coins 4) Balances should be easily verifiable from block 1 5) anyone can redeem offline, and maintain their privacy |
|
|
|
|
Show Posts
