Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 554. (Read 1276933 times)

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 ?

You need to temporarily unlock your Bitcoind wallet.

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= --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
    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 is not known', 'code': -4}


Anyone got any ideas?

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.


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

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.

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.

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.

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

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.

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

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.

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

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.

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

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.

How can I make an asset? Do I have to make it from a wallet with XCP on it or from any address?

In mathematics, a counterexample can be used to prove a statement is false.
counterparty uses bitcoin as an underlying base protocol and it works just fine!

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.

First, I think 'distirbuted kickstarter' is a great use-case, which you can bet I will be stealing for the wiki  .

I also would like to mention the new "Asset Description" feature:

• Assets are now accompanied by up to 42 characters of Unicode text which may serve as a short description of the asset (esp. a link to a website with more information and proof it does what it says).

It is important not to form too strict of an analogy between Counterparty's on-chain functionality and a real market. In our opinion, the best use of this 'description space' is to provide a link to a website. It would make sense, if, on such a website, there was a list of the addresses one was using to sell assets (and the assets associated with each address), that way the link could be verified. Of course, such verification is not perfect.

I want to emphasize, as well, that this feature does not eliminate trust or the importance of 'reputation', nor is it meant to. On the contrary, we believe that trust has to be a factor in asset sales, and the description space is only meant to help provide as robust a reputation system as possible.

If there really were a means of verifying that each of the feed-operators is unique, couldn't just apply this means to proving that the feed-operator and the two betting-parties are unique, as well?


In this case if 1 out of the 5 feeds goes bad you lose 20% of your coins. In my aggregated feed example you would need 50% of the feed operators to be bad to lose any coins.


[/quote]

I was mistaken, the two cases do not amount to the same thing. With that said, they are just different risk management situations: in this case the difference is between possibly losing 60% of your bet, or possibly losing all of it.