[ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread

[BitThink]

Can @phantomphreak please address the claims made by ethereum founder in bitcoin magazine?

http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

It seems he thinks among many things that bitcoin is not suitable to be treated as an underlying base  protocol.

One of the main reasons:

Simplified Payment Verification (see the bitcoin whitepaper Section 8 ) becomes not usable. Since the miner will not verify whether a XCP transaction is valid like they do in bitcoin transactions, to check the validity of a XCP transaction, we have to track up to the very beginning (the address sent to burn address). This requires each client to download and keep the whole blockchain.

In Ethereum, they seems to find a way to solve this problem.

Detail can be found in their whitepaper: http://www.ethereum.org/ethereum.html

Personally, I don't think this is something will make Mastercoin/XCP not usable. It just increases the downloading and parsing time.

Would it be possible to have a checkpoint file that is signed by the XCP devs that clients could load instead of the entire blockchain?
For ease of use, this is almost a requirement as few normal people will wait for hours and hours for the initial sync up

It's possible, but it will not be decentralized if there's a checkpoint. People has to trust the one who publish the checkpoint. However, I think it could be very useful to provide some trustworthy services keeping some snapshots, therefore most average users can choose to trust these services and shortcut their parsing and verification. Those trustworthy services cannot cheat others for a long time as long as there're some independent clients choose to verify transactions all by themselves.

[1714757485]

1714757485

[1714757485]

1714757485

[jl777]

Can @phantomphreak please address the claims made by ethereum founder in bitcoin magazine?

http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

It seems he thinks among many things that bitcoin is not suitable to be treated as an underlying base  protocol.

One of the main reasons:

Simplified Payment Verification (see the bitcoin whitepaper Section 8 ) becomes not usable. Since the miner will not verify whether a XCP transaction is valid like they do in bitcoin transactions, to check the validity of a XCP transaction, we have to track up to the very beginning (the address sent to burn address). This requires each client to download and keep the whole blockchain.

In Ethereum, they seems to find a way to solve this problem.

Detail can be found in their whitepaper: http://www.ethereum.org/ethereum.html

Personally, I don't think this is something will make Mastercoin/XCP not usable. It just increases the downloading and parsing time.

Would it be possible to have a checkpoint file that is signed by the XCP devs that clients could load instead of the entire blockchain?
For ease of use, this is almost a requirement as few normal people will wait for hours and hours for the initial sync up

It's possible, but it will not be decentralized if there's a checkpoint. People has to trust the one who publish the checkpoint. However, I think it could be very useful to provide some trustworthy services keeping some snapshots, therefore most average users can choose to trust these services and shortcut their parsing and verification. Those trustworthy services cannot cheat others for a long time as long as there're some independent clients choose to verify transactions all by themselves.

Could the network provide feedback on any checkpointed file to make sure it is valid? Presumably there will always be counterpartyd's that parsed the full blockchain, so before any checkpoint file is trusted locally and used, it could make sure it is valid by checking with the overall network.

Assuming it is published on counterparty.co, matches sig, odds are very good it is valid, plus it is only for initial install. So, after quick install, check with network to make sure nobody goofed when uploading the checkpoint file. If it all checks out, then BAM! we saved 17 hours of blockchain sync time without any risk

James

[BitThink]

Can @phantomphreak please address the claims made by ethereum founder in bitcoin magazine?

http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

It seems he thinks among many things that bitcoin is not suitable to be treated as an underlying base  protocol.

One of the main reasons:

Simplified Payment Verification (see the bitcoin whitepaper Section 8 ) becomes not usable. Since the miner will not verify whether a XCP transaction is valid like they do in bitcoin transactions, to check the validity of a XCP transaction, we have to track up to the very beginning (the address sent to burn address). This requires each client to download and keep the whole blockchain.

In Ethereum, they seems to find a way to solve this problem.

Detail can be found in their whitepaper: http://www.ethereum.org/ethereum.html

Personally, I don't think this is something will make Mastercoin/XCP not usable. It just increases the downloading and parsing time.

Would it be possible to have a checkpoint file that is signed by the XCP devs that clients could load instead of the entire blockchain?
For ease of use, this is almost a requirement as few normal people will wait for hours and hours for the initial sync up

It's possible, but it will not be decentralized if there's a checkpoint. People has to trust the one who publish the checkpoint. However, I think it could be very useful to provide some trustworthy services keeping some snapshots, therefore most average users can choose to trust these services and shortcut their parsing and verification. Those trustworthy services cannot cheat others for a long time as long as there're some independent clients choose to verify transactions all by themselves.

Could the network provide feedback on any checkpointed file to make sure it is valid? Presumably there will always be counterpartyd's that parsed the full blockchain, so before any checkpoint file is trusted locally and used, it could make sure it is valid by checking with the overall network.

Assuming it is published on counterparty.co, matches sig, odds are very good it is valid, plus it is only for initial install. So, after quick install, check with network to make sure nobody goofed when uploading the checkpoint file. If it all checks out, then BAM! we saved 17 hours of blockchain sync time without any risk

James

The problem is that even if we use a checkpoint, the size of a checkpoint file for counterparty will be much larger than a checkpoint of BTC. A checkpoint of BTC is just the hash of current block, but a checkpoint of counterparty has to snapshot the balance of each address and the status of each order, bid, broadcast etc.

[Olano]

Can @phantomphreak please address the claims made by ethereum founder in bitcoin magazine?

http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

It seems he thinks among many things that bitcoin is not suitable to be treated as an underlying base  protocol.

One of the main reasons:

Simplified Payment Verification (see the bitcoin whitepaper Section 8 ) becomes not usable. Since the miner will not verify whether a XCP transaction is valid like they do in bitcoin transactions, to check the validity of a XCP transaction, we have to track up to the very beginning (the address sent to burn address). This requires each client to download and keep the whole blockchain.

In Ethereum, they seems to find a way to solve this problem.

Detail can be found in their whitepaper: http://www.ethereum.org/ethereum.html

Personally, I don't think this is something will make Mastercoin/XCP not usable. It just increases the downloading and parsing time.

Damn... and people burned over 2000+ BTC on a protocol that has this big gaping hole?

[BitThink]

Can @phantomphreak please address the claims made by ethereum founder in bitcoin magazine?

http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

It seems he thinks among many things that bitcoin is not suitable to be treated as an underlying base  protocol.

One of the main reasons:

Simplified Payment Verification (see the bitcoin whitepaper Section 8 ) becomes not usable. Since the miner will not verify whether a XCP transaction is valid like they do in bitcoin transactions, to check the validity of a XCP transaction, we have to track up to the very beginning (the address sent to burn address). This requires each client to download and keep the whole blockchain.

In Ethereum, they seems to find a way to solve this problem.

Detail can be found in their whitepaper: http://www.ethereum.org/ethereum.html

Personally, I don't think this is something will make Mastercoin/XCP not usable. It just increases the downloading and parsing time.

Damn... and people burned over 2000+ BTC on a protocol that has this big gaping hole?

No, it's just a weakness, not a show stopper.

Worse case is that you have to download the whole BTC blockchain to use Counterparty. Otherwise, you could trust some big websites to verify the transactions for you (like the blockchain.info for BTC).

The only difference with current status of BTC is that 1) it's more difficult to build a light-weight client such as Multibit, and 2) the parsing time could be long when the history of XCP becomes long.

[TKeenan]

Damn... and people burned over 2000+ BTC on a protocol that has this big gaping hole?

The idea to throw $2 million into the toilet proves that XCP was stupid from the very beginning.  Ship of fools.  Happy sailing!

[BitThink]

Try harder.

As I said. Only the progress determines the price. Your opinion, or my opinion, does not matter at all. At least for now, the progress of XCP is much faster than MSC. Let's see which ship arrives the destination first.

[Alias]

Can @phantomphreak please address the claims made by ethereum founder in bitcoin magazine?

http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

It seems he thinks among many things that bitcoin is not suitable to be treated as an underlying base  protocol.

One of the main reasons:

Simplified Payment Verification (see the bitcoin whitepaper Section 8 ) becomes not usable. Since the miner will not verify whether a XCP transaction is valid like they do in bitcoin transactions, to check the validity of a XCP transaction, we have to track up to the very beginning (the address sent to burn address). This requires each client to download and keep the whole blockchain.

In Ethereum, they seems to find a way to solve this problem.

Detail can be found in their whitepaper: http://www.ethereum.org/ethereum.html

Personally, I don't think this is something will make Mastercoin/XCP not usable. It just increases the downloading and parsing time.

Would it be possible to have a checkpoint file that is signed by the XCP devs that clients could load instead of the entire blockchain?
For ease of use, this is almost a requirement as few normal people will wait for hours and hours for the initial sync up

It's possible, but it will not be decentralized if there's a checkpoint. People has to trust the one who publish the checkpoint. However, I think it could be very useful to provide some trustworthy services keeping some snapshots, therefore most average users can choose to trust these services and shortcut their parsing and verification. Those trustworthy services cannot cheat others for a long time as long as there're some independent clients choose to verify transactions all by themselves.

Could the network provide feedback on any checkpointed file to make sure it is valid? Presumably there will always be counterpartyd's that parsed the full blockchain, so before any checkpoint file is trusted locally and used, it could make sure it is valid by checking with the overall network.

Assuming it is published on counterparty.co, matches sig, odds are very good it is valid, plus it is only for initial install. So, after quick install, check with network to make sure nobody goofed when uploading the checkpoint file. If it all checks out, then BAM! we saved 17 hours of blockchain sync time without any risk

James

The problem is that even if we use a checkpoint, the size of a checkpoint file for counterparty will be much larger than a checkpoint of BTC. A checkpoint of BTC is just the hash of current block, but a checkpoint of counterparty has to snapshot the balance of each address and the status of each order, bid, broadcast etc.

There is a very elegant solution (theoretically) to this problem. Decentralise the checkpointing. A DAC (Decentralised Autonomous Community/Corporation/Company, for those who aren't familiar with the concept) could ensure that a checkpoint that has been arrived at by consensus is published/broadcast.

For those of you whose eyes glaze over when they see the acronym "DAC", picture this please:

I install my "Counterparty-qt". During installation it asks me "Do you want to run a full node?". I say yes because I personally don't care about "downloading and parsing time". This installs a DAC add-on with my Counterparty-qt.

I run Counterparty-qt. In the background a checkpoint of the system is periodically being updated (presumably by block).

My CP-DAC (CounterParty-DAC) is talking to every other CP-DAC on the network. They reach a consensus of the checkpoint of the system. The DACs then publish both the checkpoint (as a torrent perhaps?) and the checksum for it (for further verification).

Those individuals choosing to run Counterparty-qt without supporting the decentralised check-pointing add-on can just download that checkpoint torrent as their starting point. This would allow them to get up and running almost immediately.

The beautiful thing here is that after the checkpoints for every block so far (and checksums corresponding to them) are published, more people could run the DAC from those points onwards at less expense (bandwidth and processing power) and contribute to the decentralised checkpointing.

Feel free to ask me any questions about this.

So, does the Counterparty Project want to have the first useful DAC as well as the first useful decentralised exchange?

TLDR: A light-weight Counterparty Protocol client is possible by utilising a DAC.

[BitThink]

Very interesting. Could be very useful for average users.
Just one question now, how about there's a reorganization after a checkpoint is setup? There has to be a scheme to invalidate the checkpoint in a short time. Maybe associate the checkpoint with the block hash.

[sumantso]

Congrats everyone for the successful burn period. I expected it would hit 3k BTC, but less is better (for us). Can't wait for the GUI wallet to be out.

I enjoyed taking all the trouble to get counterpartyd set up and do all the stuff. I am a non-technical guy and usually its just click qt for me.

Sorry but we have MasterCoin already. 

https://bitcointalk.org/index.php?topic=265488.0

Somebody was already getting the jitters - reason for his sell off?

[trilli0n]

Hi,

Can anyone help me to resolve this? It seems I set up everything fine, see blocks coming in, but placing an order fails with a "Private key is not known" message. The address does exist in my wallet and I do have bitcoin in it.

Here's the error:

c:\counterpartyd_build>counterpartyd order --from=<valid address> --get-quantity=10 --get-asset=XCP --give-quantit
y=0.0010 --give-asset=BTC --expiration=2 --fee_provided=0.0001


c:\counterpartyd_build>echo off
Traceback (most recent call last):
  File "c:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 541, in <module>
    args.expiration, fee_required, fee_provided)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\order.py", line 31, in create
    return bitcoin.transaction(source, None, None, fee_provided, data, test)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 295, in transaction
    transaction = serialise(inputs, destination_output, data_output, change_output, multisig=multisig, source=source)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 174, in serialise
    private_key_wif = rpc('dumpprivkey', [source])
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 69, in rpc
    raise exceptions.BitcoindError('{}'.format(response_json['error']))
lib.exceptions.BitcoindError: {'message': 'Private key for address <valid address> is not known', 'code': -4}


Anyone got any ideas?

[PhantomPhreak]

Hi,

Can anyone help me to resolve this? It seems I set up everything fine, see blocks coming in, but placing an order fails with a "Private key is not known" message. The address does exist in my wallet and I do have bitcoin in it.

Here's the error:

c:\counterpartyd_build>counterpartyd order --from=<valid address> --get-quantity=10 --get-asset=XCP --give-quantit
y=0.0010 --give-asset=BTC --expiration=2 --fee_provided=0.0001


c:\counterpartyd_build>echo off
Traceback (most recent call last):
  File "c:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 541, in <module>
    args.expiration, fee_required, fee_provided)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\order.py", line 31, in create
    return bitcoin.transaction(source, None, None, fee_provided, data, test)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 295, in transaction
    transaction = serialise(inputs, destination_output, data_output, change_output, multisig=multisig, source=source)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 174, in serialise
    private_key_wif = rpc('dumpprivkey', [source])
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 69, in rpc
    raise exceptions.BitcoindError('{}'.format(response_json['error']))
lib.exceptions.BitcoindError: {'message': 'Private key for address <valid address> is not known', 'code': -4}


Anyone got any ideas?

You need to temporarily unlock your Bitcoind wallet.

[halfcab123]

Would there be a way to transfer all current XCP holdings on the entire network to a newly designed protocol that sits on top of ethereum ?

[uccoins]

Hi,

Can anyone help me to resolve this? It seems I set up everything fine, see blocks coming in, but placing an order fails with a "Private key is not known" message. The address does exist in my wallet and I do have bitcoin in it.

Here's the error:

c:\counterpartyd_build>counterpartyd order --from=<valid address> --get-quantity=10 --get-asset=XCP --give-quantit
y=0.0010 --give-asset=BTC --expiration=2 --fee_provided=0.0001


c:\counterpartyd_build>echo off
Traceback (most recent call last):
  File "c:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 541, in <module>
    args.expiration, fee_required, fee_provided)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\order.py", line 31, in create
    return bitcoin.transaction(source, None, None, fee_provided, data, test)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 295, in transaction
    transaction = serialise(inputs, destination_output, data_output, change_output, multisig=multisig, source=source)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 174, in serialise
    private_key_wif = rpc('dumpprivkey', [source])
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 69, in rpc
    raise exceptions.BitcoindError('{}'.format(response_json['error']))
lib.exceptions.BitcoindError: {'message': 'Private key for address <valid address> is not known', 'code': -4}


Anyone got any ideas?

You need to temporarily unlock your Bitcoind wallet.

I got stuck on this for a while, to unlock the Bitcoind wallet the command I used was:

bitcoind walletpassphrase *yourpassphrasehere* 600

where 600 is the number of seconds I chose to unlock it for

[prophetx]

Congrats everyone for the successful burn period. I expected it would hit 3k BTC, but less is better (for us). Can't wait for the GUI wallet to be out.

I enjoyed taking all the trouble to get counterpartyd set up and do all the stuff. I am a non-technical guy and usually its just click qt for me.

Sorry but we have MasterCoin already. 

https://bitcointalk.org/index.php?topic=265488.0

Somebody was already getting the jitters - reason for his sell off?

you should have made a bet with me, i would have bet you that it would be lower than 3k but over 1k, bummer

[Alias]

Very interesting. Could be very useful for average users.
Just one question now, how about there's a reorganization after a checkpoint is setup? There has to be a scheme to invalidate the checkpoint in a short time. Maybe associate the checkpoint with the block hash.

Do you mean that you can only "unlock" the checkpoint with the actual latest block hash? Interesting.

Could I suggest a very crude "solution" - the checkpoint doesn't necessarily need to be the very latest snapshot of the Counterparty system. If the checkpoint was always at least even 1 hour old (6-ish blocks ago) the likelihood of a reorganization affecting blocks that far back would be incredibly low.

Also, since the Counterparty Checkpoint DAC runs across multiple machines and a block-chain reorganization is a local client occurrence, the DAC could actually determine when your bitcoind requires a reorganization and postpone the rolling out of the checkpoint.

[mtbitcoin]

Very interesting. Could be very useful for average users.
Just one question now, how about there's a reorganization after a checkpoint is setup? There has to be a scheme to invalidate the checkpoint in a short time. Maybe associate the checkpoint with the block hash.

I don't think the block reorganization should be an issue with a partially updated downloadedable counterparty db. Because counterpartyd will just pick up from the last point left off and the reorganization will follow through from where it left off. Can someone further comment of this?? Alternatively the db snapshot can be taken earlier after a certain period of blocks have passed. While not exactly an ideal solution, but when combined with a checksum perhaps this should be workable stop gap solution

I have been been rebuilding the db multiple times the last few days and I must say it is time consuming

Cheers

[PhantomPhreak]

Very interesting. Could be very useful for average users.
Just one question now, how about there's a reorganization after a checkpoint is setup? There has to be a scheme to invalidate the checkpoint in a short time. Maybe associate the checkpoint with the block hash.

I don't think the block reorganization should be an issue with a partially updated downloadedable counterparty db. Because counterpartyd will just pick up from the last point left off and the reorganization will follow through from where it left off. Can someone further comment of this?? Alternatively the db snapshot can be taken earlier after a certain period of blocks have passed. While not exactly an ideal solution, but when combined with a checksum perhaps this should be workable stop gap solution

I have been been rebuilding the db multiple times the last few days and I must say it is time consuming

Cheers

counterpartyd regularly checks for blockchain reogranisations in the last ten blocks (I just changed this), so that's right.

How are you rebuilding the DB, mtbitcoin? In the vast majority of cases, you just need to run 'counterparty.py reparse', and that takes only about 90 seconds on my i5. (Are you still running on develop? master is much slower, with its 'purge' function.)

EDIT: missing words

[nakaone]

well maybe i am wrong but

CONGRATULATIONS TO YOU FOR THE FIRST DECENTRALIZED  FINANCIAL MARKET IN CRYPTOCURRENCIES


2014 will be the beginning of cryptofinance and no matter where this ship is going you were the first who realized it

[mtbitcoin]

How are you rebuilding the DB, mtbitcoin? In the vast majority of cases, you just need to run 'counterparty.py reparse', and that takes only about 90 seconds on my i5. (Are you still running on develop? master is much slower, with its 'purge' function.)

EDIT: missing words

Latest Develop commit. I overwrite the files and rerun. But like I PMed you earlier, I was running into some issues with develop branch on Windows and have been switching back and forth from the version 4 vs 6 db trying to make sense of things. The lastest DB rebuild from scratch appears to have resolved the issue though.

Another reason, i am currently using the develop branch because the db on this one excludes non counterparty transactions from the transactions table