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

Rather:
    order is for {BTC, XCP, or internal asset} <===> {BTC, XCP, or internal asset} exchange
    issuance is for Nothing ==*poof*==> new internal asset



Yeah, I myself got burned by Nxt there (heh).



Just use counterpartyd to send the XCP that you earned to your new vanity address. (You won't be able to use those XCP, however, until you import your new private key into Bitcoind.)

Thanks for the quick answers.
Not very intuitive... it may be the novelty.

So:
order is for BTC<==>XCP exchange
and issuance is for XCP <==> internal assets
Q: but then there is no direct exchange for BTC <==> internal assets?!

What I really like with proof of burn is that it puts absolutely everyone to the same level of opportunity.
Including the dev.
Congrats for not being one more greedy fast starter.
Your project success, you make money too. 'Good & honest motivation to work!
Thanks for showing exemple. Hope it will have the success it deserve.

It's too easy/unfair to create an IPO coin, sending huge amount of your money to yourself to get coins, that people get by sending you money... scam-smell 99.9%
Just watch Visacoin, Next, Mastercoin, Ripple...
I'm pretty sure for VSC at least 60% of the funds is from the dev to himself.
Almost certain it happened for NXT & MSC too.
(uncomfort: your internal assets are thought to be created this way if no XCP-POB)

Proof of burn is the way to go. Almost scam-proof.
Point of a scam: making you lose money, making the scammer take/win your money
With POB, you can still lose your money, but the dev cannot take/win your money.
Therefore there is not real motivation to scam you.
(Obvious security reminder: be careful not having all your BTC in a single wallet.dat...)

The way XCP are created also seem to avoid suddent wish of purposedly bad wealth repartition...
Yeah, 'thinking Next. (announced ~1.5 month invest time, stopped after 2 weeks... BAD)
[DO NOT CHANGE THE TIME ALLOWED TO INVEST, under any pretext, 'trusting you on that]

Important question:
Let's say my BTC are on vanitygen keys.
I imported a key<1BTC into my wallet, burned it, got my XCP linked to the same privkey.
How do I send the XCP to another vanitygen privkey? (who never touched my wallet.dat)
Major need.


edit:
for the curious = {font=courier}word-effected{/font}
for teletype = {tt}word{/tt} (next to # code)
'learning how to use this forum ^^

All donations will go toward development bounties. I know that I, at least, will be burning BTC for XCP, which I think has great potential as a currency.

Question:

How do the developers intend to be rewarded for this?

Is just donations and contributions? Or will they invest like the rest of us in "burning" BTC into XCP?

Thanks,
S.

Without txindex=1, Bitcoind won't return the details of any arbitrary transaction. And, yeah, now counterpartyd detects that specific problem and spits out a more reasonable error message.

ok, that makes sense.  I will turn it on.

However, I have a question and comment for the devs.

Q: is txindex=1 actually required for counterparty to work properly?  why?    Or it is just a case that wasn't handled in the code?

comment:  I think that most people with existing bitcoind installations will not be running with txindex=1.  Please fix the code to detect this case and print a nice warning/error message.

It looks like counterpartyd is set to run on testnet, as it's looking for Bitcoind on port 18332, though neither of those configuration files has testnet enabled. Did you pass counterpartyd the option --testnet on the command-line? If so, get rid of that and try it again. What was the exact command that you tried to run? Try the following commands, too, to see what port Bitcoind is running on and whether it's working, just in case:
    bitcoind -rpcport=8332 getinfo
    bitcoind -rpcport=18332 getinfo

First of all, thank you for that wonderful post. We're certainly open to considering all proposals. To your questions:

1) The order command is for both buying and selling. To switch from one to the other, just switch the 'give' and 'get' assets and quantities. The issuance command creates 'internal' currencies (we call them 'assets'). There's no need to burn XCP to do so. You can create as much of asset XYZW as you want, whenever you want (if you were the original issuer; unless you locked it against further issuances).

2) The exchange for XCP, BTC and all internal currencies (any pair!) is currently operating (though I'm sure there it has bugs). If you want to trade BTC for something, or vice versa, you just have to use the btcpay command, which is pretty automatic, after the order that you made with the order command is matched, so it's almost as easy. XCP fees are pretty much for making bets, and they go to the operator of the feed on which the bets are made.

3) Correct.

4) No, that's an address whose private key is stored in Bitcoind.

5) No, but I'll add one soon. All transactions are public and pseudonymous (like Bitcoin transactions). You can get some information about internal assets and Counterparty addresses with the commands asset and address, respectively. We'd really like to get a block explorer website up as soon as possible, but right now we're focusing on the reference implementation, which might serve as a website's backend.

After I get bitcoind sucessfully running(i can see the bitcoind process running),

when I try to run counterpartyd, I get the followiing error,



theres are my config files,

~/.config/counterpartyd/counterpartyd.conf

[Default]
rpc-connect=localhost
rpc-port=18332
rpc-user=rpc
rpc-password=rpcpw1234


~/.bitcoin/bitcoin.conf

rpcuser=rpc
rpcpassword=rpcpw1234
server=1
daemon=1
txindex=1


I'm on ubuntu 13.10 and was able to build counterpartd sucessfully from the source....


I'm trying to get counterpartyd running on the mainnet.

any insights would be appreciated. thx.

I read everything, and I get a very good feeling about it.
Almost wished to say I love you under the exitation *laugh

No seriously, that's very interesting.
The level is a bit too high for me, but fascinating.

I had a simpler version of proof of purn in mind. But your solution seem actually better.
The difficulty is quite increase, but the trustless factor too.
Thank you for being the first with a proof of burn lunch. I was waiting for this.

Until now you also did a good job at answering question.
That's reassuring.
We can see it's in alpha/beta, but that there is some serious work behind.
Well, at least it seems to.
I let the tech-guys check your code. Open source = good point!

Now I have many question. I will try to stick to the main one.
(I hope you're open to feature proposal, I have many ideas)

About the function of XRP:
issuance and order basically allow a descentralized exchange.
issuance = sell order at least at price x
order = buy order maximum at price y
Is that correct? [<= question 1]          edit: seem yes, 'just wanna be sure

The tech aspect is really blurry to me, my level is low.
But from what I understand, it seems that later on it will be possible to create other internal coin.
(maybe by burning XRP, to stay on this very high level of trustlessness)

So let say: BTC, XCP, insidecoinA, insidecoinB
I can burn BTC to get XCP (maybe later burn XCP to get insidecoinA&B)
Your descentralized exchange will allow the exchange function between XCP & insidecoinA, or XCP and insidecoinB. (your project is maid for that if I understood well.)
But does it works as easily to exchange XCP for BTC? (still descentralized exchange)
I doubt the direct exchange between insidecoinA to BTC is possible, but perhaps it will be?! (that's just bonus)
['was question 2-group]
    edit: all seem yes after checking github, just wish a confirmation
            where goes XCP fee? in a lottery jackpot where you buy ticket with bet?

3rd question:
Double spending of XCP is protected by the POW of BTC, idem for future insidecoinX, correct?

4th: the ADDRESS in the command line to burn BTC, it's the private key, is it?

5th: Is there already the possibility to check the total number of XCP inside your program?
maybe an internal XCP transaction explorer too?
(or are transaction encrypted? therefore not public. Anonymity++ EMU-like)
(transaction are the business of no one, except the concerned. But public current balance are appreciated)
Having an online website with stats would be nice.

Long enough, I end here.
Thank you for your time.

I just pushed a commit to the repo. that should fix the TypeError: 'NoneType' object is not subscriptable bug mentioned above. Cheers.

I can't think of why you would, but counterpartyd probably has not been tested with such a configuration before.

This isn't the place to discuss Mastercoin, but it may be worth pointing out an important difference here between Mastercoin's protocol and Counterparty's: every Mastercoin transaction has to have a small output to the Exodus Address (to which at least J.R. holds the private key). Counterparty has no such limitation.

EDIT: typo

Will I run into problems if I have bitcoind built with a newer leveldb ( > 4.8 )  ?

Only Mastercoin funding is centralized, protocol itself isn't centralized.

btc4ever, let me know the Ubuntu version and I'll see if I can reproduce the problem, as I am maintaining the build system.

I developed on Ubuntu 13.10, but I want this to be able to run on 12.04 LTS, 12.10, 13.04 and 13.10. Support for other Linux versions can be added as well (I take pull requests!

I ran into this as well, I have opened up a bug ticket with a root cause analysis. PhantomPhreak will hopefully be able to get it addressed tomorrow: https://github.com/PhantomPhreak/counterpartyd/issues/4

EDIT: This is actually because you do not have "txindex=1" specified in your bitcoin.conf file.

To fix, add that to your bitcoin.conf, then startup bitcoind manually using "bitcoind --txindex=1 --reindex=1" (along with a --datadir directive if using a non-default data directory location). Once bitcoind is done reindexing, you can kill bitcoind and restart bitcoin-qt or whatever normally.

We have been exploring taking the concept of Counterparty out to additional blockchains. From a technical standpoint, Counterparty uses the OP_RETURN feature of Bitcoin to store its data (full support for which will be included in Bitcoin v0.9, which will most likely be out and deployed across the major mining pools in about a month to two based on Gavin's estimates).

The advantage of this is that it's a very clean way of encoding the data: Counterparty transactions can be easily pruned from the blockchain. The disadvantage is that any altcoin looking to implement Counterparty support would need to have this feature (or, fork and extend the Counterparty protocol to use a slightly different encoding method, such as multisig or something similar to Mastercoin's Class A transactions).

Currently, Peercoin is moving to 0.8.4 code I believe. Once SunnyKing syncs up to 0.9, this may be possible (however, there may still need to be some adjustment made to deal with the stake blocks that Peercoin has).

This all being said, we are interested in speaking to altcoin developers (and especially ones that can work with the OP_RETURN featureset) as this develops. Counterparty becomes stronger as its standards are deployed across multiple blockchains.

Finally proof of burn \o/

Gonna read all this more carefully

FLUX built on Link built on any coin is looking to do this as well. Only for abstract trades and barter schemes as well.

We'll be glad to share ideas.

Relevant threads:
LINK:
http://forum.feathercoin.com/index.php/topic,5558.0.html
http://forum.feathercoin.com/index.php/topic,6518.0.html

FLUX:
http://forum.feathercoin.com/index.php/topic,6185.0.html
http://forum.feathercoin.com/index.php/topic,6407.0.html
http://forum.feathercoin.com/index.php/topic,6552.0.html