概述
增加一种方式让 floodfills 广告支持可选签名类型。 这将为长期支持新签名类型提供一种方法，即使并非所有实现都支持它们。
动机
GOST 提案 134 揭示了几个关于之前未使用的实验性签名类型范围的问题。
首先，由于实验性范围内的签名类型无法保留，它们可能会同时用于多个签名类型。
其次，除非一个具有实验性签名类型的路由器信息或租赁集可以存储在 floodfill 中，否则新的签名类型很难进行完整地测试或试用。
第三，如果提案 136 被实施，这并不安全，因为任何人都可以覆盖一个条目。
第四，实现一种新的签名类型可能是一个大型的开发工作。 在特定版本发布的时间内说服所有路由器实现的开发人员支持新的签名类型可能很困难。开发人员的时间和动机可能会有所不同。
第五，即使 GOST 使用标准范围内的签名类型，仍然无法确定特定 floodfill 是否支持 GOST。
设计
所有 floodfills 必须支持签名类型 DSA (0), ECDSA (1-3), 和 EdDSA (7)。
对于标准（非实验性）范围内的任何其他签名类型，floodfill 可以在其路由器信息属性中广告支持。
规范
支持可选签名类型的路由器应在其发布的路由器信息中添加 “sigTypes” 属性， 使用逗号分隔的签名类型数字。 签名类型将按数字顺序排序。 强制性签名类型（0-4,7）不应包含。
例如：sigTypes=9,10
支持可选签名类型的路由器必须仅存储、查找或洪泛到广告支持该签名类型的 floodfills。
迁移
不适用。 只有支持可选签名类型的路由器必须实现。
问题
如果支持签名类型的 floodfills 不多，可能会难以找到它们。
可能没有必要要求所有 floodfills 支持 ECDSA 384 和 521（签名类型 2 和 3）。 这些类型的使用并不广泛。
类似的问题将需要与非零加密类型一起解决，这尚未正式提议。
备注
对于不在实验范围内的未知签名类型的 NetDB 存储，floodfills 会继续拒绝， 因为无法验证签名。