Update:

Starting right now, there will be a large amount of development updates as we near the June 28th release date of the Test Network. These will be technical in nature, but explains the work going into Qtum Core.

We'll start with the first few portions:





1, Qtum Core Branding


Basic Qtum Branding

Basic renaming of the Bitcoin code to make it into Qtum. This shouldn't be too extensive, but should cover the following:

1. Use ~/.qtum instead of ~/.bitcoin for data directory by default
2. Build system should output qtumd instead of bitcoind/cli etc


2, The Basic Qtum Network


Create basic Qtum network

Change the parameters so that the Qtum network is different from Bitcoin.


1. Change genesis seed

2. Change P2P/RPC ports

3. Change "magic" P2P network bytes.

4. Add whatever changes are needed so that a new mainnet network can be mined and synced.

5. Remove bitcoin checkpoints and node lists

6. Make sure that all 3 networks work: mainnet, testnet, and regtest. With mainnet and testnet being distinctly different and incompatible with Bitcoin
Make sure to remove irrelevant tests that only affect Bitcoin, and to change tests which rely on network parameters

specific params:
Block time: 128 seconds
Block size: 2Mb
P2P port: 3888 (chosen arbitrarily, shouldn't have conflicts, but can be changed if needed)
RPC port: 3889
testnet P2P port: 13888
testnet RPC port: 13889
Qtum pubkeyhash address: 58 (Q)
Qtum p2sh address: 50 (M)
Qtum testnet p2pkh: 120 (q)
Qtum testnet p2sh: 110 (m)



3, Add EVM and OP_CREATE for Contract Execution


After this, the EVM should be integrated and a very basic contract should be executable.

There will be a new opcode, OP_CREATE (formerly OP_EXEC), which takes 4 arguments, in push order:
1. VM version (currently 1 is EVM)
2. Gas price (not yet used, anything is valid)
3. Gas limit (not yet used, assume very high limit)
4. bytecode


For now it is OK that this script format be forced and mandatory for OP_CREATE transactions on the blockchain. (ie, only "standard" allowed on the blockchain)
When OP_CREATE is encountered, it should execute the EVM and persist the contract to a database (triedb)


Note:
Make sure to follow policy for external code (commit vanilla unmodified code first, and then change it as needed)
Make the EVM test suite functional as well (someone else can setup continuous integration changes for it though)


QTUM Address for new contracts


QTUmCORE-3. Test that qtum address is generated after contract creation. Before running the test make sure that:

Node started в –regtest
Bitcoin tests passed
Test Steps


1. Create transaction TX_DEPLOYMENT in bitcoinlib-js, run decoderawtransaction.
2. Create transaction TX_ASSIGN_SC in bitcoinlib-js, run decoderawtransaction.
3. Create transaction TX_DEPLOYMENT in bitcoinlib-js, run sendrawtransaction.
3. Create transaction TX_ASSIGN_SC in bitcoinlib-js, run sendrawtransaction.


Expected Result
1. Transaction marked as deployment.
2. Transaction marked as assign.
3. Contract created (address and balance are displayed on the console).
4. Contract state changed (address and balance are displayed on the console).




4, Add PoS block verification and mining






After this, the Qtum blockchain should be capable of verifying basic PoS v3 blocks, and the wallet should be able to mine these blocks similar to PoW blocks.

There is not a network rule as of yet for only allowing PoS blocks at this point, so the chain will accept either PoW and PoS blocks as valid. Both block types should use the same default bitcoin standard difficulty.


Thing to ensure:


1, stake modifier changes every block  

2, Coinage does not change PoS values

3, No decentralized checkpoints (still in design)

4, Make sure that these statements remain true:

5, don't enforce tx fee as consensus rule

6, static pos reward (make it just 1 token for now, will change later)

7, stake modifier v2 - The purpose of stake modifier is to prevent a txout (coin) owner from computing future proof-of-stake generated by txout at the time of transaction confirmation. Verification of the block was changed, now you need only previous block, so all other blocks can be deleted and space saved  (you need last 500 blocks to stake) pruning capabilities should be in future major release

8, compatibility with BIP66

9, only last 500 blocks are needed to verify proof of stake

10, No coin age, instead just a coin confirmation requirement (500 blocks is fine for now)



5, Add ability for contracts to call other deployed contracts




Contracts should be capable of calling other contracts using a new opcode, OP_CALL.

Arguments in push order:
version (32 bit integer)
gas price (64 bit integer)
gas limit (64 bit integer)
contract address (160 bits)
data (any length)
OP_CALL should ways return false for now.


OP_CALL only results in contract execution when used in a vout; Similar to OP_CREATE, it uses the special rule to process the script during vout processing (rather than when spent as is normal in Bitcoin). Contract execution should only be triggered when the transaction script is in this standard format and has no extra opcodes.

If OP_CALL is created that uses an invalid contract address, then no contract execution should take place. The transaction should still be valid in the blockchain however. If money was sent with OP_CALL, then that money (minus the gas fees) should result in a refund transaction to send the funds back to vin[0]'s vout script.

The "sender" exposed to EVM should be the pubkeyhash spent by vin[0]. If the vout spent by vin[0] is not a pubkeyhash, then the sender should be 0.

Funds can be sent to the contract using an OP_CALL vout. These funds will be handled by the account abstraciton layer in a different story, to expose this to the EVM.
Multiple OP_CALLS can be used in a single transaction. However, before contract execution, the gas price and gas limit of each OP_CALL vout should be checked to ensure that the transaction provides enough transaction fees to cover the gas. Additionally, this should be verified even when the contract is not executed, such as when it is accepted in the mempool.

---

These updates should give you an idea of what we are working on leading up to the June 28th release of the Test Network. Please see the Roadmap below for more information:

---

Please remember that we have an event in Shanghai on the 28th so please RSVP if you plan on attending:

No, it's an old version simply. Git pull and a browser cache clear should help!

Try this trick (thanks to Evil Knievel who spent a whole day in helping me)


Add the bold part at the end of the third address (a ";" and the multisig address you donated from) and try to sign this message with two of the three private keys instead of the original one.
Anyway as far as I know unvoid is going to push a fix.

The few XEL trades on the HEAT AE (145 XEL in total) were just used to test the automatic deposit and redemption functions. If you already have an account on HEAT, it is already now possible to trade the BTC/XEL pair, but the order books are currently quite limited. What opens up tomorrow is the description on how to use the automatic deposit / withdrawal functions. Hopefully many XEL holders will participate so that we can get some volume on the sales side of the order book.

Byteball will skyrocket as usual before the distribution 

still valid.

Do not sell your qtum ... the release of the testnet will spill away any sort of doubt and finally you will get a blockchain 2.0
A single reference for the major coins..20-30-40-100 $ soon...just a little bit of patience

I think it will be closer to 25$

here you go man, as a NXT coin investor, i do not really care how much i have.... just sent you half million XEL
because as a developer in crypto for 5 years, i know the feeling.

i hope this 500000 XEL will worth 10M dollars in 1-2 years.

please also send some to other devs man.

thank you for make this happen.

i am happy i find some good people in crypto.

Both are already there, I am using the Mac version already. Just install Oracle JDK 8 (no openjdk) and use ./compile.sh as well as ./run-desktop.sh scripts ;-)

Alternatively, ./run.sh and a browser pointing to http://localhost:17876.

There is also a packager, which is not yet tested but will create a Elastic.app for your Launchpad. I guess Unvoid will do some guides soon.

You should really only use a local node installed on your computer. Because if it transmits the passphrase, then in cleartext. But if you do not start forging you should have no reason to worry about.

Forging only starts automatically when you log into your account locally. If you use a remote wallet, you will see a "Gray icon" on the forging button. Only if you click it, enter your passphrase and confirm that you want to start forging, then you will be forging.

However, forging is a good thing. If done locally on your own computer with a local wallet installed, it should be totally safe.

How can i mine XEL?

Well, IF it is transmitted to the server (which definitely is the case for forging), then it is transmitted in clear text. It may be tunnelled through an SSL socket, but it will definitely arrive as clear text at the server side.