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

Shane Kinney modsix at gmail.com
Sun Jan 1 00:06:41 UTC 2017

URL: <http://therealbitcoin.org/ml/btc-dev/attachments/20161231/attachment.txt?sha1=0a50302c9331b2828bf6756887929b9a33196153>
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

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
Version: GnuPG v1.4.10 (FreeBSD)


More information about the BTC-dev mailing list