Bitcoin Forum
October 20, 2021, 08:18:26 AM *
News: Latest Bitcoin Core release: 22.0 [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 ... 659 »
  Print  
Author Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread  (Read 1274452 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.
nakaone
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500


View Profile
March 21, 2014, 02:22:41 PM
 #5681

guys calm down, everyone in the bitcoin universe know which role the core developers play and until now they did quite a good job - I think the developers of xcp are already in close contact to the core developers, let us see where this is going
1634717906
Hero Member
*
Offline Offline

Posts: 1634717906

View Profile Personal Message (Offline)

Ignore
1634717906
Reply with quote  #2

1634717906
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
halfcab123
Full Member
***
Offline Offline

Activity: 224
Merit: 100

CabTrader v2 | crypto-folio.com


View Profile
March 21, 2014, 02:25:00 PM
 #5682

guys calm down, everyone in the bitcoin universe know which role the core developers play and until now they did quite a good job - I think the developers of xcp are already in close contact to the core developers, let us see where this is going

They're talking about getting rid of multi sig.  I need a xanax.

DayTrade with less exposure to risk, by setting buy and sell spreads with CabTrader v2, buy now @ crypto-folio.com
porqupine
Full Member
***
Offline Offline

Activity: 214
Merit: 100


View Profile
March 21, 2014, 02:39:28 PM
 #5683

So this is what a currency free from the banks is supposed to be? A money supply determined by an even smaller autocracy? At least the Bank's do not Threaten their Clients.
bitwhizz
Legendary
*
Offline Offline

Activity: 910
Merit: 1000



View Profile
March 21, 2014, 02:49:12 PM
 #5684

So this is what a currency free from the banks is supposed to be? A money supply determined by an even smaller autocracy? At least the Bank's do not Threaten their Clients.

Yep, its disgraceful
jgarzik
Legendary
*
Offline Offline

Activity: 1596
Merit: 1022


View Profile
March 21, 2014, 02:52:45 PM
 #5685

From the perspective of counterparty and the overall bitcoin community,
  • The criticism is not against counterparty, but just One Flaw in the system
  • There was zero consultation on the design with the wider community before the "on" switch was flipped
  • This flaw --network-critical database used for raw data storage-- was well known before Counterparty began life. You could have avoided this problem with communication.
  • Existing designs are known to be less abusive to the network, and do not store data in that key database

It is perfectly possible to run counterparty without this flaw.


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

Activity: 1596
Merit: 1022


View Profile
March 21, 2014, 02:59:10 PM
Last edit: March 21, 2014, 06:31:02 PM by jgarzik
 #5686

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.

No, it is trivial to block 100% of them.  A proposal to do just that appeared on the bitcoin-development mailing list yesterday from Peter Todd.  This proposed change would relay zero transactions with multisig outputs.

Most of the world is moving to P2SH for multisig, leaving the remaining "bare multisig" users mastercoin, counterparty, etc.



Isn't Peter Todd working on Mastercoin? Why would he propose that?

Think about it.  Mastercoin is a competitor to Counterparty.  Mastercoin is already aware of, and working on solving this storage-in-multisig problem.

Peter Todd's proposal simultaneously (a) benefits Mastercoin, (b) disadvantages Counterparty, and (c) presents a proposal that portions of the developer and mining community already find agreeable.


Edit: retracted, based on Peter's recent posting.


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

Activity: 672
Merit: 500


View Profile
March 21, 2014, 02:59:49 PM
 #5687

From the perspective of counterparty and the overall bitcoin community,
  • The criticism is not against counterparty, but just One Flaw in the system
  • There was zero consultation on the design with the wider community before the "on" switch was flipped
  • This flaw --network-critical database used for raw data storage-- was well known before Counterparty began life. You could have avoided this problem with communication.
  • Existing designs are known to be less abusive to the network, and do not store data in that key database

It is perfectly possible to run counterparty without this flaw.



Thanks for the explanation.

I'm reading all these posts with a lot of interest but sometimes explaining things with simple terms is really useful for the vulgum pecus.
bitexch
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
March 21, 2014, 03:02:45 PM
 #5688

From the perspective of counterparty and the overall bitcoin community,
  • The criticism is not against counterparty, but just One Flaw in the system
  • There was zero consultation on the design with the wider community before the "on" switch was flipped
  • This flaw --network-critical database used for raw data storage-- was well known before Counterparty began life. You could have avoided this problem with communication.
  • Existing designs are known to be less abusive to the network, and do not store data in that key database

It is perfectly possible to run counterparty without this flaw.



You are using the protocol as a bargaining tool, because you don't like what a project did. Do you see the problem with that?

All you are doing is making a decision for miners.
halfcab123
Full Member
***
Offline Offline

Activity: 224
Merit: 100

CabTrader v2 | crypto-folio.com


View Profile
March 21, 2014, 03:04:59 PM
 #5689

So can we hear anything from PP or XN on this ?

DayTrade with less exposure to risk, by setting buy and sell spreads with CabTrader v2, buy now @ crypto-folio.com
PhantomPhreak
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250

Counterparty Chief Scientist and Co-Founder


View Profile
March 21, 2014, 03:06:38 PM
 #5690

From the perspective of counterparty and the overall bitcoin community,
  • The criticism is not against counterparty, but just One Flaw in the system
  • There was zero consultation on the design with the wider community before the "on" switch was flipped
  • This flaw --network-critical database used for raw data storage-- was well known before Counterparty began life. You could have avoided this problem with communication.
  • Existing designs are known to be less abusive to the network, and do not store data in that key database

It is perfectly possible to run counterparty without this flaw.

It is perfectly possible to run Counterparty without storing data in the blockchain directly, yes. But there is no flaw in the possibility of doing so, and all the explanations that have been given for why it is 'abusive' or a 'problem' use circular logic. It's even misleading to call it 'raw data': it's not GIFs or tweets or anything like that---it's transaction data, just transaction data that Bitcoin itself doesn't parse.

We are adding (a great deal of) functionality to Bitcoin, and paying whatever fees miners ask for it. All of the outputs we are generating are spendable and prunable. We are doing our best to help Bitcoin (and users of Bitcoin), which has enormous potential beyond its current abilities.
halfcab123
Full Member
***
Offline Offline

Activity: 224
Merit: 100

CabTrader v2 | crypto-folio.com


View Profile
March 21, 2014, 03:11:58 PM
 #5691

From the perspective of counterparty and the overall bitcoin community,
  • The criticism is not against counterparty, but just One Flaw in the system
  • There was zero consultation on the design with the wider community before the "on" switch was flipped
  • This flaw --network-critical database used for raw data storage-- was well known before Counterparty began life. You could have avoided this problem with communication.
  • Existing designs are known to be less abusive to the network, and do not store data in that key database

It is perfectly possible to run counterparty without this flaw.

It is perfectly possible to run Counterparty without storing data in the blockchain directly, yes. But there is no flaw in the possibility of doing so, and all the explanations that have been given for why it is 'abusive' or a 'problem' use circular logic. It's even misleading to call it 'raw data': it's not GIFs or tweets or anything like that---it's transaction data, just transaction data that Bitcoin itself doesn't parse.

We are adding (a great deal of) functionality to Bitcoin, and paying whatever fees miners ask for it. All of the outputs we are generating are spendable and prunable. We are doing our best to help Bitcoin (and users of Bitcoin), which has enormous potential beyond its current abilities.

+1.00000000

DayTrade with less exposure to risk, by setting buy and sell spreads with CabTrader v2, buy now @ crypto-folio.com
BitcoinTangibleTrust
Member
**
Offline Offline

Activity: 111
Merit: 10

Digitizing Valuable Hard Assets with Crypto


View Profile WWW
March 21, 2014, 03:25:58 PM
 #5692

Isn't Peter Todd working on Mastercoin? Why would he propose that?

Think about it.  Mastercoin is a competitor to Counterparty.  Mastercoin is already aware of, and working on solving this storage-in-multisig problem.

Peter Todd's proposal simultaneously (a) benefits Mastercoin, (b) disadvantages Counterparty, and (c) presents a proposal that portions of the developer and mining community already find agreeable.



Isn't Peter Todd also employed by Counterparty? https://www.counterparty.co/sergio-lerner-peter-todd/

Maybe the devs at Counterparty should learn Peter's proposal and we explore how we might participate to benefit alongside Mastercoin?

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

Activity: 910
Merit: 1000



View Profile
March 21, 2014, 03:27:45 PM
 #5693

From the perspective of counterparty and the overall bitcoin community,
  • The criticism is not against counterparty, but just One Flaw in the system
  • There was zero consultation on the design with the wider community before the "on" switch was flipped
  • This flaw --network-critical database used for raw data storage-- was well known before Counterparty began life. You could have avoided this problem with communication.
  • Existing designs are known to be less abusive to the network, and do not store data in that key database

It is perfectly possible to run counterparty without this flaw.

It is perfectly possible to run Counterparty without storing data in the blockchain directly, yes. But there is no flaw in the possibility of doing so, and all the explanations that have been given for why it is 'abusive' or a 'problem' use circular logic. It's even misleading to call it 'raw data': it's not GIFs or tweets or anything like that---it's transaction data, just transaction data that Bitcoin itself doesn't parse.

We are adding (a great deal of) functionality to Bitcoin, and paying whatever fees miners ask for it. All of the outputs we are generating are spendable and prunable. We are doing our best to help Bitcoin (and users of Bitcoin), which has enormous potential beyond its current abilities.


I would like to see a thorough, direct and well thought answer to this. No circular logic, dodging or half answers. Please check the hyperbole and rhetoric at the door and answer to the core of this issue.
halfcab123
Full Member
***
Offline Offline

Activity: 224
Merit: 100

CabTrader v2 | crypto-folio.com


View Profile
March 21, 2014, 03:56:11 PM
 #5694

From the perspective of counterparty and the overall bitcoin community,
  • The criticism is not against counterparty, but just One Flaw in the system
  • There was zero consultation on the design with the wider community before the "on" switch was flipped
  • This flaw --network-critical database used for raw data storage-- was well known before Counterparty began life. You could have avoided this problem with communication.
  • Existing designs are known to be less abusive to the network, and do not store data in that key database

It is perfectly possible to run counterparty without this flaw.

It is perfectly possible to run Counterparty without storing data in the blockchain directly, yes. But there is no flaw in the possibility of doing so, and all the explanations that have been given for why it is 'abusive' or a 'problem' use circular logic. It's even misleading to call it 'raw data': it's not GIFs or tweets or anything like that---it's transaction data, just transaction data that Bitcoin itself doesn't parse.

We are adding (a great deal of) functionality to Bitcoin, and paying whatever fees miners ask for it. All of the outputs we are generating are spendable and prunable. We are doing our best to help Bitcoin (and users of Bitcoin), which has enormous potential beyond its current abilities.


I would like to see a thorough, direct and well thought answer to this. No circular logic, dodging or half answers. Please check the hyperbole and rhetoric at the door and answer to the core of this issue.

+( sideways 8 )

DayTrade with less exposure to risk, by setting buy and sell spreads with CabTrader v2, buy now @ crypto-folio.com
BitcoinTangibleTrust
Member
**
Offline Offline

Activity: 111
Merit: 10

Digitizing Valuable Hard Assets with Crypto


View Profile WWW
March 21, 2014, 04:02:44 PM
Last edit: March 21, 2014, 04:23:38 PM by BitcoinTangibleTrust
 #5695

Think about it.  Mastercoin is a competitor to Counterparty.  Mastercoin is already aware of, and working on solving this storage-in-multisig problem.

Peter Todd's proposal simultaneously (a) benefits Mastercoin, (b) disadvantages Counterparty, and (c) presents a proposal that portions of the developer and mining community already find agreeable.


Thanks Jeff. This is very helpful data. I was not aware of Peter's proposal and I have emailed him and asked him to respond here. It appears that Peter is also employed by Counterparty so he may be able to share some further insights about his proposal and how Counterparty may participate and add to the interests of both the bitcoin developer and bitcoin mining communities. It's in our interest to support proposals that everyone finds agreeable.

I believe the post Jeff is referring to is this one: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

However, anyone please correct me if that's the wrong thread?

EDIT: Peter's follow-up reply is here: https://bitcointalk.org/index.php?topic=395761.msg5824079#msg5824079

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

Activity: 390
Merit: 250

Counterparty Developer


View Profile
March 21, 2014, 04:03:05 PM
 #5696

So the question becomes: Should we let people store data in multisig transactions or provide a cleaner way to do it?

A less abusive way was already provided.

With OP_RETURN, the data is still in the blockchain, but at least it is not in the UTXO database of unspent outputs like Generation-1 mastercoin/counterparty designs.



If the desire is for these projects to use OP_RETURN, as it seems you are stating here, then why personally introduce a pull request (https://github.com/bitcoin/bitcoin/pull/3737) to reduce its size down to 40 bytes, which makes it that much less useful to the projects that were to be some of its biggest users in the first place? And then, for justification of the change, provide reasons that have nothing to do with how these projects are actually storing data (i.e. we don't use hashes and side-chains for reasons we explained earlier).

The blockchain itself would be most benefited by the use of OP_RETURN here, but it seems to me at least that there is a disconnect in the logic of why the size was halved among some, pointing to theoretical reasons as justification on why that would be a good idea instead of the *actual real world current uses*. While the optimal solution in your mind for Counterparty and others may be to move to their own side chains and store hashes in the Bitcoin blockchain using OP_RETURN, you have to understand that doing so is highly complex, rife with potential security issues, and that the only evidence supporting this is (as far as I know) essentially a theoretical-type thread on the Bitcoin developers mailing list. This would be a bit like me telling the Bitcoin devs that Bitcoin should move to using GHOST (https://eprint.iacr.org/2013/881.pdf) immediately as it's technically the optimal solution over the longer block times today. While the latter could be argued to be the case, it is a proposal that has not been fully vetted in the real world, and would introduce major protocol-level changes that could cause potential security and usability problems.

Jeff, our intentions are be good stewards of the blockchain, while accomplishing our goals of adding valuable financial functionality to Bitcoin in a stable, scalable and secure manner. This whole OP_RETURN thing is like saying you have a great feature that would solve a need, but that no one should actually use it.


Visit the official Counterparty forums: http://counterpartytalk.org
bitwhizz
Legendary
*
Offline Offline

Activity: 910
Merit: 1000



View Profile
March 21, 2014, 04:05:45 PM
 #5697

I just had an hypothetical  idea in an aplocalyptic situation if XCP needed to relocate, if XCP was to move to a new database, it would need to create a completely new currency, meaning more units of value would need to burned (if using proof of burn), that would be unfair to everyone holding XCP and burned/traded . I think the best thing to do would be a 'proof of swap'  (hope i coin this term), in which the XCP can be swapped for the new currency which doesn;t rely on multi sig on this database, and thats the proof issuance,
LightedLamp
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
March 21, 2014, 04:07:15 PM
 #5698

https://i.imgur.com/KZAZNzv.jpg
PhantomPhreak
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250

Counterparty Chief Scientist and Co-Founder


View Profile
March 21, 2014, 04:10:01 PM
 #5699

I just had an hypothetical  idea in an aplocalyptic situation if XCP needed to relocate, if XCP was to move to a new database, it would need to create a completely new currency, meaning more units of value would need to burned (if using proof of burn), that would be unfair to everyone holding XCP and burned/traded . I think the best thing to do would be a 'proof of swap'  (hope i coin this term), in which the XCP can be swapped for the new currency which doesn;t rely on multi sig on this database, and thats the proof issuance

If we ever absolutely had to move to a different blockchain, the protocol would just freeze, save and then transfer balances over. The currencies of Counterparty, i.e. the balances, are independent of the protocol's transport layer.
xnova
Sr. Member
****
Offline Offline

Activity: 390
Merit: 250

Counterparty Developer


View Profile
March 21, 2014, 04:12:36 PM
 #5700

Isn't Peter Todd working on Mastercoin? Why would he propose that?

Think about it.  Mastercoin is a competitor to Counterparty.  Mastercoin is already aware of, and working on solving this storage-in-multisig problem.

Peter Todd's proposal simultaneously (a) benefits Mastercoin, (b) disadvantages Counterparty, and (c) presents a proposal that portions of the developer and mining community already find agreeable.



Isn't Peter Todd also employed by Counterparty? https://www.counterparty.co/sergio-lerner-peter-todd/

Maybe the devs at Counterparty should learn Peter's proposal and we explore how we might participate to benefit alongside Mastercoin?


I don't get Jeff's point here. Even assuming that this is the case, any product of this would have to become public knowledge in the form of source code at some point, to be actually used. At that point, Mastercoin (as an open source project) would have lost their advantage here.

Also, this assertion is questionable as we are working with Peter as well. I don't want to speak for him (and he can correct me if I am wrong here), but he has communicated to us that in the end, his desires lie in moving the technology itself forward over allegiances to any specific implementations of it (for Counterparty OR Mastercoin).

Visit the official Counterparty forums: http://counterpartytalk.org
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 ... 659 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!