Topic: [ANN] [PASC] PascalCoin, true deletable blockchain - V3 Hardfork on block 210000 - page 391. (Read 990783 times)

Yea one already exist https://bitcointalksearch.org/topic/pascalcoin-buysell-1618905

there's already one that isn't self moderated

created a buy and sell thread for pascal

will try and keep it updated

https://bitcointalksearch.org/topic/pascal-coin-account-trading-thread-1638517

Short answer: the current Bitcoin-style SHA256D ASICs *probably* wouldn't work.

Here's why:
The algorithm is double-SHA256, but that doesn't necessarily mean current ASICs are capable of doing it, because it isn't the same exact "flavor" of SHA256D. Bitcoin and other SHA256D cryptocurrencies for which ASICs are designed have an 80-byte header which is hashed, consisting of 6 fields (version, previous block hash, merkle root hash of current block, timestamp, nBits difficulty, nonce). The nonce is the last 4 bytes of this header, and so ASICs modify bytes 76 through 79 of this compiled input when they increment the nonce.

PascalCoin, however, uses a different format for the data. The nonce is still at the end, but the length of the data is larger (and variable, although this is effectively avoidable).
For example, if I were to start mining a block right now (Total blocks = 18865), I would be hashing the following data:



Which is 176 bytes (compared to the 80 that an ASIC for Bitcoin is expecting). Also since that miner identification is part of that string, changing my miner name changes the length of this input! But the problems go deeper!

Let's step back real quick and look at how SHA-256 functions:
Initialize 8 variables h0...h7 with some starting values (hard-coded into the algorithm, they're the beginning part of the square roots of the prime numbers from 2 to 19)
Take your input bits, add a '1' bit to the end. Then, add zeroes until its length % 512 = 448. Then, append a 64-bit number which contains the length of the original message (thus making its length a multiple of 512).
Then, for each 512-bit chunk, do a word expansion (which involves dividing the 512-bit chunk into 16 32-bit chunks, performing some operations to them to produce another 48 32-bit integers, for a total of 64). Initialize some variables a...h to h0...h7. Perform a compression function that uses those 64 words to modify a...h. Afterwards, add a...h to h0...h7.
Once you've processed each 512-bit chunk in that manner, the hash is simply h0...h7 smashed together (each is a 32-bit integer, so 8 of them give you the 256-bit output).

SHA256D simply involves doing that twice. With a Bitcoin-like 80-byte input (640 bytes), the first SHA256 call will have two 512-bit chunks to deal with, so the word expansion and compression functions will run twice. The output is a 256-bit integer, so feeding that 256-bit output into SHA256 again will only have one 512-bit chunk to deal with, so the word expansion and compression functions only run once. Fun fact: almost 2/3 of the time computing SHA-256D on a Bitcoin-style input is in the first SHA-256 run, since the 2nd one only has one chunk.

Anyhow, with a PascalCoin-like (minimum ~166 byte, as far as I can gather) input, the first SHA256 call will have three 512-bit chunks to deal with, so the word expansion and compression functions will run three times. The output again is only a 256-bit integer, so the 2nd run of SHA256 would run identically to Bitcoin.

While I don't have any experience designing ASICs, I would assume that, between the different input size (meaning the location of the nonce is different than Bitcoin) and the extra SHA256 expansion/compression rounds that have to occur because of the larger input, ASICs designed for SHA-256D mining of Bitcoin-like coins would be unable to process PascalCoin hashes. However, some ASIC designs might be flexible enough to enable this or require only a minor modification to enable it.

Fun experiment you can do from home with PascalCoin and hashing speeds! With a length-10 miner name, the hashed data is 176 bytes (3 expansion/compression rounds in the first run of the algo, since this is 1408 bits input to SHA-256). However, if you increase your miner name to a length of 18 or greater (thus making the input data 184 bytes or larger, which is 1472 bytes or larger, which once you add the '1' bit, is 1473 bits, and 1473 % 512 = 449, so to get back to length % 512 = 448), we have to add an additional chunk, thus causing the first iteration of SHA256 to require 4 expansion/compression rounds. Effectively, your miner length of 18 or greater made SHA-256 harder to compute, so you mine at a slower speed. One core of my desktop mines at 1073 kH/s with a length-17-or-below-name, but with a length-18 name it drops down to 886 kH/s (we made it go from a total of 4 chunks to a total of 5, and unsurprisingly our speed is nearly or original speed multiplied by 4/5). Note: if you change the name and your speed doesn't decrease, restart PascalCoin to force it to use the new miner name.

That is kind of vague, do you mean two or three days, or do you mean 2/3 day.

School!

Thanks for making the calculation. can ASICs be used with Pascal, theoretically? is the algorithm double SHA256?

Mined for 2/3 days get one Block.

I'd be surprised, an AntMiner S1 is 180 GH/s, and based on the network's current difficulty, it's hash rate is somewhere below 230 MH/s

Math for anyone interested: current difficulty is 23A79E4A
For ballparking this, we only care about the first two digits (23). Let's add 1 to it, so that we overestimate instead of underestimate: 24.
24 is, in hex, the number of zeroes that need to be at the beginning of a winning hash. In decimal, that's 36.
Therefore, you need 36 zeroes at the beginning of a hash for it to win. Only 1/(2^36) hashes will, on average, meet this requirement. That means, on average, the network produces 2^36 hashes every time a block is produced (5 minutes). As such, it does (2^36)/300 = 229,064,923 hashes per second, or (229,064,923/(1024 * 1024)) = 218.45-ish MH/s.

Trade secret. But I am near the output of an Antminer s1. Grin.

Mining is getting too difficult now is there any way to work out how many miners are on the network?

I think it is fine as it is for now. Wait until it hits the exchange(s). 
Maybe make it simpler to add accounts to the transfer window by selecting more than ONE at a time though. When you try to send/sell hundreds of them it gets difficult to select one by one to move to the transfer/operation window.

*ps. I'm back to selling some of my coins/accounts as people keep asking me, if anyone needs it, but it'll cost you as some of us know where this is headed. 

A "trade/sell/give" account market would be a great addition to the client !
The only problem is how to pay for it, if you don't have any account with pascal coin in it... ?

Could we have a dual wallet ? where we could deposit BTC also ?!

Just thinking here !

You need an account to receive these coins, So they give you extra ones.. you know to sell/give to people who aren't mining this coin. 

My wallet is filling up with no end of empty accounts. Not sure why five
accounts are generated, one of which has the mining reward. I have to
then move the reward to my primary account....?

Any enlightenment to this logic?

What is being showed is the pending operations on the network to be processed by the next block to be found, nothing to do with the individual transfer, IMO.

I think it's working thanks to your explanation and assistance with video. My accounts went from 5 to 4, and it looks like its going through. Thx.

From what he is showing it looks like you sent some empty accounts to him.

No they have to have an account to send to. For example 61411-50. So you would need to send your friend an empty account first by going to operations. Tranfer account and put in his public key. After that you would go to an account you have with coins. Click operations and choose transaction and put in his address of the new account you sent him which is numbers-numbers and not a public key.

At Aetson I watched a youtube video and I tried to follow along. I changed the amount to 50. My balance was debited 50 plus 1 miner fee I added.
So wondering if there is a video on how to send just to a public key.....I guess I wasnt supposed to send from my "account"! So just input public key and amount? thought I tried that, and think it wouldnt go through....anyway...work in progress.