New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add arbitrary transactions as coinbase inputs at a given block height #3

Closed
heyrhett opened this Issue Dec 25, 2017 · 32 comments

Comments

Projects
None yet
@heyrhett
Copy link
Contributor

heyrhett commented Dec 25, 2017

Full nodes check Transactions and Blocks for validity.

Many of the validity checks are skipped for Coinbase transactions, but a Block check is made to ensure that there is only 1 Coinbase transaction per block. Both of these checks happen in main.cpp. I have included screenshots here.

What we want to do is:

  1. For a given Block Height, X, allow the block size to be larger.
  2. Include any number of transactions as coinbase inputs
  3. Include arbitrary values as coinbase inputs (from a file)

This means that miners will be mining, and at block X, they will create 1 large block will an arbitrary number of coinbase inputs with arbitrary values.

After that, mining will resume as normal.

Miners will download the hard fork before block X, all miners that agree to run the fork software will continue on their node, while non-upgraded miner will continue mining on the pre-fork code.

screen shot 2017-12-25 at 6 09 46 am

screen shot 2017-12-25 at 6 08 10 am

@airk42

This comment has been minimized.

Copy link
Contributor

airk42 commented Dec 27, 2017

If no one is working on it, I can take it

@heyrhett

This comment has been minimized.

Copy link
Contributor

heyrhett commented Dec 27, 2017

Added you as a collaborator, then I'll assign you. This is the most critical development blocker right now, so we should have regular meetings for all the developers working on it.

@Mrwh0

This comment has been minimized.

Copy link

Mrwh0 commented Dec 27, 2017

i could help too .

@heyrhett

This comment has been minimized.

Copy link
Contributor

heyrhett commented Dec 27, 2017

Great, so a little more details about how I think we should do this

  1. We announce a Bitcoin snapshot date (allow people time to move coins to private non-segwit wallets)
  2. We take the snapshot at the given date
  3. Create fork that reduces difficulty at block X and adds 1000 coinbase inputs per block for 65,000 blocks (65M total addresses).
  4. Have a small set of miners mine with this code. It will require a large input file from the Bitcoin Snapshot.
  5. Create a new version that simply uses a checkpoint at a given block height, and no longer requires the bitcoin Snapshot. This is a soft fork that simply removes the need to mine with the large file. It should not violate consensus.
  6. Miners download the updated version that uses a checkpoint and no Bitcoin UTXO set.
  7. We monitor the network and tell exchanges and everyone else when it is safe to enable the live Bitcoin Private wallets.
@Mrwh0

This comment has been minimized.

Copy link

Mrwh0 commented Dec 27, 2017

X block max size ?

@heyrhett

This comment has been minimized.

Copy link
Contributor

heyrhett commented Dec 27, 2017

X is the block height we choose in Zclassic to do the fork. Miners download the code before block X.

I think we should keep the block size limit of 2MB for all blocks.

@Mrwh0

This comment has been minimized.

Copy link

Mrwh0 commented Dec 27, 2017

@airk42

This comment has been minimized.

Copy link
Contributor

airk42 commented Dec 27, 2017

@heyrhett couple questions:

  1. so, now you don't want to have a single big block with all coinbase inputs (as per your first comment) and instead there are will be 65K of blocks with 1000 coinbase inputs per block?
  2. is this issues (#3) is to cover only checks for these artificial blocks or for creating these blocks as well?
@heyrhett

This comment has been minimized.

Copy link
Contributor

heyrhett commented Dec 28, 2017

@airk42

  1. so, now you don't want to have a single big block with all coinbase inputs (as per your first comment) and instead there are will be 65K of blocks with 1000 coinbase inputs per block?

Yes, I think we should keep the block size limit under 2 MB as it is set now. We could have issues making a single block over 1 GB.

  1. is this issues (#3) is to cover only checks for these artificial blocks or for creating these blocks as well?

We need to create the blocks as well.

@airk42

This comment has been minimized.

Copy link
Contributor

airk42 commented Dec 28, 2017

OK then, I am on it. There is not need in label "help wanted"
I will target to have all it coded before the end of the year.

@airk42

This comment has been minimized.

Copy link
Contributor

airk42 commented Dec 28, 2017

Also, I think we need to create branch for the code inserting coinbases.

@heyrhett

This comment has been minimized.

Copy link
Contributor

heyrhett commented Dec 28, 2017

Is there a place I can chat with you? Telegram, Twitter? @airk42

@Mrwh0

This comment has been minimized.

Copy link

Mrwh0 commented Dec 28, 2017

im on that too please open discord channel or irc somewhere

@heyrhett

This comment has been minimized.

Copy link
Contributor

heyrhett commented Dec 28, 2017

We're going to need to see daily progress on this, and it's also something that should require multiple people to review, so we should discuss updates on this daily somewhere.

@Mrwh0

This comment has been minimized.

Copy link

Mrwh0 commented Dec 28, 2017

@airk42

This comment has been minimized.

Copy link
Contributor

airk42 commented Dec 28, 2017

@kennethffx2

This comment has been minimized.

Copy link

kennethffx2 commented Dec 30, 2017

How's this looking boys? This issue being solved is my deciding factor in buying $30,000 worth of Zclassic.

@GildedHonour

This comment has been minimized.

Copy link

GildedHonour commented Dec 30, 2017

I'll be interested to take it. Bounty?

@airk42

This comment has been minimized.

Copy link
Contributor

airk42 commented Dec 31, 2017

It is work in progress, but it is close

@GildedHonour

This comment has been minimized.

Copy link

GildedHonour commented Dec 31, 2017

Are there other issues-bounties I can take?

@ghost

This comment has been minimized.

Copy link

ghost commented Jan 2, 2018

@heyrhett Isn't 1-Gig Block would be better than mining 65K blocks?
And, will be there any scaling plan for the Bitcoin Private?

@starrymoonlight

This comment has been minimized.

Copy link

starrymoonlight commented Jan 5, 2018

We announce a Bitcoin snapshot date (allow people time to move coins to private non-segwit wallets)

Can't BitcoinPrivate support Segwit addresses? If not, that will be a negative. Bitcoin Gold worked on Segwit addresses.

@SazzadGit

This comment has been minimized.

Copy link

SazzadGit commented Jan 5, 2018

how do we get BTCP if i have zclassic in my Bittrex?

@andreibolkonsky

This comment has been minimized.

Copy link

andreibolkonsky commented Jan 7, 2018

Any update on how this is progressing guys? Or a better place to check out progress?

@gktown

This comment has been minimized.

Copy link

gktown commented Jan 8, 2018

Puttin' +1 ZCL on the bounty.

@GildedHonour

This comment has been minimized.

Copy link

GildedHonour commented Jan 8, 2018

Are there other issues-bounties I can take?

@airk42

This comment has been minimized.

Copy link
Contributor

airk42 commented Jan 8, 2018

The issue is ready to be closed - all code is merged into cb-input branch

Forking Node Description

This is forking version of the BTCPrivate node
Its major and the only goal is to insert and verify BTC utxo into ZClassic blockchain as blocks with multiple (10000 by default) Coinbases translocation.

There are 4 additional configuration parameters to control the behavior of that node:

  1. utxo-path="path to the folder with utxo files"

This is the most important parameter - it points to the location of utxo files
These utxo files MUST be named as such - "utxo-nnnnn.bin", where nnnnn is number from 00001 to (number-of-btc-utxo/10000) and by default have 10K utxo transactions as raw records
Example - utxo-00001.bin, utxo-00002.bin and so forth

  1. fork-startheight=n
    Chain height when forking will start - default MUST be set in the code, this parameter should be used only for testing

  2. fork-heightrange=n
    Range of fork - basically the number of utxo files to process - default 65K

  3. fork-cbperblock=n
    Number of CB's in the block and number rof records in the utxo file - default 10K

This version of node can work in three different modes:

  1. Mine fork blocks with utxo transactions using built in miner
  2. Verify fork blocks
  3. Do nothing

Mode 1 and 2 reuire the the utxo files!!!

How to enable corresponding mode

1. Mining mode

a. put following into the config file (btcprivate.conf):

gen=1
utxo-path="path-to-utxo-files"

Note: Start height Must be set in the code, but it can also be set via fork-startheight config parameter

b. start the node
c. When tip of the chain will get into the range (fork-startheight <= tip < fork-startheight+fork-heightrange), miner starts to create fork blocks with only CB transactions from utxo files.
One block from each file. And will "mine" them with the reduced difficulty ~ 1 sec per block.
In this mode miner can only creates fork blocks from files - if chain tip is still inside the range, but there are no files - miner will not mine anything else.
At each moment miner tries to create block from the file with the name matching current chain height.

Example:

Let's say the fork height set in the code as 300000; range as 65K and CB per block as 10K
While chain height is bellow 300000 - miner is trying to mine using normal algo (so it most probably doesn't mine anything)
When block height become 300000 - miner creates fork block:
Miner opens file - utxo-000001.bin, reads it and creates fork block 300 001 with 10K CB's (or whatever number of record was in the file, but <= 10K)
Miner then "mines" block and sends it to the network
Then it takes the next value of chain height and search for the "matching" file.
In this example, miner will create fork blocks while chain tip is between 300000 and 364999 from utxo files as such:
300 001 -> uto-000001.bin
300 002 -> utxo-000002.bin
...
300 123 -> utxo-000123.bin
...
365 000 -> utxo-065000.bin

2. Verification mode

a. put following into the config file (btcprivate.conf):

utxo-path="path-to-utxo-files"

Note: Start height Must be set in the code, but it can also be set via fork-startheight config parameter

b. start the node
c. When tip of the chain will get into the range (fork-startheight < tip <= fork-startheight+fork-heightrange), node starts to compare the content of all newly received blocks with the content of utxo files.
If block and file match - node accepts block; if they are not - node rejects block.

Example:

Let's say the fork height set in the code as 300000; range as 65K and CB per block as 10K
While chain height is bellow 300001 - node is not doing anything different from the usual ZClassic node.
When the node receives the block that when accepted will be at height 300001 - the node perform an additional verification for newly received blocks:
Node opens utxo file - utxo-000001.bin, read it into memory and compare its records with transactions from the block # 300001
If they match - block is accepted; if not - rejected
In this example, node will do this verification for all blocks between 300001 and 365000 and checks them with utxo files as such:
300 001 -> uto-000001.bin
300 002 -> utxo-000002.bin
...
300 123 -> utxo-000123.bin
...
365 000 -> utxo-065000.bin

3. Mode 3

a. make sure utxo-path is not specified in the config file.

UTXO files format

8 bytes little endian coin amount
8 bytes little endian length of script pub key
script pub key
newline

Tool for dumping utxo's

https://github.com/jc23424/utxo_dump

@gktown

This comment has been minimized.

Copy link

gktown commented Jan 8, 2018

Fantastic info! I stand by what I said 👍

@andreibolkonsky

This comment has been minimized.

Copy link

andreibolkonsky commented Jan 8, 2018

Fantastic man

@GildedHonour

This comment has been minimized.

Copy link

GildedHonour commented Jan 8, 2018

@heyrhett Are there other issues-bounties I can take?

@Stonee101

This comment has been minimized.

Copy link

Stonee101 commented Jan 9, 2018

This is great news! I'm impressed.

How will the utxo-123 files be deployed through the network? I assume every node must have this for mining / verifying

@dolb

This comment has been minimized.

Copy link

dolb commented Jan 16, 2018

You will be able to generate them from your bitcoind directly I believe.

@airk42 airk42 closed this Feb 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment