Can you add pl.po for Polish, please?
You create it. Open template.pot and save it as pl.po, or if using Poedit click "Create new translation" and open the .pot file. |
|
|
|
We need better translations. Our wallet is only half translated, please help improve it: - join github.com and fork byteball project https://github.com/byteball/byteball- edit the relevant language file at https://github.com/byteball/byteball/tree/master/i18n/po. You can use any text editor or Poedit, which is a specialized very convenient tool. If you translate only part of the strings, no problem, the wallet will still become better than before. - submit a pull request I recently updated the strings, now the .po files include the strings that describe recently added functions (bound payments, smart contracts, etc). |
|
|
|
It is normal that there is no consensus (yet) about the unstable trailing part.
If we denote the interval of time between a transaction issuance and the transaction finalization (by witnesses) as confirmation time, does an average confirmation time increase monotonically if the global TPS rate increases monotonically? PS: "Yes" would mean that SatoNatomato was wrong that DAG has no limits on scaling even if we have superpowerful hardware (but the latency still persists). It all depends on the behavior of witnesses. That said, it is reasonable to expect that as TPS increases, witnesses also post more frequently, therefore confirmation time decreases. Of course, there is a lower bound defined by network latency, times number of witnesses. |
|
|
|
Unless you put all 12 witnesses on a single machine you have to deal with the following situation:  Blue balls are picked by 4 witnesses as the main chain, green balls are picked by other 4 witnesses and there is another version picked by the remaining witnesses (it's not shown to emphasize that noone can have a complete view of the DAG). Under high load every witness will pick its own main chain because none of them will see the whole DAG. The chance of that is high because In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction. is not true in high load, the DAG becomes very wide. Adding to the bolded part above, every node will pick its own main chain (witnesses are no special). You are demonstrating the simple fact that under high throughput and wide DAG, different nodes have different views of the world, hence build different MCs, and that the trailing part of the MC is constantly rebuilt as new units arrive. However, the algorithm that they use to build the MC guarantees that the portion of the MC that is older than certain point (stability point) is never rebuilt, it is stable. It is normal that there is no consensus (yet) about the unstable trailing part. Sorry, didn't bother to read the actual article. Try https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed: In its classic interpretation, the CAP theorem ignores latency, although in practice, latency and partitions are deeply related. Operationally, the essence of CAP takes place during a timeout, a period when the program must make a fundamental decision-the partition decision:
cancel the operation and thus decrease availability, or
proceed with the operation and thus risk inconsistency. Quoting from the whitepaper: 15. Partitioning risk
The network of Byteball nodes can never be partitioned into two parts that would both continue operating without noticing. Even in the event of a global network disruption such as a sub-Atlantic rat cutting the cable that connects Europe and America, at least one of the sides of the split will notice that it has lost the majority of witnesses, meaning that it can’t advance the stability point, and nobody can spend outputs stuck in the unstable part of the MC. Even if someone tries to send a double-spend, it will remain unstable (and therefore unrecognized) until the connection is restored. The other part of the split where the majority of witnesses happens to be, will continue as normal.
In other words, in the minority partition, confirmations will just stop before the connection is restored. |
|
|
|
Another great update, tonych! So, oracles are third party libraries that can be added to Byteball in order to read specific public available data like altcoin nodes to check payments and write to Byteballs database, right? Is a programming reference available about how to create an oracle ? Found in the github repository.They are standalone programs rather than libraries. The oracle's job consists of two steps: - read data from an external source - post it into Byteball as data feed message The simplest example is here https://github.com/byteball/byteball-data-feed/blob/master/start.js. It posts price data from yahoo finance and btc-e. |
|
|
|
Version 1.6 released https://github.com/byteball/byteball/releases. Now you can bind payments to events posted by oracles, see https://medium.com/byteball/making-p2p-great-again-episode-ii-bitcoin-exchange-d98adfbde2a5.  One such oracle is already running and allows to P2P exchange bytes (or blackbytes or any other Byteball currency) vs bitcoins. The source code of the oracle is at https://github.com/byteball/btc-oracle. The possibilities offered by the payments bound to oracle-posted events are huge, independent developers are welcome to add their own oracles that enable other P2P services. See the above Medium article for some ideas. Other updates in this release: * Back button in Android now works correctly * Chinese translation (partial) * List of balances by addresses in settings (for those who like to look under the hood) * After receiving a "message encrypted to unknown key" the undecipherable message is now deleted and the error does not pop up the next time * Performance improvements The first time you start the app after the upgrade, it may be slow to start as it creates new indexes for better performance. Please upgrade. If you run a full client (GUI or headless), you'll have to upgrade because of a bug in code that was never visited before but the first time the new functionality is used will trigger the bug. |
|
|
|
Distribution of bytes and blackbytes is complete. Bytes: 19,832.186424596 GB distributed. New available supply is 137,442.380452938 GB. Blackbytes: 36,779.346125354 GBB (giga-blackbytes) distributed 5,088.382635611 GBB added to the community fund (due to some bytes not being on the linked addresses) The 4th round is scheduled for the Full Moon of April: Apr 11, 2017 at 06:08 UTC. The rules stay the same: BTC to bytes: 1 BTC of proven balance gives you 62.5 MB (0.0625 GB) BTC to blackbytes: 1 BTC of proven balance gives you 2.1111 * 62.5 million blackbytes (money supply of blackbytes is 2.1111 times more than that of bytes) Bytes to bytes: 1 byte on any Byteball address gives you 0.1 new bytes Bytes to blackbytes: 1 byte on linked Byteball address gives you 0.21111 blackbytes Between the rounds, expect more steps towards making P2P great again (if you missed the first step, see https://medium.com/byteball/making-p2p-great-again-fe9e20546a4a#.snr320140). |
|
|
|
please @tonych i have proble.. i made MAJ v1.5.1 but my byteand b-byte are missed..so i have full backup..seed and folder previous wallet.howi can restor it please ? urgent  What have you made? Anyway don't worry if you have full backup. |
|
|
|
This post from superresistant brought me to the idea to create a little smart contract with Byteball. However I do not really know how to start. I played a little bit around with the chatbot like " how to create a smart contract?" or " create new smart contract". It did not bring much. Is it planned to create a kind of development reference or maybe there is already a tutorial with which you can start? I have a developer background. That's why it can be very technical. Start with this primer https://bitcointalk.org/index.php?topic=1617816 and the whitepaper section about addresses. |
|
|
|
Byteball Community Announcement
....
The Byteball Community Fund
....
Forgot to ask. I am looking for a tutorial how to exchange Byteball for BlackByteball with the new feature in version 1.5. When I understand correctly, the new version of Byteball wallet offers this feature now.
Can you please create a post or a blog entry for that? I would be very grateful.
If someone writes a tutorial, we offer a 0.5GB or 5GBB bounty out of the community fund. |
|
|
|
When you entrust your money to a smart contract, you want to be absolutely sure that the contract operates as you expect (remember TheDAO?). One way to achieve this is by having a smart contract language that is designed to express what the contract expects, rather than how it accomplishes its goals. This is exactly what declarative languages do. The purpose of this post is to introduce the declarative smart contract language I chose for Byteball, the cryptocurrency I recently launched. The language is designed to be as easy to understand as possible, so that even non-developer can immediately see what a contract means by just looking at its code. The language values clarity over power and it is not as powerful as Ethereum's Solidity. It is not turing-complete, and you cannot write even 'Hello world' program in this language. But it is able to solve many practical business tasks. Although each executed instance of your language is not Turing-complete in isolation, the system of instances is Turing-complete because you have the ability to reference global memory in the form of the data feed. Thus you can still have scenarios of unbounded recursion and even live or dead locks. Craig Wright had schooled Nick Szabo and Gregory Maxwell on this point also. So you have not prevented hacks. And you have somewhat crippled the language compared to Solidarity. You may argue you've made the intent clearer, but when people write convoluted systems with this in order to achieve complex smart contracts by simulating Turing completeness, then it may end up more obfuscated than Solidarity. I really don't see your design strategy as the absolute panacea you seem to claim or imply. There is a limit on the number of operations per smart contract, data feed lookups included. It is not a panacea. It is designed to meet the demands of regular users, and they are not convoluted, as the recent superresistant's example shows. If you need convoluted, go with Solidity, but be extremely careful when you expose complex systems to regular users (unaccredited investors, if we consider investments context). When users are exposed to complex systems that they don't fully understand and that can potentially harm them, the governments will want to "protect the consumer" -- by regulation. But my point is you can't prevent in the wild people from creating convoluted smart contracts even with your intended to be simple declarative language. Do you really expect users to give a damn and look at the source code of the smart contract? Users demand features such as DAOs. So I don't think you can stop the developers from bastardizing yours as well. Preventing Turing-completeness is very difficult. This is why Bitcoin is very cautious to add new opcodes. I can't stop them but hopefully most developers are smart enough to find the best tool for the purpose, and there is no lack of choice. Even if they do create something convoluted against all odds, let's see if they find many users. Do you really expect users to give a damn and look at the source code of the smart contract? I dare say yes, if we speak the user's language. The nice thing about Byteball smart contracts is that they can be easily presented in user readable form:  This example is from my article https://medium.com/byteball/making-p2p-great-again-fe9e20546a4a#.3k1a7f5yo |
|
|
|
When you entrust your money to a smart contract, you want to be absolutely sure that the contract operates as you expect (remember TheDAO?). One way to achieve this is by having a smart contract language that is designed to express what the contract expects, rather than how it accomplishes its goals. This is exactly what declarative languages do. The purpose of this post is to introduce the declarative smart contract language I chose for Byteball, the cryptocurrency I recently launched. The language is designed to be as easy to understand as possible, so that even non-developer can immediately see what a contract means by just looking at its code. The language values clarity over power and it is not as powerful as Ethereum's Solidity. It is not turing-complete, and you cannot write even 'Hello world' program in this language. But it is able to solve many practical business tasks. Although each executed instance of your language is not Turing-complete in isolation, the system of instances is Turing-complete because you have the ability to reference global memory in the form of the data feed. Thus you can still have scenarios of unbounded recursion and even live or dead locks. Craig Wright had schooled Nick Szabo and Gregory Maxwell on this point also. So you have not prevented hacks. And you have somewhat crippled the language compared to Solidarity. You may argue you've made the intent clearer, but when people write convoluted systems with this in order to achieve complex smart contracts by simulating Turing completeness, then it may end up more obfuscated than Solidarity. I really don't see your design strategy as the absolute panacea you seem to claim or imply. There is a limit on the number of operations per smart contract, data feed lookups included. It is not a panacea. It is designed to meet the demands of regular users, and they are not convoluted, as the recent superresistant's example shows. If you need convoluted, go with Solidity, but be extremely careful when you expose complex systems to regular users (unaccredited investors, if we consider investments context). When users are exposed to complex systems that they don't fully understand and that can potentially harm them, the governments will want to "protect the consumer" -- by regulation. |
|
|
|
To protect those who didn't upgrade fast enough, I'll update the default hub to refuse connections from clients that run an old version.
This is now done. If you run a your own hub, please upgrade it too. |
|
|
|
Important security update 1.5.1 https://github.com/byteball/byteball/releasesIt removes a XSS vulnerability that allowed remote code injection via specially constructed chat messages. Thanks @portabella for discovering the bug. The update also includes a minor performance improvement. Upgrade is mandatory. To protect those who didn't upgrade fast enough, I'll update the default hub to refuse connections from clients that run an old version. |
|
|
|
When I understand correctly, then conditional payments are like smart contracts, right? It is just another name for it isn't it?
Conditional payments is an application based on smart contracts. |
|
|
|
Tested Bind payment
sent 0.4 GBB for 1000 byte received.
there is something strange in Peer chat, it says "Payment 4349 bytes" but the payment condition was 1000 bytes.
Indeed payment request message was "payment request : 1000 bytes to XYA............FFR" , peer received 1000 bytes request and 1000 bytes were sent
another strange thing happen in bytes receiver wallet: 0.484 GB have been moved in a new address, wallet balance has not been affected.
0.4 GBB are in a blackbytes smart wallet now.
What i want to ask is:
- why chat messages are not the same
- sending another Binf payment will generate another subwallet?
- TX fees are doubled with this new feature, am i correct?
- Blackbytes balance of receiver wallet is splitted in GBB in main wallet + GBB "Also" in smart wallet, why not total amount ?
How did you test? Could it be that you had the same device on both sides of the trade? Main Device (PC) has 2 wallets , default wallet and Multisig (1/2) wallet -created later- 1 Pc sending GBB + 1 Android mobile receinving GBB multisig wallet (1/2) repeated test (5 GB for 1000 bytes), this time chat message says "payment 2364 bytes" , again 0.48 GB moved in a new address That's what I expected - your PC was on both sides of the trade and it had difficulty interpreting the payment that had its addresses as both sender and receiver. - TX fees are doubled with this new feature, am i correct? There are 3 transactions in total, if that's what you are asking about. agree about 3 transaction, why the third is not automatic? The wallet never signs transactions on your behalf without your explicit request. - Blackbytes balance of receiver wallet is splitted in GBB in main wallet + GBB "Also" in smart wallet, why not total amount ? Because spending of smart wallet is constrained by the smart contract conditions. You might be not able yet or already not able to spend from it. If you can spend from it, you move its balance to your main wallet, this is the 3rd and final transaction. what happen if the third transaction is undone? What do you mean undone? |
|
|
|
Tested Bind payment
sent 0.4 GBB for 1000 byte received.
there is something strange in Peer chat, it says "Payment 4349 bytes" but the payment condition was 1000 bytes.
Indeed payment request message was "payment request : 1000 bytes to XYA............FFR" , peer received 1000 bytes request and 1000 bytes were sent
another strange thing happen in bytes receiver wallet: 0.484 GB have been moved in a new address, wallet balance has not been affected.
0.4 GBB are in a blackbytes smart wallet now.
What i want to ask is:
- why chat messages are not the same
- sending another Binf payment will generate another subwallet?
- TX fees are doubled with this new feature, am i correct?
- Blackbytes balance of receiver wallet is splitted in GBB in main wallet + GBB "Also" in smart wallet, why not total amount ?
How did you test? Could it be that you had the same device on both sides of the trade? - sending another Binf payment will generate another subwallet? Yes you have a subwallet for every unfinished trade . - TX fees are doubled with this new feature, am i correct? There are 3 transactions in total, if that's what you are asking about. - Blackbytes balance of receiver wallet is splitted in GBB in main wallet + GBB "Also" in smart wallet, why not total amount ? Because spending of smart wallet is constrained by the smart contract conditions. You might be not able yet or already not able to spend from it. If you can spend from it, you move its balance to your main wallet, this is the 3rd and final transaction. |
|
|
|
Version 1.5 released https://github.com/byteball/byteball/releasesIt's the biggest update since the launch. It enables conditional payments, which allow you to P2P exchange bytes vs blackbytes since today. Much more in the next releases. Read my Medium article about making P2P great again https://medium.com/byteball/making-p2p-great-again-fe9e20546a4a#.i6kj1ug99Note that to bind your payment to a condition you must be connected in chat with the payee and click his address or accept a payment request. Other updates in this release: * Fixed frequent disconnects that might affect sync speed * Small performance optimizations * Multiple small bugs fixed Please upgrade. The wallet might start a bit longer than usual the first time after the upgrade, this is because it needs to upgrade the database, be patient. Be prepared for bugs since it is a big update (I guess you are already used to expecting this when you are into something new). |
|
|
|
|
Show Posts
