Bitcoin Forum

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

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

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

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.

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.

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

Hi amjuarez!

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


It does, because it:


And this is precisely showed in our presentation.

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


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.

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"

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?

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?

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 (https://bitcointalk.org/index.php?topic=215936.0), 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.

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.

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

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.

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.

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:

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

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

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.

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.

Cool, thanks!

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


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?

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

Cool! Thanks!

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

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

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.


Multi-signature guidance will be available at bytecoin.org in several days. Stay tuned!

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!  ;D

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 (https://wiki.bytecoin.org/wiki/Wallet_commands#list_transfers) and their outputs, new Wallet JSON RPC methods (https://wiki.bytecoin.org/wiki/Wallet_JSON_RPC_API#get_transfers).

Download Bytecoin v.1.0.2: http://bytecoin.org/downloads

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

Looking good!

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.

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.

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

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.

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

multisig and GUI wallet is urgently needly,I think

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. 

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

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.

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.

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.

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.

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.

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 ?

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.

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

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

can someone please help me to understand this error?


https://i.imgur.com/xjeVrv0.jpg

i have same error.. :(

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

dear Antonio Juarez,

why that comment ?


at

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

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/