Topic: [BCN] Bytecoin technical discussion - page 3. (Read 14770 times)

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.

Hi!


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

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

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:

As it was promised...

USABILITY UPDATES EXPLAINED

Bytecoin has introduced a number of usability updates in its latest release.
Our team is working hard to provide you with the most convenient and reliable way to anonymously transfer your funds. Among the new features you may find the following:

1. Bytecoin team has further updated its unique blockchain storage. Based on this optimization, the daemon RAM consumption has been further decreased from 900 MB to 500 MB. Comparing to all other CryptoNote currencies where the whole blockchain is stored in the memory and may take up to several GBs, Bytecoin is much more accessible even on low-end computers and virtual servers.

2. Wallet refresh is now much faster due to the interaction protocol update and the synchronization with the daemon being performed in parallel threads. This update is most appealing to the new users, which have never refreshed their wallets before. The speed increase is roughly 100 times.

3. The default transaction fee has been reduced from 10 to 0.01 bytecoins, which made the transfers 1000 times cheaper.

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.

5. New transfer command format for payment_id and fee. The payment id is indicated after "-p" argument, while fee should be placed after "-f". The new command format is as follows:


Bytecoin takes user convenience and usability above all.
Further updates are coming soon, so stay tuned and check back for other Bytecoin's updates that will be covered later today.

Yes, it is. Generating subset of such transactions in blockchain poviding a way of to do guaranteed anonymous transfers.


You right about verification but you wrong about the place where it should be done - the problem of unspendable transaction is the wallet's problem, it is not problem of transaction pools or daemon in general. So additional verification and validation is planned to be done in wallet.
Another problem with validation in transaction in daemon:  for example i'm going to generate some amount of transactions with subset of guaranteed outputs (and i'll need to do that in future) - i know that i'm gonna do hundreds transactions with different amounts, and first transactions in this flow may look like unspendable (because other transactions in this subset is not received yet), than this will cause rejection of such transactions and imposibility to generate this subset in blockchain with such restrictions that you suggesting.

Penalty function is now apllied to (base_reward+fee) instead of (base_reward). Will matter in future, when base_reward < fee

Can you further explain the new reward scheme ?
BTW, awesome update.

Bytecoin is going to have a major update on 08/13/2014, 09:00 GMT

Upcoming features:

— Updated block reward scheme
— Daemon RAM consumption is optimized
— Faster wallet refresh
— Transaction priority based on tx fee
— Transactions are returned from tx pools after 24 hours
— Dynamic maximum block size limit
— Reduced default transaction fee
— Various network health updates
— Multi-signatures

Multi-signatures is an essential strategic upgrade of Bytecoin that allows for sophisticated payment scenarios to be processed. This is the next significant step for the whole CryptoNote technology that will make Bytecoin excel in the cryptocurrency world.

It is applicable to the number of use cases, e.g.:

1. Escrow services built on the native Bytecoin protocol that provides secure and completely transparent way to transfer funds through a trusted 3rd party.

2. Wallets with increased security where the transaction outputs may be spent only if a certain subset of the key holders accepts it.

3. Cold storage with two keys and so on.

In simple terms, multi-signature works as follows. When Alice wants to send $50 to Bob in exchange for a product, Alice first picks a mutually trusted arbitrator Charlie, and sends money to a multisig between Alice, Charlie and Bob.

Bob sees that the payment was made, and confirms the order and ships the product. When Alice receives the product, she finalizes the transaction by creating a transaction sending the $50 from the multisig to Bob, signing it, and passing it to Bob. Bob then signs the transaction, and publishes it with the required two signatures. Alternatively, Bob might choose not to send the product, in which case he creates and signs a refund transaction and sends $50 to Alice so that Alice can sign and publish it.

Now, what happens if Bob claims to have sent the product and Alice refuses to release the funds?  Then, Alice and Bob contact Charlie, and Charlie decides whether Alice or Bob has the better case. After that Charlie produces a transaction sending money to the party he decides and signs it. He gets the second signature from Alice or Bob and publish it.

That is simple scheme. Bytecoin implemented M-of-N multi-signature scheme in a straight way. Sender specifies the list of keys and the number of necessary signatures. Recipient simply refers to this particular output and attaches the signatures. No script commands are needed: keys and sigs are ordered, so verifier just will try to check all M sigs, taking N keys one-by-one without repeating. No more than N checks will be performed.

Unlinkability is still in charge: all keys are one-time and unique and being generated via standard scheme from the recipient(s) addresses.

This upgrade opens the opportunities for the more robust Bytecoin ecosystem to emerge and evolve. We expect it to become one of the most wanted features in the long term as it lays the groundwork for the various smart contracts. The multi-signature API is also defined in this update so that you may already start designing new services on top of Bytecoin.

BCN past txs are not useless (unlike btc). You use them in ringsig to improve your anonymity. Without even significant part of them your privacy is corrupted.

Don't worry about a full node: 2gb or 20gb per year is not an issue. The network will undoubtedly be heterogeneous: full nodes have all the data, lite nodes (smartphones etc) have nothing. Pruning is a half-measure.

afaik Cryptonite is the same as mini-blockchain project, which is based on btc. No ringsig, no anonymity, so the arguments can't be applied. Moreover, such "hard pruning" is an infringement: it forces people to make a tx, or else their old outs will be lost.

Hi!


I means that an anonymity level of one specific tx doesn't depend on "forced mixin" flags in its outputs. This flag only influences future transactions.


Unlock_time is different from the issue we are talking about because forced mixin introduces additional dependency links between transactions: spendability depends on output availability in the blockchain:

- without forced mixin txes depend on each other with strict OUTPUT->INPUT links.
- with forced mixin txes additionally depend on each other with weak OUTPUT -> OUTPUT links.

Why can't you implement spendability verification before accepting tx to mempool?

Whether it makes sense to take unspendable tx into blockchain?

Care to make a technical assessment on the prunability of the blockchain? Apart from putting it into a database, have you considered any way in which the blockchain can be pruned at all .. in the sense that we could just completely discard previous parts of the blockchain, like in the newly released Cryptonite coin?

It's been said many times that this is not possible with CN, and I was wondering if you cared to comment on this?

I disagree with your opinion about the question being off topic: Maybe we have a different definition of "technical", but this is a question regarding actual code, which has/had a big effect on the distribution of BCN besides the unknown situation of "2 years" of being "underground"

The question was deleted as off topic. This thread is for technical discussions only. Main focus should be on core technology questions.

I have 2 questions.

Why was this question deleted: "How come your cpu miner was ridiculously slow for so long?"

Why are you so fucking shady.

Mirror with deleted posts: https://bitcointa.lk/threads/bcn-bytecoin-technical-discussion.348248/#post-7821718

Hi amjuarez!

How's it going ?!
Glad to see you here!


It does, because it:


Dear amjuarez, you probably would be surprised, but Cryptocoin (you meant CryptoNote?) protocol already allow such situations.
I know at least two different ways to generate unspendable transactions:
1. Generate transaction to fake output keys - it would be impossible to receive by anyone - you just burned coins.
2. Generate transaction with unlock_time = 0xffffffffffffffff or other big value - transaction will be received but still won't be ever spendable.

So, you should agree that this is just a question of wallet's transaction validation, that can be easily implemented as for this case as for bbr's case that you was talked.

The unique solution in BBR is to add "required mixin" flag to outputs.

First of all this idea doesn't provide guaranteed anonymity to sender because it only FORCES other people to use some specific level of mixin factor in future transactions. Sender and the transaction he creates aren't affected directly.

The potential problem goes from possible unspendable transactions in the blockchain: you can create an output with some very unusual amount and force addressee to spend it with big mixin factor. In case forced mixin factor is greater than number of outputs with the same amount in the blockchain this transaction will be unspendable for a long time. Addressee even will be unable to send this money back. CryptoNote protocol SHOULD NOT allow such situations.

I see a good intention here from BBR developers but this forced anonymity doesn't look like an improvement in CN protocol (at least right now) and requires additional design/development efforts. Additional checks of transactions being accepted to mempool or to block probably will do.

Here is another analysis of forced anonymity in BBR: https://forum.cryptonote.org/viewtopic.php?f=12&t=239

I was wondering what Bytecoin developers think about Boolberry's proposals on "solving CryptoNote flaws":
https://bitcointalksearch.org/topic/boolberry-solves-cryptonote-flaws-697355

The solution is basically the guaranteed anonymity. Here's the original quote:


So what is the deal with Boolberry propopsal? Why wasn't the solution available in the original CryptoNote implementation? Has Boolberry actually improved the protocol?

Bytecoin can hide your identity from 3rd party on technical level. BitLicense requires identification on legal level. This way this is more legal or political question.

Technically You are more secure with any CryptoNote coin than with Bitcoin.

Question to Bytecoin devs:

Do you feel Bytecoin could protect/hide crypto users from overbearing government regulation (e.g. BitLicense)?