I am reading the whitepaper and why do i feel like satoshi is back?  Btw, how does this witness thing work? Does witness get fees from maintaining the network? Yes, they get part of the fees paid by users. |
|
|
|
The snapshot will be taken on block 437000 in early November (subject to change).
Pick a block number randomly out of range of blocks, e.g. 437000-438000, after the last block in the range is closed. What for? |
|
|
|
Since there will be no ICO, how do you plan to fund this project in short term and long term?
Like I did before for the previous 22 months, plus I allocate 1% for myself. Did you mean that you will not hire any additional devs in the future? How long can you sustain with your own funds? I am not a skeptic. I just want to understand and evaluate the project's financial situation. I might move one of my employees to this project. Don't worry about funding, I can afford building something long term, even if the community is slow to join development. |
|
|
|
So when distribution happens, would we need to consolidate all bitcoins to a certain address before a certain block? How would sending from a coinbase wallet work - if a user sent maybe 0.0001 BTC from an address to your address and the Coinbase address contains 100 BTC, would he/she have a weight of 100 BTC during distribution?
IMHO a snapshot of the bitcoin blockchain must be taken at a defined block height to verify the address amounts. Without a snapshot one could easily move his bitcoins around and claim bytes multiple times. Snapshot at a certain block height is good but combining those bitcoins into one address in order to claim would become impossible. Yes but I don't see any alternative to a snapshot, the risk that you can game the distribution is too high and this must be prevented at all costs. What's the advantage to combine your bitcoin adresses anyway? In bitcoin best practice is to not re-use addresses. I think it would be better to claim with multiple addresses from your wallet without moving coins around. The snapshot will be taken on block 437000 in early November (subject to change). Answering the original question, consolidating all bitcoins to a single address is recommended for convenience, otherwise you'll have to claim for each individual address. If concerned about what blockchain analysts can uncover about you, pass the coins through a mixer prior to consolidating. 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. |
|
|
|
Since you are rightfully concerned about privacy, I want you to be aware that Byteball wallet sends crash reports to me whenever it detects any abnormal condition. These reports have already helped me fix some bugs in the latest release and identify others that need further investigation.
Thanks for pointing that out. Do you mean that it is hard-coded or the user can choose not to send the reports? My opinion on the matter in general, is that the user should have the choice and assume the consequences that come with their choice. In the current version, it is hard-coded. One way to get rid of the reports is by connecting to another hub (change hub address in global settings) that doesn't process bug reports. I'm not aware of any other hubs except the one I run, but you can run your own https://github.com/byteball/byteball-hub. This is one of recent bug reports to see what information it contains: Javascript error: Uncaught TypeError: Object [object Object] has no method 'retrieveJsMessages' TypeError: Object [object Object] has no method 'retrieveJsMessages' at pollOnce (file:///android_asset/www/cordova.js:969:40) at pollOnceFromOnlineEvent (file:///android_asset/www/cordova.js:960:5) Breadcrumbs: Sat Sep 10 2016 17:17:52 GMT+0200 (CEST): index.js Sat Sep 10 2016 17:17:56 GMT+0200 (CEST): already connecting to wss://byteball.org/bb Sat Sep 10 2016 17:17:59 GMT+0200 (CEST): already connecting to wss://byteball.org/bb Sat Sep 10 2016 17:18:00 GMT+0200 (CEST): connected to wss://byteball.org/bb Sat Sep 10 2016 17:47:18 GMT+0200 (CEST): already connecting to wss://byteball.org/bb Sat Sep 10 2016 17:47:18 GMT+0200 (CEST): already connecting to wss://byteball.org/bb Sat Sep 10 2016 17:47:20 GMT+0200 (CEST): connected to wss://byteball.org/bb Sat Sep 10 2016 17:55:58 GMT+0200 (CEST): already connecting to wss://byteball.org/bb Sat Sep 10 2016 17:55:58 GMT+0200 (CEST): already connecting to wss://byteball.org/bb Sat Sep 10 2016 17:55:59 GMT+0200 (CEST): connected to wss://byteball.org/bb Sat Sep 10 2016 17:56:08 GMT+0200 (CEST): bugreport UA: Mozilla/5.0 (Linux; Android 4.4.4; GT-I9000 Build/KTU84Q) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/33.0.0.0 Mobile Safari/537.36 Program: byteball-test android 0.2 |
|
|
|
And so if it is just 1 1000 note ?
To pay 523, I would need to change it with someone ?
Yes, same as cash. Why not have a special 'split' txn ? So I can split my 1000, into a subset of smaller denominations that allow payment of any amount. Say.. 500, 100x4, 50, 10x4, 5, 1x5.. etc That's what smaller denominations are for. If we allow unlimited splitting (remember, there is no merging), all large-denomination coins will be split and large-value payments will become inconvenient. |
|
|
|
How to see the all the previous addresses generated please
Gear icon -> Advanced -> Wallet information -> scroll to Last wallet addresses |
|
|
|
And so if it is just 1 1000 note ?
To pay 523, I would need to change it with someone ?
Yes, same as cash. |
|
|
|
Back to the tech..
With the private fixed denominations, what happens if I have a single 1000 output, and i need to pay someone 523..?
Do I need to get change from someone?
Depends on the denomination of your 1000 output. Consider it like cash. In code, we have tolerances that allow to round the transfer amount if you are short of small-denomination outputs required to compose the exact desired amount. |
|
|
|
Like many open-source projects it should be supported by the community, which will hopefully emerge.
If you are a developer, you are welcome to contribute to our github repos.
I cannot help you with the development but I can help you finding a community (and maybe there are some good devs among them). I'll try to make this project popular using my twitter account (3000 followers) and my contacts from other crypto projects. IMHO some bounties for community tasks like beta testing, documentation, translations, end user support, marketing, fighting the trolls  etc. etc. could be really helpful. You should consider to set aside another percentage of bytes for these things. Thank you for your help, we do need active community members. While I expect most community effort, including development, to be voluntary, I'll consider funding some clearly defined tasks without impacting the distribution percentages. |
|
|
|
Well, then I missed something, exactly for the attack I previously mentioned, and your answer.
....
I think you are missing that both hashes that represent the private transaction are already enclosed into a regular public transaction that is signed as usual: private_transaction: { regular_public_inputs: [...], regular_public_outputs: [...], hash_of_private_payload: ".....",
spend_proof: "....", signature_of_all_the_above: "...." } The bolded part is what makes a private transaction different from a regular one. It is covered by the signature and we know who signed it. You can't redeem BBC back to bitcoin. "Unburning" would mean dumping the entire history of the coin to the public, which is clearly against its purpose. But you can exchange it.
The thing is, one could think of a cryptographic way to redeem the bitcoin, instead of burning it, style Lightning network, so that in the end, only one transaction needs to be broadcast, to the final owner. I don't know exactly how to do this, but it must be possible in some way. Still seems unlikely that it is possible, but if you find a way, I'll be glad to know. |
|
|
|
I agree they are becoming too intrusive with their data mining. I checked F-droid but didn't change my decision to distribute APKs through google play exclusively. The biggest merit of google play is auto-updates, which is absolutely required for security apps like this. While you say you are prepared to go through the trouble of manual updating, most people aren't, and I don't want to encourage use of outdated software that might have critical security bugs. Moxie Marlinspike had some fair criticisms about f-droid, which I totally agree with, and I believe, for this kind of apps, google is a lesser evil. Since you are rightfully concerned about privacy, I want you to be aware that Byteball wallet sends crash reports to me whenever it detects any abnormal condition. These reports have already helped me fix some bugs in the latest release and identify others that need further investigation. |
|
|
|
Jesus, you need a team!  Quite an achievement for only one person, you can be proud! I've got the feeling that this could be really huge. Do you have a vision how the project should go forward? Like many open-source projects it should be supported by the community, which will hopefully emerge. If you are a developer, you are welcome to contribute to our github repos. |
|
|
|
Ah, essentially, you mean that the spend proof is in fact nothing else but a "burning transaction".
No, spend proof and burning transaction are not the same. Burning transaction happens only once to convert bitcoins to BBC, while spend proof is sent with every subsequent transfer of the private currency.
Ok, it took some time to start understanding it, but I'm starting to see now what you mean (I think).
Correct me if I'm wrong. The problem that Satoshi faced was to
1) avoid double spending, and for that, it is necessary to have a common, distributed ledger of spending proofs and
2) prove that you have an "original" coin, and not a newly invented one
and the way that Satoshi proposed to solve this was to put *the entire transaction* on the common ledger: you can see when the previous spend happened, and you can trace back each coin to its legit creation.
Indeed is there no way to "transmit a file" where the file is the money, like a bank note, because files can be copied.
What you propose, essentially, is to go back partially to "files are bank notes", and these files are individual transaction histories of the coin. On the common ledger only needs to be registered the hash of a spending signature. The "bank note file" itself needs to carry a proof of legit creation (in your proposal, a burning of bitcoin).
That is indeed not a bad idea ! It is of course not very private, in the sense that each individual "bank note" carries with it its entire spending history, but on the other hand, only the people receiving it get that file (and not the entire planet), and because of the linear nature of it, if one uses different signatures for each bank note, there's no "network analysis" that can be performed, so the pseudonymous nature is perfectly anonymous in this case, because no "joins and splits" can happen.
So if I understand correctly, the public block chain is just a "bag of hashes" which cannot be verified or anything by any node or miner. It is just a block chain of "data". These data only have meaning for the people receiving "banknote files", which allows them to check the validity of the whole "banknote". The hashes are in fact nothing else but hashes of "signed transactions", like with bitcoin, except that only the *signature hash* goes on the public block chain, and the actual transaction data remain on the individual banknote file. Is that the gist ? In fact, you need, as you say, TWO signatures (or hashes of signatures): one is the transaction signature (including the new beneficiary) and the other is the "spend" signature of simply the previous output. The first signature (spending signature) makes that you cannot do double spending any more (you have invalidated the file up to the point where you transmit it), and the second signature allows the receiver to have a valid "new address" that he can spend (and only he, because only he has the secret key that goes with it like on bitcoin).
This is indeed a very, very good idea ! Money becomes more "physical" again: it are files !
Wow, you made a good job of explaining the concept in a clearer way! Anyone who didn't understand the OP should jump here and read your post. Except for one correction: in the below paragraph, where you say "signature" you are actually referring to "hash" rather than a cryptographic signature. So if I understand correctly, the public block chain is just a "bag of hashes" which cannot be verified or anything by any node or miner. It is just a block chain of "data". These data only have meaning for the people receiving "banknote files", which allows them to check the validity of the whole "banknote". The hashes are in fact nothing else but hashes of "signed transactions", like with bitcoin, except that only the *signature hash* goes on the public block chain, and the actual transaction data remain on the individual banknote file. Is that the gist ? In fact, you need, as you say, TWO signatures (or hashes of signatures): one is the transaction signature (including the new beneficiary) and the other is the "spend" signature of simply the previous output. The first signature (spending signature) makes that you cannot do double spending any more (you have invalidated the file up to the point where you transmit it), and the second signature allows the receiver to have a valid "new address" that he can spend (and only he, because only he has the secret key that goes with it like on bitcoin).
Now, the question is: how does the mining work ? Or is this meant as a parasite on top of the bitcoin block chain ?
We are talking about two similar but distinct designs here: 1) BBC proposed in the OP is a parasite on top of the bitcoin blockchain. It was never implemented. 2) Blackbytes in Byteball, the coin I launched earlier this week https://bitcointalk.org/index.php?topic=1608859.0, there is no mining at all, the coin is in testnet phase, and you can already play with blackbytes. The thing is, you need to burn a bitcoin to obtain something, irreversibly, that is not a bitcoin at all. Nobody is going to burn a bitcoin to have a new altcoin. You would automatically give that altcoin the value of a bitcoin, if you could redeem the whole payment history against a bitcoin again. But then, what you have constructed, is a *private sidechain* on top of bitcoin.
You "lock up a bitcoin" in the side chain. The side chain is not public, but is just the private "money file". Any legit owner along the chain can transmit the chain to the next one (as you describe more or less), OR can redeem the bitcoin from the original transaction, and as such, end the side chain. It is not *entirely* what you propose, but close.
The redeeming of the bitcoin at the end of the chain is probably somewhat more tricky.
You can't redeem BBC back to bitcoin. "Unburning" would mean dumping the entire history of the coin to the public, which is clearly against its purpose. But you can exchange it. |
|
|
|
I see 65,000 bytes and 53,923 of ... why two please: Is it one for Bytes and the other for ByteBalls?
The other is for blackbytes. The "of JY4R..." part is about the asset you are holding, JY4R... is blackbytes. You can have even more than two assets. How to link my byteball to the bitcoin addresses please
The linking phase will start later, watch this thread for announcements. |
|
|
|
I installed Byteball-test-win64.exe on Windows 10 64-bit without error. but when it open, it close right away without error. Could you please help
Thanks
Try deleting the app data: navigate to c:\Users\<your user name>\AppData\Local and delete byteball-test folder. Then restart the app. |
|
|
|
Actually, I don't see mic on the list of requested permissions.
I do  . I have two lines in requested permissions: - Photos/Media/Files - Camera/Microphone I checked both on my phone and on the GP web page https://play.google.com/store/apps/details?id=org.byteball.wallet, neither lists the mic. I'm guessing you see some broad groups of permissions rather than individual ones. The app is based in Cordova, and some Cordova plugins request permissions that are not actually used by the app.
Of this list, we use only camera to scan QR codes, you can verify that by the source code.
I don't know much about Cordova or Android apps. I checked the code and found some lines that may mean that camera and flashlight are used and found code about scanning QR codes ... Anywhere to look specifically? If you found this line https://github.com/byteball/byteball/blob/e1e29620587d4a8744777af3e713c53940e1773a/src/js/directives/qrScanner.js#L13, this where we call the cordova plugin that works with the camera. There are services that automatically extract apk from google play, you can google for them.
I didn't kown about these services. Thx for pointing that out. I searched for them and found (just) two services: - https://apps.evozi.com/apk-downloader which gives me an error when I try to use it: Ops, APK Downloader got access denied when trying to download, Please try again and contact us. - A Firefox addon https://addons.mozilla.org/en-US/firefox/addon/apk-downloader (also available for Chrome) which requires me to have Google Play installed to begin with ... Do you know of any other working service that doesn't require you to have GP installed? But remember that you'll have to update manually each time we release a new version.
Yep, I'm willing to go through that trouble . Thank you. I googled for "byteball apk" and "google play apk" and found a few. Not sure how trustworthy they are, and some list the old version that was replaced yesterday. Just curious, what are you so averse of google play? |
|
|
|
Much clearer. Got it.
So, a user can actually send a private txn where the payload and spend proof are gibberish. This would still get in the database, but would be useless as noone would accept it.
He can, although I don't see why he would want to do it. What stops anyone posting a private txn with the unique spend proof of 'some' address, just to block the real owner from spending ? Since noone will know what is actually in the payload, they can't distinguish the two, and if the fake is closer to the MC at lower block, those funds would be considered spent ? The attack won't work because duplicate spend proofs must be also signed by the same user. If the same spend proof is signed by somebody else, it is not a double-spend. |
|
|
|
|
Show Posts
