Hello,
I've recently published a Inter-System Specification, which has some suggestions for decentralization of giving (including some code suggestions for implementation of the concept within Bytecoin (BCN)).
Comments are welcome, details are here:
https://github.com/ABISprotocol/ABIS/blob/master/specification_labordayweekend.md
Topic: [BCN] Bytecoin technical discussion - page 2. (Read 14707 times)
Swap was one example, state could be revealed with also other means—for example, a bug (like OpenSSL Heartbleed).
Can only repeat the same: a state is not the only thing that can be leaked. If you can read a state (no matter how), you are likely to read much, much more info.
Quote
No, only 136 bytes out of 200.
Sorry, misread the message.You're right: backward permutation will be infeasible, if we zero a part of the state.
But that does not solve the problem raised by your assumption: a non-encrypted swap still may reveal much more information, even private keys. Treat the illness, not the symptoms
Swap was one example, state could be revealed with also other means—for example, a bug (like OpenSSL Heartbleed).
Quote
No, only 136 bytes out of 200.
Sorry, misread the message.You're right: backward permutation will be infeasible, if we zero a part of the state.
But that does not solve the problem raised by your assumption: a non-encrypted swap still may reveal much more information, even private keys. Treat the illness, not the symptoms
Code:
+ memset(&state, 0, HASH_DATA_AREA);
is completely wrong, it's like set random generator's seed to zero (or the same value) after each execution
No, only 136 bytes out of 200.
regarding generate_random_bytes, I wonder would it be a good idea to provide forward secrecy by zeroing the first HASH_DATA_AREA (136) bytes before returning from generate_random_bytes.
If I understood correctly, previously generated random bytes can be recovered from the state (by backtracking) if it is recovered from e.g. non-encrypted swap.
If I understood correctly, previously generated random bytes can be recovered from the state (by backtracking) if it is recovered from e.g. non-encrypted swap.
Code:
diff --git a/src/crypto/random.c b/src/crypto/random.c
index 08604f2..1b8bfff 100644
--- a/src/crypto/random.c
+++ b/src/crypto/random.c
@@ -92,7 +92,7 @@ FINALIZER(deinit_random) {
}
INITIALIZER(init_random) {
- generate_system_random_bytes(32, &state);
+ generate_system_random_bytes(64, &state);
REGISTER_FINALIZER(deinit_random);
#if !defined(NDEBUG)
assert(curstate == 0);
@@ -120,6 +120,7 @@ void generate_random_bytes(size_t n, void *result) {
assert(curstate == 2);
curstate = 1;
#endif
+ memset(&state, 0, HASH_DATA_AREA); /* Forward secrecy */
return;
} else {
memcpy(result, &state, HASH_DATA_AREA);
Code:
+ memset(&state, 0, HASH_DATA_AREA);
is completely wrong, it's like set random generator's seed to zero (or the same value) after each execution
regarding generate_random_bytes, I wonder would it be a good idea to provide forward secrecy by zeroing the first HASH_DATA_AREA (136) bytes before returning from generate_random_bytes.
If I understood correctly, previously generated random bytes can be recovered from the state (by backtracking) if it is recovered from e.g. non-encrypted swap.
If I understood correctly, previously generated random bytes can be recovered from the state (by backtracking) if it is recovered from e.g. non-encrypted swap.
Code:
diff --git a/src/crypto/random.c b/src/crypto/random.c
index 08604f2..1b8bfff 100644
--- a/src/crypto/random.c
+++ b/src/crypto/random.c
@@ -92,7 +92,7 @@ FINALIZER(deinit_random) {
}
INITIALIZER(init_random) {
- generate_system_random_bytes(32, &state);
+ generate_system_random_bytes(64, &state);
REGISTER_FINALIZER(deinit_random);
#if !defined(NDEBUG)
assert(curstate == 0);
@@ -120,6 +120,7 @@ void generate_random_bytes(size_t n, void *result) {
assert(curstate == 2);
curstate = 1;
#endif
+ memset(&state, 0, HASH_DATA_AREA); /* Forward secrecy */
return;
} else {
memcpy(result, &state, HASH_DATA_AREA);
What is the store wallet JSON RPC command used for ?
Doesn't this command (with no argument) tell the wallet to do a 'save'?
Many thanks for the update! Works like a dream here. Much faster wallet sync.
Looking good!
What is the store wallet JSON RPC command used for ?
Bytecoin has been updated to v.1.0.2, which includes the following features:
— Transaction history for simplewallet and Wallet JSON RPC
— Reset command for simplewallet and Wallet JSON RPC
— Various simplewallet improvements
The "reset" command is a handful tool in case you would like to resynchronize your wallet's data from scratch. This command was introduced to avoid deleting the wallet.bin file in case the re-synchronization is required.
The transaction history can be obtained through "list_transfers" command in simplewallet or "get_transfers" method in Wallet RPC. It returns the information regarding all incoming and outgoing transactions:
The "list_transfers" command returns all incoming and outgoing transfers with the following structure:
The method provides an easy way for the users or services to recheck all the wallet's operations.
You may learn more about these new features on Bytecoin Wiki: new simplewallet commands and their outputs, new Wallet JSON RPC methods.
Download Bytecoin v.1.0.2: http://bytecoin.org/downloads
— Transaction history for simplewallet and Wallet JSON RPC
— Reset command for simplewallet and Wallet JSON RPC
— Various simplewallet improvements
The "reset" command is a handful tool in case you would like to resynchronize your wallet's data from scratch. This command was introduced to avoid deleting the wallet.bin file in case the re-synchronization is required.
The transaction history can be obtained through "list_transfers" command in simplewallet or "get_transfers" method in Wallet RPC. It returns the information regarding all incoming and outgoing transactions:
The "list_transfers" command returns all incoming and outgoing transfers with the following structure:
- timestamp
- transaction type (INPUT = incoming, OUTPUT = outgoing)
- tx hash
- transfer amount — please note that this data is available starting from v.1.0.2 build. For the transfers created by simplewallet of previous versions this method returns not exact transfers amounts but the transaction amounts (transfer amount + change).
- fee
- payment_id
- recipient's address (non applicable for incoming transactions)
- block height
- unlock time
The method provides an easy way for the users or services to recheck all the wallet's operations.
You may learn more about these new features on Bytecoin Wiki: new simplewallet commands and their outputs, new Wallet JSON RPC methods.
Download Bytecoin v.1.0.2: http://bytecoin.org/downloads
Overview of the recent Bytecoin network performance updates:
In its latest release Bytecoin has introduced a number of updates
In its latest release Bytecoin has introduced a number of updates
Hi Ullo, DStrange
Could you remember to explicitly mention the version to which you are referring?
Also it would be great if you could put the version on the Downloads section of the website (or at least post a news update to mention when there is a change).
Many thanks!
1) You are a bytecoin user who has never done a transfer before in your life. Where would you go and what would you do to find the payment id information to complete your transfer command consistent with the format above? :-) :-)
A payment identification (ID) is an unique number that helps Bytecoin accepting service to identify customers' payment transactions. Payment ID is generated by BCN-accepting service itself and information about it is provided to a customer after he makes a withdrawal request or an order.
You don't need payment ID to make common transfers from user to user.
2) You are a bytecoin user who has never heard of "multisignature" until today. This sounds really cool, and you downloaded the updates from Aug. 13, 2014, but you can't find guidance on multisignature in the help commands in wallet yet. Where should you go to find more on how to successfully use this really interesting feature with one or two other people you know?
Multi-signature guidance will be available at bytecoin.org in several days. Stay tuned!
Overview of the recent Bytecoin network performance updates:
In its latest release Bytecoin has introduced a number of updates including multi-signatures and various usability improvemenets.
However, the most hardcore work has been done with the underlying modules that directly affect the network performance. Most of the changes have been made with the strategic vision as they redefine the way the network will behave in 10-years’ time. Here is the brief overview of the updates:
1. The block reward scheme has been adjusted in order to secure long-term stable performance of Bytecoin when the miners' reward is dependent on the transaction fees rather than the block reward. It was adjusted in order to keep the miners motivated as well as prevent from block size abuse.
2. Newly introduced dynamic maximum block size limit takes the adjusting CryptoNote's parameters to the whole new level. On the one hand, the block size limit is crucial to prevent blockchain flooding. The block size limit is now automatically increased every year to account for the user base and the network growth thereby providing a transparent and secure way to ensure the network scalability.
3. Due to a number of requests from users, we have significantly increased the sum, which can be easily transferred through the simplewallet. In case your transaction is not included into the block, it will be automatically excluded from the transaction pools within 24 hours and safely returned back to your wallet.
Along with the multisigs this set of updates represents our strategic vision for the Bytecoin. We are committed to providing the sustainability of Bytecoin in the long run by both making it more flexible and giving ways for the new services and businesses to emerge.
https://forum.cryptonote.org/viewtopic.php?f=12&t=257
In its latest release Bytecoin has introduced a number of updates including multi-signatures and various usability improvemenets.
However, the most hardcore work has been done with the underlying modules that directly affect the network performance. Most of the changes have been made with the strategic vision as they redefine the way the network will behave in 10-years’ time. Here is the brief overview of the updates:
1. The block reward scheme has been adjusted in order to secure long-term stable performance of Bytecoin when the miners' reward is dependent on the transaction fees rather than the block reward. It was adjusted in order to keep the miners motivated as well as prevent from block size abuse.
2. Newly introduced dynamic maximum block size limit takes the adjusting CryptoNote's parameters to the whole new level. On the one hand, the block size limit is crucial to prevent blockchain flooding. The block size limit is now automatically increased every year to account for the user base and the network growth thereby providing a transparent and secure way to ensure the network scalability.
3. Due to a number of requests from users, we have significantly increased the sum, which can be easily transferred through the simplewallet. In case your transaction is not included into the block, it will be automatically excluded from the transaction pools within 24 hours and safely returned back to your wallet.
Along with the multisigs this set of updates represents our strategic vision for the Bytecoin. We are committed to providing the sustainability of Bytecoin in the long run by both making it more flexible and giving ways for the new services and businesses to emerge.
https://forum.cryptonote.org/viewtopic.php?f=12&t=257
BTW - What version are we on now? I am running bytecoin v1.0.1.316(). Has the Linux binary been updated?
Cool! Thanks!
You receive these messages because someone in the network still uses old version of binaries. It doesn't affect your software work, so don't worry about that.
I am getting these messages on the daemon (linux binary). My Wallet is o.k. and I can turn the daemon miner on and off - however when I do a refresh I don't get any additional blocks.
DAEMON
SYNCHRONIZATION started
2014-Aug-20 13:53:44.692841 [P2P9]Block <62e0d226aa3d66fd937687eb1369ef1e472cfc64d08cd67697dca878b106e7bc> has wrong major version: 2, at height 546603 expected version is 1
2014-Aug-20 13:53:44.692938 [P2P9][95.211.224.150:8080 OUT]Block verification failed, dropping connection
2014-Aug-20 13:53:46.040422 [P2P1]Block <62e0d226aa3d66fd937687eb1369ef1e472cfc64d08cd67697dca878b106e7bc> has wrong major version: 2, at height 546603 expected version is 1
2014-Aug-20 13:53:46.040520 [P2P1][85.25.196.150:8080 OUT]Block verification failed, dropping connection
2014-Aug-20 13:53:47.559735 [P2P3]Block <62e0d226aa3d66fd937687eb1369ef1e472cfc64d08cd67697dca878b106e7bc> has wrong major version: 2, at height 546603 expected version is 1
2014-Aug-20 13:53:47.559835 [P2P3][78.47.238.49:8080 OUT]Block verification failed, dropping connection
WALLET
[wallet 267his]: refresh
Starting refresh...
Refresh done, blocks received: 0
Is this to do with the issue above?
UPDATE your software: http://bytecoin.org/downloads
You receive these messages because someone in the network still uses old version of binaries. It doesn't affect your software work, so don't worry about that.
I am getting these messages on the daemon (linux binary). My Wallet is o.k. and I can turn the daemon miner on and off - however when I do a refresh I don't get any additional blocks.
DAEMON
SYNCHRONIZATION started
2014-Aug-20 13:53:44.692841 [P2P9]Block <62e0d226aa3d66fd937687eb1369ef1e472cfc64d08cd67697dca878b106e7bc> has wrong major version: 2, at height 546603 expected version is 1
2014-Aug-20 13:53:44.692938 [P2P9][95.211.224.150:8080 OUT]Block verification failed, dropping connection
2014-Aug-20 13:53:46.040422 [P2P1]Block <62e0d226aa3d66fd937687eb1369ef1e472cfc64d08cd67697dca878b106e7bc> has wrong major version: 2, at height 546603 expected version is 1
2014-Aug-20 13:53:46.040520 [P2P1][85.25.196.150:8080 OUT]Block verification failed, dropping connection
2014-Aug-20 13:53:47.559735 [P2P3]Block <62e0d226aa3d66fd937687eb1369ef1e472cfc64d08cd67697dca878b106e7bc> has wrong major version: 2, at height 546603 expected version is 1
2014-Aug-20 13:53:47.559835 [P2P3][78.47.238.49:8080 OUT]Block verification failed, dropping connection
WALLET
[wallet 267his]: refresh
Starting refresh...
Refresh done, blocks received: 0
Is this to do with the issue above?
--This business of "Block (blahblah) has wrong major version: 1, at height (blahblah) expected version is 2" is cropping up A LOT. All over the place, since the new version of bytecoind and the wallet was installed. Still synchronizes but has problems giving the green text that corresponds to the typical progress at end of synchronization. And keeps throwing the "wrong major version" stuff and "verification failed, dropping connection."
Is there a way I can minimize this from happening? Thanks for any explanation / remedy.
(p.s.: my bytecoind version is v1.0.1.316(), my wallet version is v1.0.1.316(), and the names of the files I have that correspond to or have the word "wallet" in them, are: wallet.bin, wallet.bin.address.txt, and wallet.bin.keys -- although I have updated my binaries, I haven't deleted any of them since the update, and I know I'm supposed to keep and NOT overwrite the wallet.bin.keys file because without that file I lose whatever bytecoin I have. Even though I have what I think is the most current bytecoind and wallet, these odd things still keep happening... below is a recent example... Hopefully with that information you can let me know how I should proceed.)
You receive these messages because someone in the network still uses old version of binaries. It doesn't affect your software work, so don't worry about that.
We are planning to provide a solution of this problem in the nearest update in 2-3 days.
Thank you for your comments.
Thanks!
An additional few questions occurred to me. Originally the method of transfer could by done simply by doing a command as follows:
transfer 10 PublicAddressOfAnotherUser AmountofBytecoinToSend
(where 10 would be an example of a number within a 'mix' range (a.k.a. 'mixin_count') from 1 to 10)
and hitting 'enter.'
With recent changes, the standard command is now in this format (the transfer fee by default is now .01 bytecoin, which is 1000 times cheaper than the previous default setting, unless you choose to set it at a higher fee level to expedite your transaction ~ in this example, I've shown the fee as 10 bytecoin):
Code:
transfer[-p payment_id] [-f fee]
Code:
transfer 10 27sfd....kHfjnW 10000 -p cfrsgE...fdss -f 10
So, -f precedes the fee, which is (in this example) 10 bytecoin. Additionally, -p precedes the payment id.
With that information in hand, here are the assumptions/questions:
1) You are a bytecoin user who has never done a transfer before in your life. Where would you go and what would you do to find the payment id information to complete your transfer command consistent with the format above? :-) :-)
2) You are a bytecoin user who has never heard of "multisignature" until today. This sounds really cool, and you downloaded the updates from Aug. 13, 2014, but you can't find guidance on multisignature in the help commands in wallet yet. Where should you go to find more on how to successfully use this really interesting feature with one or two other people you know?
We are planning to provide a solution of this problem in the nearest update in 2-3 days.
Cool, thanks!
--This business of "Block (blahblah) has wrong major version: 1, at height (blahblah) expected version is 2" is cropping up A LOT. All over the place, since the new version of bytecoind and the wallet was installed. Still synchronizes but has problems giving the green text that corresponds to the typical progress at end of synchronization. And keeps throwing the "wrong major version" stuff and "verification failed, dropping connection."
Is there a way I can minimize this from happening? Thanks for any explanation / remedy.
(p.s.: my bytecoind version is v1.0.1.316(), my wallet version is v1.0.1.316(), and the names of the files I have that correspond to or have the word "wallet" in them, are: wallet.bin, wallet.bin.address.txt, and wallet.bin.keys -- although I have updated my binaries, I haven't deleted any of them since the update, and I know I'm supposed to keep and NOT overwrite the wallet.bin.keys file because without that file I lose whatever bytecoin I have. Even though I have what I think is the most current bytecoind and wallet, these odd things still keep happening... below is a recent example... Hopefully with that information you can let me know how I should proceed.)
You receive these messages because someone in the network still uses old version of binaries. It doesn't affect your software work, so don't worry about that.
We are planning to provide a solution of this problem in the nearest update in 2-3 days.
Thank you for your comments.
Jump to: