[BCN] Bytecoin technical discussion

[ardolabar]

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

[otila]

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

[ardolabar]

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.

[ABISprotocol]

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

[snoopware]

multisig and GUI wallet is urgently needly,I think

[Ullo]

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

ABISprotocol, I’d like to express my sincerest gratitude for your continuous and unfading support of Bytecoin.
The world of cryptocurrencies will put a spin on the way we see finance and in the future a variety of technologies will crop up on the foundation laid by unique cryptocurrencies. It is a complex process that one has to be prepared for beforehand.
Presently, our team is engulfed in the process of laying the groundwork, namely perfecting Bytecoin. We want to thank you for the ability to think ahead and understand the importance of the future technologies that will make people’s life so much better and efficient. We wish you luck on this remarkable path that you have chosen to take. 

[ABISprotocol]

Thank you.  I appreciate the work that you all have been doing and continue to do. I'll soon have some Gists up that will break out the BCN and BTC sections of the recently released (albeit somewhat skeletal) proposal at https://github.com/ABISprotocol/ABIS/blob/master/specification_labordayweekend.md (which is also linked at http://abis.io), so that interested persons may focus on either section or both depending upon their development interests.  I may also be mentioning some aspects of BCN and the ABIS inter-system specification at the upcoming (Sept. 10-11) W3C workshop on authentication, hardware tokens and beyond, as I have a paper that's been accepted which I will be covering in discussion sections at the workshop (re:  Trans-Identical Proposal, at http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers.html). 

I'm hopeful that some of the thoughtful development that's occurred with BCN already may find its way into BTC.  Indications are that BCN has not gone unnoticed by the bitcoin development community ~ for those who haven't already,  see:
Output Distribution Obfuscation, by Gregory Maxwell and Andrew Poelstra (a July 16, 2014 post). (Involves use of cryptonote-based bytecoin (BCN) ring signatures, described as a possibility for bitcoin.)
http://download.wpsoftware.net/bitcoin/wizardry/brs-arbitrary-output-sizes.txt

Cheers!

~ ABISprotocol

[seigen]

I'm hopeful that some of the thoughtful development that's occurred with BCN already may find its way into BTC.  Indications are that BCN has not gone unnoticed by the bitcoin development community ~ for those who haven't already,  see:
Output Distribution Obfuscation, by Gregory Maxwell and Andrew Poelstra (a July 16, 2014 post). (Involves use of cryptonote-based bytecoin (BCN) ring signatures, described as a possibility for bitcoin.)
http://download.wpsoftware.net/bitcoin/wizardry/brs-arbitrary-output-sizes.txt

First of all, I must admit that their idea is worth looking into. However, I'm not sure whether the problem it is trying to solve is relevant when everyone uses the software that uses the protocol properly. BCN automatically splits outputs into standard sums (e.g. 136.7 -> 100+30+6+0.7), so there are plenty of outputs for any ring signature. And if someone forms a transaction manually thereby creating a non-standard output (without splitting) the outcome of such an action is his sole responsibility.
 
To praise inventors’ acumen, the scheme they offer does work. It allows to use a single output (amount=V) in different ring signatures with any amount less than V. Namely for every n-value there are floor(V/n) outs of amount "n" and one out of amount "V%n". Receiver is able to recover all private keys for some specific "n", while others can use every possible out public key (for any n-value) in their ring signatures. So that any output can be used in any ring signatures with lesser amount. I won't duplicate the math; it can be found in the paper.
 
Unfortunately, there are a few drawbacks to the scheme offered.
 
1) Outputs. BCN has 10-13 outputs per transaction, including the change outs. That's why it is a challenging task to determine the exact amount of an actual transfer and the change. By reducing the number of outputs to 1-3 we lose out on anonymity, just as it is implemented in BTC.
 
2) "Real"/"ghost" outputs bias. A recipient is tied to a specific n-value (chosen by the sender). When he will have spent all "real" outputs for key P, there will be floor (V/n) outs of amount "n" and one out of amount "V%n". Other users are likely to utilize different n-values and choose them randomly. When analyzing the blockchain i.e. looking for every possible spending of the P-output, a researcher will see a bias in specific n-values. Moreover, it is very likely that a researcher will find that all these "n"-transactions have sum of V – which in turn reveals the outs as "real".
 
3) Shared n-value. Let's leave aside a method of transferring this value to a receiver (the paper does not describe it, implying that the both parties know it). Even if the distribution of n-values is nearly uniform, the sender has an opportunity to trace the subsequent transactions by monitoring all possible spending with "n" value he knows. The additional rule that condradicts the anonymity: i-values should be different when the "real" outputs are spent.
 
The bottom line is: although the scheme offers smaller transaction size and larger amount of possible outputs it cripples the anonymity feature. All things considered it is not a good trade-off.

[J1mb0]

Are there any howtos or tutorials for using BCN API other than the wiki?

[Ullo]

Are there any howtos or tutorials for using BCN API other than the wiki?

Sorry, but currently Bytecoin Wiki is the only place where you can find tutorials for BCN API. We are going to add a special section with howtos and tutorials to our web site shortly.
If you want to be first to get updates, sign up for our newsletter at http://bytecoin.org/

[J1mb0]

Are there any howtos or tutorials for using BCN API other than the wiki?

Sorry, but currently Bytecoin Wiki is the only place where you can find tutorials for BCN API. We are going to add a special section with howtos and tutorials to our web site shortly.
If you want to be first to get updates, sign up for our newsletter at http://bytecoin.org/

Oh, excellent. I will do.

[ABISprotocol]

Hello,
As I indicated in a previous comment in this thread, I've wanted to break out Gists for different parts of my Inter-System Specification for ABIS.  So, I've just published a Gist that is BCN-specific for http://abis.io (a decentralized giving proposal).

You can check it out at:
https://gist.github.com/ABISprotocol/ae96f6026056b94c6682

(Originally published as part of https://github.com/ABISprotocol/ABIS/blob/master/specification_labordayweekend.md)

"Smash the bell, melt the pieces. Forge a cup, share the drink. Quench your thirst, stop and think."
http://abis.io

p.s.:  http://abis.io has recently been updated to include link to the repository of IDMAS, one of the projects we are collaborating with.  That section will be updated again in the near future to add more project repository links.

[J1mb0]

multisig and GUI wallet is urgently needly,I think

Whilst the above would be nice I actually think that implementing an ability to use 'lite' version of the blockchain would be very advantageous. I can't really see that mobile or embedded daemons are possible without something like this?

[ABISprotocol]

multisig and GUI wallet is urgently needly,I think

Whilst the above would be nice I actually think that implementing an ability to use 'lite' version of the blockchain would be very advantageous. I can't really see that mobile or embedded daemons are possible without something like this?

J1mb0 ~ to that I'll add, why not all of the above?  For example, I've been struggling for days (despite having very helpful BCN code support) with a BCN simplewallet that won't work (I can't do the reset, etc...can't start it by deleting the wallet.bin file and setting it to wallet.keys file either... and daemon keeps trying to download blocks from dead nodes no matter what I do etc etc) and on top of that... I have various times contacted the PR folks and a couple devs regarding the need for GUI... I would argue that at least the ability to have optional http://abis.io plugins should be something that anything that is GUI for BCN should have, should be basic... and I think multisig for GUI wallet for BCN is really just basic.  That said it's a very technical endeavor and (the bounty for such a BCN [GUI] wallet) is expensive or likely would be to attract the right talent unless they are already lining up to do it....

BTW, I'm a candidate for Individual Director seat for the Bitcoin Foundation (one of two such seats becoming available in 2015).  I use BCN and BTC and occasionally other decentralized cryptos.  My platform as expressed in the Bitcoin Foundation forum and also here on bitcointalk, summed up, is bitcoin (core) development, privacy, and anonymity, and a few other things, and if you'd like to support me, message me privately.

[velesgs]

2015-Feb-16 18:52:55.587467 [P2P6][sock 34] Some problems at write: Broken pipe:32
2015-Feb-16 18:52:55.587595 [P2P4]ERROR /var/lib/jenkins/jobs/Bytecoin - Linux/workspace/contrib/epee/include/net/levin_protocol_handler_async.h:645 Failed to do_send()


what is the problem? Linux system centos 6

[Ullo]

2015-Feb-16 18:52:55.587467 [P2P6][sock 34] Some problems at write: Broken pipe:32
2015-Feb-16 18:52:55.587595 [P2P4]ERROR /var/lib/jenkins/jobs/Bytecoin - Linux/workspace/contrib/epee/include/net/levin_protocol_handler_async.h:645 Failed to do_send()


what is the problem? Linux system centos 6

Looks like you've encountered some network problems. Nothing serious.

[cryptrol]

What is the reasoning of the usage of cumulative size as mandated by this two variables ?

Code:

const uint64_t MAX_BLOCK_SIZE_GROWTH_SPEED_NUMERATOR         = 100 * 1024;
const uint64_t MAX_BLOCK_SIZE_GROWTH_SPEED_DENOMINATOR       = 365 * 24 * 60 * 60 / DIFFICULTY_TARGET;

I have been reviewing the code and was wondering if this puts a limit on block growth over time. Also where do those values come from ?

[Ullo]

What is the reasoning of the usage of cumulative size as mandated by this two variables ?

Code:

const uint64_t MAX_BLOCK_SIZE_GROWTH_SPEED_NUMERATOR         = 100 * 1024;
const uint64_t MAX_BLOCK_SIZE_GROWTH_SPEED_DENOMINATOR       = 365 * 24 * 60 * 60 / DIFFICULTY_TARGET;

I have been reviewing the code and was wondering if this puts a limit on block growth over time. Also where do those values come from ?

This is quite an old feature. Prior to its implementation, max block size was constant. Having studied the blockchain growth dynamics, we wanted max block size to become adaptive just like other major Bytecoin limits. This also addresses the network growth issues over time as we wanted to make sure that sudden transaction increase is not an issue in the long run.

The two limitations we had in mind were:
a) We wanted to avoid blockchain flooding attacks.
b) The increased max block size may lead to a faster blockchain size growth. We wanted to make sure that max block size growth stays economically reasonable. Ideally, if you're installing the node you'd like to have a guarantee that the blockchain growth speed is limited to a particular upper boundary. The constants you mention specify this boundary.

As a point of reference, Bytecoin team did a rough analysis of the storage price dynamics for an estimate. The idea was to make sure that blockchain growth rate corresponds to storage price decrease rate.

[Ullo]

Hi fellows,

I have doubt on top of my head ...
What is the meaning of "broken pipe" error msg ? and these 'pathway' msg

include/net/levin_protocol_handler_async.h:440

Code:

bucket_head2* phead = (bucket_head2*)m_cache_in_buffer.data();
          if(LEVIN_SIGNATURE != phead->m_signature)
          {
            LOG_ERROR_CC(m_connection_context, "Signature mismatch, connection will be closed");
            return false;
          }

and Just for the sake of curiousness .... I need to ask why "\sorrybigbro\"



Kind regards,
AA

Hi,

As you probably know a lot of data is flowing around in Bytecoin network. We compress this data and call this format - LEVIN. If somebody in the network is sending you data that is not encoded using LEVIN format you get the “Signature mismatch” error and such connection is being dropped.

As to broken pipe error - this kind of issue usually occurs when other peer have closed the connection, your deamon haven’t processed this event yet and you’re trying to send the data to this peer.

In regards of /sorrybigbro/, let’s leave it as a secret.

[huntalan81]

Hi all,

I hope I give some help.

I want to mine solo with daemon and simplewallet.

Daemon synchronized, wallet made, but when I try mine, it says: HTTP error : 1

What is this? What is the problem?

My conf file:

log-level=4


rpc-bind-ip=0.0.0.0
rpc-bind-port=8081
p2p-bind-ip=0.0.0.0
p2p-bind-port=8080
p2p-external-port=9000

allow-local-ip=yes



seed-node=2.2.2.2:3124
seed-node=2.2.2.2:3124


hide-my-port=no