Obyte: Totally new consensus algorithm + private untraceable payments

[rendravolt]

Nice project, wait more updates.

[CryptKeeper]

Is there a mobile wallet which you can download via apple's appstore?

[tonych]

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

It seems there are many people here who hate exchanges.  We can trump them if we collectively link more BTC than they hold.

[tonych]

How will you know where to send the issued BYTEBALL tokens?

You link your Byteball address, this is where you'll receive your bytes.

[tonych]

Is there a mobile wallet which you can download via apple's appstore?

Android only for now.  Apple didn't approve our app for the app store but you can build it yourself https://github.com/byteball/byteball/blob/master/building-for-ios.md

[Fragbait]

How will you know where to send the issued BYTEBALL tokens?

You link your Byteball address, this is where you'll receive your bytes.

How do I link it?

[John_Paul]

Coinbase users will need to create a coinbase vault with the option "I will manage security myself Advanced" and move their coins to this vault.  With this option, your BTC will be on your address, not on coinbase's.

Can you also send out btc from your coinbase vault address?

[rnr]

Is there a mobile wallet which you can download via apple's appstore?

Building Byteball for iOS

Apple takes cautious approach to new cryptocurrencies and didn't approve our app for the App Store (yet). Fortunately, if you own a Mac, you can build and install Byteball for your phone yourself:

Download Xcode (4GB), if not already.
Sign up for Apple Developer Program (if not already), it's free.
Download Byteball Xcode project, it contains all the source code necessary to build.
Unzip and open Byteball.xcodeproj in Xcode.
Connect your iPhone to your Mac via USB.
Build Byteball by clicking Play button in Xcode.
Read more detailed instructions (for another app). It is one of the easiest ways to try open-source apps that are not on the App Store.

[bitcoinuserz]

I think some marketing campaign bounty is fair. It is a way for early adopters to get something even if they don't hold much btc. What do you say dev? Give cryptoland some economic incentive!

[FandangledGizmo]

Only read first four pages.

Requiring people to know about and actively link Bitcoin addresses will result in the same distribution as an any other ICO coin. It's an exercise in how to get the same/worse distribution than other ICO's and with low/no development funds to show for it.

The Clam approach or sharedropping on all addresses (possibly excluding very large ones) is actually better because it has far better distribution but very little will be claimed early on so there is not a lot of supply on the market allowing you to achieve a strong valuation.if the project does anything worthwhile.

(I'm not a fan, but to see the impact of limited supply on initial valuations look at the Steem pump and dump, they got a 400 million valuation because only a minuscule percentage was available to sell. While that's just an uneconomically viable, centralised, pump and dump, a credible project can really build from a very well distributed ownership model but with limited available supply early on.)

[dsattler]

I'm fascinated by this new tech, wow! 

@tonych:
Are you already accepting applications for witnesses? I would love to be part of this project. I have no problem to reveal my true identity. I'm here since 2013 and did a lot of trading with good reputation. Not only digital but also physical goods, so my postal address is also known to several members. Please contact me by PM if you have any further questions.

As a witness, should I run the client on a vps or is a local pc sufficient?

[tonych]

Coinbase users will need to create a coinbase vault with the option "I will manage security myself Advanced" and move their coins to this vault.  With this option, your BTC will be on your address, not on coinbase's.

Can you also send out btc from your coinbase vault address?

Sorry my mistake, you can't pay from coinbase vault address, so coinbase users will have to move funds to another wallet they have full control over.

[tonych]

How will you know where to send the issued BYTEBALL tokens?

You link your Byteball address, this is where you'll receive your bytes.

How do I link it?

I'll post instructions when we enter the linking phase.

[tonych]

It's up to the community to decide on criteria for a witness, but I would personally expect more real word reputation, not just in trading (e.g. if you are a google, you are OK with me ).

One way to become a witness is as follows:
1.  Run the witness code on your server https://github.com/byteball/byteball-witness.  To be considered seriously, you need to run it on a server that is well connected and always online.  Running this code alone won't make you a witness automatically, you'll just periodically post your units to the database (and spend your bytes by doing this).
2.  Campaign here and elsewhere trying to persuade everybody that you would be a better witness than somebody else and they should change their witness list by replacing some other witness address with yours.

I'm fascinated by this new tech, wow! 

@tonych:
Are you already accepting applications for witnesses? I would love to be part of this project. I have no problem to reveal my true identity. I'm here since 2013 and did a lot of trading with good reputation. Not only digital but also physical goods, so my postal address is also known to several members. Please contact me by PM if you have any further questions.

As a witness, should I run the client on a vps or is a local pc sufficient?

[kaicrypzen]

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!  

Cool

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 .

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.

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 .

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.

[Fragbait]

How will you know where to send the issued BYTEBALL tokens?

You link your Byteball address, this is where you'll receive your bytes.

How do I link it?

I'll post instructions when we enter the linking phase.

Sounds complex.  

Seems like signing the Byteball address with the BTC address would've been simplest.

[yengyuenshe]

any bounty dev

[KindLurker]

This is awesome. Good luck with the project 

[tonych]

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

Sorry, got totally consumed by describing the chat workflow (which is equally good for bytes BTW).
I might add the display of the sender's addresses in a future version, just for completeness, but be warned that it won't tell you who is the real person behind these addresses.

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.

They can't be burned, somebody definitely gets them after the transaction is confirmed.

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.

There is a lot of information that is available but I chose not to display.  The choice was dictated by the desire to keep the UI as clean and uncluttered as possible.  This is weighted against the usefulness of information, while keeping in mind a regular user.   I understand the choices may not be optimized for every user, and if you want to design a wallet for pro users, fork it and release your own.

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

Accepting claims as signed messages alone is not complex technically but there are serious issues on the usability side:
1.  First of all, not every wallet has this function.
2.  Even in wallets that can do it, it is a rarely used function, users need to be instructed how to use it for every brand of wallet, and they feel insecure when they do something for the first time.

Having both options adds complexity on both technical and usability sides:
1.  More code that needs to be written, debugged, and tested.  Despite all the testing, more code is always more complexity and greater probability of errors, including security errors.  Complexity is the enemy of security.
2.  More options for users means more options for attackers too.  This needs to be analyzed, and with growing complexity the chances of missing something increase.
3.  Longer instructions for users.  They are scared off by the abundance of text or unfamiliar words, like "signing a message".
4.  Users have to evaluate both options and make their choices.  Choice is difficult when the difference between the choices is not immediately clear.

All this is fine as long as there is a real tangible benefit in adding more options that overweights the negatives.  In this particular case, there isn't.

[CryptKeeper]

Please retweet: https://twitter.com/CryptKeeperBTT/status/775308424292761600