Bitcoin Forum
April 21, 2019, 03:13:05 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 [285] 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 ... 658 »
  Print  
Author Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread  (Read 1254025 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
March 21, 2014, 03:50:26 AM
 #5681


I shudder at the horrible issues that using backup blockchains will create. Actually, I am having to do exactly this with my automated gateway and there are so many special cases, so many things that usually work but could go wrong. My gateway is just an application, a bug or exploit would be bad, but I am doing my best to contain any damages.

If XCP was spread across multiple blockchains, any problem could well be catastrophic. What happens if the other blockchain goes on a fork or even a blockchain rollback? Disaster.  Even having data in a different block in the same blockchain is a might big pain. It is all nice and tidy if everything needed to resolve the protocol is right there. This is why i suggested the compression approach. This is why the devs do not want to use any "pointers" to other blockchains regardless of how nice it sounds.

Im thinking more along the line of increasing redundancy with additional blockchains. Desaster would be the case if we relied on one blockchain only and something catastrophic happens to it, breaking XCP functionalities. Having copies of the same data in different places sounds like a good idea to me (Bonus points for added decentralization). On top of saving us from catastrophic failure, we also increase stability and reliability of the services XCP provides. After all its a tool for business and no business man wants to use something he cannot rely on. Otherwise risks would outweigh the benefits. We want to avoid that. Maybe I missunderstood your complaint, if so pls explain.
XCP is already in the bitcoin blockchain, which is replicated thousands of times. It already has all the redundancy needed and is currently probably the most secure place to store data, short of some super secret defense dept archive system

The problem I see with having some of the XCP mission critical data in a different blockchain is that if something happened to that blockchain, then it will affect part of the trades, but not all of them. With XCP fully resident on the bitcoin blockchain, if anything strange happens, like a blockchain rewind, all the XCP transactions get rewound too!

If some of the transaction details are on the LTC chain and it gets rolled back, now we have some transactions that half happened and half didnt happen. The Poloniex XCP incident on a across the board scale.

Short of increasing confirmation times to the neighborhood of a day to be sure the other blockchain is stable, I see no way to avoid this risk. Clearly, a one day confirmation time will make Mr. Moneypack start having a lot more fits, so lets not go there. I doubt anybody would agree to a one day confirm time.

So, even though it sounds like we get more redundancy by utilizing a different blockchain, we actually get a LOT more risk and very little added redundancy. After all what is BTC redundancy vs (BTC+LTC) redundancy?

James

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
1555816385
Hero Member
*
Offline Offline

Posts: 1555816385

View Profile Personal Message (Offline)

Ignore
1555816385
Reply with quote  #2

1555816385
Report to moderator
100% New Software
PC, Mac, Android, & HTML5 Clients
Krill Rakeback
Low Rake
Bitcoin Poker 3.0
Bad Beat Jackpot
SwC Poker Relaunch
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1555816385
Hero Member
*
Offline Offline

Posts: 1555816385

View Profile Personal Message (Offline)

Ignore
1555816385
Reply with quote  #2

1555816385
Report to moderator
sparta_cuss
Sr. Member
****
Offline Offline

Activity: 386
Merit: 250


View Profile
March 21, 2014, 04:28:59 AM
Last edit: March 21, 2014, 04:48:40 AM by sparta_cuss
 #5682

I would like to bring a topic for discussion to get clarity in my mind with your help:
...
CITYGLUT once answered me that XCP is required- but again I am asking: to what extent? can we try to quantify/forecast the use and demand just like we would for a for profit company?
...
NXT- people didnt see a problem - and they see NXT as a store of value backing up the system. I dont see it simply because this ISN'T a company and no stocks are sold. it is a decentralized ecosystem and only the unit of excahange count for real ECONOMIC value (investment wise). the store of value is the platform and code but it cant be quantified financially without real transactions with a currency as mentioned.
...

Thank you, freedomfighter, for asking this question. I saw that you asked at least twice in the NXT forum and did not get an adequate reply. The devil is in the details, but so is the value proposition.

A helpful answer would include examples or a particular use case. Let's use BTT, since they are a live proposition. How will XCPs gain value (how and why will people want to acquire and hold XCPs) if they want to participate in BTT's services? Let's go step-by-step here and see how many times and in what ways a client or BTT has to actually touch XCPs.

EDIT: In 1998, when people were wondering how dotcoms would be worth their extraordinary valuations, the reply was usually "web traffic," "clicks," or something like this. The assumption was that the value of the dotcom had to do with how many users or visitors a website could count. "Just give away some service and once you have your customers locked into your business, then you can figure out how to get money out of them." The business model could come later, they said. For most, alas, that model never did.

"We must be willing to let go of the life we have planned, so as to have the life that is waiting for us." - E.M. Forster
NXT: NXT-Z24T-YU6D-688W-EARDT
BTC: 19ULeXarogu2rT4dhJN9vhztaorqDC3U7s
jgarzik
Legendary
*
Offline Offline

Activity: 1554
Merit: 1005


View Profile
March 21, 2014, 05:09:05 AM
 #5683

+1 for Common Sense

When you really think about it in a global way, storing data in a second blockchain is even more wasteful.

Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty

Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors?  Why even have OP_RETURN?  Why even have script if we really want to save every bit of space?

Counterparty is just tiny writings in the margins of the Bitcoin book.  Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.

Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries.  It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.

Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
BitcoinTangibleTrust
Member
**
Offline Offline

Activity: 111
Merit: 10

Digitizing Valuable Hard Assets with Crypto


View Profile WWW
March 21, 2014, 05:27:23 AM
 #5684

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.


Thanks for sharing your thoughts Jeff. So, will you help us start engaging with the existing bitcoin core-dev community? It's in Counterparty's interests to act as a responsible partner as we need the bitcoin blockchain if we are to survive. Will you let us know how we can start working together on these questions?

What would you recommend as some first steps we can take to start to engage and build a constructive relationship?

Digital Tangible
Digitizing Valuable Hard Assets with Crypto http://www.digitaltangibletrust.com
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
March 21, 2014, 05:56:44 AM
 #5685

+1 for Common Sense

When you really think about it in a global way, storing data in a second blockchain is even more wasteful.

Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty

Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors?  Why even have OP_RETURN?  Why even have script if we really want to save every bit of space?

Counterparty is just tiny writings in the margins of the Bitcoin book.  Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.

Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries.  It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.

Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.


Is there a way for the bitcoin protocol to prevent the way XCP is using it, without breaking anything else?
That seems like a very big potential issue if we dont get this resolved...

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
johnybyo
Newbie
*
Offline Offline

Activity: 58
Merit: 0


View Profile
March 21, 2014, 06:11:17 AM
 #5686

Not sure i understand right but bitcoin core dev team dont want anyone make new layers over bitcoin blockchain?
Luke-Jr
Legendary
*
Offline Offline

Activity: 2436
Merit: 1012



View Profile
March 21, 2014, 06:17:36 AM
 #5687

Is there a way for the bitcoin protocol to prevent the way XCP is using it, without breaking anything else?
That seems like a very big potential issue if we dont get this resolved...
The miners are supposed to filter out abuses.
Human problems need human solutions.

Not sure i understand right but bitcoin core dev team dont want anyone make new layers over bitcoin blockchain?
The problem isn't new layers, it's forcing things on people against their will.
New layers can be done on an opt-in basis, without polluting the blockchain and forcing non-participants to store the data.

baddw
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500



View Profile
March 21, 2014, 06:47:30 AM
 #5688

+1 for Common Sense

When you really think about it in a global way, storing data in a second blockchain is even more wasteful.

Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty

Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors?  Why even have OP_RETURN?  Why even have script if we really want to save every bit of space?

Counterparty is just tiny writings in the margins of the Bitcoin book.  Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.

Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries.  It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.

Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.

"All volunteer"?  I think that's somewhat misleading.  It's not like Bitcoin is Folding@home or something where the nodes are running for a glorious altruistic purpose.  Bitcoin nodes are running because it is profitable to do so (in the case of mining) or they hold Bitcoin and have a vested interest in preserving its value.

Counterparty and Mastercoin play by the rules of Bitcoin.  XCP users pay transaction fees and, to my limited understanding, frequently create unspendable outputs which effectively deflate Bitcoin and so theoretically make every BTC worth a little more, given a set market cap.

Furthermore, XCP is basically extending the utility of Bitcoin.  I think of XCP/MSC as being the JavaScript to Bitcoin's HTML.  Yes, HTML was a revolution, but you essentially could only do one thing with it.  The truly interesting stuff started happening once we allowed little programs to run on top of it and modify it.  We now have fully dynamic, interactive programs running within a Web browser with no plugins needed.  As somebody who started in Web Development back when Netscape was dominant and the coolest thing you could do with JavaScript was change an image on mouseover, I am blown away at the orders of magnitude how much more useful basic HTML is today than it was 15 years ago.

There are some competitors such as BitShares or NXT that run on completely different networks but are trying to achieve the same thing.  Kinda like, say, Flash -- abandon HTML completely, start from scratch and build something that in some ways is more capable than HTML+JS but less compatible, requiring a separate software download and install.

We all know how that story played out.  But if Microsoft had never added a little thing which came to be called XMLHttpRequest to Internet Explorer 5, eventually birthing AJAX and the fully interactive JSON-loaded sites that we have today, the Web might have moved on past HTML.  Would HTML still be around today, or would everybody have moved on to something more fully-featured like Flash (God forbid)?  The duo of HTML+JS = "Web 2.0" has won, but there's no guarantees in this world.

I believe in the BitShares idea, and the NXT idea, and the Ripple idea.  All of these are starting from scratch and building their own networks.  I also believe in the Counterparty and Mastercoin ideas.  Mastercoin and XCP are preserving the Bitcoin blockchain and creating useful structures on top of that blockchain.  To my mind, that should be exciting as hell to someone invested in the Bitcoin community and (presumably) Bitcoins as a currency.  It's a value-add, pure and simple.  And while nobody can predict the future, IMO these features provide a much more compelling future for Bitcoin than the alternative, where so-called "Crypto-Currency 2.0" products simply leave Bitcoin in the dust and abandon PoW-mined blockchains altogether.

I think that I understand your point about unspent outputs being memory hogs for the Bitcoin network nodes.  But AFAIK, this is the one thing that Bitcoin CANNOT do away with.  It seems that Counterparty would be happy to use the 80-byte OP_RETURN space (which, AFAIK, only takes up space in the blockchain and does not remain resident in the active memory of nodes), but with only 40 bytes of space, they are forced to use unspent outputs for some transactions; and if OP_RETURN gets shortened further, unspent outputs will be used for all transactions..

Now, I am just a disinterested observer here (with investments in Bitcoin and all major 2.0 cryptos) so I don't speak for anybody but myself here; but it seems to me that Counterparty has Bitcoin over a barrel somewhat, especially with respect to the unspent outputs, which would be quite difficult to selectively block on the Bitcoin end.  It would quickly turn into a cat and mouse game.  Bitcoin could implement code to detect and block XCP transactions, but XCP changes a few parameters and re-launches a week later to get around it, which causes Bitcoin to respond, which causes a new change in XCP, etc. ad nauseum.  I don't think that anybody wants that.

BTC/XCP 11596GYYq5WzVHoHTmYZg4RufxxzAGEGBX
DRK XvFhRFQwvBAmFkaii6Kafmu6oXrH4dSkVF
Eligius Payouts/CPPSRB Explained  I am not associated with Eligius in any way.  I just think that it is a good pool with a cool payment system Smiley
BitcoinTangibleTrust
Member
**
Offline Offline

Activity: 111
Merit: 10

Digitizing Valuable Hard Assets with Crypto


View Profile WWW
March 21, 2014, 07:04:11 AM
Last edit: March 21, 2014, 07:19:36 AM by BitcoinTangibleTrust
 #5689

Is there a way for the bitcoin protocol to prevent the way XCP is using it, without breaking anything else?
That seems like a very big potential issue if we dont get this resolved...
The miners are supposed to filter out abuses.
Human problems need human solutions.

Not sure i understand right but bitcoin core dev team dont want anyone make new layers over bitcoin blockchain?
The problem isn't new layers, it's forcing things on people against their will.
New layers can be done on an opt-in basis, without polluting the blockchain and forcing non-participants to store the data.

Thanks for engaging with us Luke-Jr. Will you be able to elaborate on how this opt-in basis would work and why reducing OP_RETURN from the proposed 80 bytes was better for bitcoin? It seems that the 40byte reduction might be the first step in a slippery slope to zero bytes in the future by the bitcoin core devs.

Will you help us understand the ways we can work together constructively?

Digital Tangible
Digitizing Valuable Hard Assets with Crypto http://www.digitaltangibletrust.com
Luke-Jr
Legendary
*
Offline Offline

Activity: 2436
Merit: 1012



View Profile
March 21, 2014, 07:23:17 AM
Last edit: March 21, 2014, 07:33:36 AM by Luke-Jr
 #5690

Thanks for engaging with us Luke-Jr. Will you be able to elaborate on how this opt-in basis would work
Merged mining, and/or hopefully soon bitcoin side-chains.

and why reducing OP_RETURN from the proposed 80 bytes was better for bitcoin?
Because:
  • Too many people were getting the impression that OP_RETURN was a feature, meant to be used. It was never intended as such, only a way to "leave the windows unlocked so we don't need to replace the glass when someone breaks in". That is, to reduce the damage caused by people abusing Bitcoin.
  • 40 bytes is more than sufficient for all legitimate needs for tying data to a transaction: you get 32 bytes for a hash, plus 8 bytes for some kind of unique identifier (which really isn't necessary either!).
  • The original 80 byte proposal was intended to be for 512-bit hashes, but this was determined to be unnecessary.

It seems that the 40byte reduction might be the first step in a slippery slope to zero bytes in the future by the bitcoin core devs.
Zero bytes is exactly how it's intended to be.
Note the OP_RETURN change by the development team is only a change in default relay policy.
Miners are, as always, expected to make their own policy decisions, and never rely on merely the default Bitcoin Core mining code.
Hopefully as mining returns to being decentralised, we will see less toleration of abusive/spam transactions whether the OP_RETURN variant or otherwise.
Now, if someone has a valid, necessary use case for actually storing hashes with transactions, obviously that's a case miners should seriously consider mining.

jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
March 21, 2014, 07:30:00 AM
 #5691

Note the OP_RETURN change by the development team is only a change in default relay policy.
Miners are, as always, expected to make their own policy decisions, and never rely on merely the default Bitcoin Core mining code.
Hopefully as mining returns to being decentralised, we will see less toleration of abusive/spam transactions whether the OP_RETURN variant or otherwise.
Now, if someone has a valid, necessary use case for actually storing hashes with transactions, obviously that's a case miners should seriously consider mining.
In your opinion, which category do you feel XCP falls into?

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
Luke-Jr
Legendary
*
Offline Offline

Activity: 2436
Merit: 1012



View Profile
March 21, 2014, 07:33:03 AM
 #5692

Note the OP_RETURN change by the development team is only a change in default relay policy.
Miners are, as always, expected to make their own policy decisions, and never rely on merely the default Bitcoin Core mining code.
Hopefully as mining returns to being decentralised, we will see less toleration of abusive/spam transactions whether the OP_RETURN variant or otherwise.
Now, if someone has a valid, necessary use case for actually storing hashes with transactions, obviously that's a case miners should seriously consider mining.
In your opinion, which category do you feel XCP falls into?
I haven't looked at XCP in detail yet, so I'll have to defer to others who have.

johnybyo
Newbie
*
Offline Offline

Activity: 58
Merit: 0


View Profile
March 21, 2014, 08:16:56 AM
 #5693

Now, I am just a disinterested observer here (with investments in Bitcoin and all major 2.0 cryptos) so I don't speak for anybody but myself here; but it seems to me that Counterparty has Bitcoin over a barrel somewhat, especially with respect to the unspent outputs, which would be quite difficult to selectively block on the Bitcoin end.  It would quickly turn into a cat and mouse game.  Bitcoin could implement code to detect and block XCP transactions, but XCP changes a few parameters and re-launches a week later to get around it, which causes Bitcoin to respond, which causes a new change in XCP, etc. ad nauseum.  I don't think that anybody wants that.

If that go to this way then i think Bitcoin dev team shoot own leg in long run. New innovations choose sure other places like LTC if they make situation "development friendly" instead try kill all projects. And like XCP have make also good to Bitcoin when have burn btc:s and in theory make every bitcoin value higher and also pay miners fees so i dont see why here is not btc core team time talk about cooperation?
BitcoinTangibleTrust
Member
**
Offline Offline

Activity: 111
Merit: 10

Digitizing Valuable Hard Assets with Crypto


View Profile WWW
March 21, 2014, 08:19:46 AM
 #5694

Zero bytes is exactly how it's intended to be.
Note the OP_RETURN change by the development team is only a change in default relay policy.
Miners are, as always, expected to make their own policy decisions, and never rely on merely the default Bitcoin Core mining code.
Hopefully as mining returns to being decentralised, we will see less toleration of abusive/spam transactions whether the OP_RETURN variant or otherwise.
Now, if someone has a valid, necessary use case for actually storing hashes with transactions, obviously that's a case miners should seriously consider mining.

Thanks Luke-Jr. Please bear with me. Although I am not the most technically bitcoin-competent, I'm trying to ask questions so we can continue to host a conversation and share further insights from bitcoin core-devs like yourself.

Maybe I'm wrong, but I am reading your words as follows: Miners will always decide their interests in what type of transactions they wish to mine. Currently, Counterparty uses multisig which are standard transactions. Although we do not wish to add to blockchain bloat, it would appear that as long as we are allowing miners to achieve their economic interests in mining all standard multisig transactions, then the system is working as it should.

Am I understanding your thoughts correctly?

Digital Tangible
Digitizing Valuable Hard Assets with Crypto http://www.digitaltangibletrust.com
Spratan
Hero Member
*****
Offline Offline

Activity: 696
Merit: 505


View Profile
March 21, 2014, 09:05:59 AM
 #5695

+1 for Common Sense

When you really think about it in a global way, storing data in a second blockchain is even more wasteful.

Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty

Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors?  Why even have OP_RETURN?  Why even have script if we really want to save every bit of space?

Counterparty is just tiny writings in the margins of the Bitcoin book.  Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.

Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries.  It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.

Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.



Translation : At the moment, Mastercoin and XCP are only parasites from bitcoin dev's points of view...
Sorry for being so direct but this is what I read as a non-technical investor.
ShroomsKit_Disgrace
Legendary
*
Offline Offline

Activity: 952
Merit: 1000

Yeah! I hate ShroomsKit!


View Profile
March 21, 2014, 09:24:07 AM
 #5696

+1 for Common Sense

When you really think about it in a global way, storing data in a second blockchain is even more wasteful.

Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty

Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors?  Why even have OP_RETURN?  Why even have script if we really want to save every bit of space?

Counterparty is just tiny writings in the margins of the Bitcoin book.  Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.

Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries.  It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.

Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.



Translation : At the moment, Mastercoin and XCP are only parasites from bitcoin dev's points of view...
Sorry for being so direct but this is what I read as a non-technical investor.

So lets everybody with a 2.0 point of view change to NXT and eventually to Etherium! BTC is no longer cool!  Cheesy
qtgwith
Hero Member
*****
Offline Offline

Activity: 602
Merit: 500


View Profile
March 21, 2014, 09:35:33 AM
 #5697

+1 for Common Sense

When you really think about it in a global way, storing data in a second blockchain is even more wasteful.

Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty

Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors?  Why even have OP_RETURN?  Why even have script if we really want to save every bit of space?

Counterparty is just tiny writings in the margins of the Bitcoin book.  Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.

Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries.  It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.

Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.



Translation : At the moment, Mastercoin and XCP are only parasites from bitcoin dev's points of view...
Sorry for being so direct but this is what I read as a non-technical investor.

So lets everybody with a 2.0 point of view change to NXT and eventually to Etherium! BTC is no longer cool!  Cheesy

NXT "BTS" and "Ethereum" have no robust ecosystem as BTC has.
Fernandez
Legendary
*
Offline Offline

Activity: 1008
Merit: 1000



View Profile
March 21, 2014, 10:10:52 AM
 #5698

Translation : At the moment, Mastercoin and XCP are only parasites from bitcoin dev's points of view...
Sorry for being so direct but this is what I read as a non-technical investor.

Thats how I see it too. The arrogance of these guys is amazing. MSC and XCP is extending the functionality of Bitcoin and may be something good have and compete with NXT, Bitshares and Ethereum.

XCP can move onto other chain, or I suggest get its on PoS chain. This will also prevent the archaic 10 minute wait.






██████████████████████████████████████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████████████████████████████
███████████████████████████████████████████████████████████████████████▄▄▄███████████████████████
███████████████████████████████████████████████████████████████████████▀▀▀████████████████████████
██████████████████████████████████████████████████████████████████████████████████████████████████
█████████████████████████████████████████████████████████████████████████████████████████████████





...INTRODUCING WAVES........
...ULTIMATE ASSET/CUSTOM TOKEN BLOCKCHAIN PLATFORM...






JahPowerBit
Sr. Member
****
Offline Offline

Activity: 300
Merit: 250


Counterparty Developer


View Profile
March 21, 2014, 10:13:18 AM
 #5699


40 bytes is more than sufficient for all legitimate needs for tying data to a transaction

To me the word "legitimate" is the main problem.
Who can claim the power to say: this data is legitimate and that another is not legitimate. This is called censorship!

The question can not be: What data is legitimate to be stored in the blockchain?
Because this is a subjective question, and that no one can claim to have the answer.

The only question is: Should we allow the storage of data in the blockchain?
And the answer is: there is no choice, because it is possible to do with multisig transaction.
So the question becomes: Should we let people store data in multisig transactions or provide a cleaner way to do it?

History has shown that it is much smarter to regulate than to ban something that is impossible to ban.

.
   █████▄▄▄▄
   ████████████▄▄▄            ▀██████
   ███ ▀▀▀▀█████████▄          ▀█████
   ███         ▀▀▀█████▄         ▀███
   ███              ▀▀████▄▄███    ▀▀
   ███                ▀███████▀
   ███                    █████
   ███     ███▄         ▄███████
   ▐██▌     ▀███▄     ▄███▀  ███
   ▐███       ▀███▄▄ ███▀     ███
    ███▌        ▀████        ▐██▌
     ███         ████         ███
      ███      ▄█████▄       ▐██
       ███   ▄████▀ ▀███▄     ▐██
        ███▄████▀     ▀███▄   ███
         █████▀         ▀███▄████
          ██▀             ▀█████▌
                            ▀███▌
  ██████                      ▀▀
  ▀▀▀███
     ███
█         █   ███
 █        ███  ███  █
███       ███   █  ███
███   █   ███   █  ███
███  ███   █       ███
███  ███   █       ███
 █   ███            █
 █    █             █
█         █   ███
 █        ███  ███  █
███       ███   █  ███
███   █   ███   █  ███
███  ███   █       ███
███  ███   █       ███
 █   ███            █
 █    █             █
             JOIN US             
TELEGRAM TWITTER FACEBOOK
LINKEDIN WHITEPAPER
freedomfighter
Full Member
***
Offline Offline

Activity: 210
Merit: 100


View Profile
March 21, 2014, 10:33:42 AM
 #5700

Dear bitcon DEVs and all,

First a general comment: as much as i support NXT ETH etc.- Bitcoin is the real estate and gold of the entire space and is where smart money is flowing, and for a good reason. The network is well tested and strong and represent less of a risk in this very risky business. XCP and MSC being a BTC layer is a great advantage to these projects and to BTC as a whole I believe. Thus the below:  

I am very surprised to say the least from this seemingly cold shoulder.

parasites? against their will? (what does this even mean in a decentralized open source context)? whose will is it that is more important? and why? is this a centralized project suddenly?

But leaving this aside:

the BTC ecosystem is not only the applications and services such as vaults, wallets, merchant software, merchant clearing, ATMS, mining machines etc etc. These are all great and there is no doubt that great things are ahead. In a way these are external to bitcoin though are necessary to drive adaptation and penetration levels.

BUT: additional decentralized applications and platforms that allow to extend the financial capabilities and develop trustless financial products for bitcoin itself are not only a must but rather a crucial tool in extending this economy.

This will strengthen the network bring in more users and demand and many more transactions that is an interest to miners and all involved. what is against what will here?

You should be embracing and supporting these innovation clearly and loudly especially those layers on top of the BTC network. how else will this get to trillions of $$$ in penetration and transactions?

I urge all: I highly suggest that XCP devs engage in a productive dialouge with BTC devs (doesnt have to be public) to alleviate these issues and get on the same page. this cold shoulder is a shot in the feet of not only XCP and MSC but also a shot against BTC itself.  

Pages: « 1 ... 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 [285] 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 ... 658 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!