public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tom Zander <tomz@freedommail.ch>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] (no subject)
Date: Sun, 16 Oct 2016 22:45:19 +0200	[thread overview]
Message-ID: <3326159.7vNQY8OkXt@strawberry> (raw)
In-Reply-To: <5803D698.2080102@mattcorallo.com>

On Sunday, 16 October 2016 19:35:52 CEST Matt Corallo wrote:
> You keep calling flexible transactions "safer", and yet you haven't
> mentioned that the current codebase is riddled with blatant and massive
> security holes.

I am not afraid of people finding issues with my code, I'm only human. Would 
appreciate you reporting actual issues instead of hinting at things here.
Can't fix things otherwise :)

But, glad you brought it up, the reason that FT is safer is because of the 
amount of conceps that SegWit changes in a way that anyone doing development 
on Bitcoin later will need to know about them in order to do proper 
development.
I counted 10 in my latest vlog entry.  FT only changes 2.

Its safer because its simpler.

> For example, you seem to have misunderstood C++'s memory
> model - you would have no less than three out-of-bound, probably
> exploitable memory accesses in your 80-LoC deserialize method at
> https://github.com/bitcoinclassic/bitcoinclassic/blob/develop/src/primitiv
> es/transaction.cpp#L119 if you were to turn on flexible transactions (and
> I only reviewed that method for 2 minutes). 

The unit test doesn't hit any of them. Valgrind only reports such possibly 
exploitable issues in secp256k and CKey::MakeNewKey. The same as in Core.

I don't doubt that your 2 minute look shows stuff that others missed, and 
that valgrind doesn't find either, but I'd be really grateful if you can 
report them specifically to me in an email off list (or github, you know the 
drill).
More feedback will only help to make the proposal stronger and even better. 
Thanks!

> If you want to propose an
> alternative to a community which has been in desperate need of fixes to
> many problems for several years, please do so with something which would
> not take at least a year to complete given a large team of qualified
> developers.

I think FT fits the bill just fine :)  After your 2 minute look, take a bit 
longer and check the rest of the code. You may be surprised with the 
simplicity of the approach.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


  reply	other threads:[~2016-10-16 20:45 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-16 14:31 [bitcoin-dev] Start time for BIP141 (segwit) Pieter Wuille
2016-10-16 14:58 ` Tom Zander
2016-10-16 16:35   ` Gavin Andresen
2016-10-16 16:42     ` Tom Zander
2016-10-16 16:57       ` Johnson Lau
2016-10-16 17:04       ` [bitcoin-dev] On the security of soft forks Matt Corallo
2016-10-16 16:42     ` [bitcoin-dev] Start time for BIP141 (segwit) Eric Voskuil
2016-10-16 16:47     ` Douglas Roark
2016-10-16 18:20       ` Tom Zander
2016-10-16 18:41         ` Jorge Timón
2016-10-16 18:54           ` Tom Zander
2016-10-16 19:11             ` Johnson Lau
2016-10-16 20:08               ` Tom Zander
2016-10-17  3:46                 ` Johnson Lau
2016-10-16 19:35         ` [bitcoin-dev] (no subject) Matt Corallo
2016-10-16 20:45           ` Tom Zander [this message]
2016-10-17 13:13             ` Btc Drak
2016-10-16 19:49         ` [bitcoin-dev] Start time for BIP141 (segwit) Douglas Roark
2016-10-16 20:58           ` Tom Zander
2016-10-16 21:03             ` gb
2016-10-16 21:08             ` Marek Palatinus
2016-10-16 21:19             ` Andrew C
2016-10-17 11:17               ` Tom Zander
2016-10-17 13:09                 ` Peter Todd
2016-10-17 13:19                 ` Andrew C
2016-10-17 13:27                   ` Btc Drak
2016-10-17 13:31                 ` Jorge Timón
2016-10-16 20:14         ` Btc Drak
2016-10-16 16:08 ` Chris Belcher
2016-10-16 17:52 ` Matt Corallo
2016-10-16 21:49 ` Peter Todd
  -- strict thread matches above, loose matches on Subject: below --
2015-10-24 16:30 [bitcoin-dev] (no subject) cAmiLLe miGnon tRixia P. Anecito

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3326159.7vNQY8OkXt@strawberry \
    --to=tomz@freedommail.ch \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox