does anyone know if publishing a feed has an xcp cost?
It has none.
Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 341. (Read 1276823 times)
March 29, 2014, 04:21:46 PM
It has none.
March 29, 2014, 04:20:07 PM
does anyone know if publishing a feed has an xcp cost?
March 29, 2014, 03:39:20 PM
AuroroCoin attacked:
https://bitcointalksearch.org/topic/delete-546338
Just a cautionary note about moving to other PoW chains with low hash rate.
https://bitcointalksearch.org/topic/delete-546338
Just a cautionary note about moving to other PoW chains with low hash rate.
March 29, 2014, 02:49:52 PM
"magical distributed thingy"
Well, that explains the reaction I recently received on IRC.
Nevertheless, the focus was on "storing data outside of the blockchain" and I mentioned DHTs only as one way to do it (or not to do it). Are you dismissing this concept as a whole?
Asking "why Bitcoin instead of X" is actually a good question.
March 29, 2014, 02:41:28 PM
Peter, I'm not sure what DHT and OP_RETURN have to do with side chains.
March 29, 2014, 02:04:55 PM
Cross-post from Counterparty forums: https://forums.counterparty.co/index.php/topic,208
Please keep the discussion of this topic on that thread.
Please keep the discussion of this topic on that thread.
March 29, 2014, 01:20:39 PM
An interesting introduction to the Chord and Kademilia algorithms is by a bitcoin developer here: http://offthelip.org/?p=149
Hey, thanks for the link. I read a few wikipedia articles, the BitTorrent things and searched the forum + mailing list, nothing really worth to share though. I heard Mike Hearn recommended TomP2P and if you are looking for an easy implementation in Python or C#, there you go.
Edit: FreePasteryTutorial might be worth to look at, too.It's worth searching through the #bitcoin-dev and #bitcoin-wizards irc logs for "DHT" - the Bitcoin development community considers them a joke for anything requiring security against adversaries, or even just good reliability in general:
You know, an interesting question to ask yourself is if it's totally ok to just embed a hash of the actual data in the blockchain, and rely on the data itself being made available by some DHT or something, why can't Bitcoin itself do that to make blocks smaller and improve scalability?
Remember that Bitcoin would work just fine if miners didn't validate transactions if clients implemented client-side validation, as is done in Mastercoin and Counterparty, and to a lesser extent, Colored Coins. What's so special about actually putting those tx's in the block?
Remember that Bitcoin would work just fine if miners didn't validate transactions if clients implemented client-side validation, as is done in Mastercoin and Counterparty, and to a lesser extent, Colored Coins. What's so special about actually putting those tx's in the block?
Availability of all messages to reconstruct the latest state, right? At least that's the problem I see. To a lesser extend: each client must have at least access to the full chain of all transactions that involves one of his wallets to reconstruct his final balance and this is not necessarily given by a DHT. Altering of messages could be avoided, if OP_RETURN hash == key == H(message).
Despite that, I'm still fascinated by the idea of on overnet, slightly related: if there were a mechanism of easy communication, people could send around CoinJoin transactions, establish channels for micropayments or open a communication line for multisig signing in general.
And not just availability, but guaranteed availability with specific time limits. Basically, in a financial application it's not good enough to just have the message eventually get to the desired recipients - you need it to be guaranteed (with high probability) to either get to them in a certain amount of time or for the message to be considered invalid. (and detectably so) Blockchains due this because they're a genuine proof that messages were published, side-chains don't.
That said, if you're just trying to, say, make a decentralized mailing list or something with good anti-censorship properties side-chains are probably just fine as you can always have the user's client handle censorship reactively, e.g. by retrying the message. Having a fallback to insert-in-blockchain available as a last resort is good too, and may discourage censors from trying in the first place. But Counterparty, Mastercoin, and Colored Coins are all financial applications and need much better censorship resistance and time guarantees than that.
March 29, 2014, 01:03:19 PM
how do i fund the wallet on testnet?
This is the easiest way to fund a testnet wallet. After the bitcoins arrive you can burn them for test XCP.
https://tpfaucet.appspot.com/
March 29, 2014, 12:28:32 PM
Here's in case you wanted to take the conversation on the topic of OP_RETURN, Counterparty and what should and should not be allowed on the blockchain to a wider audience.
https://bitcointalksearch.org/topic/are-stagnation-and-a-hostility-to-innovation-bitcoins-greatest-threats-543181
https://bitcointalksearch.org/topic/are-stagnation-and-a-hostility-to-innovation-bitcoins-greatest-threats-543181
Realistically, I don't think this is going to help at this stage.
I agree.
what do you think will?
Your mom, if she can code.
Moving to Dogecoin
Bellebite the troll has been on my ignore list for weeks, so to make sure I am not getting his filth on my screen. I suggest doing the same
March 29, 2014, 11:40:39 AM
An interesting introduction to the Chord and Kademilia algorithms is by a bitcoin developer here: http://offthelip.org/?p=149
Hey, thanks for the link. I read a few wikipedia articles, the BitTorrent things and searched the forum + mailing list, nothing really worth to share though. I heard Mike Hearn recommended TomP2P and if you are looking for an easy implementation in Python or C#, there you go.
Edit: FreePasteryTutorial might be worth to look at, too.You know, an interesting question to ask yourself is if it's totally ok to just embed a hash of the actual data in the blockchain, and rely on the data itself being made available by some DHT or something, why can't Bitcoin itself do that to make blocks smaller and improve scalability?
Remember that Bitcoin would work just fine if miners didn't validate transactions if clients implemented client-side validation, as is done in Mastercoin and Counterparty, and to a lesser extent, Colored Coins. What's so special about actually putting those tx's in the block?
Remember that Bitcoin would work just fine if miners didn't validate transactions if clients implemented client-side validation, as is done in Mastercoin and Counterparty, and to a lesser extent, Colored Coins. What's so special about actually putting those tx's in the block?
Availability of all messages to reconstruct the latest state, right? At least that's the problem I see. To a lesser extend: each client must have at least access to the full chain of all transactions that involves one of his wallets to reconstruct his final balance and this is not necessarily given by a DHT. Altering of messages could be avoided, if OP_RETURN hash == key == H(message).
Despite that, I'm still fascinated by the idea of on overnet, slightly related: if there were a mechanism of easy communication, people could send around CoinJoin transactions, establish channels for micropayments or open a communication line for multisig signing in general.
March 29, 2014, 11:34:48 AM
OP_RETURN can be used to store references to external resources, say for example very long meta transactions that don't fit into 40 byte, an asset contract or whatever. The storage pointed to could be a website which lists something like (for the sake of an example), a side chain or a P2P structure like a DHT. To my knowledge this was discussed several times, but never tested on a broader scale.
You know, an interesting question to ask yourself is if it's totally ok to just embed a hash of the actual data in the blockchain, and rely on the data itself being made available by some DHT or something, why can't Bitcoin itself do that to make blocks smaller and improve scalability?
Remember that Bitcoin would work just fine if miners didn't validate transactions if clients implemented client-side validation, as is done in Mastercoin and Counterparty, and to a lesser extent, Colored Coins. What's so special about actually putting those tx's in the block?
+1000 awesome point.
Agreed. An excellent point. Thank you Peter.
March 29, 2014, 11:25:58 AM
I think the current price is still a bit high until the open of web wallet.
in the old days (1990s) VCs in the valley used to value companies at $1m per developer, given inflation, I would say that the price is a bit undervalued at this stage.
I would say the valuation should be somewhere in the $10M range and not higher. The lower amount partially b/c this is a decentralized effort with no real business development people to actually engage partners - as you can see from the recent shitstorm with LukeJr.
if this actually had a CEO type and some Head of BizDev, LukeJr and the rest of the Bitcoin dev team would have been treated in a more partner oriented fashion rather than devolving into monkey's throwing poo at each other.
March 29, 2014, 10:55:46 AM
I think the current price is still a bit high until the open of web wallet.
March 29, 2014, 10:05:59 AM
So at the end of the price is a good time to buy, at the end of the price also can invest!
Good luck.
Smiley Smiley
Good luck.
Smiley Smiley
March 29, 2014, 10:04:39 AM
Seems like the core devs have to assume a future in which there are very few full nodes running compared to the number of transactions. Having tech savvy people downloading the full blockchain supporting the network can't be the future of bitcoin. Possibly, there needs to be a solution where light wallets can support the network without requiring the full blockchain.
I'd like a unicorn too, please.
I'm not knowledgeable enough to argue this with you. But it seemed that Peter Todd, and the Electrum guy talked about some streamlining possibilities.
If there's no incentive for full nodes outside of mining, and development, then I think you either have to imagine that in the future there won't be many full nodes, or else something has to be done to create that incentive.
i came across this magic pixie dust that solves problems like this
https://www.youtube.com/watch?v=3nbEeU2dRBg
March 29, 2014, 09:53:30 AM
Seems like the core devs have to assume a future in which there are very few full nodes running compared to the number of transactions. Having tech savvy people downloading the full blockchain supporting the network can't be the future of bitcoin. Possibly, there needs to be a solution where light wallets can support the network without requiring the full blockchain.
I'd like a unicorn too, please.
I'm not knowledgeable enough to argue this with you. But it seemed that Peter Todd, and the Electrum guy talked about some streamlining possibilities.
If there's no incentive for full nodes outside of mining, and development, then I think you either have to imagine that in the future there won't be many full nodes, or else something has to be done to create that incentive.
March 29, 2014, 09:48:13 AM
xnova has done a wonderful job developing Counterwallet,thanks very much!
March 29, 2014, 09:27:35 AM
Interesting discussion. It seems the OP_RETURN argument is not really about CounterParty. The problem the core devs have with the datasize of a CounterParty transaction is part of a deeper problem. Removing the CounterParty transactions to a sidechain doesn't solve the core problem. If Satoshi dice could cause these issues unknowingly, then it seems that down-the-line malicious(or otherwise) spam will cause huge problems.
Seems like the core devs have to assume a future in which there are very few full nodes running compared to the number of transactions. Having tech savvy people downloading the full blockchain supporting the network can't be the future of bitcoin. Possibly, there needs to be a solution where light wallets can support the network without requiring the full blockchain. Very good posts from atweiden.
Seems like the core devs have to assume a future in which there are very few full nodes running compared to the number of transactions. Having tech savvy people downloading the full blockchain supporting the network can't be the future of bitcoin. Possibly, there needs to be a solution where light wallets can support the network without requiring the full blockchain. Very good posts from atweiden.
March 29, 2014, 09:16:59 AM
I'm helping the Ethereum, Mastercoin and BitAngels folks with the hackathon at the Toronto conference
http://www.hackathon.io/events/1984/
If this community is interested in sponsoring this hackathon...
https://docs.google.com/document/d/1a1Ld_HlV8xiUseUDEozKDQmSCIRhDgW43uuWV9dTmHY/edit
If we want to do a separate fund for an XCP "prize"...
You all would need to give the funds to someone anonymous and the winners and judging can be public via that website.
http://www.hackathon.io/events/1984/
If this community is interested in sponsoring this hackathon...
https://docs.google.com/document/d/1a1Ld_HlV8xiUseUDEozKDQmSCIRhDgW43uuWV9dTmHY/edit
If we want to do a separate fund for an XCP "prize"...
You all would need to give the funds to someone anonymous and the winners and judging can be public via that website.
March 29, 2014, 09:02:36 AM
Thank you for such a good site
It is very comprehensive and very safe, I trade a lot inside!
With Bitcoin ban looming over China I think bter just got alot more risky. I wouldnt leave any coins laying around there!
Why? There is no sign that the Chinese government would confiscate the coins on bter. In which way would it be dangerous?!
China won't confiscate all the coins in China.
Yes, China would ban the bank taking part in coin exchange . But I think the btc is belong to the whole world, not the China.
I don't care about whether China ban the btc.
Don't care.
And , as a Chinese, I would like the China ban the btc . I think it is good for BTC.
Do you think so ?
Jump to: