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

Just FYI. The swarm guys are blaming counterparty bugs for not distributing their remaining swarm tokens: https://bitcointalksearch.org/topic/m.8676754

And at the bottom of the page here : http://swarm.lefora.com/topic/4/Swarm-Vote-Two-ISSUE-BURN-HOLD?page=6

They don't reference a specific bug, but instead just post a link to ALL the known bugs in the counterparty software and say "this is the problem" Anyone care to comment?

Myth 13: Are there any risk that Bitcoin will build same features what Counterparty have to Bitcoin itself?

12 Myths about CounterpartyXCP

• http://www.scribd.com/doc/238520096/12-Myths-about-CounterpartyXCP
• http://coinedtalk.com/12-myths-about-counterpartyxcp/

Myth 1: Counterparty is just Bitcoin 2.0 marketing hype.

Myth 2: Counterparty’s internal currency, XCP, is just another alt-coin.

Myth 3: Counterparty is just another project where the developers want to get rich quick. They will just run away with the money.

Myth 4: Counterparty development is dead and nothing works yet.

Myth 5: Counterwallet stores your passphrase and private keys on their servers!

Myth 7: If Bitcoin can be used in Counterparty, then XCP doesn’t have value.

Myth 8: I want to create a poll on the Blockchain, but Counterparty doesn’t have a voting feature.

Myth 9: You can’t store XCP or assets in cold storage. There is no 2FA!

Myth 10: Counterparty is polluting the Bitcoin blockchain with useless data and weighing down the network. This is a “free ride” on top of Satoshis hard work!

Myth 11: Counterparty is missing multi-sig support.

Myth 12: Broadcast feed betting is centralized.

Any news from Bittrex ?

mastercoin research that has to do with us.
Lowering tx fees greatly.
devs, how do we stand on this:

Hey all,

there was some discussion on GitHub related to OP_RETURN and transaction
costs. One point that was raised was the cost associated with output
amounts. While what has been said holds true, there are actually a few
options to save costs.

I'd like to share, and try.., a new "format":

https://i.imgur.com/hiZFZa7.png (overview)


Chancecoin demonstrated with several thousand transactions that both
output amounts as well as transaction costs can be cut significantly
without adopting a new encoding scheme, but simply by reducing output
amounts and fees.

I tracked over 2'100 transactions from broadcast to confirmation and
mapped most blocks to mining pools. It turns out that transactions with
output amounts as low as 0.00000780 BTC and transaction fees of 0.00001
BTC confirm within about 20 minutes on average while 85 %+ pools (in
terms of hash power/total network) are mining those transactions. This
includes GHash as well as DiscusFish.

The actual data can be found here:

https://docs.google.com/spreadsheets/d/1ELqeBlKKsze6Tya-Arh6HfoFcnV5CAtAObmhEb_wmSM/


TL;TR + conclusion:

Given that at least 75 % of all nodes are using Bitcoin Core v0.9+ and
about 85 % pools confirm ultra cheap transactions in general, I think
it's time to step back from the old "0.00006 BTC/packet rule" and adopt
output amounts of 0.00000546-0.00000882 BTC which are defacto default
and standard since Bitcoin core v0.9.

Furthermore it might be worth a try to cut down transaction fees from
0.0001 BTC/1000 byte to 0.00001 BTC/1000 byte transaciton size, given
the reasonable confirmation delay of about 20 minutes. The later should
not be enforced, but could be offered as an experimental option for
users who may choose cost savings over confirmation speed.


Cheers!




Previous discussions and further reading about this topic:

https://groups.google.com/a/mastercoin.org/d/msg/dev/w7WD3-pwXxg/9wyk22PP55kJ
(experiment with 250 transactions)

https://github.com/mastercoin-MSC/spec/issues/167#issuecomment-43417733
(initial post about low output amounts)

https://getaddr.bitnodes.io/dashboard/#user-agents (Bitcoin Core client
usage overview)

http://bitcoincore.org/smartfee/ (Gavin's smart fee estimates)

https://www.blocktrail.com/ (block explorer - unofficial API endpoint
/json/blockchain/block/:hash slowes down after a few hundred queries,
but remains very usable -- my favorite of the day! Just a matter of time
until all Exodus transactions are linked to blocks/pools..

Can Bitcoin developers kill Counterparty by changing the protocol? Theoretically? I like Counterparty, but a bit concerned on this issue.

That's right. It's pretty much impossible to prevent Counterparty from using Bitcoin, because of the many ways in which Counterparty can store data in the blockchain.

I proposed a block hash lottery on github, where few would win a lot. I think this would take advantage of the true potential of XCP escrow.

Happy to announce that BetXCP has an automatic BTC -> XCP Vendding machine, courtesy of the guys over at Vennd. Thanks Jeremy and Jonathan!

Vennding machine: http://betxcp.com/vennd

New BetXCP thread: https://bitcointalksearch.org/topic/betxcp-decentralized-sports-betting-vig-free-767510

I think it's a good thing that XCP is on Bitcoin, even if the blockchain may be somewhat hostile. In ViaCoin, there is a conflict of responsibility because the developers both maintain the blockchain and the the meta layer. The conflict of responsibility arises in that the blockchain developers must maintain as a priority the security of the blockchain. So in this sense of BTC vs XCP, it's healthy.

IMO when assessing a metacoin, people should assess the liquidity of the underlying blockchain as an indicator of potential success of the metacoin. The inflows into the metacoin will come almost exclusively via the blockchain it rides on. There isn't much point having a technological marvel which is in an isolated island.

In terms of technical features, it's great that Peter Todd has the funding to work on tree chains. If it proves to work well in ViaCoin, there is no reason why it won't be integrated into Bitcoin core.

If XCP used a more welcoming and suitable, less hostile blockchain, I'd pull that trigger so hard the truck would back itself up!  And I hate mixed metaphors.

Hi there.

I am trying to use vennd and when i start it it fails. So I ran the configuartion tester and it says:

"

"

I tried using 3 different versions of groovy but they all gave the same error.
I also checked the xcp and btc clients and connections, they all work fine as i have even issued a test asset with that wallet moments earlier.
I am using bitcoin and counterparty on testnet.

vennd is a key project for the counterparty ecosystem and so your help will be very appreciated.

BTC has strong incentives to prevent/penalize "parasitic" data in its un-prunable blockchain.