Hi, I can help test mining.

Computer 1

• Xeon E3-1545M v5 @ 2.9Ghz
  64 GB RAM
  Ubuntu derivative
  Chrome and Firefox

Computer 2

• i7-6700K
  16 GB RAM
  Windows 10 Pro
  Chrome, Firefox, Edge

Mobile

• Snapdragon 835
  4 GB RAM
  Android OS 7
  Chrome, Firefox, Edge
  

There's also an equality vs assignment bug which impacts how the wallet tracks (or doesn't correctly track?) serial numbers of spent private coins:

https://makebitcoingreatagain.wordpress.com/2017/02/18/is-the-zcoin-bug-in-checktransaction/#update4

What else can the exchanges do? The most recent blocks show that the attacker is still minting away, see the 100 XZC transactions:

https://chainz.cryptoid.info/xzc/block.dws?21758.htm

https://chainz.cryptoid.info/xzc/block.dws?21749.htm

The transaction is a Zcoin Spend which moves money from the private pool to the public pool.  The attacker's fraudulent Zcoin Spend transactions are being accepted as valid by nodes when instead they (and the block) should be rejected as invalid.

I don't think the bug is due to a simple typo.  I believe it's somewhere in the implementation of the verification code, which looks like its full of repeated blocks of copy and paste code.  Posted more info here:

https://makebitcoingreatagain.wordpress.com/2017/02/18/is-the-zcoin-bug-in-checktransaction/

In terms of resolution, the following would be prudent:

Link:
https://makebitcoingreatagain.wordpress.com/2017/02/18/is-the-zcoin-bug-in-checktransaction/

Summary:
The fix posted (so far) to Github is insufficient
- does not stop the attacker from continuing to create fake Zcoin Spend transactions
- prevents regular users who are holding private funds from moving them to a public address
- does not explain fix the issue of fraudulent Zcoin Spend transactions passing validation checks

Isn't this a user problem rather than a protocol issue?  First, the protocol doesn't specify that a user must destroy their private key when creating nLockTimed transactions.  Second, since there's no guarantee that any given transaction will ever be successfully mined, it doesn't seem prudent to pre-sign transactions which sit off-chain and only become valid for broadcast and potential mining in some distant future whilst also deleting the private key.  If this destructive behaviour can be condoned, it beggars belief that zero conf transactions are considered unsafe.

Fair question as the signature malleability issue is quite simple to fix.

When hashing the transaction data to generate a txid, simply skip over the signature data.  Everything else stays the same.  

Deployment and activation would be via a hard fork set at a certain block height.

Are you thinking of building your next project with Ethereum, Rootstock or some other smart contract platform?

Before you start investing resources, take into consideration some fundamental problems with smart contracts on public blockchains.  

https://makebitcoingreatagain.wordpress.com/2016/02/10/5-challenges-facing-smart-contracts/

TLDR...

• No guarantee of transaction execution
  
• Turing-complete smart contracts are slow
  
• Scaling is a moonshot
  
• Oracles break the trust model
  
• Public blockchains struggle to stay decentralized
  

@AtheistAKASaneBrain Partially :-)  I'm not advocating for this change, just trying to let you guys know what is happening.


@pooya87 @AtheistAKASaneBrain Some Bitcoin Core developers want to keep the block size at 1MB to encourage a fee market to develop, and ultimately have Bitcoin become a settlement system where the majority of transactions occur off-chain on payment hubs and sidechains.  In such a situations, any attempt to send a free or low-fee transaction on the public blockchain will likely be discarded or face significant delays.  Thus some developers feel it is wrong to continue to promise free and fast transactions:


Other developers believe the block size should be raised to increase the capacity of the system and help keep fees to a minimum, which is more in line with the original vision of Bitcoin as a fast P2P cash system without intermediaries.

Er, don't shoot the messenger.

Some developers no longer want to imply that Bitcoin offers cheap and fast transactions since a fee market will likely develop:


Link with screenshots of proposed changes: https://github.com/bitcoin-dot-org/bitcoin.org/pull/972

If you mouseover the CoinSpark link you can see what kind of transaction it is.  In this case it's a Genesis transaction, so you (or somebody else) issued one unit of an asset to a CoinSpark address (which is just a wrapper around an underlying Bitcoin address).  If the issuer uploads the PDF contract and HTML file to the website path, the SparkBit wallet for the CoinSpark address will validate the asset and then it could be sent onto someone else.

http://i.imgur.com/nF6SCXc.png

You can send messages over Bitcoin with CoinSpark (an OP_RETURN based protocol).

http://www.coindesk.com/coinspark-blockchain-notarized-messaging/

Messages are not stored on the Bitcoin blockchain itself but are sent out-of-band via message delivery servers.  When you send a message with a bitcoin transaction, the blockchain only stores enough details for the recipient to retrieve the message and ensure it is valid.  CoinSpark runs some community servers but you can run your own server and modify it to meet your needs as the code is open-source.

Get started by downloading SparkBit, a lightweight SPV wallet based on MultiBit:
http://www.coinspark.org

Developers can find open-source libraries and docs here:
http://coinspark.org/developers/messages-introduction/

Hi orobtc,

Just wanted to let you know:

• The paper has been updated and a diagram added (attached below).
• If you want some assets to play with, there is a demo faucet here: http://coinspark.org/demo-asset-faucet/
  

Cheers!

http://i.imgur.com/BUPDtSN.jpg?1

Thanks OROBTC, that's a good idea.  Is a high-level view sufficient - where Bitcoin is treated as a black box - or do you think readers would benefit from a bit more detail?  I think dropping down to OP_RETURN and transaction outputs might be too much.

A common complaint from gold investors is that the benchmark price of physical gold, set twice daily in London by a handful of banks, is open to manipulation.  There is currently a lawsuit underway concerning such allegations and the benchmark is due to be replaced in early 2015 because of incoming financial regulations stemming from the LIBOR scandal.

With the emergence of Bitcoin as a platform to transfer assets other than BTC, I believe that if entrepreneurs and gold stakeholders were to support the development of investor products based around gold-backed Bitcoin assets, a new price benchmark for physical gold could emerge.  With the bulk of the world's gold production and consumption now in Asia, and new gold exchanges having launched there recently, Bitcoin could help tip the balance, and we could enter a new era where the price of gold is no longer influenced so much by London.  For some, this would be liberation.

I have put together a short paper to explore this topic, including how to create a new Bitcoin asset in just a few minutes and why these assets are superior to existing gold instruments.  It's currently a working draft and your feedback is most welcome.  Please feel free to comment here or within the Google Document itself.  Thank you!

https://docs.google.com/document/d/15VG1f8Jwkl6eKLsqGv1KdUUgVRkQleaXr33JgDL-4So/edit?usp=sharing

Note: I am involved in a Bitcoin assets project, within the colored coins family, called CoinSpark.  You can find out more here: http://www.coinspark.org

Update: Example diagram showing how GoldCo can securitize their gold holdings as Bitcoin assets

http://i.imgur.com/BUPDtSN.jpg?1

CoinSpark is a lightweight bitcoin 2.0 solution for transferring assets using OP_RETURN.

If you're in San Francisco this week, there's a mini meetup on Wednesday evening (8th Oct 2014) , just a block away from the Uber and Twitter offices.

https://www.eventbrite.com/e/bitcoin-20-op-returns-the-blockchain-as-tcpip-registration-13209506991