Bitcoin Forum
October 20, 2021, 06:03:10 AM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 [74] 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 ... 200 »
  Print  
Author Topic: [SKY] Skycoin Launch Announcement  (Read 381231 times)
patmast3r
Hero Member
*****
Offline Offline

Activity: 980
Merit: 1001


View Profile
January 03, 2015, 03:51:33 PM
 #1461

Update:

The tutorial on Cipher is done. Now eight year olds can do public key cryptography.

https://github.com/skycoin/skycoin/wiki/cipher

This library handles address generation, deterministic wallets, signing transactions with private keys and encrypting data to a public key. It is the core of the Skycoin Project. The coin and everything else is built on top of this.

Roadmap
...

Is there any word on when we can expect a detailed whitepaper for Obelisk ?

PS: Claiming to be the first secure non-POW crypto is bold to say the least.

1634709790
Hero Member
*
Offline Offline

Posts: 1634709790

View Profile Personal Message (Offline)

Ignore
1634709790
Reply with quote  #2

1634709790
Report to moderator
1634709790
Hero Member
*
Offline Offline

Posts: 1634709790

View Profile Personal Message (Offline)

Ignore
1634709790
Reply with quote  #2

1634709790
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1634709790
Hero Member
*
Offline Offline

Posts: 1634709790

View Profile Personal Message (Offline)

Ignore
1634709790
Reply with quote  #2

1634709790
Report to moderator
1634709790
Hero Member
*
Offline Offline

Posts: 1634709790

View Profile Personal Message (Offline)

Ignore
1634709790
Reply with quote  #2

1634709790
Report to moderator
1634709790
Hero Member
*
Offline Offline

Posts: 1634709790

View Profile Personal Message (Offline)

Ignore
1634709790
Reply with quote  #2

1634709790
Report to moderator
Mickeyb
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000

Move On !!!!!!


View Profile
January 04, 2015, 11:52:52 AM
 #1462

Where can we buy this coin? Is it launched yet or what?
Repunza
Sr. Member
****
Offline Offline

Activity: 357
Merit: 250


View Profile
January 04, 2015, 11:57:05 AM
 #1463

Where can we buy this coin? Is it launched yet or what?

I was wondering the same...
leigh2k14
Legendary
*
Offline Offline

Activity: 1288
Merit: 1000



View Profile
January 04, 2015, 02:18:41 PM
 #1464

Where can we buy this coin? Is it launched yet or what?

I was wondering the same...

No not yet.

I am waiting for the IPO details off the Dev.

























▄▄▄▄▄▄▄▄▄▄          ▄▄▄                   ▄▄▄▄▄▄▄                 ▄▄▄▄▄▄▄        ▄▄▄      ▄▄▄
████████████▄       ███                ▄███████████▄            ▄██████████      ███     ███▀
███     ▀▀███▌      ███               ████▀     ▀████         ▄███▀▀     ▀▀      ███    ███▀
███       ███▌      ███              ███▀         ▀███       ▄███                ███   ███
███     ▄███▀       ███             ▐██▌           ▐██▌     ▐███                 ███  ███
██████████▀         ███             ▐██▌           ▐██▌     ▐██▌                 ███ ███
███▀▀▀▀▀████▄       ███             ▐██▌           ▐██▌     ▐██▌                 ███  ███     ███           ███
███      ▀███▌      ███             ▐██▌           ▐██▌     ▐███                 ███   ███     ███         ███
███       ███▌      ███              ███▄         ▄███        ███                ███    ███     ███       ███
███     ▄▄███▌      ███               ████▄     ▄████         ▀███▄▄     ▄▄      ███     ███▄    ███▄   ▄███
████████████▀       ███████████        ▀███████████▀            ▀██████████      ███      ███▄    ███▄ ▄███
▀▀▀▀▀▀▀▀▀▀          ▀▀▀▀▀▀▀▀▀▀▀           ▀▀▀▀▀▀▀                  ▀▀▀▀▀▀        ▀▀▀       ▀▀▀     ███▄███
                                                                                                    ▀███▀
                                                                                                     ▀█▀



















 
Token Sale Starts on [ 12 October ]
[ PRESALE IS OPEN ] ●●●






































BitZCoin
Sr. Member
****
Offline Offline

Activity: 275
Merit: 250



View Profile WWW
January 04, 2015, 02:48:57 PM
Last edit: January 04, 2015, 03:49:29 PM by BitZCoin
 #1465

To be honest.. This project looks is very, very interesting amazing!

Here it is: TakePart!
LemonAndFries
Sr. Member
****
Offline Offline

Activity: 462
Merit: 250


View Profile
January 04, 2015, 10:17:31 PM
 #1466

Have a feeling that when skycoin is launched it will be very forward thinking and we might be witnessing crypto generation 3.0 birth.
BlackShibe1
Sr. Member
****
Offline Offline

Activity: 260
Merit: 250


View Profile
January 05, 2015, 01:19:48 AM
 #1467

Shhhh
Don't buzz too much less for us if there are too much investors

Lisk.
    Develop Decentralized Applications & Sidechains in JavaScript with Lisk!
    Website | Blog | BTT Thread | Chat - Be part of the decentralized application movement!
Mickeyb
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000

Move On !!!!!!


View Profile
January 10, 2015, 04:48:53 PM
 #1468

Where can we buy this coin? Is it launched yet or what?

I was wondering the same...

No not yet.

I am waiting for the IPO details off the Dev.

Can we subscribe to some newsletter so we don't miss the IPO?

Thanks guys  Smiley
MemoryShock
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500


View Profile
January 10, 2015, 06:17:52 PM
Last edit: January 11, 2015, 06:28:41 PM by MemoryShock
 #1469

I will try to do a soft launch, get it working with command line tools, so that it can launch and the the GUI wallet can be fixed later. I think the initial distribution of coins will be over tox group chat and there will be a google spreadsheet. There may be a trader bot to automate it later.

It was mentioned that the initial distribution would happen over Tox but there has been no mention of it since.  I am unsure if that means that he found somethings he wanted to fix or if that went ahead and happened...I am leaning more toward the latter than.

But considering the sporadic nature of the updates, I think that a newsletter is likely not going to happen at this point...: D

██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
  I/O DIGITAL
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
iodigital.io & iocoin.io

█████████████████
███████████████████
████████▌████████▐████
███████████████████████
████████████████████████
█████▌██████████████▐███
█████▌██████████████▐███
█████▌██████████████▐███
████████████████████████
███████████████████████
████████▌████████▐████
███████████████████
█████████████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
gomei
Hero Member
*****
Offline Offline

Activity: 770
Merit: 500



View Profile
January 11, 2015, 05:25:16 AM
 #1470

Where can we buy this coin? Is it launched yet or what?

I was wondering the same...

No not yet.

I am waiting for the IPO details off the Dev.

Can we subscribe to some newsletter so we don't miss the IPO?

Thanks guys  Smiley
yes, we really need it.

.Ambit.    ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  █████
██
████████████
   Become part of the mining family   
✔ SECURED  │ WHITEPAPER │  ★ 171% ROI
██   
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
█████  ██
██
████████████
CECVW
Legendary
*
Offline Offline

Activity: 961
Merit: 1000


View Profile
January 11, 2015, 05:55:49 PM
 #1471

Where can we buy this coin? Is it launched yet or what?

I was wondering the same...

No not yet.

I am waiting for the IPO details off the Dev.

Can we subscribe to some newsletter so we don't miss the IPO?

Thanks guys  Smiley
yes, we really need it.

I agree, please provide with a subscribe newsletter that we are inform of any news and the IPO launch. Some people can not check here all the time and would not like to miss it, please understand

⏲⏳⏲⏳⏲     WIRELESS COIN     ⏲⏳⏲⏳⏲
══════════════════════════════════════════════════════════════════════════════════════════════════════════
⏲  FORUM THREADGITHUBTWITTERSLACK 1 #time-travellers-yet/#wlcSLACK 2 #21_tickets/#wlc  ⏲
cryptrol
Hero Member
*****
Offline Offline

Activity: 637
Merit: 500


View Profile
January 12, 2015, 11:31:00 AM
 #1472


Can we subscribe to some newsletter so we don't miss the IPO?

Thanks guys  Smiley
yes, we really need it.

I agree, please provide with a subscribe newsletter that we are inform of any news and the IPO launch. Some people can not check here all the time and would not like to miss it, please understand

Not sure if it is still alive but at one point there where updates to the BM channel, I no longer follow the channel :

Quote from: skycoin
Bitmessage Contact:
Private Messages: BM-2cX8R4saGGUPnEkwUpTsQdP4Bu1YCqUtqE
Announcements (subscribe to address): BM-2cXxcRpG1raeNYwDjcb6Axxqi4yiMdqvPf
Channel: name: skycoin, key: BM-2cW9oxq2cx8PmWgySvaHyJnTpcxpsiFhqD

BTW, it seems there has been some advances on the code, but nothing on the consensus part.

Will you release a testnet at some point ?
skycoin
Hero Member
*****
Offline Offline

Activity: 498
Merit: 500


View Profile WWW
January 13, 2015, 12:00:01 AM
Last edit: January 13, 2015, 12:41:36 AM by skycoin
 #1473

Update:

Ubiquiti has  802.11N 2×2 MIMO on 900 Mhz.
http://www.muniwireless.com/2010/11/02/who-needs-white-space/

This is good background on meshnet routing problem
http://www.freedomlayer.org/articles_index.html
http://www.freedomlayer.org/articles/exp_virtual_dht_routing.html
http://www.freedomlayer.org/articles/sqrt_n_routing.html
http://www.freedomlayer.org/articles/landmarks_navigation_rw.html

XCASH
Legendary
*
Offline Offline

Activity: 930
Merit: 1000


View Profile
January 13, 2015, 12:31:16 AM
 #1474

Is there an ETA for the IPO yet?
gomei
Hero Member
*****
Offline Offline

Activity: 770
Merit: 500



View Profile
January 13, 2015, 03:04:39 AM
 #1475

thanks for these update, and we also need IPO date?

.Ambit.    ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  █████
██
████████████
   Become part of the mining family   
✔ SECURED  │ WHITEPAPER │  ★ 171% ROI
██   
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
█████  ██
██
████████████
MemoryShock
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500


View Profile
January 13, 2015, 04:32:35 AM
 #1476


I think the reason for the post was to communicate the issues they are encountering with progress...and if one is to infer correctly, I believe it would be along the lines of a notion that there is reticence in releasing a project or providing dates while there is an incomplete product.

They're trying to do something cool and which hasn't been done before...and for the first time in crypto, I think I am seeing a team who wants to release the awesome before the IPO...or as much of it as possible.

At least that is how I am interpreting things here...once the tech work is out of the way than they might be comfortable walking through the cakewalk of other details...if true...mad respect.

██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
  I/O DIGITAL
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
iodigital.io & iocoin.io

█████████████████
███████████████████
████████▌████████▐████
███████████████████████
████████████████████████
█████▌██████████████▐███
█████▌██████████████▐███
█████▌██████████████▐███
████████████████████████
███████████████████████
████████▌████████▐████
███████████████████
█████████████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
skycoin
Hero Member
*****
Offline Offline

Activity: 498
Merit: 500


View Profile WWW
January 13, 2015, 06:55:21 AM
Last edit: January 13, 2015, 11:15:57 AM by skycoin
 #1477

Is there an ETA for the IPO yet?

Its ready to go. I am just procrastinating. I was going to start IPO but ended up spending 8 hours writing rant about economic models for coin valuation.

Changes
- the unit tests are fixed
- the refactoring is still not done, but getting closer
- the json output formater for transactions is fixed/pretty printer.
- the way transactions are signed has been modified. Instead of signing the hash of the transaction, with the private key for the output being spent. You now sign the hash of the SHA256 sum of the output being spent with the transaction hash. This has subtle implications. Before you could spend all outputs for an address with one signature in one transaction. This means you could spend 200 outputs with one signature, reducing leakage of private key information if there is an attack on secp256k1 (but addresses should not be reused anyways). However, during coin join transactions a malicious server could spend outputs you didnt intend if your client did not validate the transaction. I decided the validation code was inelegant and so changed the way the hash was constructed, so each input now requires a unique signature. I am conflicted about this. Its like choice between painting shed red or blue, so I should ignore it.
- transactions have two hashes, an "inner hash" of the inputs/outputs excluding signatures and an "outer hash" which is the binary serialization of the transaction. Transactions only have malleability if you have the private key for one of the inputs for the transactions, where as all Bitcoin transactions have malleability. This means, in a Bitcoin 51% attack anyone can invalidate a chain of transactions by using malleability to change the hash of the transaction (even if they were not a party to the transaction). In Skycoin, there is no way to retroactively modify a transaction hash or change an output hash unless you have a private key for an address used as input in the transaction chain.
- I am trying to decide if there is an advantage or difference of using the inner hash vs outer hash as the "ID" of the transaction. I resolved this in favor of using the outer hash, because it allows you to verify the binary network serialization. You hash the canonical binary serializatoin and get an ID uniquely verifying the hash.
- I would prefer to use the new SHA3 Keccak sponge function instead of SHA256, to add security margin but do not have time to study it in depth required. This is a decision that will require months of reflection and the benefit is marginal. When Kazaa was launched MD5 was state-of-the-art, but a few years later the network came under attack and the RIAA was successfully creating hash collisions in order to corrupt MP3s. The hash was used to validate files and RIAA found some attack to find collisions, allowing them to pass data that validated but was corrupt. Bitcoin has edge cases where you can create hash collisions (duplicate coin outputs) and does not check for collisions, requiring monkey patching. Skycoin will be extremely frustrating to attack, even for someone with an oracle for SHA256 collisions and second preimage attacks.
- The security margin of secp256k1 is excessive. RSA-512 can be broken, but if you stored a maximum of 5 coins per address the cost of doing so would make the attack unprofitable. RSA-1024 is still unbroken. By the time secp256k1 is in danger, there will be a need for a blockchain reset (rolling over balance).
- Skycoin has one transaction type. I was worried that I would have to add inflation, in order to fund on-going acquisition of foreign currency reserves to maintain a currency peg. This would require multiple transaction types. Adding multiple transaction types would pollute the code and destroy its elegance. At the last minute, a solution for funding the currency peg was found that did not require inflation. So there are no remaining cases where inflation is desirable or necessary. The coin number can be hard constraint, with no future increase (under the current assumptions).
- Transactions now have a type and length prefix just in case more transaction types have to be added later.

Skycoin Transactions are
- 97 bytes per input +  37 bytes per output + 37 bytes
Bitcoin Transactions are
- 180 bytes per input + 34 bytes per output + 10 bytes

- The merkle tree is always padded to power of 2 and zero padded.  This was originally a radix-16 merkle tree, but Ripple uses a radix-16 merkle tree so I looked at it more carefully and decided that radix-2 was better. If there are 2^N transactions, there will be N levels in the merkle tree and it will require 32*N bytes to describe a path from the root of the merkle tree to the leaf (to prove that a hash is an element of the merkle tree). For radix 16 with 256 bit hashes, it requires 16 32 byte hash even for a one level merkle tree. For radix 16 the size of the descriptor for a tree of depth 1 is same size as radix-2 for depth 4.  So its 32*ceil(log2(N)) for radix-2 vs 16*32*ceil(log16(N)). So radix-16 increases hash speed marginally, but explodes the proof lengths for typical cases. Ripple also uses SHA512 and discards the last 256 bits, which feels ad-hoc. The proof length is more important than the hashing speed (which is already very fast).

I noticed something interesting.

The key for the first 16 rounds in SHA256 are the 16 message blocks in order. A compressed pubkey is 33 bytes. SHA256 takes input, breaks it into 512 bit blocks, adds a 64 bit length to end and then pads with 1 followed by zeros. The padding is fixed after the 33 bytes. Most of the bits in the input are fixed. The compression function takes in two 256 bit blocks and compresses to a 256 bit output. However, almost half of the inputs are determined. For SHA256(SHA256(x)) for 256 bit x and for SHA256(pubkey) for 33 byte compressed pubkey.

The key schedule for 0 to 16, is just the two 256 bit input blocks block up into 32 bit segments, in order
    for i from 0 to 15
        w = w
The key schedule from 16 to 63 is
    for i from 16 to 63
        s0 := (w[i-15] rightrotate 7) xor (w[i-15] rightrotate 18) xor (w[i-15] rightshift 3)
        s1 := (w[i-2] rightrotate 17) xor (w[i-2] rightrotate 19) xor (w[i-2] rightshift 10)
        w := w[i-16] + s0 + w[i-7] + s1

w[8] to w[15] are fixed. 1 followed by zero padding.  For any 256 bit input to SHA256 this is true. For compressed secp256k1 pubkey of 33 bytes, the w[9] to w[15] are known. The padding that fills w[8] to w[15] is only a function of the length of the input, where input length is less than or equal to 256 bits.
- for bitcoin mining, most of the fields/bits are fixed for the problem. Everything except nonce bits.
- for hashing a compressed pubkey to address of the 64 bytes of input to the compression function forming the key input, 33 bytes are fixed/known.
- 3-SAT can invert 20 rounds assuming 512 bits of entropy in input and naive SHA256 encoding. If half the bits in the key schedule are already known, may be exponentially easier than solving for a 512 unknown bits in key schedule. If you modify SHA256 to take out the mixing and feedback in the key schedule, then this appears insecure against 3-SAT attack. The first 16 rounds fall quickly, but only 4 rounds can be broken after the key schedule mixing starts in round 16.
- for Bitcoin mining, only ~32 bits in the key schedule appear undetermined which are unknown
- w[0] to w[15] are just the two 512 bit input blocks.
- there is optimized SHA256 encoding using carry-save adders, used for mining that is simpler to work on and may be faster
- If you can find preimage for SHA256(x) for 256 bit x (x is expanded to 512 bit block but the last 256 bits are padding knows bits are known in advance), you can can find preimage for SHA256(SHA256(x))
- Ripemd160 is a similar Merkle–Damgård compression function. If you can break SHA256 with that attack its likely to break Ripemd160
- If you can preimage Ripemd160, you get random SHA256(x) for 256 bit x (and 256 bits of known padding bits in key schedule) which you then preimage to get a random compressed secp256k1 pubkey
- If the probability that a random secp256k1 pubkey is weak, is 1 in 1024, then you have to do this on average 1024 times, before you get a pubkey that is valid for the address, which you can recover the private key for. If almost all randomly generated public keys are strong, then attack fails.
- We know that almost all randomly generated secret keys produce strong public keys (public keys we cannot recover the private key for). The secret key is 32 bytes and the compressed public key is 33 bytes.
- Recovering the private key from a random public key is the discrete logarithm problem on an elliptic curve. I dont know what percentage of random points on the curve, have easily recoverable exponents. It is probably close to zero.
- The majority of headers do not have a 32 bit nonce that puts the output hash below the current difficulty target. Trying to use 3-SAT for mining would be more interesting and practical with a 64 bit nonce. I think in benchmarks it beat CPU mining with brute force trial and error SHA256 hashing, then brute force became more competitive as difficulty increased. Its not clear why. Now, brute force SHA256 miners commonly run through the nonce without generating a block below the target, so its futile even if there was fast algorithm.

*Sakura*
Legendary
*
Offline Offline

Activity: 1596
Merit: 1005

I wish you all love and profitable investments!!!


View Profile
January 13, 2015, 07:50:41 AM
 #1478

We believe and always ready to support you, Dev!
MadGhost
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250

★777Coin.com★ Fun BTC Casino!


View Profile
January 13, 2015, 07:54:59 AM
 #1479

We believe and always ready to support you, Dev!

Dev whenever you need support just ask.

yowatmean
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
January 13, 2015, 10:18:12 AM
 #1480

Is there an ETA for the IPO yet?

Its ready to go. I am just procrastinating. I was going to start IPO but ended up spending 8 hours writing rant about economic models for coin valuation.

Changes
- the unit tests are fixed
- the refactoring is still not done, but getting closer
- the json output formater for transactions is fixed/pretty printer.
- the way transactions are signed has been modified. Instead of signing the hash of the transaction, with the private key for the output being spent. You now sign the hash of the SHA256 sum of the output being spent with the transaction hash. This has subtle implications. Before you could spend all outputs for an address with one signature in one transaction. This means you could spend 200 outputs with one signature, reducing leakage of private key information if there is an attack on secp256k1 (but addresses should not be reused anyways). However, during coin join transactions a malicious server could spend outputs you didnt intend if your client did not validate the transaction. I decided the validation code was inelegant and so changed the way the hash was constructed, so each input now requires a unique signature. I am conflicted about this. Its like choice between painting shed red or blue, so I should ignore it.
- transactions have two hashes, an "inner hash" of the inputs/outputs excluding signatures and an "outer hash" which is the binary serialization of the transaction. Transactions only have malleability if you have the private key for one of the inputs for the transactions, where as all Bitcoin transactions have malleability. This means, in a Bitcoin 51% attack anyone can invalidate a chain of transactions by using malleability to change the hash of the transaction (even if they were not a party to the transaction). In Skycoin, there is no way to retroactively modify a transaction hash or change an output hash unless you have a private key for an address used as input in the transaction chain.
- I am trying to decide if there is an advantage or difference of using the inner hash vs outer hash as the "ID" of the transaction. I resolved this in favor of using the outer hash, because it allows you to verify the binary network serialization. You hash the canonical binary serializatoin and get an ID uniquely verifying the hash.
- I would prefer to use the new SHA3 Keccak sponge function instead of SHA256, to add security margin but do not have time to study it in depth required. This is a decision that will require months of reflection and the benefit is marginal. When Kazaa was launched MD5 was state-of-the-art, but a few years later the network came under attack and the RIAA was successfully creating hash collisions in order to corrupt MP3s. The hash was used to validate files and RIAA found some attack to find collisions, allowing them to pass data that validated but was corrupt. Bitcoin has edge cases where you can create hash collisions (duplicate coin outputs) and does not check for collisions, requiring monkey patching. Skycoin will be extremely frustrating to attack, even for someone with an oracle for SHA256 collisions and second preimage attacks.
- The security margin of secp256k1 is excessive. RSA-512 can be broken, but if you stored a maximum of 5 coins per address the cost of doing so would make the attack unprofitable. RSA-1024 is still unbroken. By the time secp256k1 is in danger, there will be a need for a blockchain reset (rolling over balance).
- Skycoin has one transaction type. I was worried that I would have to add inflation, in order to fund on-going acquisition of foreign currency reserves to maintain a currency peg. This would require multiple transaction types. Adding multiple transaction types would pollute the code and destroy its elegance. At the last minute, a solution for funding the currency peg was found that did not require inflation. So there are no remaining cases where inflation is desirable or necessary. The coin number can be hard constraint, with no future increase (under the current assumptions).
- Transactions now have a type and length prefix just in case more transaction types have to be added later.

Skycoin Transactions are
- 97 bytes per input +  37 bytes per output + 37 bytes
Bitcoin Transactions are
- 180 bytes per input + 34 bytes per output + 10 bytes

- The merkle tree is always padded to power of 2 and zero padded.  This was originally a radix-16 merkle tree, but Ripple uses a radix merkle tree so I looked at it more carefully and decided that radix-2 was better. If there are 2^N transactions, there will be N levels in the merkle tree and it will require 32*N bytes to describe a path from the root of the merkle tree to the leaf (to prove that a hash is an element of the merkle tree). For radix 16 with 256 bit hashes, it requires 16 32 byte hash even for a one level merkle tree. For radix 16 the size of the descriptor for a tree of depth 1 is same size as radix-2 for depth 4.  So its 32*ceil(log2(N)) for radix-2 vs 16*32*ceil(log16(N)). So radix-16 increases hash speed marginally, but explodes the proof lengths for typical cases. Ripple also uses SHA512 and discards the last 256 bits, which feels ad-hoc. The proof length is more important than the hashing speed (which is already very fast).

I noticed something interesting.

The key for the first 16 rounds in SHA256 are the 16 message blocks in order. A compressed pubkey is 33 bytes. SHA256 takes input, breaks it into 512 bit blocks, adds a 64 bit length to end and then pads with 1 followed by zeros. The padding is fixed after the 33 bytes. Most of the bits in the input are fixed. The compression function takes in two 256 bit blocks and compresses to a 256 bit output. However, almost half of the inputs are determined. For SHA256(SHA256(x)) for 256 bit x and for SHA256(pubkey) for 33 byte compressed pubkey.

The key schedule for 0 to 16, is just the two 256 bit input blocks block up into 32 bit segments, in order
    for i from 0 to 15
        w = w
The key schedule from 16 to 63 is
    for i from 16 to 63
        s0 := (w[i-15] rightrotate 7) xor (w[i-15] rightrotate 18) xor (w[i-15] rightshift 3)
        s1 := (w[i-2] rightrotate 17) xor (w[i-2] rightrotate 19) xor (w[i-2] rightshift 10)
        w := w[i-16] + s0 + w[i-7] + s1

w[8] to w[15] are fixed. 1 followed by zero padding.  For any 256 bit input to SHA256 this is true. For compressed secp256k1 pubkey of 33 bytes, the w[9] to w[15] are known. The padding that fills w[8] to w[15] is only a function of the length of the input, where input length is less than or equal to 256 bits.
- for bitcoin mining, most of the fields/bits are fixed for the problem. Everything except nonce bits.
- for hashing a compressed pubkey to address of the 64 bytes of input to the compression function forming the key input, 33 bytes are fixed/known.
- 3-SAT can invert 20 rounds assuming 512 bits of entropy in input and naive SHA256 encoding. If half the bits in the key schedule are already known, may be exponentially easier than solving for a 512 unknown bits in key schedule. If you modify SHA256 to take out the mixing and feedback in the key schedule, then this appears insecure against 3-SAT attack. The first 16 rounds fall quickly, but only 4 rounds can be broken after the key schedule mixing starts in round 16.
- for Bitcoin mining, only ~32 bits in the key schedule appear undetermined which are unknown
- w[0] to w[15] are just the two 512 bit input blocks.
- there is optimized SHA256 encoding using carry-save adders, used for mining that is simpler to work on and may be faster
- If you can find preimage for SHA256(x) for 256 bit x (x is expanded to 512 bit block but the last 256 bits are padding knows bits are known in advance), you can can find preimage for SHA256(SHA256(x))
- Ripemd160 is a similar Merkle–Damgård compression function. If you can break SHA256 with that attack its likely to break Ripemd160
- If you can preimage Ripemd160, you get random SHA256(x) for 256 bit x (and 256 bits of known padding bits in key schedule) which you then preimage to get a random compressed secp256k1 pubkey
- If the probability that a random secp256k1 pubkey is weak, is 1 in 1024, then you have to do this on average 1024 times, before you get a pubkey that is valid for the address, which you can recover the private key for. If almost all randomly generated public keys are strong, then attack fails.
- We know that almost all randomly generated secret keys produce strong public keys (public keys we cannot recover the private key for). The secret key is 32 bytes and the compressed public key is 33 bytes.
- Recovering the private key from a random public key is the discrete logarithm problem on an elliptic curve. I dont know what percentage of random points on the curve, have easily recoverable exponents. It is probably close to zero.
- The majority of headers do not have a 32 bit nonce that puts the output hash below the current difficulty target. Trying to use 3-SAT for mining would be more interesting and practical with a 64 bit nonce. I think in benchmarks it beat CPU mining with brute force trial and error SHA256 hashing, then brute force became more competitive as difficulty increased. Its not clear why. Now, brute force SHA256 miners commonly run through the nonce without generating a block below the target, so its futile even if there was fast algorithm.

are you pegging the coin?
Pages: « 1 ... 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 [74] 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 ... 200 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!