[BTC-dev] The Bitcoin Foundation: STATE OF BITCOIN ADDRESS

[Shane Kinney]

URL: <http://therealbitcoin.org/ml/btc-dev/attachments/20161231/attachment.txt?sha1=0a50302c9331b2828bf6756887929b9a33196153>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

 ..::[ The Bitcoin Foundation: STATE OF BITCOIN ADDRESS ]::..

     [        Date: 2016.12.28                          ]
     [   Co-Chairs: mod6 [R.01] && ben_vulpes [R.02]    ]

0x00]: Introduction

   It is with great honor and privilege that The Bitcoin Foundation embraces
   this opportunity to address the public on the state of current progress,
   obstacles and continuing steps in our mission.

   During the course of December, The Foundation continued its focus towards
   review, testing of submitted, and newly created vpatches for the Reference
   Implementation.

0x01]: Accomplishments

   ben_vulpes published a genesis vpatch [R.03] of his `VEH' implementation.

0x02]: Complications and Obstacles

   During review and testing of newly proposed vpatches this interval, it was
   noted that behavior in mod6's implementation of V is incorrect; generally,
   a more strict `wot-variant' implementation is required.

   Specifically, mod6's `v.pl' (99995) does not check the signatures for any
   patch that is WILD and presses them unchecked.  This is a bug.  Proper
   vtronics, under no circumstances, should acknowledge a vpatch unless it has
   a corresponding, valid, signature.

   As stated, the most appropriate fix for this defect is to implement a more
   strict wot-variant V so these unsigned vpatches are ignored.  This will
   resolve the problem described above with WILD vpatches.

   Another problem still exists with orphaned vpatches when the following
   situation occurs: you have vpatches a->b->c->d, then you remove c.vpatch.
   At this point, V (99995) will incorrectly detect 'd' as a 'root' since it has
   no antecedents. By adding a more strict check when selecting roots, by
   ensuring that all antecedents are equal to false, then this problem is
   resolved.  The resulting flow should be a->b [R.04] [R.05].

   Work on these issues is currently underway.  The bulk of work will be in
   testing to ensure correctness.  A new release will be prepared and published
   when testing is complete.

0x03]: Continuing Steps

   ben_vulpes requested a change to implement an additional parameter to the
   previously posted mod6_privkey_tools.vpatch [R.06].  The new parameter is
   to allow the user to begin scanning at a specific block height for associated
   UTXOs, as opposed to the default, the entire chain.

   mod6 completed the implementation early in the month, and testing has been
   on-going since this time.

   Additionally, mod6 has begun review, and regrinding of polarbeard's [R.07]
   send rawtransaction vpatch [R.08].  This proposed vpatch will need much
   testing to validate correctness.  To this end, mod6 has started creating
   additional tools to help with this process.  All of which are still
   in-progress or currently being tested.

   All of the progress here will continue after the necessary changes to mod6's
   V implementation are complete.

0x04]: Conclusion

   The Bitcoin Foundation would like to bestow our sincerest thanks and
   gratitude to the contributors and community for its support and insight.

[ References ]:

  [R.01]: 027A 8D7C 0FB8 A166 4372 0F40 7217 05A8 B71E ADAF
  [R.02]: 4F79 0794 2CA8 B89B 01E2 5A76 2AFA 1A9F D2D0 31DA
  [R.03]: http://cascadianhacker.com/vehlisp-genesisvpatch
  [R.04]: http://btcbase.org/log/2016-12-23#1589010
  [R.05]: http://btcbase.org/log/2016-12-29#1592726
  [R.06]: http://thebitcoin.foundation/ml/btc-dev/2016-November/000241.html
  [R.07]: 3DB7 D131 FE4F FF3C A6BB AC30 11CC 9042 929D 3682
  [R.08]: http://btcbase.org/log/2016-02-07#1398974
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)

iQIcBAEBCgAGBQJYaE9sAAoJEHIXBai3Hq2vOSkP/2CcaBGWZt/IO8CkbANUNZ9z
6Qczj6Ps/2hOqA0dVPZuiCo3+xSajG25yw252AlKTVroJQ7iFDeeHG1bJcEvYjzm
GvZ+tIdVn4CrUuLrdrUJXkQ3XzFfm36x00HLGFp9UTKxpEs3rBbLeTF8QofPXZJQ
jIK36OHoLg7cqqn504AtCI+iXHIJlO1dYaUuB/ZCD3nhd3UaTcTu3ycpyvIiB3wQ
vDv6oaYc4XLHKqmm4nqALh4nhOXuobv+DMj21ia3UCkvL77A0hPIC4Rd7UspV8Sd
r25dn7zQaM2u0JTsrOFVqm6SdpRL4SvwI99vSXFGP1qYiVvSVWu3kx2N8Vzw9x2E
Sv99fv8r/G0J8+qA2FBXwPenvoK09mVIXP+eY42Jnah3dWYzz3Q4/k/Re7GeYDW+
WxYOn6RfPr/Xp/idHp5DY8tmic1rvnela4XEjhR3aB63uiR0b4qk/1geC3dTGqHy
JoYBdVpa/mC768JbmQQx8/BmFuDvMUdMldo3IfGTmFDkRX8WBcld3MToT1gSkNuE
RCoeEjbTb3w2hV+FtWc1bp1ROH8SIUD9RCBKhH9zKhGBETebA+V+wz6fqoLp08vY
mWOj0neXHW5zPvF/xF96BEuS7otDxVLjJ7waU9CMG+kZX+4ukRRQDJ0fsguIbqCN
SgTe5Ey5QRBCwmynXnDi
=Ujn9
-----END PGP SIGNATURE-----