I must admit that the transaction speed of Skycoin is really amazing.
I don't know how it is made possible, but it is really a good feature.
What I worried the most at this point is that Skycoin might never drop to a much lower price.
I'm a bit confused here as well. What is the current ACTUAL state of Obelisk? Is is - 1. Theoretical (POC) 2. Implemented on Testnet only (Release Candidate) 3. Implemented on Skycoin block chain (Production) I'd appreciate an answer from OP, or a skycoin dev that knows this firsthand. I ask bcs in the telegram channel, skycoin dev named Steve said that Obelisk is NOT implemented yet, and consensus is achieved by a masternode. If #3 holds (contrary to what was said in telegram), why the masternode, and is the masternode open-sourced (link/source plz). If #2 holds, we are basically completely centralized right now...? When is the Obelisk launch ETA and roadmap? I would highly value elaboration on these points. Chat screenshot: https://pasteboard.co/Hgii1nf.jpg.  1> There will be a giant marketing event for the consensus main-net launch towards the end of the year (assuming we hit time line on Skywire, but timeline may slip). 2> The consensus algorithm has already been implemented, benchmarked, three times. So its beyond theoretical and is in implementation. The major delay for the Obelisk main net was that the CXO library needed to be finished first. 3> We will test the consensus algorithm on other blockchains on the platform and fix the bugs before deploying it on Skycoin 4> The larger exchanges, demanded that we add a development checkpoint system (like IOTA has), to prevent the exchanges from losing coins if there is a bug in the consensus implementation. There will be an Obelisk mainnet launch event, but we may want to run the consensus algorithm in testing or sandbox for several months, to make sure there are not any bugs. Right now, we has a lot of testing standards in place (wallet encryption was done 4 months ago, but is only making it into the next release), but we cannot release new features to production until the test suites are implemented and the dev branch has been under testing for at least a month. So even if feature is implemented, it can take ~4 months after implementation to make its way to the release branch. The best compromise to get the consensus algorithm out the quickest possibl is - release the full consensus implementation on a side chain (and also enable the CX scripting language at the same time, in same release) - test it for 4 to 6 months - then switch the Skycoin Main net onto the full Obelisk implementation (with a large marketing event and conference). --- Someone complained that we are doing too many things - This is a lie, we are actually only focused on one or two things at a time (right now, launching Skywire tesnet, antennas, the Skyminers) Then we are doing one thing and finishing it, everyone starts asking "When are you going to do A, B, C, D, E, F and G". I think the release schedule will be - Skyminers - Skywire - Antennas / Hardware - Hardware Wallet - Obelisk Testnet? (second half of year?) - CX (First half of next year?) - etc... CX may end up being higher priority than Obelisk (because of the partnerships we are signing and the immediate needs of coins launching on the platform). So the release schedules and priorities are still being determined. --- Most of the backend for Obelisk is extremely simple and is finished or can be finished extremely quickly. The problem is that there are several frontend, HTML/GUI applications like the consensus network explorer and they require Angular 4.0 developers and we have a shortage of front end developers and they are all working on Skywire or other things right now. We will release a docker simulation environment for obelisk and run some Fiber chains on it, to hold people over and then work on the front end applications after Skywire and prepare for the Obelisk mainnet launch event. |
|
|
|
Hey Crypto Rocker, watched your video. Its not clear to me, who is Jane? Whats her role on skycoin? Why is she not listed in the team members or github? Jane Zhang is the founder of Shellpay, a company that reportedly owns the patent for the Skyledger blockchain platform. Her company is focused on private blockchain implementations on Skyledger such as in an ongoing government project in Dubai. Shellpay doesn't have any patent on skycoin tech |
|
|
|
Hello.
Wasn't there a 32 bit linux wallet
available for download on the skycoin webpage?
Where can I download 32 bit linux wallet?
Thanks.
It was mislabelled, it was actually an ARM wallet You can run the wallet from source easily, https://github.com/skycoin/skycoinThanks. I have tried to install from source. I have successfully installed and configured golang then I went to execute this command: go get github.com/skycoin/skycoin/...
than i got this strange output: # github.com/skycoin/skycoin/vendor/github.com/tang0th/go-chacha20/chacha
chacha20_krovetz.c:83:2: error: #error -- Implementation supports only machines with neon, altivec or SSE2
#error -- Implementation supports only machines with neon, altivec or SSE2
^
chacha20_krovetz.c: In function ‘xor_key_stream’:
chacha20_krovetz.c:157:11: warning: implicit declaration of function ‘NONCE’ [-Wimplicit-function-declaration]
vec s3 = NONCE(np);
^
chacha20_krovetz.c:157:11: error: incompatible types when initializing type ‘vec {aka __vector(4) unsigned int}’ using type ‘int’
chacha20_krovetz.c:94:19: error: ‘VBPI’ undeclared (first use in this function)
#define BPI (VBPI + GPR_TOO) /* Blocks computed per loop iteration */
^
chacha20_krovetz.c:158:33: note: in expansion of macro ‘BPI’
for (iters = 0; iters < inlen/(BPI*64); iters++) {
^
chacha20_krovetz.c:94:19: note: each undeclared identifier is reported only once for each function it appears in
#define BPI (VBPI + GPR_TOO) /* Blocks computed per loop iteration */
^
chacha20_krovetz.c:158:33: note: in expansion of macro ‘BPI’
for (iters = 0; iters < inlen/(BPI*64); iters++) {
^
chacha20_krovetz.c:94:26: error: ‘GPR_TOO’ undeclared (first use in this function)
#define BPI (VBPI + GPR_TOO) /* Blocks computed per loop iteration */
^
chacha20_krovetz.c:158:33: note: in expansion of macro ‘BPI’
for (iters = 0; iters < inlen/(BPI*64); iters++) {
^
chacha20_krovetz.c:161:13: error: ‘ONE’ undeclared (first use in this function)
v7 = v3 + ONE;
^
chacha20_krovetz.c:97:22: warning: implicit declaration of function ‘ROTW16’ [-Wimplicit-function-declaration]
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:97:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:98:22: warning: implicit declaration of function ‘ROTW12’ [-Wimplicit-function-declaration]
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:98:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:99:22: warning: implicit declaration of function ‘ROTW8’ [-Wimplicit-function-declaration]
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:99:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:100:22: warning: implicit declaration of function ‘ROTW7’ [-Wimplicit-function-declaration]
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:100:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:6: warning: implicit declaration of function ‘ROTV1’ [-Wimplicit-function-declaration]
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:20: warning: implicit declaration of function ‘ROTV2’ [-Wimplicit-function-declaration]
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:35: warning: implicit declaration of function ‘ROTV3’ [-Wimplicit-function-declaration]
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:33: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:102:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:103:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:104:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:105:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:32: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:97:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:98:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:99:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:100:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:101:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:101:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:101:33: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:102:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:103:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:104:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:105:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:106:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:106:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:106:32: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:97:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:98:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:99:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:100:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:33: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:102:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:103:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:104:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:105:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:32: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:97:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:98:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:99:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:100:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:33: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:102:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:103:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:104:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:105:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:32: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
# github.com/skycoin/skycoin/src/cipher/chacha20/go-chacha20/chacha
chacha20_krovetz.c:83:2: error: #error -- Implementation supports only machines with neon, altivec or SSE2
#error -- Implementation supports only machines with neon, altivec or SSE2
^
chacha20_krovetz.c: In function ‘xor_key_stream’:
chacha20_krovetz.c:157:11: warning: implicit declaration of function ‘NONCE’ [-Wimplicit-function-declaration]
vec s3 = NONCE(np);
^
chacha20_krovetz.c:157:11: error: incompatible types when initializing type ‘vec {aka __vector(4) unsigned int}’ using type ‘int’
chacha20_krovetz.c:94:19: error: ‘VBPI’ undeclared (first use in this function)
#define BPI (VBPI + GPR_TOO) /* Blocks computed per loop iteration */
^
chacha20_krovetz.c:158:33: note: in expansion of macro ‘BPI’
for (iters = 0; iters < inlen/(BPI*64); iters++) {
^
chacha20_krovetz.c:94:19: note: each undeclared identifier is reported only once for each function it appears in
#define BPI (VBPI + GPR_TOO) /* Blocks computed per loop iteration */
^
chacha20_krovetz.c:158:33: note: in expansion of macro ‘BPI’
for (iters = 0; iters < inlen/(BPI*64); iters++) {
^
chacha20_krovetz.c:94:26: error: ‘GPR_TOO’ undeclared (first use in this function)
#define BPI (VBPI + GPR_TOO) /* Blocks computed per loop iteration */
^
chacha20_krovetz.c:158:33: note: in expansion of macro ‘BPI’
for (iters = 0; iters < inlen/(BPI*64); iters++) {
^
chacha20_krovetz.c:161:13: error: ‘ONE’ undeclared (first use in this function)
v7 = v3 + ONE;
^
chacha20_krovetz.c:97:22: warning: implicit declaration of function ‘ROTW16’ [-Wimplicit-function-declaration]
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:97:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:98:22: warning: implicit declaration of function ‘ROTW12’ [-Wimplicit-function-declaration]
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:98:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:99:22: warning: implicit declaration of function ‘ROTW8’ [-Wimplicit-function-declaration]
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:99:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:100:22: warning: implicit declaration of function ‘ROTW7’ [-Wimplicit-function-declaration]
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:100:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:6: warning: implicit declaration of function ‘ROTV1’ [-Wimplicit-function-declaration]
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:20: warning: implicit declaration of function ‘ROTV2’ [-Wimplicit-function-declaration]
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:35: warning: implicit declaration of function ‘ROTV3’ [-Wimplicit-function-declaration]
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:33: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:102:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:103:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:104:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:105:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:32: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:182:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:97:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:98:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:99:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:100:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:101:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:101:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:101:33: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:102:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:103:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:104:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:105:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:106:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:106:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:106:32: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:183:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v4,v5,v6,v7)
^
chacha20_krovetz.c:97:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:98:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:99:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:100:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:33: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:102:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:103:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:104:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:105:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:32: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:240:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:97:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:98:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:99:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:100:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:101:33: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV1(b); c = ROTV2(c); d = ROTV3(d); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:102:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW16(d); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:103:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW12(b); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:104:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
a += b; d ^= a; d = ROTW8(d); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:105:20: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
c += d; b ^= c; b = ROTW7(b); \
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:4: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:18: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
chacha20_krovetz.c:106:32: error: incompatible types when assigning to type ‘vec {aka __vector(4) unsigned int}’ from type ‘int’
b = ROTV3(b); c = ROTV2(c); d = ROTV1(d);
^
chacha20_krovetz.c:253:4: note: in expansion of macro ‘DQROUND_VECTORS’
DQROUND_VECTORS(v0,v1,v2,v3)
^
Is there any remedy to this?! try CGO_ENABLED=0 go get github.com/skycoin/skycoin/...
|
|
|
|
Hello.
Wasn't there a 32 bit linux wallet
available for download on the skycoin webpage?
Where can I download 32 bit linux wallet?
Thanks.
It was mislabelled, it was actually an ARM wallet You can run the wallet from source easily, https://github.com/skycoin/skycoin |
|
|
|
Wow, this is an old crypto from 2013. Strange, that I never heard about it. I see its not very popular price wise also. What's the main use of this crypto?
- fastest transactions time ( new consensus algorithm, next generation, competing with IOTA, etc, not PoW/PoS) - fastest transaction rate of any blockchain tech so far (over 300 transactions/second) - new blockchain (Skycoin actually has a blockchain, unlike the 400,000 ERC20 tokens doing ICOs) - new full programming language for blockchain, CX. cx.skycoin.net (Ethereum killer). We can embed full videos games on blockchain, etc - +300 transactions/second while Bitcoin can only do 6 and Ethereum can only do 30. - Transactions in second instead of hours/minutes (like Bitcoin/Ethereum). - eliminates 51% attack with new consensus algorithms (So exchanges cannot lose coins from double spending). A revolution in blockchain consensus. - Competitor to Ethereum for launching tokens, Skyledger. Each coin gets their own complete, independent blockchain, no 51% attacks and transactions a hundred times faster than Ethereum. - Applications like Skywire for people to earn/spend Skycoins (mesh network, community internet project, like ToR but users are paid coins for forwarding traffic within the network) - Distributed social media on top of CXO (competitor to steemit, github.com/skycoin/bbs ) - higher level of transaction privacy than zerocoin but without the slowdown (while still doing over 300 transactions/second), using CoinJoin, UXTX, CoinHour swaps and "send to public key", which eliminate all tracking information from transaction. - default DEX (decentralized exchange) and OTC market for whole coin family. - mobile wallet, desktop wallet, web-wallet, hardware wallet. With multi-coin support. Bitcoin/Ethereum ("send to Bitcoin" functionality being added soon). The big thing will be Skywire. |
|
|
|
I just saw the Skycoin pitch given at https://m.youtube.com/watch?v=K-63rxeqVtgHonestly - it's CRAP. I mean... Come on.... Viewers were told: 1. "Skycoin was designed to be better than bitcoin." 2. We have dedicated hardware, made in China. If this is our marketing staff, then we should call Houston. Why wasn't "no fees" mentioned? Why wasn't the meshnet mentioned? Only a VPN application where operator can earn some coins...? That's our highlight? Why wasn't new consensus protocol explained, where 51% attack is not an issue. Why wasn't CX mentioned, or that skycoin has its programming language, and side-chains that can function like ERC-20 tokens? Why wasn't decentralized exchange and stomic-swaps mentioned? Who is this guy pitching? Really, who is spearheading marketing? Yes. He did not mention any of those. He even used the wrong logo for Skycoin! LOL Really bad attempt. Now its more organized. The videos are improving and getting a lot better. https://www.youtube.com/watch?v=KhLLu6lPpOY- we need cryptopia to fix the Skycoin logo - we need coinmarket cap to list the other exchanges Skycoin is on (coinmarketcap had some DNS issues and delisted a bunch of exchanges, so 80% of the Skycoin volume is not even showing up!) - the videos are getting much better, many more views and better channels are paying attention as the content gets more organized. 90% of the Skycoin project is still in stealth mode and has not been unveiled and put on the website. The content pages are not there yet. |
|
|
|
I just saw the Skycoin pitch given at https://m.youtube.com/watch?v=K-63rxeqVtgHonestly - it's CRAP. I mean... Come on.... Viewers were told: 1. "Skycoin was designed to be better than bitcoin." 2. We have dedicated hardware, made in China. If this is our marketing staff, then we should call Houston. Why wasn't "no fees" mentioned? Why wasn't the meshnet mentioned? Only a VPN application where operator can earn some coins...? That's our highlight? Why wasn't new consensus protocol explained, where 51% attack is not an issue. Why wasn't CX mentioned, or that skycoin has its programming language, and side-chains that can function like ERC-20 tokens? Why wasn't decentralized exchange and stomic-swaps mentioned? Who is this guy pitching? Really, who is spearheading marketing? This was from July. Yes its very bad, hopefully it will be buried from search results. The presenter left our marketing staff in August. We are working on a better presentation that will be made into a video for our youtube channel need more marketing man.. I totally agree. Their dev team are very active though, so that's absolute! We did one youtube video and the price went up 40%. Someone tried to buy 400 coins and it drives the price up 30%. Its like 50 BTC to blow it to triple digits. The marketing guy, setting up the videos, his assistant was in car accident and so slowed us down by two months. We just hired writers last week. We have to wait for the Bitcoin drama to die down a bit before we can hit marketing hard. We did successful press release push and it went all over twitter and was picked up by over four hundred websites. We have major Youtube channels lined up when the miners are ready. The hardware wallet, the mobile and Skywire needs to be ready by the big push. |
|
|
|
Wow, this is an old crypto from 2013. Strange, that I never heard about it. I see its not very popular price wise also. What's the main use of this crypto?
>I see its not very popular price wise also. The price is up 500x from the first ICO. People are already buying houses with the Skycoin money, lol We did one tube video and the price went up 50% and stayed there. You do not make money investing in coins when they are at 20 billion dollars dollars and already in the top 10. You invest at a penny then ride the market/growth up to $800. Its much easier for smaller coins with good fundamentals (user community, technology, growth) to grow significantly than for something that is already at 100 billion dollars to grow. |
|
|
|
Update:The Skycoin mobile wallet is finally up 
|
|
|
|
I just saw the Skycoin pitch given at https://m.youtube.com/watch?v=K-63rxeqVtgHonestly - it's CRAP. I mean... Come on.... Viewers were told: 1. "Skycoin was designed to be better than bitcoin." 2. We have dedicated hardware, made in China. If this is our marketing staff, then we should call Houston. Why wasn't "no fees" mentioned? Why wasn't the meshnet mentioned? Only a VPN application where operator can earn some coins...? That's our highlight? Why wasn't new consensus protocol explained, where 51% attack is not an issue. Why wasn't CX mentioned, or that skycoin has its programming language, and side-chains that can function like ERC-20 tokens? Why wasn't decentralized exchange and stomic-swaps mentioned? Who is this guy pitching? Really, who is spearheading marketing? This was from July. Yes its very bad, hopefully it will be buried from search results. The presenter left our marketing staff in August. We are working on a better presentation that will be made into a video for our youtube channel |
|
|
|
Skycoin is also listed on C2CX. See the markets page: https://www.skycoin.net/markets/Of course Skycoin needs to be listed on a more high-profile exchange, we are working on it. |
|
|
|
**** Very interesting idea, gaming on blockchain  By the way in my opinion 200 ms lateny is way too much for an FPS game*** this stupid if someone will have to store that data..  many you kno how much such shit you nned to store and multiply x1000... PC and noone really needs that data. This have sence when you want make some opereation trustles but data cannot be stored forever but like 500 bloks >this stupid if someone will have to store that data.. Grin Skycoin was designed for the blockchain to be pruned. These games wont be stored on the main blockchain, but on independent blockchain. And they can choose to retain only a day, an hour, a month, or a few minutes of the data. Skycoin is one of the first chains that was designed to allow the old data to be pruned efficiently (we use UXTX instead of UXTO). This is one of the major improvements of the data structure Skycoin is using for transactions, over Bitcoin. |
|
|
|
Update:The Skycoin blockchain programming language CX, now has OpenGL support and key input support. https://cx.skycoin.net In theory, we will be able to embed video games (like poker or real money multiplayer dwarf fortress) on the blockchain. But we still have to figure out how to do random number generation on blockchain and on-going R&D. We will be able to get the block time down to 200 ms per block (5 updates per second), which is almost enough to run FPS games on. With independent chains for the game and using a variant of Skycoin's Obelisk Consensus Protocol with leadership election and fall over for consensus. In contrast, Ethereum block-times cannot be less than 30 seconds and has an inconsistent or random block rate that precludes applications for turn based video games We have proposals to get down to 33 ms per block which is enough for 30 physics updates for second. We might want to implement multiplayer Sim Ant on blockchain and do some test cases for multiplayer gaming. In the CX model, each game object is a software object. Each game object exports "affordances" which are actions that can be invoked upon the software object. Affordances have restrictions and invariants checks for when they can be invoked (by who, under what context and under what conditions). For instance, an object representing a ledger for a pile of money, might only allow the "send money to" command to be invoked if signatures/public key validation passes (the owner of the pile of money, signed the affordance or operation). Or a player in a poker game can only invoke or commit to a move, for their own player (verified by a signature) and is unable to make moves for other players (because of inability to fake the signature for the public keys for the the other players in the game). One of the reasons we chose a cluster architecture for Skywire, is that we expect to be running thousands or millions of independent blockchains, with each application having its own blockchain running at a different tick rate over a different set of servers. We are not trying to force every application on to one giant blockchain, like ethereum. We are only forcing users to subscribe to applications which they are using, instead of replicating the data/transactions for every user on Earth. Very interesting idea, gaming on blockchain By the way in my opinion 200 ms lateny is way too much for an FPS game, even 33 ms is too high IMO. As I see this would be the base latency of the core network, but there would be some latency on top of it from the client side as well, or not? (My knowledge is limited so it's just a guess) >even 33 ms is too high IMO. Ethereum is 30,000 ms. So going from 30,000 ms to 200 ms or 33 ms is a major improvement. Normal network latency for an FPS game is 200 to 300 ms for network latency. For physics updates, games run at 20 ticks per sond, 30 ticks per second or maximum of 60 ticks per second. Most physics updates are at 30 ticks per second or 33 ms per tick. The performance, exceeds what is necessary to embed counter strike on blockchain. 200 ms, is below what humans can even perceive, for the purposes of poker and non-real time games. Even 500 ms is fine for these games. Going below 200 ms for block timedoes not add any benefit if the average network latency is 300 ms. |
|
|
|
How does Skycoin solve scalability problems? The project is very interesting, but I must say there's another one with very strong tech, which was also being developed for 4 years, the one which had DAG first actually, but then abandoned it due to its scalability problems. I'm talking about Radix (formerly eMunie), which is coming out this year. They already have made their first private deployment live in one of the 2017 YCombinator startups. Not a pilot, trial, but a real product. If you haven't heard about it, you should have to, because it will really be a game changer, not Byteball or IOTA. I'm always looking for interesting tech and my top 2 are Radix and Skycoin  please answer. Also, whats the load on skycoin, in terms of how many transactions a sec? It states 40x faster than bitcoin, can we go faster? If so, when and how? Bitcoin can handle 6 transactions per second Ethereum can handle 30 transactions per second Skycoin can handle +300 transactions per second. The bottleneck is the signature verification. We can only verify so many secp256k1 signatures per second on an ARM board, before the nodes cannot keep up with the network. The problem with these DAG, Tangle and "hashchain" coins is that they have no way of capping their transaction rate. If the number of transactions on network, exceeds the rate the signatures can be verified, then it means the network nodes cannot keep up and the network is effectively non-functioning (DDoS attack). So for Skycoin we capped the transaction rate, at the maximum rate that a single CPU can verify in real time. We also are implementing off chain transactions, which can support up to 3000 transactions per second, per server. No blockchain that exists can handle the transaction rates required for a distributed peer-to-peer utility company, so we had to move these off blockchain. The whole Ethereum network would be clogged by Skywire running with 600 users downloading videos at the same time. None of the existing blockchains or anything that is an ERC20 token, can handle the required transaction rates (Which are hundreds of times orders of magnitude higher than the rate ECC signatures can be verified). Skycoin is doing off blockchain payment channels, that use a special one way hashing function, that is much faster than ECC or secp256k1 signature verification (hundreds of thousands per second, instead of 5,000 signature verifications per second). And for small payments less than 1 penny, most of the transactions will be running on this. It is useless to have a tangle or "Hashchain" that can handle 1 million transactions per second, if a single CPU can only verify 5,000 signatures per second! The computers in the network cannot even verify the transactions, so it does not make any sense. Also, another problem and reason these ERC20 tokens wont work, is that the transaction fees on ethereum are millions of times higher than the cost of the micro-transactions for doing a distributed ISP. It just wont work. |
|
|
|
Wallet version 0.20.3 is published on the website now. If you had problems with block syncing on windows this should fix it. https://www.skycoin.net/downloads/We contacted Cryptopia yesterday about their withdrawal lock. It looks like they have enabled deposits/withdrawals again. |
|
|
|
Update:The Skycoin blockchain programming language CX, now has OpenGL support and key input support. https://cx.skycoin.netIn theory, we will be able to embed video games (like poker or real money multiplayer dwarf fortress) on the blockchain. But we still have to figure out how to do random number generation on blockchain and on-going R&D. We will be able to get the block time down to 200 ms per block (5 updates per second), which is almost enough to run FPS games on. With independent chains for the game and using a variant of Skycoin's Obelisk Consensus Protocol with leadership election and fall over for consensus. In contrast, Ethereum block-times cannot be less than 30 seconds and has an inconsistent or random block rate that precludes applications for turn based video games We have proposals to get down to 33 ms per block which is enough for 30 physics updates for second. We might want to implement multiplayer Sim Ant on blockchain and do some test cases for multiplayer gaming. In the CX model, each game object is a software object. Each game object exports "affordances" which are actions that can be invoked upon the software object. Affordances have restrictions and invariants checks for when they can be invoked (by who, under what context and under what conditions). For instance, an object representing a ledger for a pile of money, might only allow the "send money to" command to be invoked if signatures/public key validation passes (the owner of the pile of money, signed the affordance or operation). Or a player in a poker game can only invoke or commit to a move, for their own player (verified by a signature) and is unable to make moves for other players (because of inability to fake the signature for the public keys for the the other players in the game). One of the reasons we chose a cluster architecture for Skywire, is that we expect to be running thousands or millions of independent blockchains, with each application having its own blockchain running at a different tick rate over a different set of servers. We are not trying to force every application on to one giant blockchain, like ethereum. We are only forcing users to subscribe to applications which they are using, instead of replicating the data/transactions for every user on Earth.
|
|
|
|
how much did they collect as a result? what are the plans for the next 3 months?  The roadmap for the next three months is - Launch mobile wallet in beta - Launch new desktop wallet (done, debugging) - Start skycoin distribution campaign - Launch OTC market place (Skycoin, Bitcoin, Ethereum, etc) - Integrate the OTC market into the wallet - Add OTC market for Skycoin CoinHours so that they can trade. - Finish website rebranding (new logo, branding kit, branding guide) - Submit press releases to media - Hire technical writers to produce content and PR writers - Have advertising campaign and banners ready - Launch Skycoin on two new exchanges. We are trying to engage the larger exchanges, but they do not answer emails because they are getting so many requests, so its difficult - Building up a list of youtubers to make videos about Skycoin - Building up the twitter, reddit and telegram community - Building a community on Skycoin BBS social media platform (we want to get Skycoin tipping working on the platform and get people using it) - Get skywire.skycoin.net working and up (global network dashboard) - Ship the first 300 Skywire Miner hardware units - Begin doing interviews |
|
|
|
Update:The first 10,000 vinyl cut Skycoin stickers are ready. We are finishing rebranding of the website now 
|
|
|
|
The transfer fee is surprisingly high. EDIT: i moved the coins to my wallet and had 18 coin hours. I created a new wallet because i had no seed for the first one and send the coins to the new wallet - but now its only 2 coin hours left. Where are the other 16 coin hours gone? But the transmission from wallet to wallet seems to be free - or are the coin hours paid for transmission fee? When you do a transaction, currently at least 50% of the coin houses in the outputs need to be burnt. When you do a transaction - you create an output owned by an address in your wallet (the change) - you create an output owned by the receivers wallet (the money you are sending) If you have an output with 10 coins and want to send 3 coins - you send the person 3 coins - you send 7 coins back to yourself Currently, when you do a transaction the CoinHours are split evenly between the transaction outputs. If you have 100 coin hours in the outputs being spent - atleast 50 must be burned - 25 coin hours will go to the first output (your change address) - 25 coin hours will go to the second ouput In the next version of wallet, we will allow users to split how to split the CoinHours and to show the fees. We may also reduce the minimum CoinHour burn from 50% to 30% or 20%. Or make CoinHours decay 1% per month, so that they eventually reach a peak/cap and Coin Hours created equals Coin Hours being destroyed. |
|
|
|
|
Show Posts
