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

[bitcoinrocks]

Once the initial buy-in period is over, how will the price be determined?  Will a decentralized exchange be online then?

[1715672251]

1715672251

[1715672251]

1715672251

[1715672251]

1715672251

[1715672251]

1715672251

[1715672251]

1715672251

[porqupine]

.144 BTC a day would be quite high. Especially if BTC goes up another couple thousand, and supposing that you aren't receiving anything back in fees.

[wizzardTim]

Ok, I burned 0.01BTC. Transaction id: 089318e80783a93e15e4bdc7be922cc303a85f5045b942ffe05eb249c27ffaea

Now when I enter:

python run.py address 15prRGqRvQckN7dQjqA18H1uy4e1ruiBrh

I see that I have 14.41 XCP balance but after that I get a:

UnicodeEncodeError: 'charmap' codec cant encode character '\u2026'


Should I worry?


@devs: now I should wait for an hour to pass before I burn the whole BTC? Because I remember reading somewhere that there is only one valid transaction per address per hour.

[panonym]

Once the initial buy-in period is over, how will the price be determined?  Will a decentralized exchange be online then?

On testnet it is online and working.
On mainnet the code is the same and work if miner process OP_RETURN.
Good chance are all miner will process it with the upload to bitcoind v0.9.
This day it will be online and usable.

[PhantomPhreak]

Ok, I burned 0.01BTC. Transaction id: 089318e80783a93e15e4bdc7be922cc303a85f5045b942ffe05eb249c27ffaea

Now when I enter:

python run.py address 15prRGqRvQckN7dQjqA18H1uy4e1ruiBrh

I see that I have 14.41 XCP balance but after that I get a:

UnicodeEncodeError: 'charmap' codec cant encode character '\u2026'


Should I worry?


@devs: now I should wait for an hour to pass before I burn the whole BTC? Because I remember reading somewhere that there is only one valid transaction per address per hour.

You shouldn't worry, and you don't need to wait.

[cryptrol]

Once the initial buy-in period is over, how will the price be determined?  Will a decentralized exchange be online then?

On testnet it is online and working.
On mainnet the code is the same and work if miner process OP_RETURN.
Good chance are all miner will process it with the upload to bitcoind v0.9.
This day it will be online and usable.

TBH I have yet to see any authorized voice not speaking bad about this, so I wouldnt be so sure to see this finally implemented on .9 . I like this project and how it has been launched, but all this project and the BTC spent (burnt) depends on the implementation of a feature that may or may not appear on 0.9 and it is uncertain even when. I would like to have a more clear roadmap for this nice project.

[xibeijan]

Feeds
+------------------------------------+---------------------------+------------------+----------+----------------+
|            Feed Address            |         Timestamp         |       Text       |  Value   | Fee Multiplier |
+------------------------------------+---------------------------+------------------+----------+----------------+
| mt1N2qE4wHkjdDeumCtRg1NKwxXGMCAx5X | 2014-01-06T16:00:03+00:00 | CoinDesk BPI USD | 922.0817 |     0.0001     |
| mgYWm8Ug76czkAMSVNECJ31iEAGH5V9py1 | 2014-01-06T15:57:53+00:00 |      foobar      |   3.0    |       10       |
| n1TzSvnJRH4LUKA9j6qvCpiqc2yvxGKSmg | 2014-01-06T15:06:40+00:00 |      foobar      |  123.0   |      1E-7      |
| mq8srYuaPCrzk4mdKuz3168dxJQAQKv7Wo | 2014-01-05T02:06:34+00:00 |   Hello World    |   0.0    |      0.01      |
| mtQheFaSfWELRB2MyMBaiWjdDm6ux9Ezns | 2014-01-02T01:41:46+00:00 |      foobar      |   2.0    |     0.001      |
| mz8qzVaH8RaVp2Rq6m8D2dTiSFirhFf4th | 2014-01-02T01:04:17+00:00 |     <Locked>     |   0.0    |      0.01      |
| n3EHaCAycMEv6DhMPbrQsEubFsgtUmoin1 | 2014-01-01T13:16:05+00:00 |       Test       |   0.0    |    0.000001    |
+------------------------------------+---------------------------+------------------+----------+----------------+

So feeds shows us all feeds being "broadcast", rather than just the ones we care about?

The feeds listed first are those that have been most recently broadcast.

Won't this pose a risk to spamming?  For only 0.144 BTC /day you could spam the Feed list every minute and keep your spam visible on top.

As I wrote here, users will most likely determine which feeds they want to bet on with reference to a source outside of the blockchain. Spamming broacasts, then, will probably just cause this, which will happen naturally and of its own accord, to happen more quickly.

My question is not about trust (I understood your earlier post).  It's about whether the information being displayed is useful.

What I'm asking is that if this "Feed info window" has information (including spam) changing randomly every 10 minutes, then how useful is it to display it?

Feeds of interest will be selected from another source (e.g. a website or forum post), so perhaps it would be better use to show only the feeds a user is interested in (user configurable).  I don't know if that's possible, but just a suggestion.

Another solution could be to give feeds a feedback rating (as part of the system), then the "Feed window" could be sorted from highest to lowest feedback rating.  Feeds could obtain feedback by decentralised voting.

[wizzardTim]

Ok, I burned 0.01BTC. Transaction id: 089318e80783a93e15e4bdc7be922cc303a85f5045b942ffe05eb249c27ffaea

Now when I enter:

python run.py address 15prRGqRvQckN7dQjqA18H1uy4e1ruiBrh

I see that I have 14.41 XCP balance but after that I get a:

UnicodeEncodeError: 'charmap' codec cant encode character '\u2026'


Should I worry?


@devs: now I should wait for an hour to pass before I burn the whole BTC? Because I remember reading somewhere that there is only one valid transaction per address per hour.

You shouldn't worry, and you don't need to wait.

Thank you, sir.

[xibeijan]

.144 BTC a day would be quite high. Especially if BTC goes up another couple thousand, and supposing that you aren't receiving anything back in fees.

Ah, but you're forgetting that this is based on the min BTC TX fee.  If BTC goes up, then the min TX fee is adjusted down.  Thus, 0.XXX BTC day should be a reasonable, relatively constant amount hovering around $144 or $0.09 USD per feed post.  Perhaps, I've got it wrong though?

[xibeijan]

Once the initial buy-in period is over, how will the price be determined?  Will a decentralized exchange be online then?

On testnet it is online and working.
On mainnet the code is the same and work if miner process OP_RETURN.
Good chance are all miner will process it with the upload to bitcoind v0.9.
This day it will be online and usable.

TBH I have yet to see any authorized voice not speaking bad about this, so I wouldnt be so sure to see this finally implemented on .9 . I like this project and how it has been launched, but all this project and the BTC spent (burnt) depends on the implementation of a feature that may or may not appear on 0.9 and it is uncertain even when. I would like to have a more clear roadmap for this nice project.

Good point.  I am now feeling very nervous.

[panonym]

this project and the BTC spent (burnt) depends on the implementation of a feature that may or may not appear on 0.9 and it is uncertain even when.

It is a risk.
You block your money for a month, with the possibility to lose it.
Therefore the thought in some that the early reward in a bit tiny.
But it's true that one month isn't that long either.

Whatever.
Pretty sure OP_RETURN will be on v0.9, 'coz the block chain is getting messy and messier without it.
Good dev like clean thing.

In the worst case scenario, the proof of burn are still a record of investment.
That let the dev considering alternative development, with coin distribution according to burning.
It would rely on trust. But it would be a nice gesture of the dev, 'clearly possible.
Let's just hope everything goes smoothly =)

[xibeijan]

this project and the BTC spent (burnt) depends on the implementation of a feature that may or may not appear on 0.9 and it is uncertain even when.

It is a risk.
You block your money for a month, with the possibility to lose it.
Therefore the thought in some that the early reward in a bit tiny.
But it's true that one month isn't that long either.

Whatever.
Pretty sure OP_RETURN will be on v0.9, 'coz the block chain is getting messy and messier without it.
Good dev like clean thing.

In the worst case scenario, the proof of burn are still a record of investment.
That let the dev considering alternative development, with coin distribution according to burning.
It would rely on trust. But it would be a nice gesture of the dev, 'clearly possible.
Let's just hope everything goes smoothly =)

What happens if OP_RETURN is never added or there is something wrong with it or for some reason the bitcoin devs decide never to add it?  Then all the BTC burnt is as loss for investors.

[panonym]

Yes, but as written, the record of the burnproof is still existent.
Allowing a new distribution of a modified project. Without reburning.

It works on testnet. Most of recent project do not have that public.
If v0.9 isn't out in a month, it will be in 2.
Will see.

[xibeijan]

Here's patch for a few more issues I ran into

diff --git a/lib/bitcoin.py b/lib/bitcoin.py
index c61636b..6d8ed5e 100644
--- a/lib/bitcoin.py
+++ b/lib/bitcoin.py
@@ -111,7 +111,7 @@ def serialise (inputs, destination_output=None, data_output=None, change_output=
     # List of Inputs.
     for i in range(len(inputs)):
         txin = inputs
-        s += binascii.unhexlify(txin['txid'])[::-1]         # TxOutHash
+        s += binascii.unhexlify(bytes(txin['txid'], 'UTF-8'))[::-1]         # TxOutHash
         s += txin['vout'].to_bytes(4, byteorder='little')   # TxOutIndex
 
         # No signature.
diff --git a/lib/blocks.py b/lib/blocks.py
index 7a9985b..827a0d6 100644
--- a/lib/blocks.py
+++ b/lib/blocks.py
@@ -316,7 +316,7 @@ def get_tx_info (tx):
         if not data:
             asm = vout['scriptPubKey']['asm'].split(' ')
             if asm[0] == 'OP_RETURN' and len(asm) == 2:
-                data = binascii.unhexlify(asm[1])
+                data = binascii.unhexlify(bytes(asm[1], 'UTF-8'))
 
     # Only look for source if data were found (or destination is UNSPENDABLE), for speed.
     if not data and destination != config.UNSPENDABLE:
diff --git a/lib/btcpay.py b/lib/btcpay.py
index 7241c98..8a2501b 100644
--- a/lib/btcpay.py
+++ b/lib/btcpay.py
@@ -12,7 +12,7 @@ LENGTH = 32 + 32
 
 def create (db, order_match_id, test=False):
     tx0_hash, tx1_hash = order_match_id[:64], order_match_id[64:] # UTF‐8 encoding means that the indices are doubled.
-    tx0_hash_bytes, tx1_hash_bytes = binascii.unhexlify(tx0_hash), binascii.unhexlify(tx1_hash)
+    tx0_hash_bytes, tx1_hash_bytes = binascii.unhexlify(bytes(tx0_hash, 'UTF-8')), binascii.unhexlify(bytes(tx1_hash, 'UTF-8'))
     data = config.PREFIX + struct.pack(config.TXTYPE_FORMAT, ID)
     data += struct.pack(FORMAT, tx0_hash_bytes, tx1_hash_bytes)

[PhantomPhreak]

Here's patch for a few more issues I ran into

diff --git a/lib/bitcoin.py b/lib/bitcoin.py
index c61636b..6d8ed5e 100644
--- a/lib/bitcoin.py
+++ b/lib/bitcoin.py
@@ -111,7 +111,7 @@ def serialise (inputs, destination_output=None, data_output=None, change_output=
     # List of Inputs.
     for i in range(len(inputs)):
         txin = inputs
-        s += binascii.unhexlify(txin['txid'])[::-1]         # TxOutHash
+        s += binascii.unhexlify(bytes(txin['txid'], 'UTF-8'))[::-1]         # TxOutHash
         s += txin['vout'].to_bytes(4, byteorder='little')   # TxOutIndex
 
         # No signature.
diff --git a/lib/blocks.py b/lib/blocks.py
index 7a9985b..827a0d6 100644
--- a/lib/blocks.py
+++ b/lib/blocks.py
@@ -316,7 +316,7 @@ def get_tx_info (tx):
         if not data:
             asm = vout['scriptPubKey']['asm'].split(' ')
             if asm[0] == 'OP_RETURN' and len(asm) == 2:
-                data = binascii.unhexlify(asm[1])
+                data = binascii.unhexlify(bytes(asm[1], 'UTF-8'))
 
     # Only look for source if data were found (or destination is UNSPENDABLE), for speed.
     if not data and destination != config.UNSPENDABLE:
diff --git a/lib/btcpay.py b/lib/btcpay.py
index 7241c98..8a2501b 100644
--- a/lib/btcpay.py
+++ b/lib/btcpay.py
@@ -12,7 +12,7 @@ LENGTH = 32 + 32
 
 def create (db, order_match_id, test=False):
     tx0_hash, tx1_hash = order_match_id[:64], order_match_id[64:] # UTF‐8 encoding means that the indices are doubled.
-    tx0_hash_bytes, tx1_hash_bytes = binascii.unhexlify(tx0_hash), binascii.unhexlify(tx1_hash)
+    tx0_hash_bytes, tx1_hash_bytes = binascii.unhexlify(bytes(tx0_hash, 'UTF-8')), binascii.unhexlify(bytes(tx1_hash, 'UTF-8'))
     data = config.PREFIX + struct.pack(config.TXTYPE_FORMAT, ID)
     data += struct.pack(FORMAT, tx0_hash_bytes, tx1_hash_bytes)

Thanks, but I already fixed all that.

[xibeijan]

Oh, didn't notice on my last pull.... did you push?

[xnova]

Once the initial buy-in period is over, how will the price be determined?  Will a decentralized exchange be online then?

On testnet it is online and working.
On mainnet the code is the same and work if miner process OP_RETURN.
Good chance are all miner will process it with the upload to bitcoind v0.9.
This day it will be online and usable.

TBH I have yet to see any authorized voice not speaking bad about this, so I wouldnt be so sure to see this finally implemented on .9 . I like this project and how it has been launched, but all this project and the BTC spent (burnt) depends on the implementation of a feature that may or may not appear on 0.9 and it is uncertain even when. I would like to have a more clear roadmap for this nice project.

Good point.  I am now feeling very nervous.

Since OP_RETURN relay support is already merged into the upcoming 0.9 release, the probability of Gavin tearing it out is very remote. He even commented on it in his development update 5 (https://bitcoinfoundation.org/blog/?p=290), and PhantomPhreak has talked to him about the 0.9 release timeframe.

Also, from the conversation at the actual commit page, it seems the core dev team members there are fine with this change: https://github.com/bitcoin/bitcoin/pull/2738

I think, minimally,they see the value of having OP_RETURN over not having it, since there is a huge demand for this kind of feature, and using OP_RETURN is a much cleaner and less wasteful method, compared to other approaches. We are committed to accomplishing this effort in a way that plays as well with the blockchain as possible, which is why we are going for OP_RETURN (and looking into the announce/commit sacrifices item that Jeff Garzik mentioned).

However, worse case, if for some reason OP_RETURN relaying support is ripped out of 0.9, we will just resort to another method, such as multisig. It will not stop this project.

[xibeijan]

Can feeds or bets _automatically_ reference the price of an asset in open orders or last trade?

[Peter Todd]

We may need to switch to destroying coins by sending them to an unspendable address.

Ugh.  No.  That will simply bloat one of the network's key resources for all time.

See announce/commit sacrifices and other tools.

Frankly the Counterparty system is better off sticking with the unspendable address method. Unlike OP_RETURN it's standard now, it doesn't encourage centralization like announce-commit sacrifice-to-fees does, it keeps an even playing field and doesn't give discounts to big pools, it's way more convenient than sacrifice-to-fees, and finally it is good marketing.

You can complain all they want, but you have to accept that in a decentralized system full of anonymous participants asking people to act against their own interests for some vague greater good isn't going to be very successful.

[bitme]

There's a 1BTC limit per address mentioned in first post.Is it ok to burn more from another address in the same wallet?