3 ms·

> I can't help but feel the blockchain-tricks referenced by the author (in addition to the upcoming "incoices/receipts" mechanism) are nought but scope creep, b

> I can't help but feel the blockchain-tricks referenced by the author (in addition to the upcoming "incoices/receipts" mechanism) are nought but scope creep, best left out as violators of "do one thing and do it well", and in general a bad sign for Bitcoin's future. The bitcoin core developers have strict policy - they don't accept these additional features such as distributed DNS to the main chain. However alternative chains can be developed for these features. I think that there can be a tremendous value for other kind of public, distributed, databases as well, not just currency.

contingencies 14y ago
Sharing the same network-resource with those 'tricks', official or not, is not going to come free. However, I was mostly referring to the recent "invoices/receipts" thing, which is being included. IMHO as an implementer of a Bitcoin-integrated system, that's not helpful, rather it's a PITA. But I am not framing any of my development with Bitcoin purely in mind, rather I am trying to bridge arbitrary settlement systems objectively. (If interested, see http://ifex-project.org/ http://ifex-project.org/ for more info there.)
- jerguismi 14y ago
  Hmm I understood that the invoice/receipt stuff is not related to blockchain, just an additional protocol for these. However it might be questionable if this kind of stuff should be included in the main client.
- ewillbefull 14y ago
  Worth mentioning what Gavin's response was to this proposal: > RE: Mr. Stanish's suggestion to punt all of this and wait for a Grand Unified Solution: > No, we have problems that need a solution right now. And, having written one (I was the lead author of the ISO/IEC 14772-1 international standard) I'm very pessimistic about your chances for anything like IFEX to actually be adopted.
  - contingencies 14y ago
    Right, that was understandable if a little disappointing. First, let us unravel the underlying assumption, which is false. When sharing a standards proposal, one isn't necessarily hoping everyone blindly adopts it as gospel but rather it provides some basis for reasonable research and/or provisional implementation within a given area that (hopefully) benefits from previous research and provides a basis for the community building upon the knowledge gained through implementation of systems in that area. The idea is that, given some common ground, people can move forward (ie. towards interoperability) while benefiting from each others' experience, and hopefully the better connected, more heterogeneous and stronger community that results. In the particular case of IFEX, we have thus far been dealing with extremely basic areas that remain ignored by Bitcoin, ie. market identification, asset identification, and a viable decentralized internet-based financial endpoint identification scheme that provides familiar syntax, checksum protection against transposition errors, ease of integration with legacy financial systems, typo-squat-protection, and other key features. Also in the works but far more complex and slower moving are more holistic approaches to the transaction metadata/invoicing problem area than Bitcoin is apparently prepared to tackle. The other thing that is notable in Gavin's response was the apparent notion that engineering decisions affecting the entire Bitcoin community's future are being made on a rapid basis because of perceived short-term needs. I am not sure this is necessarily a trend, but as an implementer it doesn't give me the greatest peace of mind. Just my 2c.
  - SkyMarshal 14y ago
    Is that from a thread on bitcointalk.org somewhere? Can you link it? Would like to read the whole thing.
    - contingencies 14y ago
      Thread: 'Payment Protocol Proposal: Invoices/Payments/Receipts', 2012-11-27, horrid SourceForge archive roughly around http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development&max_rows=100&style=flat&viewmonth=201211&viewday=27 http://sourceforge.net/mailarchive/forum.php?forum_name=bitc... Summary gist: https://gist.github.com/4165865 https://gist.github.com/4165865

contingencies 14y ago

Sharing the same network-resource with those 'tricks', official or not, is not going to come free. However, I was mostly referring to the recent "invoices/receipts" thing, which is being included. IMHO as an implementer of a Bitcoin-integrated system, that's not helpful, rather it's a PITA. But I am not framing any of my development with Bitcoin purely in mind, rather I am trying to bridge arbitrary settlement systems objectively. (If interested, see http://ifex-project.org/ http://ifex-project.org/ for more info there.)

jerguismi 14y ago
Hmm I understood that the invoice/receipt stuff is not related to blockchain, just an additional protocol for these. However it might be questionable if this kind of stuff should be included in the main client.
ewillbefull 14y ago
Worth mentioning what Gavin's response was to this proposal: > RE: Mr. Stanish's suggestion to punt all of this and wait for a Grand Unified Solution: > No, we have problems that need a solution right now. And, having written one (I was the lead author of the ISO/IEC 14772-1 international standard) I'm very pessimistic about your chances for anything like IFEX to actually be adopted.
- contingencies 14y ago
  Right, that was understandable if a little disappointing. First, let us unravel the underlying assumption, which is false. When sharing a standards proposal, one isn't necessarily hoping everyone blindly adopts it as gospel but rather it provides some basis for reasonable research and/or provisional implementation within a given area that (hopefully) benefits from previous research and provides a basis for the community building upon the knowledge gained through implementation of systems in that area. The idea is that, given some common ground, people can move forward (ie. towards interoperability) while benefiting from each others' experience, and hopefully the better connected, more heterogeneous and stronger community that results. In the particular case of IFEX, we have thus far been dealing with extremely basic areas that remain ignored by Bitcoin, ie. market identification, asset identification, and a viable decentralized internet-based financial endpoint identification scheme that provides familiar syntax, checksum protection against transposition errors, ease of integration with legacy financial systems, typo-squat-protection, and other key features. Also in the works but far more complex and slower moving are more holistic approaches to the transaction metadata/invoicing problem area than Bitcoin is apparently prepared to tackle. The other thing that is notable in Gavin's response was the apparent notion that engineering decisions affecting the entire Bitcoin community's future are being made on a rapid basis because of perceived short-term needs. I am not sure this is necessarily a trend, but as an implementer it doesn't give me the greatest peace of mind. Just my 2c.
- SkyMarshal 14y ago
  Is that from a thread on bitcointalk.org somewhere? Can you link it? Would like to read the whole thing.
  - contingencies 14y ago
    Thread: 'Payment Protocol Proposal: Invoices/Payments/Receipts', 2012-11-27, horrid SourceForge archive roughly around http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development&max_rows=100&style=flat&viewmonth=201211&viewday=27 http://sourceforge.net/mailarchive/forum.php?forum_name=bitc... Summary gist: https://gist.github.com/4165865 https://gist.github.com/4165865