[ANN] [GLB]Globe – One Currency for One Globe - Polished and Ready for Action

[sphere]

Ok I think I found a practical way to distribute the reserves on the network. This idea is open to discussion and will not be implemented until I have support of the community.

The following method involves cold-storing GLBs reserves. Reserves held in both BTC as well as GLB can be cold-stored in the Globe network.


1. We create 20 cold-storage wallets (10 for GLB, 10 for BTC). We will have more in the future when we have LTC etc. (Not all at once of-course)

2. We make public keys easily available (post on form) and we can keep adding tax to these cold-storage wallets

3. We encrypt private key with a password using 128-bit AES enryption using a program such as  http://sourceforge.net/projects/simpletextenc/

4. This will result in something like this:

2EBFE714A5968A63117BB68F32F7D2CB799EABFEFADD9BB36CC673D62426CC50AAA3D612097FC4B D33FB57FF4C37F10DB496FC3179176BCC91E415DCDA829E26


5. We can then convert the encrypted string into binary such as this :

00110010 01000101 01000010 01000110 01000101 00110111 00110001 00110100 01000001 00110101 00111001 00110110 00111000 01000001 00110110 00110011 00110001 00110001 00110111 01000010 01000010 00110110 00111000 01000110 00110011 00110010 01000110 00110111 01000100 00110010 01000011 01000010 00110111 00111001 00111001 01000101 01000001 01000010 01000110 01000101 01000110 01000001 01000100 01000100 00111001 01000010 01000010 00110011 00110110 01000011 01000011 00110110 00110111 00110011 01000100 00110110 00110010 00110100 00110010 00110110 01000011 01000011 00110101 00110000 01000001 01000001 01000001 00110011 01000100 00110110 00110001 00110010 00110000 00111001 00110111 01000110 01000011 00110100 01000010 01000100 00110011 00110011 01000110 01000010 00110101 00110111 01000110 01000110 00110100 01000011 00110011 00110111 01000110 00110001 00110000 01000100 01000010 00110100 00111001 00110110 01000110 01000011 00110011 00110001 00110111 00111001 00110001 00110111 00110110 01000010 01000011 01000011 00111001 00110001 01000101 00110100 00110001 00110101 01000100 01000011 01000100 01000001 00111000 00110010 00111001 01000101 00110010 00110110

6. We can then send all the binary data as transactions to a random un-used Globe address ( we can use 1 address for each reserve / set of binaries)

7. We will share the decryption password with a few trusted individuals of the community. If we ever need to access this data we can view transaction history put all the binaries together, de-crypt the code and get the private key to retrieve the reserves

Some points.  

Given what I have heard about 128-bit AES enryption i'm not too worried about people hacking it but am no encryption specialist. So is it possible to hack?

The only issue in my opinion is that sending so many transactions will bloat the block-chain (make it bigger) . But we won't have to do it often as we can keep adding to the reserve with the public-key and we may find a better way to place the encrypted data in the block chain in the future.

I was worried that the price-stabilization mechanism once implemented may cause issues as it will need to constantly sell and buy but you can re-load a cold-storage wallet even after you imported the coins it held. However, I hear it may cause some security issues . Also this method is a bit cumbersome.

Just calculated. Assuming we have that many binaries per encrypted string and we have 20 wallets we would have created approximately 2800 transactions.

For benefits of this idea view : https://bitcointalk.org/index.php?topic=360255.msg4188737#msg4188737
Any suggestions and view would be appreciated.

[sphere]

Anyone willing to share their opinion on  the idea above ?

[sphere]

Anyone willing to share their opinion on  the idea above ?

[bcfanminer]

per my knowledge, the private key will be used only once.
the sender assigns some coins to the private key, then sends the private key as message to a receiver.
the receiver imports the private key to his/her wallet, and gets all the money assigned to the private key.
As you will send money from the reserved wallet frequently to stablize the price, you need create new private keys and assign GLB to each private key frequently.
It looks not practical.

As your goal is to find a secure place to store the reserved wallet, the simplest way might be to encrypt the wallet in a very strong way, and upload it to dropbox/google drive/sky drive/box.
Make the encrypted wallet publicly to everyone, but only a few trusted members know how to decrypt the wallet.
A server can be configured to do the automated trading for price stablization, and automatically backup of the wallet to the aforementioned servers.
In this way, the wallet is publicly accessible, but is spendable by a few trusted members.
What do you think?

[Mike270]

Well, I'm not yet an expert on this as I just recently read about it at
http://www.coindesk.com/bitgo-safe-aims-secure-bitcoin-wallets-multi-signature-transactions/

How about using such a multi-signature method? That way, a "consortium" can decide on the funds and needs a n-out-of-m majority for signing the transaction.

Also: Look at how Freicoin is doing on their end, they have the same problem to solve with their key where the fees go to.
About concerns of the dev using the coins other than expected: Well, whatever is decided, he has the private key of the address where they go to NOW anyways... Whomever he hands the key to, he might have a copy. Which does not mean I mistrust him, just stating the fact.
Could be solved by releasing a new code which sends the fee to another address, moving funds to that new address, and have that new address generated by a to-be-nominated comittee. Not sure if a multi-signature key would require a new address anyway (assuming that globe supports this feature or can be made to support it, not sure of the requirements here).

Kind regards
Mike

[sphere]

per my knowledge, the private key will be used only once.
the sender assigns some coins to the private key, then sends the private key as message to a receiver.
the receiver imports the private key to his/her wallet, and gets all the money assigned to the private key.
As you will send money from the reserved wallet frequently to stablize the price, you need create new private keys and assign GLB to each private key frequently.
It looks not practical.

As your goal is to find a secure place to store the reserved wallet, the simplest way might be to encrypt the wallet in a very strong way, and upload it to dropbox/google drive/sky drive/box.
Make the encrypted wallet publicly to everyone, but only a few trusted members know how to decrypt the wallet.
A server can be configured to do the automated trading for price stablization, and automatically backup of the wallet to the aforementioned servers.
In this way, the wallet is publicly accessible, but is spendable by a few trusted members.
What do you think?

Ok, I read abit and actually tried the cold-storage mechanism my-self with https://www.bitaddress.org/ and the Globe Qt wallet. You can keep adding funds to the cold-storage wallet with the public key. To import all the funds in the cold-storage wallet you open up the console and type importprivkey followed by the private key. This takes all the funds stored in cold-storage and places the funds into your wallet.

Have a go your-self goto https://www.bitaddress.org and generate a private and public key. Send multiple transaction to the public key and then retrieve all the money using the importprivkey command in the console.

Yes I just tried, the private key can only be used once as after you claim the private key any further funds sent to the corresponding public key will go into your wallet.

Maybe I was not not clear in my first post. The price stabilization mechanism and reserve are two different things we have simply merged them temporarily because we do not have an exchange.

The price stabilization mechanism as you said will buy/sell and doing this via this mechanism would be im-practical but the reserve is different. The reserve does not involve it self in speculation (buying/selling), The reserve will be never sold and can therefore be inserted into the block-chain practically using the method I mentioned before.

As for the price stabilization we can still use cold-storage wallets but we would need to keep changing them and it may be in-practical to store them on the block-chain (bloat it too much). But the process could be automated with a macro or script and we could view the effect it has on the block-chain. If we find that the price-stabilization mechanism is bloating it too much due to the large number of transactions its making we could opt for your method of uploading it onto drive / dropbox etc.

EDIT : We can re-use the private keys if we delete the wallet.dat file after retrieval of funds . So lets say we had to retrieve some BTC the scrypt could put the binaries together de-crypt using password and empty the contents of the cold-storage wallet. The scrypt could then sell all these Bitcoins in the exchange. If we need to put money back into the cold-storage wallet we can delete the wallet.dat file. This will means private key will no longer be associated with that wallet and we can start sending funds to the same public key. If we need to retrieve BTC again we can repeat the process by re-importing the private key. <I will try this in practice when I have some spare time>

[sphere]

Well, I'm not yet an expert on this as I just recently read about it at
http://www.coindesk.com/bitgo-safe-aims-secure-bitcoin-wallets-multi-signature-transactions/

How about using such a multi-signature method? That way, a "consortium" can decide on the funds and needs a n-out-of-m majority for signing the transaction.

Also: Look at how Freicoin is doing on their end, they have the same problem to solve with their key where the fees go to.
About concerns of the dev using the coins other than expected: Well, whatever is decided, he has the private key of the address where they go to NOW anyways... Whomever he hands the key to, he might have a copy. Which does not mean I mistrust him, just stating the fact.
Could be solved by releasing a new code which sends the fee to another address, moving funds to that new address, and have that new address generated by a to-be-nominated comittee. Not sure if a multi-signature key would require a new address anyway (assuming that globe supports this feature or can be made to support it, not sure of the requirements here).

Kind regards
Mike

Hi Mike,

Thanks for your contribution. I think this would be even more impractical then my idea   . The price stabilization mechanism would be run by a script and buy/sell based on predefined rules. The mechanism once their is market-depth may work very fast buying and selling multiple times throughout the day to ease price movements. Asking a group of people 24/7 to approve or disapprove a transaction would therefore be difficult.

For the reserve I think there are other methods of making sure that 1 individual alone cannot access the reserves. For example we could set passwords to access the "private key de-crypting password". The passwords could then be switched between members. So 1 member would need another members password to access the "private key de-crypting password". We can go more detail into this lets fist embed the reserve and price stabilization mechanism into Globe.

To be honest we have already had to change the code twice after release. You can see the effect it has had on Globe. I would rather not edit the code and release the QTs again because it may just kill Globe.  

If I have missed anything or you want to discuss this further feel free to post

[bcfanminer]

per my knowledge, the private key will be used only once.
the sender assigns some coins to the private key, then sends the private key as message to a receiver.
the receiver imports the private key to his/her wallet, and gets all the money assigned to the private key.
As you will send money from the reserved wallet frequently to stablize the price, you need create new private keys and assign GLB to each private key frequently.
It looks not practical.

As your goal is to find a secure place to store the reserved wallet, the simplest way might be to encrypt the wallet in a very strong way, and upload it to dropbox/google drive/sky drive/box.
Make the encrypted wallet publicly to everyone, but only a few trusted members know how to decrypt the wallet.
A server can be configured to do the automated trading for price stablization, and automatically backup of the wallet to the aforementioned servers.
In this way, the wallet is publicly accessible, but is spendable by a few trusted members.
What do you think?

Ok, I read abit and actually tried the cold-storage mechanism my-self with https://www.bitaddress.org/ and the Globe Qt wallet. You can keep adding funds to the cold-storage wallet with the public key. To import all the funds in the cold-storage wallet you open up the console and type importprivkey followed by the private key. This takes all the funds stored in cold-storage and places the funds into your wallet.

Have a go your-self goto https://www.bitaddress.org and generate a private and public key. Send multiple transaction to the public key and then retrieve all the money using the importprivkey command in the console.

Yes I just tried, the private key can only be used once as after you claim the private key any further funds sent to the corresponding public key will go into your wallet.

Maybe I was not not clear in my first post. The price stabilization mechanism and reserve are two different things we have simply merged them temporarily because we do not have an exchange.

The price stabilization mechanism as you said will buy/sell and doing this via this mechanism would be im-practical but the reserve is different. The reserve does not involve it self in speculation (buying/selling), The reserve will be never sold and can therefore be inserted into the block-chain practically using the method I mentioned before.

As for the price stabilization we can still use cold-storage wallets but we would need to keep changing them and it may be in-practical to store them on the block-chain (bloat it too much). But the process could be automated with a macro or script and we could view the effect it has on the block-chain. If we find that the price-stabilization mechanism is bloating it too much due to the large number of transactions its making we could opt for your method of uploading it onto drive / dropbox etc.

EDIT : We can re-use the private keys if we delete the wallet.dat file after retrieval of funds . So lets say we had to retrieve some BTC the scrypt could put the binaries together de-crypt using password and empty the contents of the cold-storage wallet. The scrypt could then sell all these Bitcoins in the exchange. If we need to put money back into the cold-storage wallet we can delete the wallet.dat file. This will means private key will no longer be associated with that wallet and we can start sending funds to the same public key. If we need to retrieve BTC again we can repeat the process by re-importing the private key. <I will try this in practice when I have some spare time>

Good. Let me summarize it.

Reserve:
1. Funds keep going to code-storage wallet (i.e., a private key).
2. A private key is encrypted and sent as a message in a transaction, which is stored in the block chain.
3. The password for the private key is shared in a few trusted members.
4. Anyone, if permitted by the committee, can import the private key to an empty wallet to get the whole reserve.
5. Once finishing to use the reserved GLB, the guy who imported the private key must delete the wallet file, so that the private key can be used again.
6. It's important to make sure that the private key can be imported twice or more.

Price Stabilization:
1. A robot/script creates an empty wallet file, and then imports the encrypted private key to get the full fund in the code-storage wallet.
2. The robot/script trades automatically using the pre-defined rules.
3. Once finishes each run of the price stabilization, the robot/script deletes the wallet file, and the private key can be re-used again.

If every step works well, I think there should be no problem to implement your idea. It's innovative.
To be safer, I do suggest that, instead of publishing your private key at the beginning, we might publish the other, i.e., a new wallet with limited reserve, or the wallet I'm monitoring. Because your wallet keeps receiving the funds. If it's hacked, then the coin might die. If it works well, then you can the private key of the wallet receiving taxes to the block chain.

[Exocyst]

Well, I'm not yet an expert on this as I just recently read about it at
http://www.coindesk.com/bitgo-safe-aims-secure-bitcoin-wallets-multi-signature-transactions/

How about using such a multi-signature method? That way, a "consortium" can decide on the funds and needs a n-out-of-m majority for signing the transaction.

Also: Look at how Freicoin is doing on their end, they have the same problem to solve with their key where the fees go to.
About concerns of the dev using the coins other than expected: Well, whatever is decided, he has the private key of the address where they go to NOW anyways... Whomever he hands the key to, he might have a copy. Which does not mean I mistrust him, just stating the fact.
Could be solved by releasing a new code which sends the fee to another address, moving funds to that new address, and have that new address generated by a to-be-nominated comittee. Not sure if a multi-signature key would require a new address anyway (assuming that globe supports this feature or can be made to support it, not sure of the requirements here).

Kind regards
Mike

Hi Mike,

Thanks for your contribution. I think this would be even more impractical then my idea  . The price stabilization mechanism would be run by a script and buy/sell based on predefined rules. The mechanism once their is market-depth may work very fast buying and selling multiple times throughout the day to ease price movements. Asking a group of people 24/7 to approve or disapprove a transaction would therefore be difficult.

For the reserve I think there are other methods of making sure that 1 individual alone cannot access the reserves. For example we could set passwords to access the "private key de-crypting password". The passwords could then be switched between members. So 1 member would need another members password to access the "private key de-crypting password". We can go more detail into this lets fist embed the reserve and price stabilization mechanism into Globe.

To be honest we have already had to change the code twice after release. You can see the effect it has had on Globe. I would rather not edit the code and release the QTs again because it may just kill Globe. 

If I have missed anything or you want to discuss this further feel free to post

This is precisely the problem, you shouldn't have released Globe until you had (1) built in a described and preferably a decentralized mechanism for stabilizing the price, (2) described the process for applying for & releasing developer funds, (3) Fund-raised the BTC and LTC stabilization funds before release. Globe was likely dead at it's half-baked conception. For the stabilization process to work, Globe needs to be exchange traded at release. I suggest you think seriously about re-developing the concept. Perhaps you should integrate Globe with an escrow-backed virtual counterpart issued in colored coins or on the MasterCoin protocol—the latter option would allow for decentralized, rule-based price stabilization see https://github.com/mastercoin-MSC/spec#escrow-backed-user-currencies.

[sphere]

Good. Let me summarize it.

Reserve:
1. Funds keep going to code-storage wallet (i.e., a private key).
2. A private key is encrypted and sent as a message in a transaction, which is stored in the block chain.
3. The password for the private key is shared in a few trusted members.
4. Anyone, if permitted by the committee, can import the private key to an empty wallet to get the whole reserve.
5. Once finishing to use the reserved GLB, the guy who imported the private key must delete the wallet file, so that the private key can be used again.
6. It's important to make sure that the private key can be imported twice or more.

Price Stabilization:
1. A robot/script creates an empty wallet file, and then imports the encrypted private key to get the full fund in the code-storage wallet.
2. The robot/script trades automatically using the pre-defined rules.
3. Once finishes each run of the price stabilization, the robot/script deletes the wallet file, and the private key can be re-used again.

If every step works well, I think there should be no problem to implement your idea. It's innovative.
To be safer, I do suggest that, instead of publishing your private key at the beginning, we might publish the other, i.e., a new wallet with limited reserve, or the wallet I'm monitoring. Because your wallet keeps receiving the funds. If it's hacked, then the coin might die. If it works well, then you can the private key of the wallet receiving taxes to the block chain.

Sounds good  . I will try the "wallet.dat" deleting practice using a couple GLB later.

[sphere]

This is precisely the problem, you shouldn't have released Globe until you had (1) built in a described and preferably a decentralized mechanism for stabilizing the price, (2) described the process for applying for & releasing developer funds, (3) Fund-raised the BTC and LTC stabilization funds before release. Globe was likely dead at it's half-baked conception. For the stabilization process to work, Globe needs to be exchange traded at release. I suggest you think seriously about re-developing the concept. Perhaps you should integrate Globe with an escrow-backed virtual counterpart issued in colored coins or on the MasterCoin protocol—the latter option would allow for decentralized, rule-based price stabilization see https://github.com/mastercoin-MSC/spec#escrow-backed-user-currencies.

Hi,

Its very well saying all this but convincing an exchange to accept a coin after launch is difficult enough trying to get one before is borderline impossible. To automate the price stabilization we need the API from an exchange, the APIs are not standard and commands / rules very from exchange to exchange you can see how this leads us to the exchange problem again. Finally, I do am not a coder / hacker and was going to get a bitcoin developer to help de-centralize the system using some of the dev tax. This practical way of embedding the reserves and price stabilization mechanism just came into my mind a couple days ago so for that I apologize. If it came to me before I would have done it before launch. I also don't agree with the notion of releasing a counter-part, Bitcoin is already accepted as the virtual gold why try and copy it ? Thanks for you view non-the less  

[atta2k15]

- Work idea out
- Make a roadmap for Globe 2.0.
- Try to hire an c++ coder, with knowledge of building wallets (multi-platform)

All things doesnt have to be 1 one big bang,
as long as you communicate it in the 1# post.

[sphere]

- Work idea out
- Make a roadmap for Globe 2.0.
- Try to hire an c++ coder, with knowledge of building wallets (multi-platform)

All things doesnt have to be 1 one big bang,
as long as you communicate it in the 1# post.

Hi,

Here is what I plan to do in the following days :


1. Test the method of embedding reserves and price stabilization mechanism into block-chain

2. Embed reserves and price stabilization into the block-chain

3. Do a giveaway to promote advancements in the project and increase hash of network


Currently we will not need to create a "Globe 2.0", modify any code and release new QTs as the current method of embedding the price stabilization and reserves does not require us to do so.

Thanks
  

[MassimoJee]

Currently we absolutely need an exchange !!!

(Modified exchanger -> exchange)

[sphere]

Currently we absolutely need an exchanger !!!

Do you mean "exchange" ? If so agreed but others have mentioned that exchanges will only start accepting Globe if we have very high rate of hash this is why I am planning a giveaway that will increase the hash of the network.

[MassimoJee]

exchange yes, sorry.

[sphere]

On another note is the P2P pool : http://www.japool.com:8680/static/  working ?

[Sampey]

Suggestion : do a GiveAway but only for people who are mining for some hours (they must post the Nick on the pool) 

[MassimoJee]

Suggestion : do a GiveAway but only for people who are mining for some hours (they must post the Nick on the pool) 

+1

I suggest to prepare a plan for several giveaways in the next days so that people are encouraged to start mining GLB

[sphere]

Suggestion : do a GiveAway but only for people who are mining for some hours (they must post the Nick on the pool) 

Yes I am going to do this once we have the reserves and price stabilization embedded into the block chain. I hope to start a giveaway tomorrow for miners assuming I can start getting the reserves and price stabilization embedded into the block chain today.