Uh, there is development going on:
https://counterparty.io/news/counterparty-lib-9-55-2/

That link also contains a link to our slack chat which is the best way to stay up to date.

Nope they are totally differently things.

Offline (cold storage) wallet: here is one for ledger S -- https://github.com/mandelmonkey/ledger-cp

Main BCT thread: https://bitcointalk.org/index.php?topic=1617264.0

Check out all the links there and join the telegram group

Because, math and stuff... each card is a Counterparty asset (embedded into the Bitcoin blockchain).

Sure, you could save the image itself to your computer, but that doesn't mean you own the card.

http://Counterparty.io

EDIT: here is the asset info for Pepecash, for instance: http://blockscan.com/assetInfo/PEPECASH
(Click on AssetHolders to see which addresses own PEPECASH)

Blockscan.com is one of the Counterparty explorers.

The first time I saw HAIRPEPE was within a data dump, as I was trying to figure out how the network crashed. I think my initial reaction was wondering what the hell a "hair pepe" was.

IIRC, the parameters chosen for a HAIRPEPE order hit up on an obscure bug where the calculated integer value chosen for the order quantity was higher than the max integer value for sqllite, but equal to the max int value used in the python validation code (they differed by 1). Thus, the value was not further limited in the sanity check code, and  when the daemon was attempting to store the record in sqllite it caused an exception.... we now handle this situation in a way that should avoid this kind of issue in the future anywhere in the code.

Because of all of this, as well as the excellent artwork, today it is my favorite card. That hair...

No, since contract executions can modify a state shared across the nodes.

However, there are other options, like a side chain of some sort, that could be employed in the future.

EDIT: See https://github.com/CounterpartyXCP/Documentation/blob/master/Basics/FAQ-SmartContracts.md#can-payment-channels-be-used-with-the-evm

Also see: https://github.com/CounterpartyXCP/Documentation/blob/master/Basics/FAQ-SmartContracts.md#how-does-bitcoins-10-minute-block-time-affect-the-evm

Try not using MAX (use slightly less. MAX appears to be slightly off due to the new fee estimation code in the new release. We will get that fixed.)

The link is old, will fix/remove that too.

Blockscan is currently updating and is down. You can use counterpartychain.io until it is back up

Try now. I updated wallet.counterwallet.io ... the problem 90% probably an insufficient BTC error (i.e. you lack the BTC at the address to make the transaction, as CP transactions require BTC fees), but that error message was not coming through due to a bug that has been fixed.

Will need some more info to be able to troubleshoot. Can you join our slack and DM me on there (@robby-dermody)?

Hey guys, can you update the forums link for Counterparty to https://counterpartytalk.org ?

the first part is true (Bitcoin does not validate Counterparty transactions), but it doesn't follow that there is thus no record of consensus. counterparty keeps its own "ledger in a ledger" that it assembles from decoding Counterparty protocol data payloads from any Bitcoin transaction that contains them, using the reference client code at  https://github.com/CounterpartyXCP/counterparty-lib ,

it has been working well for over 2.5 years now

With regard to "tangible new developments" I think that was a valid view 6 months ago, but the project has been revitalized on several fronts. We have daily code commits on our github repos that outpaces most other crypto projects by a wide margin. In the last month, developments include:

* all the EVM work being done (almost live on testnet)... Faq at http://counterparty.io/docs/faq-smartcontracts/
* p2sh support added (https://github.com/CounterpartyXCP/counterparty-lib/pull/818)
* payment channels work (https://github.com/F483/picopayments) that will soon be merged in
* revamped docker based build system. Works on Linux, Windows and Mac OS. (http://counterparty.io/docs/federated_node/)
* numerous counterwallet updates (https://github.com/CounterpartyXCP/counterwallet/compare/1.7.0...master)
* revamped website (Chinese and Japanese translations in the works)
* Counterparty-lib test suite overhaul
* tons of bug fixes (eg https://github.com/CounterpartyXCP/counterparty-lib/commits/develop)

Feel free to join our slack and ask away/get involved, as well: http://slack.counterparty.io

Hi Shelby,

I've appreciated your posts here, especially as Anonymint in the Economics forum. To your points:


The first part is correct, but I would say the second is not, it's just different than PoW. As Counterparty works through embedded consensus, it essentially maintains its own ledger built off of Bitcoin transactions it scans that contain "valid" Counterparty data. By "valid", I mean data that is 1) a valid Bitcoin transaction that 2) has been validated against the consensus logic present in the Counterparty client. Consensus is established via nodes running the same consensus sensitive code. Thus, beyond identical, timestamped input data being provided (which Bitcoin accomplishes for us), the record of which transaction/ledger state is "valid" becomes a matter of establishing which consensus sensitive code is "valid". If nodes run different code, a fork can emerge, where the nodes' respective ledgers diverge.

So whereas with Bitcoin, "validity" is measured via the longest chain of proof-of-work (and by extension, which code is producing that chain), with Counterparty, it's measured on the specific code used, which produces transactions embedded within the longest Bitcoin chain. This is just how embedded consensus works. This may seem "light" when compared to other cryptocurrencies, but in reality I think "validity" of any Cryptocurrency ledger/protocol is ultimately determined by social consensus (e.g. witness Classic vs Core), it's just with PoW coins in particular, the technical forking dynamics are more explicit.

As it is, this model has worked well with Counterparty, and it has been functioning for over 2.5 years with almost 500K transactions on the network, and the embedded consensus approach offers benefits that allow us to adopt rapidly and add functionality with less consideration around the technical capabilities of the underlying ledger required than would be so if we had to add it more directly into the underlying ledger (e.g. Colored Coins).

As for your other points:

Not entirely sure what you mean here...A Counterparty broadcast message could be used to publish periodic data points from a data feed to the blockchain, which some kind of contract (e.g. EVM smart contracts, or otherwise, such as with the embedded binary options support in the protocol) can deterministically utilize to perform an operation. As for there being consensus about the actual data published by the feed, multisig could be utilized to require some level of consensus between multiple sources.


Counterparty today supports 0-confirmation transactions, but these transactions essentially shouldn't be trusted very much, due to the fact that they haven't been mined yet. The protocol builds the authoritative ledger off of mined transactions, validated in the order in which they are mined in a block. So 0-conf tx are not "absolutely impossible" in Counterparty, they are being done today. Similar to Bitcoin 0-conf transactions, one just cannot really trust them until they are mined.


As stated above, for any given block, Counterparty relies on the transaction ordering established by the miner that mined the block. So I would say that your point is valid when we are talking about examining unconfirmed operations, but if you consider if a contract were to look at a XCP balance of some address, for instance, it would essentially be depending on the ordering of transactions with >= 1 confirmation, which is fine.


I don't think blockchains were ever intended to be seen in the same way as a general purpose database server, with similar scalability. However, the implicit message is a valid one. As far as enhancing scalability, there are numerous options.

For instance, we are in the process of adding payment channels support, which should ultimately make use on Lightning Network possible. In addition, there is the option in the future of utilizing sidechains or some other mechanism, if it makes sense and has community support.

If Counterparty has proven anything, it's that it's a very flexible protocol with a pragmatic team at the helm. We are built on Bitcoin, but intend to investigate and potentially make use of any technical innovations to occur with it.

Yes

900 XMR

#8 - 0.57

#3 - 500 XMR

It's a fundamentally different approach. BTCRelay as I understand it allows validation of bitcoin transactions in Ethereum smart contracts. Counterparty executes the Ethereum smart contracts essentially as mainnet Bitcoin transactions. A smart contract execution, once kicked off, will execute within a single block (e.g. each instruction in the smart contract is not a Bitcoin transaction, or anything like that...they execute independently and modify the state of the Counterparty internal ledger, not Bitcoin).

Re: freezing, I'm not sure the amount of XCP frozen at any one time would be material to the total amount of XCP in existence. If that is not the case, then some "scale down" coefficient can be introduced that will reduce the amount of coins frozen for a given smart contract execution as the total # of coins frozen at any one time increases. Schemes like that do add complexity, however, and I'd like to avoid them if it's not deemed totally necessary, at least for a first pass.

Sure, they're not linked (that is more the theme with something like BTCRelay).

What we are working on is a port of the Ethereum Virtual Machine (EVM) to Counterparty. This means that one can take an ethereum smart contract (e.g. written in solidity) and run it "on Counterparty, on Bitcoin". There is no link to the Ethereum blockchain.

Counterparty works via a mechanism called embedded consensus, where we embed our protocol data within regular Bitcoin transactions, and maintain our own embedded ledger within Bitcoin's. Executions of Ethereum smart contracts would modify the state of this ledger.

See the announcement here: https://counterparty.io/news/proposal-for-ethereum-smart-contracts-on-counterparty-mainnet/

Feel free to join our slack channel to discuss. We'll also try to answer questions posted here as well.