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

[BitThink]

Agree.

If marketing is a must, then please use a proper key. Something like 'welcome to test' rather than 'Issue your real asset here now.'

Moreover, as a financial software, we really need extensive unit tests, function tests and pass all tests on all platforms before releasing. In my opinion this testing position is at least as important as the marketing one.

[jimhsu]

Um.. I think a troll ate the order book:

http://blockscan.com/order.aspx?q=3336

I hereby submit a bug: Orders for BTC should check balance of address before submission.

[MoneypakTrader.com]

To the Dev/s:
The following counterpartyd protocol/CLI issues should be resolved:
1) Paying a 0.0001 BTC fee can wipe order -
FIX:
a) XCP for BTC offer should include an option/variable to limit block period for a matching order lock (lockperiod) and a failure to BTCpay in such time period should reinstate the temporarily locked offer (instead of canceling as it currently does)

After more careful examination, it looks like it will require .000372 to wipe the order book

But, that raises a more important FLAW IN THE PROTOCOL THAT WILL PREVENT MASS ADOPTION:
Bitcoin can be transferred with no fees. Sending XCP currently costs ~0.0002+ BTC !!!!!
A BTC/XCP DEX trade costs the BTC sender 0.0007+ BTC and the XCP sender 0.0003+ BTC
That's OVER $1 US in FEES to do a SINGLE trade!
WHERE DO ALL THOSE FEES GO?
WHY ARE THERE SO MANY FEES?

2) no BTCSend support outside of BTCPay
b) Improve: Allow counterpartyd BTCsend fromaddress toaddress BTC fee(optional/can use default)
c) Improve: Allow BTCSend and XCP at same time to an address
d) BONUS: Allow BTCSend to ASSET which divides the BTC among all asset holders similar to how XCP dividend should be distribued

3) Escrowed/Multisig Bitdust is unspendable in counterpartyd.
a) fix: allow spending such dust natively in counterpartyd

WHERE DO ALL THESE FEES GO???

4) MINOR: market display updates.
a) Reorganize market CLI to display Feeds, then Bets, then Open Orders with BTC/XCP & XCP/BTC orders and Order matches awaiting BTCpay LAST in chart.
b) Update sorting open orders by asset exchange type first (XCP/BTC, etc.), then ratio second (subsorting inside the different types). i.e. force XCP/BTC BTC/XCP last in chart for easier viewing.

5) Regarding Major Program/Protocol revisions: Please don't change significant aspects of the protocol (such as asset fees) without consulting stakeholders.
Specifically In Re: Asset creation fees: Where does this new fee go? Ideally it would be either extinguished (to the burn address) or distributed among all XCP stakeholders.

Someone please link to a description of Where all these mandatory fees go?? This is crazy, there was not supposed to be MORE fees than standard BTC transactions. . . This makes it practically unusable, $1 to trade BTC/XCP on DEX!!!!

To Blockscan:
ONLY trades that have received BTCpay should be included, but it's not so important for now.

Crossposted to my own thread:

We have enabled a simple DEX trading option/platform to expand people's options and hopefully gain that market share (of allowing non-technical bitcoin holders to invest in or send XCP/DEX). This is an innovative and unique service similar to our MP/BTC trading services. Anyone with the private key for their BTC address can buy XCP/MPTSTOCK by sending BTC to our specified address (see our forum thread or website). We then spend the BTC on the DEX to buy XCP/MPTSTOCK which is sent (minus 10% commission) to the Buyer's address.
Essentially - Anyone can buy XCP/DEX Assets by sending bitcoins from their bitcoin client to our current XCP buy address (shown on both our site and our bitcointalk thread for redundancy). This will work for any client/address which the buyer has the private key for (pretty much all BTC clients except exchange accounts).
When our messenger (TC and/or FB) shows green, this service is available for rapid processing at a premium. Otherwise, our goal is to process all such transactions within 24-48 hrs. Frequency of trades will depend on volume of submitted orders.

THANKS to all the Dev's!

+1
[/quote]

[cityglut]

Where do you get $1 in fees from?

Seller posts order: Cost = 0.0001 BTC
Buyer matches order: Cost = 0.0001 BTC + whatever the fee required to match is
Buyer sends BTCPay: Cost = 0.0001 BTC

Yes. Depending on the type of transaction, a Counterparty transaction should cost between .0001 and .0004 BTC.

[MoneypakTrader.com]

Where do you get $1 in fees from?

Seller posts order: Cost = 0.0001 BTC
Buyer matches order: Cost = 0.0001 BTC + whatever the fee required to match is
Buyer sends BTCPay: Cost = 0.0001 BTC

Please link to the blockchain transaction to support each of those:
for the most recent transactions:
XCP offered:
https://blockchain.info/tx/b844cf1b76237b48bb156c14ad9145c073ec812ab6388a8d33a2d296cbafc83d
EXTRA FEES COST: 0.0003172 BTC ~$0.3

BTC offered:
https://blockchain.info/tx/5ab38cd0b172d3d93e5f8d5cde3f3222ec45818e8bf9d4c3550c30be7844c12b
EXTRA FEES COST: 0.0003172 BTC ~$0.3

BTCpay:
https://blockchain.info/tx/f0cb991676f41fb3e71bdf568ee298e677f97a70b046d557d2674f52cef41419
EXTRA FEES COST: 0.0004258 BTC ~$0.4

total fees for BTC/XCP DEX trade ~$1

[MoneypakTrader.com]

Where do you get $1 in fees from?

Seller posts order: Cost = 0.0001 BTC
Buyer matches order: Cost = 0.0001 BTC + whatever the fee required to match is
Buyer sends BTCPay: Cost = 0.0001 BTC

Yes. Depending on the type of transaction, a Counterparty transaction should cost between .0001 and .0004 BTC.

It should cost 0, the burn was a little strange requiring 0.0001 BTC Transaction fee and it just gets worse now in the system with all these so far unexplained fees

[jimhsu]

Where do you get $1 in fees from?

Seller posts order: Cost = 0.0001 BTC
Buyer matches order: Cost = 0.0001 BTC + whatever the fee required to match is
Buyer sends BTCPay: Cost = 0.0001 BTC

Yes. Depending on the type of transaction, a Counterparty transaction should cost between .0001 and .0004 BTC.

It should cost 0, the burn was a little strange requiring 0.0001 BTC Transaction fee and it just gets worse now in the system with all these so far unexplained fees

The ultimate objective is to transition to OP_RETURN (which works already on testnet) when Bitcoin 0.9 comes around, so this this "dust" no longer remains.

[BitThink]

Where do you get $1 in fees from?

Seller posts order: Cost = 0.0001 BTC
Buyer matches order: Cost = 0.0001 BTC + whatever the fee required to match is
Buyer sends BTCPay: Cost = 0.0001 BTC

Yes. Depending on the type of transaction, a Counterparty transaction should cost between .0001 and .0004 BTC.

It should cost 0, the burn was a little strange requiring 0.0001 BTC Transaction fee and it just gets worse now in the system with all these so far unexplained fees

Those are all anti dust trades requirement. Zero cost means your transaction will never be included in a block. Fees will be  lower once op-return is supported. Multisig used now costs more.

[PhantomPhreak]

Um.. I think a troll ate the order book:

http://blockscan.com/order.aspx?q=3336

I hereby submit a bug: Orders for BTC should check balance of address before submission.

If you don't want your orders to sell XCP for BTC to get eaten, then you need to set a higher fee_required. Note that only orders to buy BTC have this issue, and there's no way around it that I can think of.

The problem with that, besides the fact that it kind of misses the point, is that Bitcoind cannot look up the balance of an arbitrary address.

[jimhsu]

Where do you get $1 in fees from?

Seller posts order: Cost = 0.0001 BTC
Buyer matches order: Cost = 0.0001 BTC + whatever the fee required to match is
Buyer sends BTCPay: Cost = 0.0001 BTC

Yes. Depending on the type of transaction, a Counterparty transaction should cost between .0001 and .0004 BTC.

It should cost 0, the burn was a little strange requiring 0.0001 BTC Transaction fee and it just gets worse now in the system with all these so far unexplained fees

Each bitcoin transaction requires a 0.0001 BTC fee paid to the mining network. Perhaps you have been using an online wallet such as Coinbase that pays these fees for you so you don't see them?

The 0.0001086 BTC values in XCP transactions are put into a 1 of M Multisig escrow which you are theoretically able to spend. Currently I'm not sure which, if any, wallet clients support spending of Multisig outputs, but if you really wanted to you could craft a raw transaction to spend them today (not recommended)

Hopefully counterpartyd will support spending of these outputs natively at some point.

Here is more detail: https://bitcointalk.org/index.php?topic=287063.20

So basically:
1) No, your 0.0001086 bitcoins are not gone.
2) No client currently offers the ability to spend them. Multisig is still a fairly new idea. One might in the future.

[MoneypakTrader.com]

Each bitcoin transaction requires a 0.0001 BTC fee paid to the mining network.

wrong:
https://blockchain.info/block-index/465919/00000000000000006e1a275bff2757913c4513c7e361ccb19ee6f2734ba1e8f1
click advanced at bottom, and starting at bottom of page you will see MANY bitcoin transactions with NO FEE, AKA 0 FEE.

The 0.0001086 BTC values in XCP transactions are put into a 1 of M Multisig escrow which you are theoretically able to spend. Currently I'm not sure which, if any, wallet clients support spending of Multisig outputs, but if you really wanted to you could craft a raw transaction to spend them today (not recommended)
Hopefully counterpartyd will support spending of these outputs natively at some point.

Currently they are spent and at some point in the future, it is theoretical that we may get them back.
On my balance statement I can only mark it as an expense for now.

[PhantomPhreak]

Where do you get $1 in fees from?

Seller posts order: Cost = 0.0001 BTC
Buyer matches order: Cost = 0.0001 BTC + whatever the fee required to match is
Buyer sends BTCPay: Cost = 0.0001 BTC

Yes. Depending on the type of transaction, a Counterparty transaction should cost between .0001 and .0004 BTC.

It should cost 0, the burn was a little strange requiring 0.0001 BTC Transaction fee and it just gets worse now in the system with all these so far unexplained fees

Each bitcoin transaction requires a 0.0001 BTC fee paid to the mining network. Perhaps you have been using an online wallet such as Coinbase that pays these fees for you so you don't see them?

The 0.0001086 BTC values in XCP transactions are put into a 1 of M Multisig escrow which you are theoretically able to spend. Currently I'm not sure which, if any, wallet clients support spending of Multisig outputs, but if you really wanted to you could craft a raw transaction to spend them today (not recommended)

Hopefully counterpartyd will support spending of these outputs natively at some point.

Here is more detail: https://bitcointalk.org/index.php?topic=287063.20

So basically:
1) No, your 0.0001086 bitcoins are not gone.
2) No client currently offers the ability to spend them. Multisig is still a fairly new idea. One might in the future.

This is worth emphasizing.

Also worth emphasizing is that it is quite likely that no blockchain-based technology will ever be used for HFT or for trades of a very small size... it's simply not very efficient to send every message everywhere.

[PhantomPhreak]

Can we already make CFD?

I am thinking that the possibility of shorting altcoins would be very interesting!

I think there is huge demand which is not fullfill by the market right know and that could be the killer app of the protocol.

Yes CFDs are currently implemented.

Would you like to test them out? The test Super Bowl bet between me and jimhsu patched a few bugs. If someone comes up with interesting terms for a short-term bet, I'm up for taking the other side.

I think probably the killer use case for CFDs is being able to short XCP/USD. This would essentially allow you to keep your wealth in XCP but have no exposure to XCP price fluctuations.

Sorry I can't, I haven't install counterpartyd yet, I am waiting the GUI.

I don't think a lot of people will be ready to keep their wealth in XCP, but for those who want to keep it in BTC (which makes quite a lot of people) be able to short BTC/USD would be indeed a revolutionary perspective.

The problem with shorting BTC/USD though is that you can only bet using XCP. So you are left with XCP/BTC exposure.

You can bet on the price of BTC/USD, and if you do nothing else, then you'll also have exposure to the price of XCP. However, with a second bet, or a different first bet, a fall in that too can be hedged against.

[jimhsu]

Um.. I think a troll ate the order book:

http://blockscan.com/order.aspx?q=3336

I hereby submit a bug: Orders for BTC should check balance of address before submission.

If you don't want your orders to sell XCP for BTC to get eaten, then you need to set a higher fee_required. Note that only orders to buy BTC have this issue, and there's no way around it that I can think of.

The problem with that, besides the fact that it kind of misses the point, is that Bitcoind cannot look up the balance of an arbitrary address.

Surely though since counterparty can issue "lib.exceptions.BalanceError: Insufficient bitcoins at address" errors, that means it's possible to check locally if the person selling BTC actually has that much to sell (just as a sanity check)? I'm not worried about the balance in remote addresses. That doesn't fix "order hogging", but it's a sanity check.

[jimhsu]

Um.. I think a troll ate the order book:

http://blockscan.com/order.aspx?q=3336

I hereby submit a bug: Orders for BTC should check balance of address before submission.

If you don't want your orders to sell XCP for BTC to get eaten, then you need to set a higher fee_required. Note that only orders to buy BTC have this issue, and there's no way around it that I can think of.

The problem with that, besides the fact that it kind of misses the point, is that Bitcoind cannot look up the balance of an arbitrary address.

Surely though since counterparty can issue "lib.exceptions.BalanceError: Insufficient bitcoins at address" errors, that means it's possible to check locally if the person selling BTC actually has that much to sell (just as a sanity check)? I'm not worried about the balance in remote addresses.

But that's a client-side check. Anyone can craft their own raw transaction to get around that.

EDIT: Although I agree that having this client-side check would at least discourage most people from sweeping the book, as well as unintentionally trying to sell BTC they don't have

+1, I think the people who want to try to sweep the order book and the people who know how to craft a raw transaction are pretty mutually exclusive.

[MoneypakTrader.com]

If you don't want your orders to sell XCP for BTC to get eaten, then you need to set a higher fee_required. Note that only orders to buy BTC have this issue, and there's no way around it that I can think of.

Maybe someone else can think of something. . .

To the Dev/s:
The following counterpartyd protocol/CLI issues should be resolved:
FIX:
a) XCP for BTC offer should include an option/variable to limit block period for a matching order lock (lockperiod) and a failure to BTCpay in such time period should reinstate the temporarily locked offer (instead of canceling as it currently does)

This would prevent total wiping and make it temporary at best (10 blocks ~ 90 minutes, shorter for greater persistence).
many other options, but this resolves multiple issues at once.

My point IN RE FEES, is there should be NO FEES outside of OPTIONAL transaction fees if people choose to pay them, thus allowing XCP to be more usable.

Each bitcoin transaction requires a 0.0001 BTC fee paid to the mining network.

wrong:
https://blockchain.info/block-index/465919/00000000000000006e1a275bff2757913c4513c7e361ccb19ee6f2734ba1e8f1
click advanced at bottom, and starting at bottom of page you will see MANY bitcoin transactions with NO FEE, AKA 0 FEE.

The 0.0001086 BTC values in XCP transactions are put into a 1 of M Multisig escrow which you are theoretically able to spend. Currently I'm not sure which, if any, wallet clients support spending of Multisig outputs, but if you really wanted to you could craft a raw transaction to spend them today (not recommended)
Hopefully counterpartyd will support spending of these outputs natively at some point.

Currently they are spent and at some point in the future, it is theoretical that we may get them back.
On my balance statement I can only mark it as an expense for now.

2) no BTCSend support outside of BTCPay
b) Improve: Allow counterpartyd BTCsend fromaddress toaddress BTC fee(optional/can use default)
c) Improve: Allow BTCSend and XCP at same time to an address
d) BONUS: Allow BTCSend to ASSET which divides the BTC among all asset holders similar to how XCP dividend should be distribued

3) Escrowed/Multisig Bitdust is unspendable in counterpartyd.
a) fix: allow spending such dust natively in counterpartyd

4) MINOR: market display updates.
a) Reorganize market CLI to display Feeds, then Bets, then Open Orders with BTC/XCP & XCP/BTC orders and Order matches awaiting BTCpay LAST in chart.
b) Update sorting open orders by asset exchange type first (XCP/BTC, etc.), then ratio second (subsorting inside the different types). i.e. force XCP/BTC BTC/XCP last in chart for easier viewing.

5) Regarding Major Program/Protocol revisions: Please don't change significant aspects of the protocol (such as asset fees) without consulting stakeholders.
Specifically In Re: Asset creation fees: Where does this new fee go? Ideally it would be either extinguished (to the burn address) or distributed among all XCP stakeholders.

Crossposted to my own thread:

We have enabled a simple DEX trading option/platform to expand people's options and hopefully gain that market share (of allowing non-technical bitcoin holders to invest in or send XCP/DEX). This is an innovative and unique service similar to our MP/BTC trading services. Anyone with the private key for their BTC address can buy XCP/MPTSTOCK by sending BTC to our specified address (see our forum thread or website). We then spend the BTC on the DEX to buy XCP/MPTSTOCK which is sent (minus 10% commission) to the Buyer's address.
Essentially - Anyone can buy XCP/DEX Assets by sending bitcoins from their bitcoin client to our current XCP buy address (shown on both our site and our bitcointalk thread for redundancy). This will work for any client/address which the buyer has the private key for (pretty much all BTC clients except exchange accounts).
When our messenger (TC and/or FB) shows green, this service is available for rapid processing at a premium. Otherwise, our goal is to process all such transactions within 24-48 hrs. Frequency of trades will depend on volume of submitted orders.

THANKS to all the Dev's!

It seems like these ideas are not under consideration, yes?

[PhantomPhreak]

Um.. I think a troll ate the order book:

http://blockscan.com/order.aspx?q=3336

I hereby submit a bug: Orders for BTC should check balance of address before submission.

If you don't want your orders to sell XCP for BTC to get eaten, then you need to set a higher fee_required. Note that only orders to buy BTC have this issue, and there's no way around it that I can think of.

The problem with that, besides the fact that it kind of misses the point, is that Bitcoind cannot look up the balance of an arbitrary address.

Surely though since counterparty can issue "lib.exceptions.BalanceError: Insufficient bitcoins at address" errors, that means it's possible to check locally if the person selling BTC actually has that much to sell (just as a sanity check)? I'm not worried about the balance in remote addresses.

But that's a client-side check. Anyone can craft their own raw transaction to get around that.

EDIT: Although I agree that having this client-side check would at least discourage most people from sweeping the book, as well as unintentionally trying to sell BTC they don't have

It could at most be a warning, because there's no reason that someone should not send to himself the bitcoins after he secures the order match he wants.

[PhantomPhreak]

Um.. I think a troll ate the order book:

http://blockscan.com/order.aspx?q=3336

I hereby submit a bug: Orders for BTC should check balance of address before submission.

If you don't want your orders to sell XCP for BTC to get eaten, then you need to set a higher fee_required. Note that only orders to buy BTC have this issue, and there's no way around it that I can think of.

The problem with that, besides the fact that it kind of misses the point, is that Bitcoind cannot look up the balance of an arbitrary address.

Surely though since counterparty can issue "lib.exceptions.BalanceError: Insufficient bitcoins at address" errors, that means it's possible to check locally if the person selling BTC actually has that much to sell (just as a sanity check)? I'm not worried about the balance in remote addresses.

But that's a client-side check. Anyone can craft their own raw transaction to get around that.

EDIT: Although I agree that having this client-side check would at least discourage most people from sweeping the book, as well as unintentionally trying to sell BTC they don't have

+1, I think the people who want to try to sweep the order book and the people who know how to craft a raw transaction are pretty mutually exclusive.

It's not even a question of crafting a raw transaction, but rather of deleting one line of Python code.

[jimhsu]

Um.. I think a troll ate the order book:

http://blockscan.com/order.aspx?q=3336

I hereby submit a bug: Orders for BTC should check balance of address before submission.

If you don't want your orders to sell XCP for BTC to get eaten, then you need to set a higher fee_required. Note that only orders to buy BTC have this issue, and there's no way around it that I can think of.

The problem with that, besides the fact that it kind of misses the point, is that Bitcoind cannot look up the balance of an arbitrary address.

Surely though since counterparty can issue "lib.exceptions.BalanceError: Insufficient bitcoins at address" errors, that means it's possible to check locally if the person selling BTC actually has that much to sell (just as a sanity check)? I'm not worried about the balance in remote addresses.

But that's a client-side check. Anyone can craft their own raw transaction to get around that.

EDIT: Although I agree that having this client-side check would at least discourage most people from sweeping the book, as well as unintentionally trying to sell BTC they don't have

+1, I think the people who want to try to sweep the order book and the people who know how to craft a raw transaction are pretty mutually exclusive.

It's not even a question of crafting a raw transaction, but rather of deleting one line of Python code.

Alright, you've made your point and I agree. How about moneypaktrader's suggestion though? A lockin period + the ability to reinstate orders automatically?

Also is fee_required / fee_provided deducted at the time of match, or btc payment? If the latter, then that approach is also useless, because someone could simply put an absurdly high fee and not intend to actually pay it.

This is kind of similar to the asset name issue we had a while back...

[MoneypakTrader.com]

Another suggestion:
Require 1XCP to be escrowed for each order match beyond the first, which is returned on successful BTCpay, otherwise it goes to the person whose order was offline for the lockin period?
Thus a new BTC order must be submitted for EACH order to be wiped unless they escrow XCP

Edit: or even 0.01 XCP to be escrowed.
Obviously such a change should be implemented at a certain block number in future to allow people to prepare for the changeover.
Those are several of the glaring problems I see (order wiping, High fees, etc.).