Post
Topic
Board Pools
Re: [6600Th] Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB (New Thread)
by
Luke-Jr
on 08/09/2014, 23:14:03 UTC
Personally, I question the "social agreement/contract" aspect.  To me, the software/code is the entirety of the contract.  That is kind of the whole point of a decentralized, trustless, electronic currency.  The rules are stated in the code, and enforced by the code.  Any transaction that meets the rules of the Bitcoin code is a valid Bitcoin transaction, by definition.
This is true, but being a valid transaction does not imply a right to be stored by every Bitcoin node forever, be mined by every Bitcoin miner, or be relayed by every p2p node.
Every node has the right to decide for himself what he wants to relay.
Every miner has the right to decide for himself what he wants to mine.

It is also impossible to mine every possible transaction: doing so means inherently unbounded storage requirements by every Bitcoin user.
This is why human miners are charged with the responsibility of filtering out spam.

Yes, so, how do you filter out spam, given how easy it is to obfuscate arbitrary data using any number of options?  The only real way to do this (and the one that has already been chosen) is by implementing a transaction fee to make such spam efforts expensive in relation to the benefit realized.
The transaction fee method has proven unreliable so far. Humans are chosen to do the job because we can react to changes in spam methods, unlike fixed algorithms which the humans behind spam will always find a method to bypass or workaround.

But if somebody wants to waste a good amount of money to have something stored in the blockchain, let 'em.
Why? "If somebody wants to waste a good amount of money to steal your heirloom, let 'em." (analogously equivalent) doesn't sound like an appropriate answer.

This solution is both effective and simple.  If Eligius wanted to start including only transactions that include 10x the standardized fee, that would certainly block Mastercoin and Counterparty transactions.  I know that I have sent BTC transactions that have taken 12+ hours to be confirmed in a block because, even though they supposedly met the coin-age requirements needed to be fee-free according to the QT client (which did not even prompt me to add a fee), miners refused to include them in a block for that length of time.  And I was left to sit there and stew, and see my transaction as "unconfirmed" for half a day while I'm trying to send money to somebody.  So it seems that a LOT of pools have taken this action of only mining transactions with fees even when technically a fee is not required.
Miners are currently receiving a 25 BTC subsidy to try to encourage Bitcoin adoption.
While it is certainly true that we could all start demanding fees that cover the expense of mining and storing the transaction (probably higher than the 0.01 BTC/kB we originally started with), Bitcoin adoption is likely to suffer from that.
It seems to me a much better approach is trying to filter out the abuse and subsidize (only) the transactions that benefit Bitcoin.

Ok, so how do you determine who's consented to store XCP data?  How do you determine who's consented to store SatoshiDICE data?  The reality is that everyone who downloads the QT client (or other client that stores the entire blockchain) and who is concerned about such things and smart enough to understand them, must realize that the blockchain contains some stuff that they don't care about, or is irrelevant or even (to them) immoral.  But if they want to use Bitcoin and download the blockchain, they will receive the whole blockchain.
The blockchain has always been intended for financial data, and everyone who has it implicitly agrees to store it.
The same cannot be said of any non-financial data.

Not to mention that, if this is your main issue with Counterparty et al. then you need to implement something in bitcoind itself to block these transactions, because by not mining them in Eligius, they will still be mined by the other 95% of the network and still end up in the blockchain to be stored by all the QT users and full-node runners, including Eligius.  Not including them in Eligius blocks might be your way of taking a stand, but it's ineffective if your concern is the transactions showing up in the blockchain and forcing users to store them.
Miners are neglecting their job if they run mainline mining code.
It is intended to be a (technologically and politically conservative) example only, not used unmodified.
Unmodified use puts inappropriate authority in the development team that we do not want and, of course, neglects to perform the quality of filtering the network needs today.

Quote
Identification of spam in filtering is an independent matter from whether it is spam.
There are proposals for identification of valid hashes at least (look up P2SH2), but hopefully we won't have to use them...

I remember looking at the P2SH^2 stuff a couple of months ago when all of this was going down in the Counterparty thread, and it seems to me that it's a non-solution.  It's just a hash of a hash, right?  That doesn't prove that the first hash (which will still need to be published) is actually a hash.  The only way to prove that a hash(X) is actually a hash, is to provide the (X) that it's hashing.
The first hash doesn't need to be stored in the blockchain, only relayed to the miner.

Quote
And the Counterparty developers would certainly prefer for *everything* (except for valid escrow/m-of-n situations) to take place in OP_RETURN instead of being encoded in pubkeys or anywhere else.
Unfortunately, that did not seem to be the case in my experience. They were more worried about forcing the transactions on miners by hiding them. If there's been a change of heart since then, great. If Eligius isn't mining these properly-formed transactions, they should get in touch.

AFAIK, They were prepared to switch all XCP transactions to use exclusively the 80-byte OP_RETURN at the release of 0.9.0 which was supposed to implement it and which had implemented it in development code until a last-minute change to 40 bytes.  They had been following the development, knew about the 80-byte OP_RETURN and had based Counterparty development around using it exclusively.  When 0.9.0 was released with only 40 bytes of OP_RETURN, they were forced to continue with other alternatives, as not doing so would mean the end of Counterparty.  (Again, this is only AFAIK! I am not affiliated with the Counterparty team in any way, and I have not read the code, and there might be other situations where non-OP_RETURN data storage might have been used, but my recollection is that 80-byte OP_RETURN would have been used for the vast majority of Counterparty transactions.)
The 80/40 byte OP_RETURN is merely a matter of node-specific relay policy, and should not in any way affect how anyone implements their protocols, which should be done correctly, without regard for others' policies.
If people want to support these new protocol standards, they should adjust their policies accordingly.

Quote
This is solved by Bitcoin daughter-chain support - you would be able to pay Bitcoin transaction fees on a conceptual Counterparty blockchain and miners could collect on them.

That's awesome, is it supported now?  I could definitely see them moving to a daughter-chain if/when it is implemented.
No, it isn't yet. I wouldn't expect Counterparty to move to another blockchain until it is.

Quote
Lastly, I have to close with this.  As a supporter of Bitcoin, wouldn't you rather have this functionality (decentralized exchange; like a stock market for crypto-currencies and crypto-assets) exist on the Bitcoin blockchain and be a part of the Bitcoin ecosystem instead of having all of this functionality take place in NXT, BTSX, Ethereum, Ripple, etc. and leave Bitcoin in the dust as a simple/stupid currency-only?  Does the idea of this not excite you?  Think about displacing ALL of the corrupt stock exchanges in the world, with something provably fair and honest and decentralized!  This is what is going to happen, and what Counterparty and Mastercoin are trying to make happen on the Bitcoin blockchain, with Bitcoin as the common price denominator.  Wouldn't you rather be able to buy a share of Overstock directly with BTC instead of NXT, and to have that transaction immortalized in the Bitcoin blockchain instead of the NXT blockchain?  Wouldn't you like to see on the ticker "Shares of Overstock are trading at .05 BTC today" instead of USD, NXT, or some other currency?  Woudn't that strengthen and accelerate the growth and acceptance of Bitcoin to an incredible degree?  It's coming.  One way or another, it's coming.  Overstock is already in discussions with multiple crypto-asset projects, including Counterparty.  As a Bitcoin supporter, would you rather this future be "Built on Bitcoin" or built on something else? 
Stocks are inherently centralised, and cannot gain any direct benefit from being traded on a blockchain.
The stocks have value only because of recognition by the company (to pay dividends) or government (to enforce payment of dividends)
Therefore, the logical place to track the stocks is a centralised registry operated by the company, government, or someone they outsource it to.
Remember that centralisation is more efficient than decentralisation, so with the benefits of decentralisation eliminated, it doesn't make sense to incur the costs of decentralisation anymore.

That's certainly an interesting take, and one that I hadn't heard before.  You're right, of course, but I think you're looking at part of the picture.  The bigger part of the picture, to be sure, but a lot of interesting stuff is taking place at the smaller end of the picture.  I think a lot of the promise of decentralized stock-markets has to do with smaller companies and the high price of entry into a "real" stock exchange.  It's a way of crowd-funding that actually creates equity, unlike Kickstarter where a bunch of people gave money to the Oculus guys and a couple years down the road the Oculus guys sell to Facebook for $2Billion and the original Kickstarter backers get nothing.  There needs to be a way for this to happen, to bridge the gap between crowdfunding and equity.  Decentralized crypto-exchanges provide a good way to do it.  You're right, there's still a large amount of trust involved, but you could say the same thing about Kickstarter (and lots of Kickstarter projects have failed) but Kickstarter still manages to get projects funded.  Not to mention the numerous other crowd-funding sites out there.
There certainly seems to be a market for a usable "roll your own stock" system or service, but there's no reason to make it inefficient/decentralised.
I suspect part of the problem is that securities are highly regulated in some countries, and people have a misconception that decentralisation bypasses the law.
People who seriously want to support Bitcoin shouldn't encourage anything that would lead to illegal use of it, since that is only liable to harm Bitcoin.

Even within the Bitcoin space we have seen some applications for this.  I think it was Bitmain, but I might be wrong.  One of the Chinese ASIC makers.  The guy took in a bunch of funding, maintained a list of contributors, used the funding to manufacture a bunch of ASICs and sell them, and the original contributors were paid out the profits in BTC.  I think he was keeping his list of "shareholders" (in quotes because this was all an ad-hoc, extra-legal situation) on an Excel spreadsheet or something.  And if one of these "shareholders" wanted to sell their "shares" to another person, they would have to receive the BTC as payment, e-mail the dude and he would have to change their ownership in the spreadsheet.  A bunch of hassle, prone to error, prone to fraud.  I may have some of the details wrong, but it was all in a big thread here on bitcointalk.  Maybe you are familiar with it.  I think the whole thing is defunct now.
I hope it isn't defunct, because I am supposed to own some of those shares - just checking now, I notice I haven't received any dividends since 2013 Nov :|

In any case, all of this could have been handled in a lovely way by Counterparty.  Ownership tracking, dividend payments, a market for the "shares" where any owner/contributor could liquidate at any time.  (Of course Counterparty wasn't around at the time that this "shareholder" situation was created.)  But this is the kind of thing that a distributed crypto-exchange such as Counterparty is made for... small-ish companies, less than $1M or so in valuation, just "getting things done" and raising money and paying out dividends without a bunch of regulatory hoopla.  Of course, as you said, trust is needed.  But trust is really never in short supply (just look at all the scams that have been run on this forum) and it also happens that a lot of people are actually worthy of that trust.
Yes, and it could all have been handled by a centralised stock exchange better.
The real "coloured coin" use case is in smart property. Smiley

Quote
Honestly it amazes me to hear you suggest that any project should be "on their own blockchain".  What, and derail the work and the value that has been put into Bitcoin?  To someday possibly eclipse Bitcoin?  Of course as a Bitcoin developer, you can't go crazy and implement every weird idea that's come up in every altcoin out there (not that there are that many good ideas in the altcoin world).  Can't rock the boat too much, and you don't want to put anything untested into production.  Stability is definitely the core concern at this point.  But adding new features and value to Bitcoin should also be a priority, and if third-parties are able to do this discretely and "on top of" Bitcoin without disturbing Bitcoin-per-se in any significant way, I think they should be encouraged.
I'm all for experimentation in general, which is why I don't buy into the "X should leave simply on the basis of it being not Bitcoin-unit denominated".
Daughter-chains should definitely help the situation by making any innovation possible within the Bitcoin framework.
Basically instead of a single blockchain, Bitcoin would now be comprised of any number of multiple blockchains, each with their own possibly-different set of rules.
So, when you want to try a new feature by Joe Random Developer, you just sent however many bitcoins you want to his blockchain.
If you decide you want to go back, you just send whatever you have left there back to the main blockchain (assuming his blockchain didn't allow you to get robbed of them, of course).
In the Counterparty example, you would occasionally fund your wallet on the Counterparty blockchain with bitcoins to spend on fees, and miners would be the ones bringing them back to the main blockchain when they mine your transaction.

Again, the daughter-chains idea sounds great, is it on the roadmap?
Adam Back and Austin Hill recently raised funds to develop it (they're forming a company named Blockstream).
I don't know how much of the company details are public at this time, so I'll just have to simply say they have a competent team to work on it.
(disclosure: I'm planning to do contracting work for Blockstream myself)