Currently we absolutely need an exchange !!!
(Modified exchanger -> exchange)
Topic: [ANN] [GLB]Globe – One Currency for One Globe - Polished and Ready for Action - page 37. (Read 113608 times)
December 30, 2013, 07:49:36 AM
December 30, 2013, 07:34:34 AM
- 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.
- 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
December 29, 2013, 11:23:33 PM
- 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.
- 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.
December 29, 2013, 08:42:04 PM
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
December 29, 2013, 07:58:43 PM
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.
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. 
December 29, 2013, 07:45:57 PM
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
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.
December 29, 2013, 07:44:34 PM
December 29, 2013, 07:01:00 PM
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
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
December 29, 2013, 06:03:30 PM
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?
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.
December 29, 2013, 05:35:02 PM
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
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
December 29, 2013, 03:24:35 PM
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?
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?
December 29, 2013, 01:30:56 PM
Anyone willing to share their opinion on the idea above ?
December 29, 2013, 05:50:16 AM
Anyone willing to share their opinion on the idea above ?
December 28, 2013, 05:25:06 PM
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://bitcointalksearch.org/topic/m.4188737
Any suggestions and view would be appreciated.
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://bitcointalksearch.org/topic/m.4188737
Any suggestions and view would be appreciated.
December 28, 2013, 01:24:16 PM
but if one of the admins dies, the wallet will be useless... 
True. Plus users have mentioned a VPS is not secure 
December 28, 2013, 01:16:18 PM
but if one of the admins dies, the wallet will be useless...
December 28, 2013, 01:14:13 PM
just an idea...
Perhaps an better idea is to put the wallet on a separate VPS,
and make a shell script for all admin users controlling Globe.
Next to this script sent an email to all users a login has taken place.
On this script, for every user an password can be given in.
(every user has to login and run the script)
1. The script will make an md5/sha2 of the password, and append it to 1 file. ex..password
like
password=....
2. the script will never encrypt if length of password isnt the length of all passwords combined.
the content of the line 'password'= (combined of all.password files) will be the password of the encrypted wallet.dat
The script should be able to encrypt/decrypt the wallet.dat using the external files mentioned in 1.)
After wallet usage,
every user should supply a new password for the next encryption of the wallet.
this way, everyone has knowledge of wallet access, because not 1 user is possible to open the wallet.
ex. Menu for script
[ User #1 has filled in password. ]
[ User #2 has filled in password. ]
[ No users has filled in password. ]
Choose:
1) user #1 setup password
2) user #2 setup password
3) encrypt wallet *
4) decrypt wallet *
* after decryption/encryption the.password files of all users will be deleted.
Perhaps an better idea is to put the wallet on a separate VPS,
and make a shell script for all admin users controlling Globe.
Next to this script sent an email to all users a login has taken place.
On this script, for every user an password can be given in.
(every user has to login and run the script)
1. The script will make an md5/sha2 of the password, and append it to 1 file. ex.
like
password=....
2. the script will never encrypt if length of password isnt the length of all passwords combined.
the content of the line 'password'= (combined of all
The script should be able to encrypt/decrypt the wallet.dat using the external files mentioned in 1.)
After wallet usage,
every user should supply a new password for the next encryption of the wallet.
this way, everyone has knowledge of wallet access, because not 1 user is possible to open the wallet.
ex. Menu for script
[ User #1 has filled in password. ]
[ User #2 has filled in password. ]
[ No users has filled in password. ]
Choose:
1) user #1 setup password
2) user #2 setup password
3) encrypt wallet *
4) decrypt wallet *
* after decryption/encryption the
December 28, 2013, 12:52:39 PM
20,000 GLB has been sent to bcfanminer to keep in his reserve.
An additional 1 GLB has been sent in exchange for all he has done for the community
An additional 1 GLB has been sent in exchange for all he has done for the community
December 28, 2013, 12:38:02 PM
So guys what do you think about this idea ?
Hey Globe community,
I just came up with an idea that might help completely de-centralize the reserve and price stabilization system. Not sure if this would work in practice but what if we cold-store all the reserves, encrypt the private-keys with a password and send them as a message in the block chain. Would this work? I think the difficult part would be trying to send it into the block-chain and not quite sure how this would be done.
Thanks
Hey Globe community,
I just came up with an idea that might help completely de-centralize the reserve and price stabilization system. Not sure if this would work in practice but what if we cold-store all the reserves, encrypt the private-keys with a password and send them as a message in the block chain. Would this work? I think the difficult part would be trying to send it into the block-chain and not quite sure how this would be done.
Thanks
I didn't quite understand this idea. Do you mean just send a message with encrypted private-key with a password to some address? then the transaction with the message will be stored into the block chain?
If doing this, you will open your private key to the world. If someone hacks your password, then the reserved money will go along the wind.
And this has nothing to do with de-centralization.
Feel free to correct me.
Ok, I will try and better describe it. To my knowledge ( Im still looking this up) you can place messages into the block-chain via a transaction. Once this message is placed everyone on the network will have a copy of this message.
So my idea is as follows. If we encrypt the private key using a strong form of encryption and strong password and place it into the block-chain. Everyone on the network will have the reserves stored in their block-chain but they will not be able to access the private key as the message can't be de-crypted without the password.
Certain trusted individuals will know the password to de-crypt the message and get the private key. This way we do not need to rely on any computers or servers as it will be stored on the block-chain and we can view the encrypted message via a block-chain viewer.
I agree that this does have the added risk that someone might un-encrypt the private key but if we use a strong password and strong method of encryption the key It will take a very long time to crack without the password ( I have been doing some reading and a mix of good encryption and complex password means it could take centuries to crack a message or file) . Please correct me if I am wrong
In the future scripts could be built to help automate the reserve (Exchange API to buy and sell etc) this way we would not even need to know the private-keys as the scripts would handle all the trades.
We would not rely on individual machines but on the entire network. Is this not a more de-centralized method of keeping the reserve ?
December 28, 2013, 12:23:39 PM
Ok. Sending 20,000 I know its slightly above 50% but its a good round number and will average out to 50% in the coming days anyway.
Jump to: