Quote from: CryptKeeper on September 11, 2016, 06:17:18 PM

Quote from: kaicrypzen on September 11, 2016, 06:08:55 PM

CryptKeeper, I sent 111 bytes to the first address and 999 bytes to the second, did you receive them? Both transactions cost 589 bytes, does this mean that the fee is set to this amount whatever the number of bytes one sends?

Yes, I acknowledge! Grin

Cool

Quote from: tonych on September 11, 2016, 07:35:48 PM

Quote from: CryptKeeper on September 11, 2016, 06:17:18 PM

I cannot see who has sent these tx, there is no sender address! Is this meant to be like this?

That's a good question that presents me an opportunity to tell you about another workflow, which is the only workflow possible for blackbytes (the private currency). When you pay in blackbytes, the private payload is not stored on the public database, rather it is sent directly to the payee. To deliver it, we need to establish a direct communication link between the payer and the payee. This is accomplished by pairing their wallets.

One of the parties (payer or payee) creates an invitation in his wallet by clicking Menu button -> Paired devices -> Add new -> Invite. Select and send the long code to the other party (if meeting in person, the other party can just scan the QR code). The other party just clicks the code if it is clickable, or pastes it in his wallet at Menu button -> Paired devices -> Add new -> Accept invitation. Now they are paired. Don't paste the code on this forum as it is for one-time use only, it won't work for the second person. Rather PM it to the intended counterpart.

Once you are paired, start a chat and use "Insert address" button to share your address with the correspondent (this will be a freshly generated address, specifically for this correspondent). The other party then clicks the received address and sends payment in bytes or in blackbytes, and you immediately receive notification in chat and know who sent the payment. At this moment, the private payload (if it was payment in blackbytes) is already saved in your wallet, and only you and the payer know about it.

This explains the blackbytes workflow but doesn't seem to answer CryptKeeper's question ...

By the way if anyone is interested in pairing devices, shoot me a PM Wink

.

Quote from: tonych on September 11, 2016, 07:57:27 PM

Quote from: kaicrypzen on September 11, 2016, 06:08:55 PM

Quote from: tonych on September 05, 2016, 04:00:28 PM

The fees are collected partially by those who are first to reference your transaction as parent and partially by witnesses.

So, anyone here who got the fees?

In the current version, the wallet does not display who got the fees, and I believe it is of little interest to most users. Besides, the fees paid by one transaction are too small to care about (unless the marketcap is over $100bn).

I am not interested in who got the fees, I just want to know if some user got them or if they were burned ... I mean if someone was the first to reference my transaction as parent and/or is a witness then they should've gotten the fees, just wanted to make sure of that.

Quote from: tonych on September 11, 2016, 07:57:27 PM

Quote from: kaicrypzen on September 11, 2016, 06:08:55 PM

Is there any way to have more information about a transaction, the id for instance, the number of confirmations it needed (it just goes from unconfirmed to cofirmed)?

There is no such thing as number of confirmations, the transaction is either confirmed or pending. This is by design (see the white paper https://byteball.org/Byteball.pdf).

Ok, bare with my silly questions until I master the courage to read the white paper

.

Quote from: tonych on September 11, 2016, 07:57:27 PM

The wallet is designed for unsophisticated users (GUI was borrowed from Copay, the most easy to use bitcoin wallet) and we generally avoid displaying information that bears little meaning to regular user.

Having both is having complexity again, something I avoid by all means throughout this project.

I'm not against accommodating regular users, I just think that this simplicity may annoy less regular users. As far as I'm concerned, even if the info may have little meaning, being able to display it and choosing not to is not the same as not being able to display it.

Can you elaborate a bit on the complexity that signing a message instead of making a payment may introduce? (I'm not taking about the complexity of signing a message per se, I'm talking about how this will make the distribution process more complex.)

Thank you.