The exchange is not built-in (as in Nxt, Ripple, and Bitshares), it is an application built on smart contracts. It is the first application on our network that uses smart contracts. By keeping the exchange out of the core, we achieve that we don't have to add complexity to the core, as well as greater flexibility in how the exchange can work.
This is interesting approach. Nxt, Ripple or Bitshares don't have businesses which run their exchanges, but they all need businesses to run gateways which take care of deposits/withdrawals of funds. Do you suggest that exchange and gateway are combined and ran by same business? How would assets issued by different exchanges be traded against each other in this case? Issuers and exchanges can be combined or not. If a business issues assets that try to mirror fiat currencies, i.e. acts as a gateway, it does make sense to run the two activities under the same roof because customers would benefit from one-stop shopping. |
|
|
|
GBYTE/BTC will be quite low. as a comparison those with 100btc linked will get 300GB. unless you expect 0.5btc per GB rates then MB is a better measure. its why i asked tony on it. 1GB is a huge measure on overall percent. when the tipbot gives 1MB or 1000KB in proportion 1GB is too huge to be a base unit. very few would have 1TB if any. i think you should use MB
I don't think byteball gains BTC market cap easily, there will be 1 milion GBYTE market suply, compared to 21 milion BTC, price of GBYTE should be below 1 as all other crypto. MBYTE price would have 3 leading zeros more (after dot) which leeds to confusion. No. Not yet, maybe in a year. I guess, it`s better to start with small units so that we have the potential for gradual growth. At the beginning there is only 100 000 and not 1 mln. GB. tonych, what do you thing about it? It's just the numbers, they have nothing to do with potential for growth. Gigabyte is ok with me. |
|
|
|
So I cloned master again, run build steps leaving only the final "grunt" to be run.
Then find byteball/node_modules/byteballcore renamed it to get ride of it.
Put in its place the content of your unfinished byteballcore, and run grunt and tried to run byteball as before.
But after chose full wallet it shows and exclamation icon with message:
An exception occurred: TypeError: Wallet.readBalance is not a function: cause: undefined
And after click OK button it closes.
it seems I'm doing it the wrong way.
If you still want me to test this sock5 thing, could you please point me to some instruction on how to make it works.
Besides of this, I think I'm afraid I could not use this new version of byteball with sock5 to link and participate on byteball first round of distribution, as it probably won't be ready soon enough;
I still want to use TOR and so my only option seems to be whonix building livenet myself.
You did everything right, but the versions appeared to be incompatible (the fork was lagging a few commits), so forget it, better wait that we merge, or given the time constraints, the whonix ways seems safer. If by doing: git clone https://github.com/byteball/byteball.git I get "new testnet", how can I clone live 0.7.1 (with I assume is the version everybody linking their bitcoins is using) to build it to proceed with live wallet generation and linking process via TOR? Thanks. Switch to "livenet" branch, it corresponds to live 0.7.1. OK, that works and I've successfully build and run livenet. Thank you. Now, my security model imply, as a way to link byteball to bitcoins, that I sign byteball addresses offline. So I've tried to generate a certain number of byteball address in order to create a file to take it offline to another computer and while there I would sign each byteball address with a bitcoin address and save the signed text. Then I would bring that file back to the online computer start byteball again and inform to the linking bot those addresses and signed results and have everything linked. So, to generate the byteball addresses I went to receive and press generate address button several times and then went to Preferences > Advanced > Wallet Information and at button copied the generated byteball addresses. First thing I noticed was that it seems to only show the last about 6 generated addresses. Never mind, I come back to receive and generate some more and go back to Walled Information and copy the new ones from there, Then I noticed that after some time receive stop generating new addresses and every time that I press generate button it generates one of those already generated. I tried to close and run again the wallet and the same thing happened Is there a way around this? Even thou I'm not being able to see all addresses can I be sure to have all them registered inside the wallet? Thanks again Complementing.... I've also noticed that when I press insert address button on transition bot it place there one of the previouslly generated ađresses and not a newly generated one. thanks BIP44 recommends to avoid having more than 20 unused addresses in a row, that's why we stop generating new addresses at this point and give a random unused one. However, you can hack this around by editing MAX_BIP44_GAP constant at https://github.com/byteball/byteballcore/blob/master/wallet_defined_by_keys.js#L25. Note that signed message is expected to sign the last BB address that you told the bot. So if you want to avoid all your Bitcoin addresses being associated with the same BB address, your dialog with the bot should consist of repeated series of these 3 steps: - BB address - Bitcoin address - signed message |
|
|
|
No Pow No Pos. Transaction fees are redistributed to wallets in the network.
Well, what a coin's winning pattern is.
Does this make the developer famous?
Came a question like this. Is he/she asking how to earn transaction fees? Be a well connected node, receive new transactions earlier than the others, and when you create your own transactions, reference these fresh transactions as parents. |
|
|
|
Two news for today: version 0.8.0t is released and trustless exchange is launched. Both are for testnet. Download the new version from https://github.com/byteball/byteball/releases, Android should auto-update, and the link to the exchange is at https://byteball.org. Only the new version will work with the exchange. The exchange allows to exchange public assets issued on Byteball platform, including bytes. Blackbytes are not covered as they are a private asset. The exchange is not built-in (as in Nxt, Ripple, and Bitshares), it is an application built on smart contracts. It is the first application on our network that uses smart contracts. By keeping the exchange out of the core, we achieve that we don't have to add complexity to the core, as well as greater flexibility in how the exchange can work. The exchange is centralized and trustless. Centralized means that there can be many centralized exchanges competing with each other and trying to deliver better product. Centralized also means that it is run as a business and can be properly managed and marketed. Trustlessness means that the exchange operator can't steal customer's money, nor can he lose it if the exchange is hacked or mismanaged. This is achieved by very simple smart contracts that every user can see and verify, and he doesn't need to be a developer to understand them: To create an order to exchange asset A to asset B, a customer sends his asset A to an address that can be spent: - by the customer himself after a timeout, or - by the exchange operator if the same transaction simultaneously sends asset B to the customer (in the specified amount) The first clause allows the customer to cancel the order and take his money back. The 2nd clause doesn't give the operator arbitrary control over asset A: the operator can use asset A only if he simultaneously pays asset B to the customer. This is the key difference from conventional trustful exchanges -- the operator is bound by the contract. The operator then matches this order with a reverse order from another customer and signs for both sides of the deal simultaneously. This is what a typical dialog with exchange operator looks like (yes, it is a chatbot, you've already got used to):   Before paying, the customer is presented with a user readable description of the contract:  HXY5... is the asset we are buying (chips). W272... is the exchange address (actually, it doesn't matter who owns this address as long as the asset is sent to us). Before the order is executed, the customer can see everything about this smart contract address in his wallet -- its balance and history, and can spend from this address (after the timeout specified in the contract). The address is presented as a subwallet, it is easy to navigate to and from. For those who have experience with conventional exchanges, there are a few differences that may seem odd. Due to how the smart contracts work, there is no partial matching of orders. To overcome this, orders are split into a small number of standard sized orders. The standard lot sizes are powers of 2, which allows to match equal-sized orders, as well as some common combinations thereof, such as one large order against two half-sized orders (e.g. 32=16+16). (Instead of powers of 2, we could also use Fibonacci numbers as standard lot sizes because each size would be equal to the sum of two smaller sizes, e.g. 13=8+5). That's why when you create an order you usually pay to several addresses. These sub-orders can match at different time and you'll receive your assets in several standard-sized portions. Also, placing an order is not instant, you have to wait that the transaction that funds it becomes final. Obviously, there is no margin trading, and there are no charts in chat. So, if you are a day trader, it is not for you. If you need to occasionally buy or sell assets, I think this tool is quite good for you. Try it for yourself, the new UI is available after upgrading to 0.8.0t, and the link to start a chat with the exchange bot is at https://byteball.org. Remember, this will work with testnet wallet only. Please retweet https://twitter.com/ByteballOrg/status/811007135148572672 |
|
|
|
So I cloned master again, run build steps leaving only the final "grunt" to be run.
Then find byteball/node_modules/byteballcore renamed it to get ride of it.
Put in its place the content of your unfinished byteballcore, and run grunt and tried to run byteball as before.
But after chose full wallet it shows and exclamation icon with message:
An exception occurred: TypeError: Wallet.readBalance is not a function: cause: undefined
And after click OK button it closes.
it seems I'm doing it the wrong way.
If you still want me to test this sock5 thing, could you please point me to some instruction on how to make it works.
Besides of this, I think I'm afraid I could not use this new version of byteball with sock5 to link and participate on byteball first round of distribution, as it probably won't be ready soon enough;
I still want to use TOR and so my only option seems to be whonix building livenet myself.
You did everything right, but the versions appeared to be incompatible (the fork was lagging a few commits), so forget it, better wait that we merge, or given the time constraints, the whonix ways seems safer. If by doing: git clone https://github.com/byteball/byteball.git I get "new testnet", how can I clone live 0.7.1 (with I assume is the version everybody linking their bitcoins is using) to build it to proceed with live wallet generation and linking process via TOR? Thanks. Switch to "livenet" branch, it corresponds to live 0.7.1. |
|
|
|
Now the worst part will be to find someone willing to borrow me some BTC before 25th of the month. I hope i will manage this too before is to late  Just an idea, you don't have to actually borrow, just convince them to sign your BB address, but don't tell them what for! |
|
|
|
Please use nwjs v0.14.7 and node v5.12 (they match). You can use nvm to have multiple versions of node at the same time.
After you rebuild and start for the first time, it will complain about node_sqlite3.node again. Find this file in the neighboring directory and just copy it to where nwjs tries to find it, it'll work next time.
Hello. Thanks for the advice. I managed to reinstall the sqlite3 for the platform before I have read this post. Anyway it seem to work now. I have synchronized the wallet in less then an hour. For those who could need it this is the specification of the my environment: linux 32 bit machine node.js v6.9.2 nw.js v0.19.2-linux-ia32 I have executed the following commands: git clone https://github.com/byteball/byteball.git
cd byteball
npm install -g bower
npm install -g grunt-cli
npm install jasmine-core --save-dev
bower install
npm install
grunt
sudo npm install nw-gyp -g
npm uninstall sqlite3
npm install sqlite3 --build-from-source --runtime=node-webkit --target_arch=ia32 --target=0.19.2
Now I wanted some bytes to play with but when I click the link on that https://byteball.org/it cant open it. link:
byteball-tn:AxBxXDnPOzE/AxLHmidAjwLPFtQ6dK3k70zM0yKVeDzC@byteball.org/bb-test#0000
or
byteball-tn:AzG28EqBgI9OkDa5yka9gYTqqrfuwt+7mUAUuhaAXLAT@byteball.org/bb-test#0000
or
byteball:A2WMb6JEIrMhxVk+I0gIIW1vmM3ToKoLkNF8TqUV5UvX@byteball.org/bb#0000
I receve a message box with "Error Loading Extension" Failed to load extension from: Manifest file is missing or unreadable Is there a way to opet links byteball-tn: or byteball: on a desktop machine? Great, this is also a valid way to build. To make the links work, please run "grunt desktop" (you might have to edit the Gruntfile.js a little bit to enable 32 bit version) and run Byteball once from ../byteballbuilds. It will set up the proper protocol handlers for byteball-tn:. |
|
|
|
Based on the progress of address linking that we've seen so far, I have to make a few adjustments to the future distribution plan. Nothing changes for the first round (December 25) but the rules for further rounds are optimized to maximize the long-term value of your bytes.
For the 2nd round:
- for every 1 BTC of proven balance you receive 62.5 MB
- for every 1 byte, you receive 0.1 new bytes
We no longer commit to distributing exactly 20% in the second round, we'll distribute as much as is linked and calculated by the above rules. After the price of byte is established in the markets, the rules make it significantly simpler for new users to estimate how much they get by linking their Bitcoins or by buying bytes. Hopefully, this will encourage much more people to join.
Compared with the previous rules, the weight of bytes in the basket is decreased. This still encourages byteholders to hold in order to receive more bytes in the future rounds, while giving more weight to the newly linked BTC. We do need to be more attractive to new users, who are going to eventually link much much more BTC than we see in the current round, otherwise they might feel like a huge chunk of the second distribution will go to the participants of the first distribution, while new users are significantly disadvantaged. If it is not quite clear, this is the math:
Under the old rules, for the basket weight calculation, 62.5 MB were accepted as 1 BTC. 1014 bytes are distributed in the first round, the total weight of these bytes is 1,600,000 BTC. This seems huge compared with the amount of BTC the second-rounders are going to realistically link, based on current progress. Therefore, under the old rules, the vast majority of new bytes are going to be distributed to the first-rounders, which scares new users off and contradicts my plans of creating the widest possible distribution and increasing value through network effects (which are proportional to square of the number of users). To give new users better chance, the total weight of bytes distributed in the first round is reduced to 160,000 BTC under the new rules.
We will probably distribute less than 20% in the 2nd round, this means we'll have more rounds before all bytes are distributed, more opportunity to multiply your holdings in each round, more incentive to hold.
The 3rd and subsequent rounds will follow similar rules, but the relative weight of bytes vs. BTC in the 3rd and further rounds will change and will gradually increase back to 1 BTC=62.5 MB. It will be selected to maximize the value of bytes and keep the speed of distribution in sync with the growth of user base and the actual use of the network.
The date of the 2nd round is not decided yet, rough estimate is mid-February.
Interesting changes. Indeed, it will favor more the new users, but there are a few problems. (1) First time users are more loyal I believe, they've been following this thread for long time and really interested. (2) decrease weight in bytes will cause more dump of bytes in the market, which is not good. We certainly hope people will hold more longer term. Fair enough, but we have to strike a balance to encourage new users to join, as we won't create value by trading among ourselves. That said, remember that first time users still get about 4 GB per BTC (at the current rate) while second-rounders get 62.5 MB per BTC, and I plan to increase the weight of bytes in the final rounds, so it still makes a lot of sense to hold. |
|
|
|
@tonych
Keep in mind that not all those who linked their addresses have funded them yet. It takes time to convert all these altcoins to BTC at reasonable prices, so the huge increase in linked BTC is probably going to happen at the last moment before 25th. It is a good idea not to set in stone the rules for 2nd and 3rd rounds for now.
I hope you are right but have to prepare for less optimistic outcome too. |
|
|
|
Based on the progress of address linking that we've seen so far, I have to make a few adjustments to the future distribution plan. Nothing changes for the first round (December 25) but the rules for further rounds are optimized to maximize the long-term value of your bytes.
For the 2nd round:
- for every 1 BTC of proven balance you receive 62.5 MB
- for every 1 byte, you receive 0.1 new bytes
We no longer commit to distributing exactly 20% in the second round, we'll distribute as much as is linked and calculated by the above rules. After the price of byte is established in the markets, the rules make it significantly simpler for new users to estimate how much they get by linking their Bitcoins or by buying bytes. Hopefully, this will encourage much more people to join.
Compared with the previous rules, the weight of bytes in the basket is decreased. This still encourages byteholders to hold in order to receive more bytes in the future rounds, while giving more weight to the newly linked BTC. We do need to be more attractive to new users, who are going to eventually link much much more BTC than we see in the current round, otherwise they might feel like a huge chunk of the second distribution will go to the participants of the first distribution, while new users are significantly disadvantaged. If it is not quite clear, this is the math:
Under the old rules, for the basket weight calculation, 62.5 MB were accepted as 1 BTC. 1014 bytes are distributed in the first round, the total weight of these bytes is 1,600,000 BTC. This seems huge compared with the amount of BTC the second-rounders are going to realistically link, based on current progress. Therefore, under the old rules, the vast majority of new bytes are going to be distributed to the first-rounders, which scares new users off and contradicts my plans of creating the widest possible distribution and increasing value through network effects (which are proportional to square of the number of users). To give new users better chance, the total weight of bytes distributed in the first round is reduced to 160,000 BTC under the new rules.
We will probably distribute less than 20% in the 2nd round, this means we'll have more rounds before all bytes are distributed, more opportunity to multiply your holdings in each round, more incentive to hold.
The 3rd and subsequent rounds will follow similar rules, but the relative weight of bytes vs. BTC in the 3rd and further rounds will change and will gradually increase back to 1 BTC=62.5 MB. It will be selected to maximize the value of bytes and keep the speed of distribution in sync with the growth of user base and the actual use of the network.
The date of the 2nd round is not decided yet, rough estimate is mid-February.
Why also not increase number of phases thus also decreasing percentages? Its easy to announce and increase/modify later if everything starts rolling. It would allow time for market to develop. Also, correct your post. First you state nothing changes in round one then explain how its calculated differently.My mistake The new plan means that there will be more phases. |
|
|
|
|
Based on the progress of address linking that we've seen so far, I have to make a few adjustments to the future distribution plan. Nothing changes for the first round (December 25) but the rules for further rounds are optimized to maximize the long-term value of your bytes.
For the 2nd round:
- for every 1 BTC of proven balance you receive 62.5 MB
- for every 1 byte, you receive 0.1 new bytes
We no longer commit to distributing exactly 20% in the second round, we'll distribute as much as is linked and calculated by the above rules. After the price of byte is established in the markets, the rules make it significantly simpler for new users to estimate how much they get by linking their Bitcoins or by buying bytes. Hopefully, this will encourage much more people to join.
Compared with the previous rules, the weight of bytes in the basket is decreased. This still encourages byteholders to hold in order to receive more bytes in the future rounds, while giving more weight to the newly linked BTC. We do need to be more attractive to new users, who are going to eventually link much much more BTC than we see in the current round, otherwise they might feel like a huge chunk of the second distribution will go to the participants of the first distribution, while new users are significantly disadvantaged. If it is not quite clear, this is the math:
Under the old rules, for the basket weight calculation, 62.5 MB were accepted as 1 BTC. 1014 bytes are distributed in the first round, the total weight of these bytes is 1,600,000 BTC. This seems huge compared with the amount of BTC the second-rounders are going to realistically link, based on current progress. Therefore, under the old rules, the vast majority of new bytes are going to be distributed to the first-rounders, which scares new users off and contradicts my plans of creating the widest possible distribution and increasing value through network effects (which are proportional to square of the number of users). To give new users better chance, the total weight of bytes distributed in the first round is reduced to 160,000 BTC under the new rules.
We will probably distribute less than 20% in the 2nd round, this means we'll have more rounds before all bytes are distributed, more opportunity to multiply your holdings in each round, more incentive to hold.
The 3rd and subsequent rounds will follow similar rules, but the relative weight of bytes vs. BTC in the 3rd and further rounds will change and will gradually increase back to 1 BTC=62.5 MB. It will be selected to maximize the value of bytes and keep the speed of distribution in sync with the growth of user base and the actual use of the network.
The date of the 2nd round is not decided yet, rough estimate is mid-February.
|
|
|
|
Hi tonych, Today, I was preparing to byteball lunch and linking some bitcoin. I'll use whonix, that same environment that, with your help, I had built and tested successfully byteball before. I decided to build Byteball-TN first to test a little more. I first cloned Byteball-TN branch only with: > git clone -b tn --single-branch https://github.com/byteball/byteball.git> cd byteball Then followed build process and resolved same issues as before, and then run byteball wallet with: > nw . Everything seems ok. I choose full wallet. The wallet shows "[NEW TESTNET]." It's run for hours but it still shows "syncing... 0%" (even after changing window focus and changing focus back to byteball window). The file byteball.sqlite has only 345 kib. Is the new testnet supposed to sync until 100% as before? Can you imagine what is wrong? Next I'll do the same thing with master branch (live) in other go generate a wallet and do the linking, but before I'd like to be sure everything is working. Thanks again. Please clone from master branch, master is now testnet. BTW, we are adding TOR support (or rather support for socks5 proxy), almost done, should be merged in a few days, but if you are ok to experiment with unfinished software, you can clone from our developer's fork https://github.com/DevAlexey/byteballcore. |
|
|
|
Linking to my previous post i have installed the sdk version. From the console it results that it can't load multiple resources(files) Failed to load resource: net::ERR_FILE_NOT_FOUND chrome-extension://fhbdbceecnjfepdnmkgncdnkleeblcpf/public/css/foundation.css
Failed to load resource: net::ERR_FILE_NOT_FOUND chrome-extension://fhbdbceecnjfepdnmkgncdnkleeblcpf/public/icons/foundation-icons.css
Failed to load resource: net::ERR_FILE_NOT_FOUND chrome-extension://fhbdbceecnjfepdnmkgncdnkleeblcpf/public/css/byteball.css
Failed to load resource: net::ERR_FILE_NOT_FOUND chrome-extension://fhbdbceecnjfepdnmkgncdnkleeblcpf/public/angular.js
Failed to load resource: net::ERR_FILE_NOT_FOUND chrome-extension://fhbdbceecnjfepdnmkgncdnkleeblcpf/public/byteball.js
index.html:44 starting scripts...
index.html:51 done scripts
 Did you run grunt? CCCCC My bad  somehow I forgot to run that line :-/ Anyway I have started the wallet and trying to create the profile. I choose the option for the full wallet Is stuck at that "Createing Profile..." screen. In console i have the following error: module.js:496
throw err;
^
Error: Cannot find module '/home/******/byteball/node_modules/sqlite3/lib/binding/node-webkit-v0.19.2-linux-ia32/node_sqlite3.node'
at Function.Module._resolveFilename (module.js:494:15)
at Function.Module._load (module.js:437:25)
at Module.require (module.js:522:17)
at require (internal/module.js:20:19)
at Object.<anonymous> (/home/******/byteball/node_modules/sqlite3/lib/sqlite3.js:4:15)
at Module._compile (module.js:595:32)
at Object.Module._extensions..js (module.js:610:10)
at Module.load (module.js:512:32)
at tryModuleLoad (module.js:471:12)
at Function.Module._load (module.js:463:3)
module.js:496
throw err;
^
Error: Cannot find module '/home/******/byteball/node_modules/sqlite3/lib/binding/node-webkit-v0.19.2-linux-ia32/node_sqlite3.node'
at Function.Module._resolveFilename (module.js:494:15)
at Function.Module._load (module.js:437:25)
at Module.require (module.js:522:17)
at require (internal/module.js:20:19)
at Object.<anonymous> (/home/******/byteball/node_modules/sqlite3/lib/sqlite3.js:4:15)
at Module._compile (module.js:595:32)
at Object.Module._extensions..js (module.js:610:10)
at Module.load (module.js:512:32)
at tryModuleLoad (module.js:471:12)
at Function.Module._load (module.js:463:3)
Is something related to sqlite3. :-/ I had errors during install phase which I have already pasted here in my previous post https://bitcointalk.org/index.php?topic=1608859.msg17215344#msg17215344I have stopped the application and then run "npm install sqlite3" within the byteball directory during install or sqlite3 i have received again this output: ~/byteball$ npm install sqlite3
> sqlite3@3.1.8 install /home/******/byteball/node_modules/sqlite3
> node-pre-gyp install --fallback-to-build
node-pre-gyp ERR! Tried to download(403): https://mapbox-node-binary.s3.amazonaws.com/sqlite3/v3.1.8/node-v48-linux-ia32.tar.gz
node-pre-gyp ERR! Pre-built binaries not found for sqlite3@3.1.8 and node@6.9.2 (node-v48 ABI) (falling back to source compile with node-gyp)
make: Entering directory '/home/******/byteball/node_modules/sqlite3/build'
ACTION deps_sqlite3_gyp_action_before_build_target_unpack_sqlite_dep Release/obj/gen/sqlite-autoconf-3150000/sqlite3.c
TOUCH Release/obj.target/deps/action_before_build.stamp
CC(target) Release/obj.target/sqlite3/gen/sqlite-autoconf-3150000/sqlite3.o
AR(target) Release/obj.target/deps/sqlite3.a
COPY Release/sqlite3.a
CXX(target) Release/obj.target/node_sqlite3/src/database.o
../src/database.cc: In static member function ‘static Nan::NAN_METHOD_RETURN_TYPE node_sqlite3::Database::New(Nan::NAN_METHOD_ARGS_TYPE)’:
../src/database.cc:133:96: warning: ‘bool v8::Object::ForceSet(v8::Local<v8::Value>, v8::Local<v8::Value>, v8::PropertyAttribute)’ is deprecated: Use CreateDataProperty / DefineOwnProperty [-Wdeprecated-declarations]
info.This()->ForceSet(Nan::New("filename").ToLocalChecked(), info[0].As<String>(), ReadOnly);
^
In file included from /home/******/.node-gyp/6.9.2/include/node/v8.h:25:0,
from /home/******/.node-gyp/6.9.2/include/node/node.h:42,
from ../../nan/nan.h:47,
from ../src/database.h:10,
from ../src/database.cc:4:
/home/******/.node-gyp/6.9.2/include/node/v8.h:2695:22: note: declared here
bool ForceSet(Local<Value> key, Local<Value> value,
^
/home/******/.node-gyp/6.9.2/include/node/v8config.h:333:3: note: in definition of macro ‘V8_DEPRECATED’
declarator __attribute__((deprecated(message)))
^
../src/database.cc:134:86: warning: ‘bool v8::Object::ForceSet(v8::Local<v8::Value>, v8::Local<v8::Value>, v8::PropertyAttribute)’ is deprecated: Use CreateDataProperty / DefineOwnProperty [-Wdeprecated-declarations]
info.This()->ForceSet(Nan::New("mode").ToLocalChecked(), Nan::New(mode), ReadOnly);
^
In file included from /home/******/.node-gyp/6.9.2/include/node/v8.h:25:0,
from /home/******/.node-gyp/6.9.2/include/node/node.h:42,
from ../../nan/nan.h:47,
from ../src/database.h:10,
from ../src/database.cc:4:
/home/******/.node-gyp/6.9.2/include/node/v8.h:2695:22: note: declared here
bool ForceSet(Local<Value> key, Local<Value> value,
^
/home/******/.node-gyp/6.9.2/include/node/v8config.h:333:3: note: in definition of macro ‘V8_DEPRECATED’
declarator __attribute__((deprecated(message)))
^
../src/database.cc: In static member function ‘static void node_sqlite3::Database::Work_BeginOpen(node_sqlite3::Database::Baton*)’:
../src/database.cc:144:9: warning: unused variable ‘status’ [-Wunused-variable]
int status = uv_queue_work(uv_default_loop(),
^
../src/database.cc: In static member function ‘static void node_sqlite3::Database::Work_BeginClose(node_sqlite3::Database::Baton*)’:
../src/database.cc:230:9: warning: unused variable ‘status’ [-Wunused-variable]
int status = uv_queue_work(uv_default_loop(),
^
../src/database.cc: In static member function ‘static void node_sqlite3::Database::Work_BeginExec(node_sqlite3::Database::Baton*)’:
../src/database.cc:525:9: warning: unused variable ‘status’ [-Wunused-variable]
int status = uv_queue_work(uv_default_loop(),
^
../src/database.cc: In static member function ‘static void node_sqlite3::Database::Work_BeginLoadExtension(node_sqlite3::Database::Baton*)’:
../src/database.cc:625:9: warning: unused variable ‘status’ [-Wunused-variable]
int status = uv_queue_work(uv_default_loop(),
^
CXX(target) Release/obj.target/node_sqlite3/src/node_sqlite3.o
CXX(target) Release/obj.target/node_sqlite3/src/statement.o
../src/statement.cc: In static member function ‘static Nan::NAN_METHOD_RETURN_TYPE node_sqlite3::Statement::New(Nan::NAN_METHOD_ARGS_TYPE)’:
../src/statement.cc:103:74: warning: ‘bool v8::Object::ForceSet(v8::Local<v8::Value>, v8::Local<v8::Value>, v8::PropertyAttribute)’ is deprecated: Use CreateDataProperty / DefineOwnProperty [-Wdeprecated-declarations]
info.This()->ForceSet(Nan::New("sql").ToLocalChecked(), sql, ReadOnly);
^
In file included from /home/******/.node-gyp/6.9.2/include/node/v8.h:25:0,
from /home/******/.node-gyp/6.9.2/include/node/node.h:42,
from ../src/statement.cc:2:
/home/******/.node-gyp/6.9.2/include/node/v8.h:2695:22: note: declared here
bool ForceSet(Local<Value> key, Local<Value> value,
^
/home/******/.node-gyp/6.9.2/include/node/v8config.h:333:3: note: in definition of macro ‘V8_DEPRECATED’
declarator __attribute__((deprecated(message)))
^
../src/statement.cc: In static member function ‘static void node_sqlite3::Statement::Work_BeginPrepare(node_sqlite3::Database::Baton*)’:
../src/statement.cc:118:9: warning: unused variable ‘status’ [-Wunused-variable]
int status = uv_queue_work(uv_default_loop(),
^
In file included from ../src/statement.cc:6:0:
../src/statement.cc: In static member function ‘static void node_sqlite3::Statement::Work_BeginBind(node_sqlite3::Statement::Baton*)’:
../src/macros.h:125:9: warning: unused variable ‘status’ [-Wunused-variable]
int status = uv_queue_work(uv_default_loop(), \
^
../src/statement.cc:322:5: note: in expansion of macro ‘STATEMENT_BEGIN’
STATEMENT_BEGIN(Bind);
^
../src/statement.cc: In static member function ‘static void node_sqlite3::Statement::Work_BeginGet(node_sqlite3::Statement::Baton*)’:
../src/macros.h:125:9: warning: unused variable ‘status’ [-Wunused-variable]
int status = uv_queue_work(uv_default_loop(), \
^
../src/statement.cc:370:5: note: in expansion of macro ‘STATEMENT_BEGIN’
STATEMENT_BEGIN(Get);
^
../src/statement.cc: In static member function ‘static void node_sqlite3::Statement::Work_BeginRun(node_sqlite3::Statement::Baton*)’:
../src/macros.h:125:9: warning: unused variable ‘status’ [-Wunused-variable]
int status = uv_queue_work(uv_default_loop(), \
^
../src/statement.cc:438:5: note: in expansion of macro ‘STATEMENT_BEGIN’
STATEMENT_BEGIN(Run);
^
../src/statement.cc: In static member function ‘static void node_sqlite3::Statement::Work_BeginAll(node_sqlite3::Statement::Baton*)’:
../src/macros.h:125:9: warning: unused variable ‘status’ [-Wunused-variable]
int status = uv_queue_work(uv_default_loop(), \
^
../src/statement.cc:504:5: note: in expansion of macro ‘STATEMENT_BEGIN’
STATEMENT_BEGIN(All);
^
../src/statement.cc: In static member function ‘static void node_sqlite3::Statement::Work_BeginEach(node_sqlite3::Statement::Baton*)’:
../src/macros.h:125:9: warning: unused variable ‘status’ [-Wunused-variable]
int status = uv_queue_work(uv_default_loop(), \
^
../src/statement.cc:601:5: note: in expansion of macro ‘STATEMENT_BEGIN’
STATEMENT_BEGIN(Each);
^
../src/statement.cc: In static member function ‘static void node_sqlite3::Statement::Work_BeginReset(node_sqlite3::Statement::Baton*)’:
../src/macros.h:125:9: warning: unused variable ‘status’ [-Wunused-variable]
int status = uv_queue_work(uv_default_loop(), \
^
../src/statement.cc:724:5: note: in expansion of macro ‘STATEMENT_BEGIN’
STATEMENT_BEGIN(Reset);
^
SOLINK_MODULE(target) Release/obj.target/node_sqlite3.node
COPY Release/node_sqlite3.node
COPY /home/******/byteball/node_modules/sqlite3/lib/binding/node-v48-linux-ia32/node_sqlite3.node
TOUCH Release/obj.target/action_after_build.stamp
make: Leaving directory '/home/******/byteball/node_modules/sqlite3/build'
byteball-tn@0.7.1-t /home/******/byteball
└─┬ byteballcore@0.1.27 (git+https://github.com/byteball/byteballcore.git#336c05e7dc2ebe558f8cc7ee65a2a5237144971f)
└── sqlite3@3.1.8
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.0.15: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"ia32"})
seems this sqlite3 makes quite problems with node-webkit :-/ I have tried uninstall and install with various options like: npm install sqlite3 --build-from-source npm install https://github.com/mapbox/node-sqlite3/tarball/masternothing helped. I still have this error of missing module. Please use nwjs v0.14.7 and node v5.12 (they match). You can use nvm to have multiple versions of node at the same time. After you rebuild and start for the first time, it will complain about node_sqlite3.node again. Find this file in the neighboring directory and just copy it to where nwjs tries to find it, it'll work next time. |
|
|
|
Linking to my previous post i have installed the sdk version. From the console it results that it can't load multiple resources(files) Failed to load resource: net::ERR_FILE_NOT_FOUND chrome-extension://fhbdbceecnjfepdnmkgncdnkleeblcpf/public/css/foundation.css
Failed to load resource: net::ERR_FILE_NOT_FOUND chrome-extension://fhbdbceecnjfepdnmkgncdnkleeblcpf/public/icons/foundation-icons.css
Failed to load resource: net::ERR_FILE_NOT_FOUND chrome-extension://fhbdbceecnjfepdnmkgncdnkleeblcpf/public/css/byteball.css
Failed to load resource: net::ERR_FILE_NOT_FOUND chrome-extension://fhbdbceecnjfepdnmkgncdnkleeblcpf/public/angular.js
Failed to load resource: net::ERR_FILE_NOT_FOUND chrome-extension://fhbdbceecnjfepdnmkgncdnkleeblcpf/public/byteball.js
index.html:44 starting scripts...
index.html:51 done scripts
Did you run grunt? |
|
|
|
ok ive linked my addresses through signing. i take it if sig doesnt verify it gives an error? if so i guess im good to go for 25th.
just a few questions
1 - do we get equal blackbytes and normal byteballs in distribution?
2 - whats the base unit in byteball? e.g 1btc = 1.00000000 = 100,000,000 satoshi. im trying to find the base unit exchanges will use to give me an idea of how much byteball/value i have
i just want to ask a same question like that so if i linked my address with balance 1 btc how many byteball will i receive on 25 dec ? the value is changing as more link http://transition.byteball.org tells you the current value its roughly 4GB per 1btc. i want to know if GB or MB is the 1.00000000 unit in byteball. what unit will be the 1.0 value used on exchanges i.e 1byteball = 0.00000000 btc? 1. In equal proportions. The numbers will be different because the money supplies of the two coins are different. 2. I think GB will be good for 2017. You can use any unit you find convenient though. |
|
|
|
If I connect a wallet and it does not have any BTC, will I receive the small percentage allocated to the first 100 million addresses? Or u need a BTC to receive the percentage?
i think it was earlier stated a small amount given to new wallet installs. that is byteball wallet installs not btc. linking a 0btc balance will get you nothing The giveaway to 100 million addresses is long time ahead. For now, you have to link non-zero BTC balance to get bytes. |
|
|
|
|
Show Posts
