Topic: [BCN] Bytecoin technical discussion (Read 14707 times)

Booking On Dukley’s, Made Simple with Bytecoin

his is a paid-for submitted press release. CCN does not endorse, nor is responsible for any material included below and isn’t responsible for any damages or losses connected with any products or services mentioned in the press release. CCN urges readers to conduct their own research with due diligence into the company, product or service mentioned in the press release.

https://www.cryptocoinsnews.com/booking-dukleys-made-simple-bytecoin/

dear Antonio Juarez,

why that comment ?


at

https://github.com/amjuarez/bytecoin/blob/master/src/P2p/LevinProtocol.cpp

i have same error..

is minergate.com joined with bytecoin and made it impossible to mine solo ?

can someone please help me to understand this error?

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

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.

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.

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


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 ?

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

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

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.

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?

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.

Oh, excellent. I will do.

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/

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

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.

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

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. 

multisig and GUI wallet is urgently needly,I think