[BCN] Bytecoin technical discussion

[DStrange]

Hey guys,

I am glad to introduce you the Bytecoin (BCN) technical thread where core developers will answer any of your technical questions.

Please refrain from the off topic and keep it civil. All questions will be answered but you should take into account that it can take some time. Main focus should be on core technology questions since minor issues have been already discussed numerous times.

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

Also, we’ve setup an irc channel - #bytecoin-dev where you will be able to talk to developers live.

General discussion can be found here: https://bitcointalk.org/index.php?topic=512747.0

[1713269642]

1713269642

[1713269642]

1713269642

[1713269642]

1713269642

[1713269642]

1713269642

[cryptrol]

Are multi-sig transactions of N-M available or possible in BCN ?

[DStrange]

One more thing, later on, based on the most popular and most hardcore questions we will create a technical Bytecoin FAQ. So try to ask smart questions which could present interest to other people.

[ardolabar]

Are multi-sig transactions of N-M available or possible in BCN ?

Short answer: possible -- yes, available -- not yet.

I guess the real question is "Are multisigs and ringsigs compatible?"

Technically, yes. Independent features. Multisig: "who can sign" and ringsig: "how to sign". But some specific problems may arise.

Suppose we have three 1-of-2 outputs: (A,B), (C,D), (E,F), the same amount. (A) can spend (A,B) with ringsig (A,C,E), hiding which output was used. The problem: (B) can double-spend (A,B) with (B,D,F).

Another case: only one output 1-of-5: (A,B,C,D,E). (A) can spend it with ringsig (A,B,C,D,E), hiding the actual signer, but not the fact of spending.

The bottom line: "naive" multisig will work perfectly if we don't care about anonymity. Combining it with untraceable ringsig demands some additional rules.

[DianaN]

Question to Bytecoin devs:

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

[amjuarez]

Question to Bytecoin devs:

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

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.

[Rias]

I was wondering what Bytecoin developers think about Boolberry's proposals on "solving CryptoNote flaws":
https://bitcointalk.org/index.php?topic=697355.0

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

Good News Everybody!
     
We are proud to announce that we're starting a series of presentations in which we'll explain Boolberry's unique and very important features.

We've created an easy-to-understand presentation that explains how Boolberry solves CryptoNote flaws.
     
In this first presentation, you'll find out how Boolberry provides guaranteed privacy, while other CryptoNote coins cannot.
     
     
   
     
    > Download Boolberry_Solves_CryptoNote_Flaws.pdf

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?

[amjuarez]

I was wondering what Bytecoin developers think about Boolberry's proposals on "solving CryptoNote flaws":
https://bitcointalk.org/index.php?topic=697355.0

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?

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

[crypto_zoidberg]

Hi amjuarez!

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

I was wondering what Bytecoin developers think about Boolberry's proposals on "solving CryptoNote flaws":
https://bitcointalk.org/index.php?topic=697355.0

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?

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

It does, because it:

...FORCES other people to use some specific level of mixin factor in future transactions....

And this is precisely showed in our presentation.

Sender and the transaction he creates aren't affected directly

Surely, this transaction is a way of generating outputs with guaranteed anonimity.

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. Cryptocoin protocol SHOULD NOT allow such situations.

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.

[AdamWhite]

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

[DStrange]

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

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

[Quanttek]

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

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

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"

[kbm]

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?

[amjuarez]

Hi!

Hi amjuarez!

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

I was wondering what Bytecoin developers think about Boolberry's proposals on "solving CryptoNote flaws":
https://bitcointalk.org/index.php?topic=697355.0

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?

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

It does, because it:

...FORCES other people to use some specific level of mixin factor in future transactions....

And this is precisely showed in our presentation.

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.

Sender and the transaction he creates aren't affected directly

Surely, this transaction is a way of generating outputs with guaranteed anonimity.

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. Cryptocoin protocol SHOULD NOT allow such situations.

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.

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?

[ardolabar]

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?

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.

... like in the newly released Cryptonite coin?

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.

[Ullo]

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.

[cryptrol]

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

[ardolabar]

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

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

[crypto_zoidberg]

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.

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

......

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?

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.

[Ullo]

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:

Code:

transfer <mixin_count> <address> <amount> [-p payment_id] [-f fee]

Code:

transfer 10 27sfd....kHfjnW 10000 -p cfrsgE...fdss -f 0.1

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.