Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
> > > Who benefits from not fixing bugs in Bitcoin? > > We can bring up politics if you want. No, please don't. That question was rhetorical, not an invitation for you to try and convince bystanders that anyone who disagrees with you is a shadowy Agent Of Centralisation or an idiot. You use that tactic way too much: it's obnoxious and you need to stop it. Hard forks vs soft forks are *purely* about whether you drag along old nodes in a quasi-broken state. They do not reduce total work needed by the community one iota. Non-miners who wish to reject a soft fork can easily run a node that does so, if they wanted to - the voting mechanism still boils down to "which side of the fork do I accept in my economic activity". It's certainly garbage to claim that the reason to want to avoid soft forks is being an Evil Centralised Foundation: this is about a set of engineering tradeoffs only. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
On Fri, Nov 7, 2014 at 12:30 PM, Clément Elbaz wrote: > Thinking out loud here : would it make sense to separate the consensus code > into some kind of "Bitcoin Kernel" (similar to the Linux Kernel) project > that could be used by anyone ? Yes, we're moving in that direction. First with a script verification library in 0.10, which will be extended to other parts of the consensus by 0.11 and after that. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
On Fri, Nov 07, 2014 at 11:30:22AM +, Clément Elbaz wrote:
> Thinking out loud here : would it make sense to separate the consensus code
> into some kind of "Bitcoin Kernel" (similar to the Linux Kernel) project
> that could be used by anyone ?
That's a pretty old idea, and we're working on it. First step is a
stand-alone script verification library:
https://github.com/theuni/bitcoin/blob/da18a0266c4de76c2a461cc2984aa2fa066c42f5/src/script/bitcoinconsensus.h
#ifndef H_BITCOIN_BITCOINCONSENSUS
#define H_BITCOIN_BITCOINCONSENSUS
#if defined(BUILD_BITCOIN_INTERNAL) && defined(HAVE_CONFIG_H)
#include "config/bitcoin-config.h"
#if defined(_WIN32)
#if defined(DLL_EXPORT)
#if defined(HAVE_FUNC_ATTRIBUTE_DLLEXPORT)
#define EXPORT_SYMBOL __declspec(dllexport)
#else
#define EXPORT_SYMBOL
#endif
#endif
#elif defined(HAVE_FUNC_ATTRIBUTE_VISIBILITY)
#define EXPORT_SYMBOL __attribute__ ((visibility ("default")))
#endif
#elif defined(MSC_VER) && !defined(STATIC_LIBBITCOINCONSENSUS)
#define EXPORT_SYMBOL __declspec(dllimport)
#endif
#ifndef EXPORT_SYMBOL
#define EXPORT_SYMBOL
#endif
#ifdef __cplusplus
extern "C" {
#else
#include
#endif
/** Script verification flags */
enum
{
bitcoinconsensus_SCRIPT_FLAGS_VERIFY_NONE = 0,
bitcoinconsensus_SCRIPT_FLAGS_VERIFY_P2SH = (1U << 0), // evaluate
P2SH (BIP16) subscripts
};
/// Returns true if the input nIn of the serialized transaction pointed to by
/// txTo correctly spends the scriptPubKey pointed to by scriptPubKey under
/// the additional constraints specified by flags.
EXPORT_SYMBOL bool bitcoinconsensus_verify_script(const unsigned char
*scriptPubKey, const unsigned int scriptPubKeyLen,
const unsigned char *txTo, const
unsigned int txToLen,
const unsigned int nIn, const unsigned int
flags);
EXPORT_SYMBOL unsigned int bitcoinconsensus_version();
#ifdef __cplusplus
} // extern "C"
#endif
#undef EXPORT_SYMBOL
#endif // H_BITCOIN_BITCOINCONSENSUS
--
'peter'[:-1]@petertodd.org
01208038fd7130083ff118147890dbb37913ffa83c1f48cd
signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
Thinking out loud here : would it make sense to separate the consensus code into some kind of "Bitcoin Kernel" (similar to the Linux Kernel) project that could be used by anyone ? Bitcoin Core (and any other application wishing to do so) could be based on it. The kernel would just contain the absolute minimum code for reaching consensus, leaving every other aspects of the implementation to the applications built with it. It would be stateless : it would provide an interface to submit a block/transaction to be validated, including the context needed to validate it (the previously validated blocks referenced by this block/transaction). What do you think ? Clément Le Fri Nov 07 2014 at 9:49:05 AM, Peter Todd a écrit : On Fri, Nov 07, 2014 at 09:07:47AM +0100, Tamas Blummer wrote: > > Peter, > > > > forking would work best with a freeze of the consensus code. Do you see > any chance for that? > > To a first approximation the consensus code *is* frozen; if we introduce > any consensus changes into it at this point it's due to a mistake, not > intentionally. > > Of course, that's not including the two serious soft-fork proposals in > the air right now, Pieter Wuille's BIP62 and my CHECKLOCKTIMEVERIFY. > However dealing with proposed changes like those in an environment where > the competing implementations all use essentially the same > consensus-critical code is much easier than in an environment where they > don't; I say this on both a technical and political level. > > -- > 'peter'[:-1]@petertodd.org > 0c901eb1b6b765519b99c3afd7a9062ff4cfa29666ce140d > > -- > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
On Fri, Nov 07, 2014 at 09:07:47AM +0100, Tamas Blummer wrote: > Peter, > > forking would work best with a freeze of the consensus code. Do you see any > chance for that? To a first approximation the consensus code *is* frozen; if we introduce any consensus changes into it at this point it's due to a mistake, not intentionally. Of course, that's not including the two serious soft-fork proposals in the air right now, Pieter Wuille's BIP62 and my CHECKLOCKTIMEVERIFY. However dealing with proposed changes like those in an environment where the competing implementations all use essentially the same consensus-critical code is much easier than in an environment where they don't; I say this on both a technical and political level. -- 'peter'[:-1]@petertodd.org 0c901eb1b6b765519b99c3afd7a9062ff4cfa29666ce140d signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
Peter, forking would work best with a freeze of the consensus code. Do you see any chance for that? Tamas Blummer On Nov 7, 2014, at 1:03 AM, Peter Todd wrote: > Forking the codebase, rather than rewriting it, best > ensures that your code actually implements the protocol properly, is > safe to use for mining, and actually gets used. > > Rewriting Bitcoin Core is a fun project, but it's terrible politics. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
