[Bitcoin-development] Running a full node

2014-11-06 Thread Francis GASCHET
Dear all, I'm currently discovering the Bitcoin's universe. I installed bitcoind on my PC and I'm currently testing different things on testnet. I just read an article saying that the risk for Bitcoin in the future is

[Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT

2014-11-06 Thread Peter Todd
So right now git head will accept the following invalid transaction into the mempool:

Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT

2014-11-06 Thread Peter Todd
On Thu, Nov 06, 2014 at 05:38:20AM -0500, Peter Todd wrote: So right now git head will accept the following invalid transaction into the mempool:

Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT

2014-11-06 Thread Pieter Wuille
On Thu, Nov 6, 2014 at 2:38 AM, Peter Todd p...@petertodd.org wrote: However the implementation of the STRICTENC flag simply makes pubkey formats it doesn't recognize act as through the signature was invalid, rather than failing the transaction. Similar to the invalid due to too many sigops

Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT

2014-11-06 Thread Pieter Wuille
On Thu, Nov 6, 2014 at 2:47 AM, Pieter Wuille pieter.wui...@gmail.com wrote: I suggest we either change STRICTENC to simply fail unrecognized pubkeys immediately - similar to how non-standard signatures are treated - or fail the script if the pubkey is non-standard and signature verification

Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT

2014-11-06 Thread Peter Todd
On Thu, Nov 06, 2014 at 02:47:29AM -0800, Pieter Wuille wrote: On Thu, Nov 6, 2014 at 2:38 AM, Peter Todd p...@petertodd.org wrote: However the implementation of the STRICTENC flag simply makes pubkey formats it doesn't recognize act as through the signature was invalid, rather than failing

Re: [Bitcoin-development] Running a full node

2014-11-06 Thread Thomas Zander
On Thursday 6. November 2014 10.51.38 Francis GASCHET wrote: Dear all, I'm currently discovering the Bitcoin's universe. I installed bitcoind on my PC and I'm currently testing different things on testnet. I just read an article saying that the risk for Bitcoin in the future is the

Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT

2014-11-06 Thread Marius Hanne
On Thu, 6 Nov 2014 05:45:09 -0500 Peter Todd p...@petertodd.org wrote: On Thu, Nov 06, 2014 at 05:38:20AM -0500, Peter Todd wrote: So right now git head will accept the following invalid transaction into the mempool:

[Bitcoin-development] Nakapay - Proposal for payment method using client generated paycodes and federated paycode servers

2014-11-06 Thread Michael McLees
I sent this yesterday but it is not showing in the archives, so I'm not sure if I did it correctly. I sent it prior to subscribing, so perhaps that mucked it up. nakapay.com I have developed a system whereby a person requesting Bitcoin can make a specific request (amount, address, timeframe,

[Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Peter Todd
Recently wrote the following for a friend and thought others might learn from it. Nope, never heard that term. By bug-for-bug compatibility, do you mean that, for each version which has a bug, each bug must behave in the *same* buggy way? Exactly. tl;dr: if you accept a block as valid due

Re: [Bitcoin-development] Running a full node

2014-11-06 Thread odinn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 If you are considering running a full node (or think you are running one), you should read the comments here: https://www.reddit.com/r/Bitcoin/comments/1scd4z/im_running_a_full_node_and_so_should_you/cdw38ve Thomas Zander wrote: On Thursday 6.

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Tamas Blummer
Thanks Peter, Having tried to write a bug-for-bug compatible code with Satoshi, I can only second that it is rather close to impossible. The aim of BIP62 is noble, still it does not feel right for me to increase the complexity of the code with e.g. soft-fork-ready versioning. Freezing the

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Matt Corallo
Depends, without BIP62 a /lot/ of the even basic contracts that people want to use today (or wanted to use 18 months ago) are unusable, in fact, without BIP62, the atomic swaps suggested as important for sidechains are not secure. While redoing Bitcoin in a hardfork is nice, its a very long-term

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Jeff Garzik
IMO, CHECKLOCKTIMEVERIFY should be included in that list, too. RE soft fork vs. hard fork: It's about this time at Mike Hearn will chime in, on the side of hard forks. Hard forks are in a sense much cleaner, and permit solving problems not otherwise solvable with a hard fork. However, hard

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Justus Ranvier
On 11/06/2014 04:11 PM, Jeff Garzik wrote: RE soft fork vs. hard fork: It's about this time at Mike Hearn will chime in, on the side of hard forks. Hard forks are in a sense much cleaner, and permit solving problems not otherwise solvable with a hard fork. However, hard forks clearly have

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Peter Todd
On Thu, Nov 06, 2014 at 10:05:54PM +, Matt Corallo wrote: Depends, without BIP62 a /lot/ of the even basic contracts that people want to use today (or wanted to use 18 months ago) are unusable, in fact, without BIP62, the atomic swaps suggested as important for sidechains are not secure.

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Peter Todd
On Thu, Nov 06, 2014 at 11:11:52PM +0100, Jeff Garzik wrote: IMO, CHECKLOCKTIMEVERIFY should be included in that list, too. RE soft fork vs. hard fork: It's about this time at Mike Hearn will chime in, on the side of hard forks. Hard forks are in a sense much cleaner, and permit solving

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Peter Todd
On Thu, Nov 06, 2014 at 04:48:54PM -0600, Justus Ranvier wrote: Why not schedule protocol upgrades every two years for the foreseeable future? For the same reason we don't do hard-forking upgrades of basically every protocol on the planet on a regular basis, even when we don't have consensus

Re: [Bitcoin-development] DS Deprecation Window

2014-11-06 Thread Tom Harding
Added a section Confidence to include tx1 and subsection Deliberate delay attack https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md I found that under concerted attack, if miner excludes any transaction first seen less than 30 seconds ago, or double-spent less than 30 seconds after

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Peter Todd
On Thu, Nov 06, 2014 at 05:36:55PM -0600, Justus Ranvier wrote: This explanation is completely incoherent. Because Bitcoin has a extra consensus requirements, requirements which are really rare in engineering, the necessity of fixing bugs is even greater. There are two general ways to fix

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Gregory Maxwell
On Thu, Nov 6, 2014 at 11:12 PM, Peter Todd p...@petertodd.org wrote: BIP62 does make life easier for wallet authors as they don't have to deal with malleability - maybe! - Yes, I agree for most contract purposes CTLV is what you want to be using, instead of refund transactions beyond being