Topic: RFCs for Bitcoin (Read 1041 times)
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.
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
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:
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
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.
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?
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).
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.
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).
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).
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.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
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.
Quote
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
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. 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
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.
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
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
Jump to: