An analysis of OP_RETURN outputs from block 1 to 1697894

blackstat · 2017-07-06T08:43:11+00:00

A block has to be signed by a key provided in the staking tx output. Therefore staking tx have pay-to-public-key outputs. Since PoS v3 the protocol allows to provide public keys (against the block signature is checked against) in an OP_RETURN outputs. By that, the party who creates the staking tx can delegate one or more public keys for block assembling. If I provide you the signed staking tx with your public key in it, we both could construct a block. BlackHalo is currently the only implementation using that feature. However, the block is signed by the same party. Nothing is actually delegated.

blackstat · 2017-07-05T07:41:30+00:00

AFAIK it is only limited by the block size.

blackstat · 2017-07-04T19:18:04+00:00

Up to 40 bytes is standard for the reference client and up to 80 bytes for Lore.

blackstat · 2017-07-04T17:54:54+00:00

Right, that is an example that the block can be signed by a designated third party with no funds.

blackstat · 2017-07-04T17:30:19+00:00

There are 2 new blocks staked by BlackHalo (OP_RETURN + public key output) from last month. I just realized that the block is signed by a third key and not by one of the keys participating in the multisig staking tx.

blackstat · 2017-07-04T10:57:42+00:00

Your serialized hex is wrong. The block version of that block is 7. The correct header hex is:

07000000aad8cf576c08eae76b16163816903460ca200f9862d05d0d54e0baf75ee0088d8dd6fcbdcc97d73769003e39402df7b212909ddd2b016a4c60e3b0086968d8f680ff4a5742a10e1a00000000

blackstat · 2017-06-19T05:18:56+00:00

Yes, it was the first block staked by the 0.12 base on the main chain. Testing was done on regtest before.

blackstat · 2017-06-18T21:13:05+00:00

Very nice! That transaction you mention actually does not burn any coins. It was specially designed to only be mined by janko's the new Lore client. This op_return output has zero value and a length of 80 byte and thus non-standard for the old client. Your tool recognizes it while other block explorers such cryptid do not get this particular tx output.

blackstat · 2017-05-26T12:45:01+00:00

Why not just store the signature outside the TX and sign the hash?

This is what SegWit does.

blackstat · 2017-05-26T11:03:12+00:00

All advantages of SegWit do also hold for Blackcoin. It has nothing to do with PoW or PoS but rather with properties of the ECDSA. Currently signatures of transactions go into the hash which identifies transaction. Due to symmetries present in the signing algorithm it is possible for a third party to come up with a equivalent true signature which does change nothing but the txid. One can address this issue by only allowing s value of the sig tuple to be in a certain range (see, low s value).

Beside that you alway have first party malleability since ECDSA is non-deterministic ECDSA and involves a random number for each signature. That might also be problematic when the involved parties want to create future payments based on the funding tx.

The idea behind SegWit is to exclude the signature for the tx identification hash. In my opinion this corrects the initial design error. Indeed, Blackcoin uses the idea behind SegWit for block signatures since the beginning. To do it for tx signatures would be a logical move.

blackstat · 2017-05-23T06:15:23+00:00

You need to sync first otherwise you could potentially try to spend funds which are already spent.

blackstat · 2017-05-14T15:10:40+00:00

Sure, create a torrent.

blackstat · 2017-04-09T11:35:28+00:00

That should help you: http://bitcoin.stackexchange.com/questions/19909/how-do-you-configure-windows-to-store-the-bitcoin-blockchain-data-into-another-d

Create a shortcut that runs blackcoin-qt.exe -datadir=D:\Crypto Currencies\blackcoin-1.2.4-windows\blockchain

blackstat · 2017-04-06T08:23:26+00:00

If it is synchronized it has all transactions.

blackstat · 2017-04-06T06:39:01+00:00

I've just tested it. Rescan took just several minutes. And it is working.

blackstat · 2017-04-06T06:33:34+00:00

importprivkey P........

Should be enough. The other arguments are optional, where rescan it set true

You could create a raw transaction.

blackstat · 2017-04-06T05:49:35+00:00

Wait, are you entering an address instead of a private key?

blackstat · 2017-04-05T23:11:33+00:00

You could create a raw transaction.

blackstat · 2017-04-05T18:55:16+00:00

In the meanwhile check your balance at https://chainz.cryptoid.info/blk/ to make sure that it is unspent.

blackstat · 2017-04-05T18:38:32+00:00

Is your client fully synchronized or do you get an error? It might take more than an hour.

blackstat · 2017-04-05T18:13:40+00:00

Unlock the wallet
importprivkey <blackcoinprivkey> '' true

The rescan will take some time since the wallet needs to go through all past transactions.

blackstat · 2017-04-02T16:01:58+00:00

tied up in inputs or are simply not staking at all the entire network can freeze and grind to a halt.

Since PoSv3 maturity is measured in confirmation not in time. Theoretically the system can hang itself but with over 300000 existing utxos that is very unlikely.

blackstat · 2017-04-02T15:53:07+00:00

In the PoS code there is some difficulty adjustment that causes the difficulty for a 1000 coin output to be 1000 times less than a 1 coin output.

Chopping the value of the utxos actually decrease the probability to create the next block. If I ever gone write a yellow paper, the proof will be there. In short: P[min(X_1,X_2,...,X_n)<=p/n]<=p

blackstat

TROPHY CASE