RFCs for Bitcoin

[Gyrsur]

2016 will be the year where we can expect different Bitcoin implementations in the wild. Until now it was enough to have one Bitcoin reference implementation in form of code but what we need now is a specification of Bitcoin in form of Requests for Comments.

The wild west time should end now. Boy's you've had your fun. We were impressed of your egos. Grow up or leave please.

Now we need professionalism to continue the success story of Bitcoin!


http://www.rfc-editor.org

http://www.ietf.org/rfc/rfc2223.txt

[1713580285]

1713580285

[1713580285]

1713580285

[1713580285]

1713580285

[1713580285]

1713580285

[1713580285]

1713580285

[kiblirov]

Why should we prioritize transactions with RBF? All bitcoins are equally valid. And all of them are mathematically processed the same way. I totally disagree with RBF concept. Bitcoin has a good year of 2016. There will be lot of implications are going to happen in this year. Many top chairs will relocate themselves for sure.

[achow101]

2016 will be the year where we can expect different Bitcoin implementations in the wild. Until now it was enough to have one Bitcoin reference implementation in form of code but what we need now is a specification of Bitcoin in form of Requests for Comments.

The wild west time should end now. Boy's you've had your fun. We were impressed of your egos. Grow up or leave please.

Now we need professionalism to continue the success story of Bitcoin!


http://www.rfc-editor.org

http://www.ietf.org/rfc/rfc2223.txt

Bitcoin related stuff should not be governed by the ietf but rather by a specific group for bitcoiners.  Also, there already is an RFC like thing in bitcoin, BIPs. Bitcoin is specified by these BIPs and the bitcoin white paper with the reference implementation to provide exactly that.

[Gyrsur]

2016 will be the year where we can expect different Bitcoin implementations in the wild. Until now it was enough to have one Bitcoin reference implementation in form of code but what we need now is a specification of Bitcoin in form of Requests for Comments.

The wild west time should end now. Boy's you've had your fun. We were impressed of your egos. Grow up or leave please.

Now we need professionalism to continue the success story of Bitcoin!


http://www.rfc-editor.org

http://www.ietf.org/rfc/rfc2223.txt

Bitcoin related stuff should not be governed by the ietf but rather by a specific group for bitcoiners.  Also, there already is an RFC like thing in bitcoin, BIPs. Bitcoin is specified by these BIPs and the bitcoin white paper with the reference implementation to provide exactly that.

with all respect who is this "specific group for bitcoiners"?

are this "specific group for bitcoiners" the mostly immature boy's with their big egos for fighting each other?

IMO it's better to have something different. TBF is gone, it was an bunch of ppl which wasted the money of the members.

ISOC is a non-profit organization founded in 1992 to provide leadership in Internet-related standards, education, and policy. It is dedicated to ensuring the open development, evolution and use of the Internet for the benefit of people throughout the world.  See: www.internetsociety.org

[CIYAM]

It has been discussed before - the issue is that as a protocol Bitcoin is far more problematic than something like say email where it doesn't really matter if some software works perfectly or not.

For blockchain consensus you need 100% precise behaviour and even languages like C++ are problematic when it comes to that (if Bitcoin were to be compiled with say VC++ you might find some unusual compiler bug/quirk that means it won't agree with the g++ builds).

So I very much doubt we are going to see an RFC that suddenly becomes the definition of Bitcoin's consensus (but the libconsensus stuff is a very good step in that sort of direction).

[Gyrsur]

It has been discussed before - the issue is that as a protocol Bitcoin is far more problematic than something like say email where it doesn't really matter if some software works perfectly or not.

For blockchain consensus you need 100% precise behaviour and even languages like C++ are problematic when it comes to that (if Bitcoin were to be compiled with say VC++ you might find that it breaks).

So I very much doubt we are going to see an RFC that suddenly becomes the definition of Bitcoin's consensus (but the libconsensus stuff is a very good step in that sort of direction).

ok, you are speaking about the technical aspect which is much important but it is not all.

[CIYAM]

ok, you are speaking about the technical aspect which is much important but it is not all.

There is only a technical aspect about "blockchain consensus" (anything else would be basically nonsense as it wouldn't work).

Maybe you need to rethink exactly what it is that you are advocating?

[Gyrsur]

ok, you are speaking about the technical aspect which is much important but it is not all.

There is only a technical aspect about "blockchain consensus" (anything else would be basically nonsense as it wouldn't work).

sounds like the (good) old times where a fork (2013) happened for a certain timeframe. but the community was united in these days. that's the difference.

[Gyrsur]

this is not the right approach, gavin!

http://gavinandresen.ninja/classic-unlimited-xt-core

the maturation of Bitcoin will be delayed for several years with this wrong approach of fighting each other!

IMO it should be like this:

• first specification
  
• second implementation united

[fronti]

For blockchain consensus you need 100% precise behaviour and even languages like C++ are problematic when it comes to that (if Bitcoin were to be compiled with say VC++ you might find some unusual compiler bug/quirk that means it won't agree with the g++ builds).

just thinking:

if there will be a meta language described in the RFC which can be used to check a block/transaction by hand this may be enough.
If we encounter on a compiler/compiled version to check something this will be hard in the future.

a clear definition will be better. Sure, there can be problems when an implementation will not be precise enough or a compiler will make something wrong. But the same can happen if you have buggy hardware (memory errors for example)..

but, this is just a loud thinking if it will possible to go away from the g++ builds to a more abstract layer

[rubygon]

RFC is not clear to me. There should be some clear definition for RFC to easily understand by non-technical people like me. It should have information with how it is implemented into bitcoin? What one can do with the RFC? What are the pros and cons of using it.