Can someone be so kind and send even 1 Xivra to my new wallet address so I can make sure it is correct before sending my pool payout to it. Thanks
XWLz8XXywNq281jG1DVAzgt6aupyS6Tq7n
1 XIV sent. |
|
|
|
Imagine hundreds or thousands of AM container farms deployed around the world by nation-states, corporations, and cooperatives. Just because you can't put one in your basement or afford to own and run one yourself does not mean it is not decentralized. In 5 years there could be tens of thousands of them deployed, especially as competitors emerge and follow the model FC is pioneering. This is all possible with btc at $10,000 each.
Gee, you don't think my Homeowner's Association would mind if I stack 5 or 6 containers in my tiny suburban backyard, do you?  "Uh...it's a kids' play structure." |
|
|
|
|
JsmQWynDaB9dVcs84mtQQ7M2vVTYT1HvGw
Thanks.
|
|
|
|
onecoin was cool, i think the exchanges just didn't add it because it messed with their decimal places. It should be revived it was a nice idea.
Agreed. I was sad to see onecoin fade into obscurity at the same time that so many unimaginative clonecoins thrived. |
|
|
|
I think its important that the new clients connect only to the new clients.
Please post your IP on this thread once you have the new client.
In your globe.conf delete all the nodes and use the following command to connect to nodes with the new IP.
connect=XXX.XXX.XXX
Obviously, replace the XXX.XXX.XXX with peoples actual IPs. By using the connect command you will only connect to those specified nodes avoiding the old clients.
The coin has split in two then? I guess this demonstrates how hardforks without enough advance warning before the switchover are a bad idea. |
|
|
|
|
Are mined blocks under the old client going to be valid under the new client?
If not, you'll have some pissed off miners.
|
|
|
|
Yes. 100 Globes received.
Good Good does it reduce in value e.g. in your balance do you see it reduce to like 99.9999XXXX Stable at 100, it is not reducing. Also stuck at 0 confirmations. |
|
|
|
|
Yes. 100 Globes received.
|
|
|
|
|
I recompiled on Linux from the new source, if that counts.
12qBnn8UzfMuwhyfYqudZYEcJxvJbTrYSJ
|
|
|
|
|
I'm not sure which part of the demurrage code you just altered, but at a minimum, wouldn't this cause the old client (people who haven't upgraded yet) and the new client to disagree about how many coins someone has available to spend or has sent in a transactions? At that point you've forked to different, inconsistent versions of the blockchain, I would think.
|
|
|
|
Ok got the new source code up. I think that was the issue but need to check
Won't changing this parameter cause a hardfork? |
|
|
|
When does diff go up because it's a orphan graveyard now.
Unsure. I expected an adjustment at block 2016 but I guess I was reading too quickly... Now diff 4. Presumably rose at block 4032. |
|
|
|
When does diff go up because it's a orphan graveyard now.
Unsure. I expected an adjustment at block 2016 but I guess I was reading too quickly... |
|
|
|
did anyone compile it for Linux from source is working?
edit: maybe pass this one
I compiled it on 64-bit Ubuntu 12.04 with the usual alt-coin dependencies, with one new (to me) twist. Apparently this coin (and freicoin, which I've never complied before) requires a library for arbitrary-precision binary floating-point computation. So I found it necessary to install: sudo apt-get install libmpfr-dev
and then I was able to compile the Globe linux-QT client successfully. Thats great bro but you can download the linux-QT. The problems with the Windows  I like to inspect and compile from source whenever possible. Inside a VM. Also, sphere, I think you need to fix the checkpoints.cpp file in the source, it looks like it has leftover freicoin checkpoints: (10080, uint256("0x00000000003ff9c4b806639ec4376cc9acafcdded0e18e9dbcc2fc42e8e72331"))
(20160, uint256("0x0000000000009708ba48a52599295db8b9ec5d29148561e6ac850af765026528"))
(28336, uint256("0x000000000000cc374a984c0deec9aed6fff764918e2cfd4be6670dd4d5292ccb"))
(30240, uint256("0x0000000000004acbe1ed430d4a70d8a9ac62daa849e0bc708da52eeba8f39afc"))
(37800, uint256("0x00000000000042958bc14bd04b0a2a3c8cc675c248e404c418899e6b7c77e969"))
I'll bet that could be causing some of the problems upthread (e.g. inability to use external miners) if you compiled the binaries with those checkpoints. My compiled client expected 37800 blocks from the outset and kept trying to sync even when it had all the blocks. Ok thanks. Yes i will resolve the checkpoints issue later down the road. Just need to get some traction regarding use going first. Whats the point of having good checkpoints if no-ones using right? thanks again. If you want to fix the checkpoints issue and upload it onto Github I would be more than happy. Hey are these 28336,37800 etc the ref height Those are the block height. |
|
|
|
Ok going now. Will try and sort out checkpoints issue this weekend so those with external miners can start mining and get a exchange post up and running. If anyone has issues please try and help each other out.
I'm not sure how long you have -- guess it depends on the difficulty algorithm and how fast hashing power piles on. The lowest "incorrect" checkpoint is 10080 and the Globe blockchain is already at block 1200 after just a few hours. Plus you need to leave leeway time before block 10080 arrives for everyone to replace their current versions with updated versions of the client. You don't necessarily need to add "good" checkpoints, but you need to delete the bad, inherited checkpoints and redistribute binaries ASAP, I would think. Good luck! |
|
|
|
did anyone compile it for Linux from source is working?
edit: maybe pass this one
I compiled it on 64-bit Ubuntu 12.04 with the usual alt-coin dependencies, with one new (to me) twist. Apparently this coin (and freicoin, which I've never complied before) requires a library for arbitrary-precision binary floating-point computation. So I found it necessary to install: sudo apt-get install libmpfr-dev
and then I was able to compile the Globe linux-QT client successfully. Thats great bro but you can download the linux-QT. The problems with the Windows I like to inspect and compile from source whenever possible. Inside a VM. Also, sphere, I think you need to fix the checkpoints.cpp file in the source, it looks like it has leftover freicoin checkpoints: (10080, uint256("0x00000000003ff9c4b806639ec4376cc9acafcdded0e18e9dbcc2fc42e8e72331"))
(20160, uint256("0x0000000000009708ba48a52599295db8b9ec5d29148561e6ac850af765026528"))
(28336, uint256("0x000000000000cc374a984c0deec9aed6fff764918e2cfd4be6670dd4d5292ccb"))
(30240, uint256("0x0000000000004acbe1ed430d4a70d8a9ac62daa849e0bc708da52eeba8f39afc"))
(37800, uint256("0x00000000000042958bc14bd04b0a2a3c8cc675c248e404c418899e6b7c77e969"))
I'll bet that could be causing some of the problems upthread (e.g. inability to use external miners) if you compiled the binaries with those checkpoints. My compiled client expected 37800 blocks from the outset and kept trying to sync even when it had all the blocks. |
|
|
|
did anyone compile it for Linux from source is working?
edit: maybe pass this one
I compiled it on 64-bit Ubuntu 12.04 with the usual alt-coin dependencies, with one new (to me) twist. Apparently this coin (and freicoin, which I've never complied before) requires a library for arbitrary-precision binary floating-point computation. So I found it necessary to install: sudo apt-get install libmpfr-dev
and then I was able to compile the Globe linux-QT client successfully. |
|
|
|
|
approx how many blocks, currently?
|
|
|
|
Why can't an address be created that you associate a password with like Bitcoin? It's just a different approach. Either you have wallet.dat file with private keys which you must hold in dark cold place, affraid of viruses, bad blocks and your mom cleaning room early morning. Or you have just long passphrase associated - in your brain olny! - with some good old times when grass was greener and light was brighter... oh, nevermind Both ways have some weak points, both required to understand things, both give you good ability to lost everything you have. And I not even speak about thermorectal cryptoanalysis! Ha, very nice! I agree with you, both have weak points. People can stress about a wallet file on their desktop that could be stolen, destroyed with the computer, etc.. I think there are ways to improve security with Nxt model, such as limiting unlock attempts per minute for a specific IP, or perhaps locking a specific Nxt address to an IP as an option for the user, so you could only login from a specific IP address, etc.. There is room for improvement and the good thing about Nxt is you won't get the online hosted wallet thefts like BTC is seeing. Even if implemented, the bolded suggestions would be easily circumvented through custom code, since Nxt can be run entirely locally and doesn't rely on a centralized server/client model. Especially after Nxt source code is released. |
|
|
|
|
If after ten minutes in a bitcoin thread you do not know who the patsy isyou are the patsy.
|
|
|
|
|
Show Posts
