Topic: Obyte: Totally new consensus algorithm + private untraceable payments - page 1114. (Read 1233994 times)

I don't, and always tell everybody not to do this. But people still use them and give them a shitload of their BTC, which those scamers are going to use to game your giveaway. And when they will get 99% of your bytes, they will dump them at their exchanges and drop the price into shit. MWHAHAHAHA!!!

Oh no, please don't deal with exchanges where employees can take coins so easily.

You need to control the address and have your balance on the address.  This is most easily achieved by owning the private keys, but other options also exist, e.g. the Coinbase vault in the specific setup described above, blockchain.info.

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

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.

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


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

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.


It can be different, in particular it depends on the number of unspent outputs consumed by the transaction, more outputs take up more space.

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

I've seen the 589 Bytes fee also for my own tx. IMHO this tx type "send bytes" has a size of 589 bytes, so we have to pay 589 Bytes! 
Other tx types may vary in fees because of a different tx size.

So to confirm, would you need to own the private keys to the address to claim it or only send a small portion from the address?

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? What about this:



So, anyone here who got the fees?

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


Can't we have both? Users who know how to/can/want to sign a message may do so and others may send a payment.

Definitely keeping an eye on this one! I see potential

You say "we". Is there a team behind Byteball? Or is it a one-man-show so far?

From exchange wallets into personal wallets and back after snapshot is taken.  This can be done by exchange employees without their boss even knowing about it, if they know when snapshot is going to happen. This is just one example.

Looks too complex to me because we need to somehow know the balance in advance.


This one is complex too.  Not every wallet has this function, and even when it has, users rarely know how to use it.  There is nothing simpler than just regular payment, which is the basic functionality of every wallet.

What kind of moving funds around will get them more bytes?

Hi Tony CH - why not either

a) require an address to burn 1% of its balance instead of flat fee of 0.001 BTC
      - this wouldn't matter to small-medium holders at all, and
      - it would make the distribution better as a whale sitting on 10k BTC wouldn't probably want to spend all 100 BTC, and
      - it would prevent or at least make it hard for exchanges and other parties holding other people's coins to get large percentage for free

or

b) require a signed message from the claiming address instead of making a 0.001 BTC transaction
      - then people wouldn't have to make a tx that possibly compromises their privacy or loses them coins

A possibility to game it by exchanges using user's funds was mentioned above, and this is a valid concern. Knowing the block number of snapshot in advance may help them to move funds around to get more bytes. Of course, making the number to be random still does not exclude all possibilities to game the distribution, but at least this could make it more difficult to plan ahead.

Since there is no way to game it, certainty is way better than mystery

If you want to test drive the wallet, you can post your byteball address here and I will send you some bytes! 

Here are my addresses:
KYZN4SPSZAUN2SEO4JZ2F5PEHQEXYC5S
byteball:KYZN4SPSZAUN2SEO4JZ2F5PEHQEXYC5S

DSZ6HWO6VWSQUCI67PIN27HL4LYYK5JV
byteball:DSZ6HWO6VWSQUCI67PIN27HL4LYYK5JV

This way nobody will know exact number in advance. More mystery, less possibility to game the distribution.

Valid points.  Maybe we'll extend the preparation period, it should become clear in a few weeks.

Why did you choose around this block, why not push this distribution process few more months all the way to new years. Then we can countdown for new years and byteball.
current expected distribution is only a month and a bit to two months most. That is not very long, especially since you wanted get as big of a distribution as possible.
stretch out few more months and maybe pay bounty for people to advertise out.