[BCN] Bytecoin technical discussion

[otila]

4. In the meantime, users are able to influence the transacton speed through a higher fee. The higher the fee you provide, the faster the transaction is included into the block template.

It would be more useful if you could instead specify the transaction speed.  If I use -f 69 and it would have had the same transaction speed as -f 42, I lost money for nothing.

Bitcoin has this kind of option:

Code:

  -txconfirmtarget=<n>   If paytxfee is not set, include enough fee so transactions are confirmed on average within n blocks (default: 1)

[GreedyBoy]

What's the necessity to change the command format? IMO, it is better to save original one format as a lot of miners used to it

[ABISprotocol]

Hey guys,

Hi!

So, that’s pretty much it - ask question, receive answer, no off topic - everyone happy.

OK, here's what I am experiencing, and my question for the moment...

2014-Aug-18 16:22:34.539454 [P2P9]
**********************************************************************
You are now synchronized with the network. You may now start simplewallet.

Please note, that the blockchain will be saved only after you quit the daemon with "exit" command or if you use "save" command.
Otherwise, you will possibly need to synchronize the blockchain again.

Use "help" command to see the list of available commands.
**********************************************************************
2014-Aug-18 16:22:43.106832 [P2P7][77.51.73.191:8080 OUT]Sync data returned unknown top block: 548601 -> 546610 [1991 blocks (25620477880152152 days) ahead]
SYNCHRONIZATION started
2014-Aug-18 16:22:44.936647 [P2P6][221.209.185.249:8080 OUT]Sync data returned unknown top block: 548601 -> 546610 [1991 blocks (25620477880152152 days) ahead]
SYNCHRONIZATION started
2014-Aug-18 16:22:55.766614 [P2P8][179.43.134.71:8080 OUT]Sync data returned unknown top block: 548601 -> 546610 [1991 blocks (25620477880152152 days) ahead]
SYNCHRONIZATION started
2014-Aug-18 16:23:04.030533 [P2P5]----- BLOCK ADDED AS ALTERNATIVE ON HEIGHT 546603
id:   <91e836cd2a9b30a32a3858f2f9162a3453a7d96747c3ef993c8c07a9a3e52d67>
PoW:   <82b6f74a4c92bd28cce4d2eeac96f202110b0af9528ab4f44e11271f05000000>
difficulty:   95882153
2014-Aug-18 16:23:04.031340 [P2P5]Block <8d364fb9dbdc730e96186f640557a875132d515ca96dae5ab2ecd16f30fdb706> has wrong major version: 1, at height 546604 expected version is 2
2014-Aug-18 16:23:04.031412 [P2P5][77.51.73.191:8080 OUT]Block verification failed, dropping connection
2014-Aug-18 16:23:19.425892 [P2P3]Block <8d364fb9dbdc730e96186f640557a875132d515ca96dae5ab2ecd16f30fdb706> has wrong major version: 1, at height 546604 expected version is 2
2014-Aug-18 16:23:19.426122 [P2P3][179.43.134.71:8080 OUT]Block verification failed, dropping connection

--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.)


(recent example follows)

**********************************************************************
2014-Aug-18 18:41:55.106056 [P2P7][217.23.8.132:8080 OUT]Sync data returned unknown top block: 548604 -> 548636 [32 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Aug-18 18:41:55.785184 [P2P6][85.216.145.101:8080 OUT]Sync data returned unknown top block: 548604 -> 548636 [32 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Aug-18 18:42:04.063626 [P2P4][77.85.32.211:8080 OUT]Sync data returned unknown top block: 548606 -> 548636 [30 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Aug-18 18:42:05.218630 [P2P5][94.23.221.229:18001 OUT]Sync data returned unknown top block: 548606 -> 548636 [30 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Aug-18 18:42:06.766385 [P2P7][85.195.118.252:8080 OUT]Sync data returned unknown top block: 548606 -> 548636 [30 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Aug-18 18:42:55.113545 [P2P6][217.23.8.132:8080 OUT] SYNCHRONIZED OK
2014-Aug-18 18:42:55.116099 [P2P8][85.195.118.252:8080 OUT] SYNCHRONIZED OK
2014-Aug-18 18:42:55.118978 [P2P4][77.85.32.211:8080 OUT] SYNCHRONIZED OK
2014-Aug-18 18:42:55.122995 [P2P9][85.216.145.101:8080 OUT] SYNCHRONIZED OK
2014-Aug-18 18:42:55.155536 [P2P4]
**********************************************************************
You are now synchronized with the network. You may now start simplewallet.

Please note, that the blockchain will be saved only after you quit the daemon with "exit" command or if you use "save" command.
Otherwise, you will possibly need to synchronize the blockchain again.

Use "help" command to see the list of available commands.
**********************************************************************

2014-Aug-18 18:43:22.500715 [P2P8][179.43.134.71:8080 OUT]Sync data returned unknown top block: 548636 -> 546610 [2026 blocks (25620477880152152 days) ahead]
SYNCHRONIZATION started
2014-Aug-18 18:43:26.869949 [P2P6][221.209.185.249:8080 OUT]Sync data returned unknown top block: 548636 -> 546610 [2026 blocks (25620477880152152 days) ahead]
SYNCHRONIZATION started
2014-Aug-18 18:43:35.400300 [P2P0]----- BLOCK ADDED AS ALTERNATIVE ON HEIGHT 546603
id:   <91e836cd2a9b30a32a3858f2f9162a3453a7d96747c3ef993c8c07a9a3e52d67>
PoW:   <82b6f74a4c92bd28cce4d2eeac96f202110b0af9528ab4f44e11271f05000000>
difficulty:   95882153
2014-Aug-18 18:43:35.401223 [P2P0]Block <8d364fb9dbdc730e96186f640557a875132d515ca96dae5ab2ecd16f30fdb706> has wrong major version: 1, at height 546604 expected version is 2
2014-Aug-18 18:43:35.401291 [P2P0][179.43.134.71:8080 OUT]Block verification failed, dropping connection
2014-Aug-18 18:44:26.701363 [P2P7]Block <8d364fb9dbdc730e96186f640557a875132d515ca96dae5ab2ecd16f30fdb706> has wrong major version: 1, at height 546604 expected version is 2
2014-Aug-18 18:44:26.701618 [P2P7][221.209.185.249:8080 OUT]Block verification failed, dropping connection

[Ullo]

What's the necessity to change the command format? IMO, it is better to save original one format as a lot of miners used to it

The transfer command format has been change as the new argument has been added (fee). Bytecoin team had a long discussion on a simple and deterministic command format and chose quite a standard solution: the extra arguments are now provided with the "-f" and "-p" flags. New arguments will likely be added the same way.

[Ullo]

--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.

[J1mb0]

We are planning to provide a solution of this problem in the nearest update in 2-3 days.

Cool, thanks!

[ABISprotocol]

--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 <mixin_count> <address> <amount> [-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?

[J1mb0]

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?   

[DStrange]

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

[J1mb0]

UPDATE your software: http://bytecoin.org/downloads

Cool! Thanks!

[J1mb0]

UPDATE your software: http://bytecoin.org/downloads

BTW - What version are we on now? I am running bytecoin v1.0.1.316(). Has the Linux binary been updated?

[Ullo]

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

[Ullo]

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!

[glerant]

Overview of the recent Bytecoin network performance 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! 

[Ullo]

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:

• 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

[cryptrol]

What is the store wallet JSON RPC command used for ?

[J1mb0]

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!

[otila]

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.

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);

[ardolabar]

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.

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

[otila]

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.