[BTC-dev] The Bitcoin Foundation: STATE OF BITCOIN ADDRESS
modsix at gmail.com
Sun Jan 1 00:06:41 UTC 2017
-----BEGIN PGP SIGNED MESSAGE-----
..::[ The Bitcoin Foundation: STATE OF BITCOIN ADDRESS ]::..
[ Date: 2016.12.28 ]
[ Co-Chairs: mod6 [R.01] && ben_vulpes [R.02] ]
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
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.
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.07]: 3DB7 D131 FE4F FF3C A6BB AC30 11CC 9042 929D 3682
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
-----END PGP SIGNATURE-----
More information about the BTC-dev