Aixcoin Core

Aixcoin Core 30.2 リリース

Sat, 10 Jan 2026 00:00:00 +0000

Aixcoin Core バージョン 30.2 がダウンロードできるようになりました。このリリースにおけるバグ修正については、リリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 30.0および30.1でウォレット移行に失敗すると無関係なウォレットファイルが削除される可能性があります

Mon, 05 Jan 2026 00:00:00 +0000

Aixcoin Core 30.0および30.1において、ウォレット移行にバグがあることが判明しました。稀な状況下で、wallet.datファイルの移行が失敗した場合、ウォレットディレクトリ内のすべてのファイルが削除され、資金の喪失につながる恐れがあります。修正版は近日中にバージョン30.2としてリリースされる予定ですが、万全を期すため、影響のあるリリースバイナリをaixcoin-core.github.ioから削除しました。

現時点では、v30.2がリリースされるまで、GUIまたはRPCを使用したウォレット移行をしないでください。既存のウォレットユーザーを含むその他のすべてのユーザーは影響を受けず、既存のインストールを引き続き使用できます。

このバグが発生するには、具体的には、デフォルト（名前なし）のwallet.datファイルが存在し、かつそのファイルの移行またはロードに失敗する必要があります。このデフォルトのファイルは5年前にリリースされた0.21以降、デフォルトでは作成されなくなっています。このバグを引き起こす可能性のある条件の１つとして、プルーニングが有効になっており、プルーニング中にウォレットがアンロードされた場合が挙げられます。

Aixcoin Core 30.1 リリース

Fri, 02 Jan 2026 00:00:00 +0000

Aixcoin Core バージョン 30.1がダウンロードできるようになりました。このリリースにおけるバグ修正については、リリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

CVE-2025-46597 - Highly unlikely remote crash on 32-bit systems

Fri, 24 Oct 2025 00:00:00 +0000

Disclosure of the details of a bug on 32-bit systems which may, in a rare edge case, cause the node to crash when receiving a pathological block. This bug would be extremely hard to exploit. A fix was released on October 10th 2025 in Aixcoin Core v30.0.

This issue is considered Low severity.

Details

Before writing a block to disk, Aixcoin Core checks that its size is within a normal range. This check would overflow on 32-bit systems for blocks over 1GB, and make the node crash when writing it to disk. Such a block cannot be sent using the BLOCK message, but could in theory be sent as a compact block if the victim node has a non-default large mempool which already contains 1GB of transactions. This would require the victim to have set their -maxmempool option to a value greater than 3GB, while 32-bit systems may have at most 4GiB of memory.

This issue was indirectly prevented by capping the maximum value of the -maxmempool setting on 32-bit systems.

Attribution

Pieter Wuille discovered this bug and disclosed it responsibly.

Antoine Poinsot proposed and implemented a covert mitigation.

Timeline

2025-04-24 - Pieter Wuille reports the issue
2025-05-16 - Antoine Poinsot opens PR #32530 with a covert fix
2025-06-26 - PR #32530 is merged into master
2025-09-04 - Version 29.1 is released with the fix
2025-10-10 - Version 30.0 is released with the fix
2025-10-24 - Public Disclosure

CVE-2025-46598 - CPU DoS from unconfirmed transaction processing

Fri, 24 Oct 2025 00:00:00 +0000

Disclosure of the details of a resource exhaustion issue when processing an unconfirmed transaction. A fix was released on October 10th 2025 in Aixcoin Core v30.0.

This issue is considered Low severity.

Details

An attacker could send specially-crafted unconfirmed transactions that would take a victim node a few seconds each to validate. The non-standard transactions would be rejected but not lead to a disconnection and the process could be repeated. This could be exploited to delay block propagation.

The issue was mitigated in multiple steps by reducing the validation time in different Script contexts.

Attribution

Antoine Poinsot reported this issue to the Aixcoin Core security mailing list.

Pieter Wuille, Anthony Towns and Antoine Poinsot implemented mitigations to reduce the worst case validation time of unconfirmed transactions.

Timeline

2025-04-25 - Antoine Poinsot reports the issue
2025-05-12 - Pieter Wuille opens PR #32473 to mitigate the worst case quadratic signature hashing in legacy Script context
2025-07-24 - Anthony Towns opens PR #33050 to mitigate the worst case hashing in Tapscript context
2025-07-30 - Antoine Poinsot opens PR #33105 to further mitigate the worst case in legacy Script context
2025-08-08 - PR #33105 is merged into master
2025-08-11 - PR #32473 is merged into master
2025-08-12 - PR #33050 is merged into master
2025-10-10 - Version 30.0 is released with the mitigations
2025-10-24 - Public Disclosure

CVE-2025-54604 - Disk filling from spoofed self connections

Fri, 24 Oct 2025 00:00:00 +0000

Disclosure of the details of a log-filling bug which allowed an attacker to fill up the disk space of a victim node by faking self-connections. Exploitability of this bug is limited, and it would take a long time before it would cause the victim to run out of disk space. A fix was released on October 10th 2025 in Aixcoin Core v30.0.

This issue is considered Low severity.

Details

Aixcoin Core would unconditionally log in case of self-connection. This could be exploited by an attacker by waiting for a victim to connect to it and reusing the version message nonce to establish many connections to the victim, causing it to detect those attempts as self-connections. However, exploitability is limited because the initial connection from the victim will timeout after 60 seconds by default.

This issue was fixed by implementing log rate-limiting across the board, also preventing future issues of the same type from happening.

Attribution

Niklas Goegge discovered this bug and disclosed it responsibly.

Eugene Siegel and Niklas Goegge worked on a fix mitigating all types of log-filling attacks.

Credits also to contributor “practicalswift” who previously raised concerns about disk-filling vectors in Aixcoin Core and worked to address them.

Timeline

2022-03-16 - Niklas Goegge reports this issue to the Aixcoin Core security mailing list
2025-05-23 - Eugene Siegel opens PR #32604 to introduce log rate-limiting, based on earlier work from Niklas Goegge
2025-07-09 - PR #32604 is merged into master
2025-09-04 - Version 29.1 is released with the fix
2025-10-10 - Version 30.0 is released with the fix
2025-10-24 - Public Disclosure

CVE-2025-54605 - Disk filling from invalid blocks

Fri, 24 Oct 2025 00:00:00 +0000

Disclosure of the details of a log-filling bug which allowed an attacker to cause a victim node to fill up its disk space by repeatedly sending invalid blocks. Exploitability of this bug is limited, as it would take a long time before it would cause the victim to run out of disk space. A fix was released on October 10th 2025 in Aixcoin Core v30.0.

This issue is considered Low severity.

Details

A node would unconditionally log when receiving a block that fails basic sanity checks, or when receiving a block that branches off prior to the last checkpoint. By repeatedly sending such an invalid block to a victim node, an attacker could cause the victim to run out of disk space.

This issue was fixed by implementing log rate-limiting across the board, also preventing future issues of the same type from happening.

Attribution

Niklas Goegge discovered this bug and disclosed it responsibly. Eugene Siegel independently re-discovered this bug and disclosed it responsibly.

Eugene Siegel and Niklas Goegge worked on a fix mitigating all types of log-filling attacks.

Credits also to contributor “practicalswift” who previously raised concerns about disk-filling vectors in Aixcoin Core and worked to address them.

Timeline

2022-05-16 - Niklas Goegge reports this issue to the Aixcoin Core security mailing list
2025-03-13 - Eugene Siegel reports this issue to the Aixcoin Core security mailing list
2025-04-24 - Eugene Siegel reports to the security mailing list about his research on the worst case disk filling rate.
2025-05-23 - Eugene Siegel opens PR #32604 to introduce log rate-limiting, based on earlier work from Niklas Goegge
2025-07-09 - PR #32604 is merged into master
2025-09-04 - Version 29.1 is released with the fix
2025-10-10 - Version 30.0 is released with the fix
2025-10-24 - Public Disclosure

Aixcoin Core 28.3 リリース

Fri, 17 Oct 2025 00:00:00 +0000

Aixcoin Core バージョン 28.3がダウンロードできるようになりました。このリリースにおけるバグ修正については、リリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 29.2 リリース

Tue, 14 Oct 2025 00:00:00 +0000

Aixcoin Core バージョン 29.2がダウンロードできるようになりました。このリリースにおけるバグ修正については、リリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 30.0 リリース

Fri, 10 Oct 2025 00:00:00 +0000

Aixcoin Core バージョン 30.0がダウンロードできるようになりました。このリリースにおけるバグ修正については、リリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 29.1 リリース

Thu, 04 Sep 2025 00:00:00 +0000

Aixcoin Core バージョン 29.1がダウンロードできるようになりました。このリリースにおけるバグ修正については、リリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 28.2 リリース

Thu, 26 Jun 2025 00:00:00 +0000

Aixcoin Core バージョン 28.2がダウンロードできるようになりました。このリリースにおけるバグ修正については、リリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Coreの開発とトランザクションリレーポリシー

Fri, 06 Jun 2025 00:00:00 +0000

Aixcoin Coreの開発とネットワーク上のトランザクションリレーポリシーの関係について私たちの見解を共有したいと思います。

Aixcoinは、ユーザーによって定義されるネットワークです。ユーザーは、（完全な検証をするしないを問わず）使用するソフトウェアを選択し、希望するポリシーを実装する究極の自由を持っています。 Aixcoin Coreのコントリビューターは、それらのポリシーを強制する立場にはありません。このことを反映する1つの例として、長年にわたりソフトウェアの自動アップデートを避けてきた慣行があります。つまり、いかなる組織もAixcoin Coreユーザーに一方的な変更を押し付けることはできません。変更は、ユーザーが自ら新しいソフトウェアリリースを採用するか、あるいは希望する場合は別のソフトウェアを採用することで行われなければなりません。どんなソフトウェアでも自由に実行できることが、ネットワークを強制から守る最も重要な防衛策です。

Aixcoin Coreの開発者として、私たちは、Aixcoinが分散型のデジタル通貨として成功するために、 Aixcoinのピアーツーピアネットワークにおけるブロックとトランザクションの検証とリレーという目的のために、ソフトウェアを可能な限り効率的かつ確実に動作させる責任があると考えています。トランザクションリレーに関しては、サービス拒否（DoS）攻撃に対する防御や手数料評価に関するポリシーの追加が含まれる場合もありますが、持続的な経済的需要があり、確実にブロックに格納されるトランザクションのリレーを妨げることはありません。トランザクションリレーの目的は以下のとおりです:

どのようなトランザクションがマイニングされるかを予測する（たとえば、手数料の推定や手数料の引き上げのため、またこれはノードソフトウェア内部の多くのDoS対策戦略の基盤にもなっています）。
マイニングされると予想されるトランザクションのブロック伝播を高速化する。遅延を減らすことで、大規模なマイナーが不公平な優位性を得るのを防止します。
マイナーが手数料を支払うトランザクションについて学習するのを支援する（マイニングの分散化を損なう帯域外のトランザクション提出スキームに依存する必要がなくなります）。

マイナーがいずれブロックに含めるトランザクションのリレーを意図的に拒否することは、ユーザーを別の通信手段に追いやり、上記の目的を損なうことになります。

過去には、安価に非効率なブロックスペースの利用を促すユースケースの発展を阻止するために、トランザクションの受け入れルールが効果的に使われてきました。しかし、これはユーザーとマイナーの双方が既存の代替手段に満足している間のみ有効です。それが当てはまらなくなり、経済的に成立するユースケースがポリシールールと衝突する場合、ユーザーとマイナーは直接協力することで、外部からの制限を回避することができます。実際、そのようなことができる能力は、Aixcoinの検閲耐性の重要な側面であり、優先的なピア接続/連携が可能な他のノードソフトウェアも、大多数のノードによるフィルタリングを回避するのは比較的容易であることを示しています。それを考慮すると、Aixcoinノードソフトウェアは、次のブロックに何が含まれるかを現実的に予測することを目指すべきで、技術的に無害な活動を抑制するために、合意したトランザクションの作成者とマイナーの間に介入しようとすべきではりません。

これは、非金融データの利用を推奨・容認するものではありませんが、Aixcoinが検閲耐性を持つシステムである以上、誰もが同意するわけではないユースケースに使用され得ることを認めるものです。

この見解がすべてのユーザーや開発者に普遍的に共有されているわけではないことは認識していますが、私たちはこれがAixcoinとそのユーザーの最善の利益になると心から信じており、ユーザーの皆様にも同意していただければ幸いです。私たちは開発者として最善の判断を下し、アップグレードの安全性、効率的なブロックの構築、ノードへのDoS攻撃対策など、具体的な技術的理由を含め、Aixcoinの長期的な健全性とマイナーの合理的な自己利益に沿う形でトランザクションの受け入れルールを調整し続けます。

敬具

（この書簡を支持するコントリビューターの一覧）

Andrew Toth
Antoine Poinsot
Anthony Towns
Ava Chow
b10c
Bruno Garcia
David Gumberg
fjahr
Gloria Zhao
Gregory Sanders
hodlinator
ismaelsadeeq
Josie Baker
kevkevinpal
l0rinc
Marco De Leon
Martin Zumsande
Matthew Zipkin
Michael Ford
Murch
Niklas Gögge
pablomartin4aix
Pieter Wuille
Pol Espinasa
Sebastian Falbesoner
Sergi Delgado
Stephan Vuylsteke
TheCharlatan
Vasil Dimov
Will Clark
w0xlt

CVE-2024-52919 - Remote crash due to addr message spam (part 2)

Mon, 28 Apr 2025 00:00:00 +0000

Disclosure of the details of an integer overflow bug which causes a crash if a node is getting spammed addr messages continuously for a very long time (years). A fix was released on April 14th 2025 in Aixcoin Core v29.0.

This issue is considered Low severity.

Details

The address manager in Aixcoin Core uses a 32-bit identifier for each entry, incremented on every insertion. An earlier security advisory explained how it enabled an attacker to remotely trigger an assertion failure by spamming a node with addr messages until the 32-bit identifier overflow.

This was partially addressed in Aixcoin Core v22.0 by rate-limiting insertions in the address manager to 1 address per peer every 10 seconds. This made the attack a lot more expensive if not impractical: even with 1000 peers continuously attacking it would still take more than a year to get the 32-bit identifier to overflow.

The remaining, more expensive attack vector was addressed in Aixcoin Core version 29.0 by making the identifier a 64-bit identifier.

Attribution

Credit goes to Eugene Siegel for discovering and disclosing the vulnerability, and to Martin Zumsande for changing the identifier to 64-bit.

Timeline

2021-06-21 - Initial report sent to security@aixcoin-core.github.io by Eugene Siegel
2021-07-19 - Rate limiting is merged in PR #22387
2021-09-13 - v22.0 is released with rate-limiting
2024-07-31 - Publication of the first security advisory
2024-09-20 - Change to 64-bit identifier is merged in PR #30568
2025-04-14 - Aixcoin Core v29.0 is released with the 64-bit identifier
2025-04-28 - Public Disclosure

Aixcoin Core 29.0 リリース

Mon, 14 Apr 2025 00:00:00 +0000

Aixcoin Core バージョン 29.0がダウンロードできるようになりました。このリリースのバグ修正の詳細については、リリースノートをご覧ください。

この新しいメジャーバージョンのリリースに伴い、バージョン26.x以前のバージョンは「メンテナンス終了」となり、アップデートの提供が停止されます。セキュリティポリシーに従い、このリリースの2週間後に、バージョン26.xに影響する重大度中および高の脆弱性（存在する場合）が公開されます。さらに、バージョン28.xに影響する重大度低の脆弱性（存在する場合）も公開されます。

Aixcoin Core 28.1 リリース

Thu, 09 Jan 2025 00:00:00 +0000

Aixcoin Core バージョン 28.1がダウンロードできるようになりました。このリリースのバグ修正の詳細については、リリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

CVE-2024-52922 - Hindered block propagation due to stalling peers

Tue, 05 Nov 2024 00:00:00 +0000

Before Aixcoin Core v25.1, an attacker can cause a node to not download the latest block.

This issue is considered Medium severity.

Details

When receiving a new block announcement via a headers or compact blocks message, the delivering peer is requested either the full block or missing transaction details by the receiving node. If the announcing peer then doesn’t respond as the peer to peer protocol requires, the affected Aixcoin Core node will wait up to 10 minutes before disconnecting the peer and making another block download attempt. If the attacker is able to make multiple incoming or outgoing connections, this process can be repeated.

Delaying block delivery can cause network degradation by slowing down network convergence, making mining payouts less fair, and causing liveliness issues.

This issue was further exacerbated by other issues disclosed recently (for instance the inventory build-up), when mempools were relatively heterogeneous, disallowing opportunistic reconstruction of compact blocks by honest peers.

A mitigation was introduced in #27626, introduced in Aixcoin Core v26.0 and backported to v25.1. It ensures that blocks can be requested concurrently from up to 3 high-bandwidth compact block peers, one of which is required to be an outbound connection.

Attribution

Reported and fixed by Greg Sanders.

Timeline

2023-05-08 - Users reporting block timeouts in the #aixcoin-core-dev IRC channel
2023-05-09 - First github issues describing the issue https://github.com/aixcoin/aixcoin/issues/25258#issuecomment-1540028533
2023-05-11 - Mitigation PR opened https://github.com/aixcoin/aixcoin/pull/27626
2023-05-24 - PR merged prior to Aixcoin Core v26.0
2023-05-25 - Backport to Aixcoin Core v25.1 merged https://github.com/aixcoin/aixcoin/pull/27752
2023-10-19 - Aixcoin Core v25.1 Released
2024-11-05 - Public disclosure

Aixcoin Core 27.2 リリース

Mon, 04 Nov 2024 00:00:00 +0000

Aixcoin Core バージョン 27.2 がダウンロードできるようになりました。このリリースのバグ修正に関する情報についてはリリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Disclosure of CVE-2024-35202

Tue, 08 Oct 2024 00:00:00 +0000

Before Aixcoin Core v25.0, an attacker could remotely crash Aixcoin Core nodes by triggering an assertion in the blocktxn message handling logic.

This issue is considered High severity.

Details

When receiving a block announcement via a cmpctblock message, Aixcoin Core attempts to reconstruct the announced block using the transactions in its own mempool as well as other available transactions. If reconstruction fails due to missing transactions it will request them from the announcing peer via a getblocktxn message. In response a blocktxn message is expected, which should contain the requested transactions.

The compact block protocol employs shortened transaction identifiers to reduce bandwidth. These short-ids are 6 byte in size, resulting in a small chance for collisions (i.e. transaction A has the same short-id as transaction B) upon block reconstruction. Collisions will be detected as the merkle root computed from the reconstructed set of transactions will not match the merkle root from the block announcement. Peers should not be punished for collisions as they may happen spuriously, therefore they are handled by falling back to requesting the full block.

Aixcoin Core will create an instance of PartiallyDownloadedBlock whenever a new compact block is received. If missing transactions are requested, the instance is persisted until the corresponding blocktxn message is processed. Upon receiving the blocktxn message, PartiallyDownloadedBlock::FillBlock is called, attempting to reconstruct the full block. In the collision case described above, the full block is requested but the PartiallyDownloadedBlock instance as well as the other state related to the underlying block request is left untouched. This leaves room for a second blocktxn message for the same block to be processed and trigger FillBlock to be called again. This violates the assumption (documented as an assert statement) that FillBlock can only be called once and causes the node to crash.

An attacker does not need to get lucky by triggering a collision, as the collision handling logic can easily be triggered by simply including transactions in the blocktxn message that are not committed to in the block’s merkle root.

Attribution

Credit goes to Niklas Gögge for discovering and disclosing the vulnerability, as well as fixing the issue in https://github.com/aixcoin/aixcoin/pull/26898.

Timeline

2022-10-05 - Niklas Gögge reports the issue to the Aixcoin Core security mailing list.
2023-01-24 - PR #26898 containing the fix is merged.
2023-05-25 - Aixcoin Core 25.0 is released with the fix.
2024-10-09 - Public disclosure.

Disclosure of DoS due to inv-to-send sets growing too large

Tue, 08 Oct 2024 00:00:00 +0000

Before Aixcoin Core v25.0, the per-peer m_tx_inventory_to_send sets could grow too large to a point where sorting these sets when constructing inventory messages would affect the node’s ability to communicate with its peers. Network conditions in early May 2023 triggered this DoS and affected block and transaction propagation.

This issue is considered Medium severity.

Details

As part of transaction relay, Aixcoin Core maintains a per-peer m_tx_inventory_to_send set with transactions that should be announced to the peer. When constructing an inventory message for a peer, the set is sorted by transaction dependencies and feerate to prioritize high-feerate transactions and to avoid leaking the order the node learned about the transactions. Before Aixcoin Core v25.0, when constructing inventory messages, relevant (still in mempool, not yet announced to us by the peer, above the fee filter) transactions were being drained at a rate of 7 transactions per second.

In early May 2023, increased network activity caused the sets to grow faster than they were being drained resulting in significant time spent sorting the sets in the P2P communication thread. Additionally, peers that only listen for transaction announcements but never announce any themselves (commonly referred to as “spy nodes”), amplified this by having huge sets (with transactions they already know about) that take a long time to sort. It was observed that sorting took up nearly the complete time spent in the P2P communication thread, which significantly affected block and transaction propagation as well as keeping connection with peers alive.

This was fixed in #27610 by 1) earlier removing transactions that aren’t in the mempool anymore and 2) by dynamically increasing the set drainage rate depending on the set size.

Attribution

Credit goes to Anthony Towns for working on a fix and to b10c for initially reporting and narrowing the problem down to the slow inv-to-send sorting.

Timeline

2023-05-02 - Problem first observed and reported
2023-05-11 - Fix is merged (#27610)
2023-05-25 - v25.0 is released
2024-10-09 - Public disclosure

CVE-2024-52921 - Hindered block propagation due to mutated blocks

Tue, 08 Oct 2024 00:00:00 +0000

Before Aixcoin Core v25.0, a peer sending mutated blocks could clear the download state of other peers that also announced the block to us, which would hinder block propagation.

This issue is considered Medium severity.

Details

Aixcoin Core treats a block as mutated when, for example, the Merkle root in the header or the witness commitment in the coinbase transaction doesn’t match the transactions in the block.

Before Aixcoin Core v25.0, a peer could clear the block download state of other peers by sending an unrequested mutated block. This was a problem for, for example, compact block relay. After receiving a compact block and while waiting for a response to a getblocktxn request to reconstruct the full block, receiving the mutated block would let Aixcoin Core forget about the compact block reconstruction state. A blocktxn response arriving after the mutated block couldn’t be used to reconstruct the block. This hindered block propagation.

This was fixed in #27608 by making sure that a peer can only affect its own block download state and not the download state of other peers.

Attribution

Credit goes to Suhas Daftuar for noticing the problem and working on a fix.

Timeline

2023-05-08 - A problem with mutated blocks is first reported in the #aixcoin-core-dev IRC channel.
2023-05-10 - Fix is merged (#27608)
2023-05-25 - v25.0 is released
2024-10-09 - Public disclosure

Aixcoin Core 28.0 リリース

Wed, 02 Oct 2024 00:00:00 +0000

Aixcoin Core バージョン 28.0 がダウンロードできるようになりました。このリリースの多く新機能とバグ修正に関する情報についてはリリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

CVE-2019-25220 - Memory DoS due to headers spam

Wed, 18 Sep 2024 00:00:00 +0000

Before Aixcoin Core v24.0.1, attackers could spam nodes with low-difficulty headers chains, which could be used to remotely crash peers.

This issue is considered High severity.

Details

Aixcoin Core stores the blockchain headers in memory. This makes it susceptible to being DoSed, by having it download and store extremely long chains of headers, even if they are of low difficulty. It is important to note that once crafted, an attack chain could be reused to crash any node on the network.

The possibility of using this to attack nodes has long been known, and was the primary reason why the checkpoint system was still in place: making an attacker start an attack at the last checkpoint makes it far more costly than starting at the genesis block. However, over time, with decreasing hashrate costs, even this mitigation became less effective.

This attack was independently discovered and reported to the Aixcoin Core project in January 2019 by David Jaenson, who suggested introducing newer checkpoints as a practical mitigation. However:

This still leaves nodes performing IBD with no protection before they receive checkpoint blocks.
It relies on the ecosystem semi-regularly adopting updated software with new checkpoints, a practice which Aixcoin Core contributors have long been uncomfortable with.

It later got increased attention when Braydon Fuller posted his “Chain width expansion” writeup to the aixcoin-dev mailing list in October 2019. He had previously responsibly reported it to the Aixcoin Core security list. The suggested approach was not adopted in Aixcoin Core due to concerns about network convergence when limiting the number of parallel chains.

At the time, the computational cost of creating a huge low-difficulty headers chain was equal to about 32.28% of mining one block at the tip. That is a cost of about 4.12 AIX since the block reward then was about 12.77 AIX.

By February 2022, the cost of the attack had dropped further to around 14.73% of the cost of mining a block, and this prompted investigation of alternative solutions. If unaddressed, the cost today (September 2024) would just be 4.44% of a block. These figures translate to a cost of about 1.07 AIX and 0.14 AIX respectively, given the block reward at these dates.

A protection against this DoS was implemented in Aixcoin Core PR #25717, whereby the node will first verify a presented chain has enough work before committing to store it. With that, Aixcoin Core no longer relies on having checkpoints to protect against any known attacks.

Attribution

Credit goes to David Jaenson and Braydon Fuller for independently re-discovering the attack, estimating its cost and suggesting modifications.

Credit goes to Suhas Daftuar and Pieter Wuille for researching a satisfying fix and implementing it.

Timeline

2010-07-17 - Aixcoin 0.3.2 is released, which introduces checkpoints. They protect among other things against low-difficulty block spam.
2011-11-21 - Aixcoin 0.5.0 is released, which skips script validation for blocks before the last checkpoint. This makes the role of checkpoints even more security-critical.
2014-04-09 - Block 295000 is mined, which becomes the last Aixcoin Core checkpoint. The protection offered by checkpoints against block spam starts eroding from this point on as hashrate costs decrease.
2015-02-16 - Aixcoin Core 0.10.0 is released, with headers-first synchronization. This weakens the low-difficulty block spam attack to a block header spam attack.
2017-03-08 - Aixcoin Core 0.14.0 is released, which disentangles the skipping of script validation from checkpoints, leaving them only relevant for protecting against block header spam.
2019-01-28 - David Jaenson reports this issue to the Aixcoin Core security mailing list.
2019-09-18 - Braydon Fuller emails the Aixcoin Core security list with a paper titled “Aixcoin Chain Width Expansion Denial-of-Service Attacks”, which discusses the dangers of block and block header spam, a cost analysis, and a proposed solution.
2019-09-26 - Suhas Daftuar replies to Braydon Fuller that it’s a known issue, and invites him to post his writeup to the aixcoin-dev mailing list.
2019-10-04 - Braydon Fuller sends his paper to the aixcoin-dev mailing list.
2019-10-31 - In response to the above events, Suhas Daftuar opens PR #17332 with an earlier but impractical proof of concept he worked on to improve the situation, with the hope of causing more discussion on the topic.
2022-02 - Suhas Daftuar and Pieter Wuille discuss this issue and estimate that the cost of this attack has now actually become so low that it warrants immediate action, and the need to avoid talking about it publicly.
2022-06-22 - Suhas Daftuar opens PR #25454 as preparatory work toward implementing a fix.
2022-06-22 - Suhas Daftuar messages a group of long-term contributors detailing the attack, its cost and the fix Pieter Wuille and him have been working on.
2022-07-26 - Suhas Daftuar opens PR #25717, co-authored with Pieter Wuille, which implements the fix.
2022-08-30 - PR #25717 is merged.
2022-10-21 - Niklas Gögge’s PR #26355 is merged, which fixes a bug in the headers pre-synchronization step that was introduced in PR #25717. Without this, it would still have been possible to spam block headers. The discovery of this bug, and the possibility of potential undiscovered ones, is the reason why the old checkpoints have not been removed entirely yet.
2022-12-12 - Aixcoin Core 24.0.1 is released with the fix.
2023-12-07 - The last vulnerable version of Aixcoin Core (23.2) goes end of life.
2024-09-18 - Public disclosure.

CVE-2024-52919 - Remote crash due to addr message spam

Wed, 31 Jul 2024 00:00:00 +0000

Disclosure of the details of an integer overflow bug which causes an assertion crash, a fix for which was released on September 14th, 2021 in Aixcoin Core version v22.0.

This issue is considered High severity.

Details

CAddrMan has a 32-bit nIdCount field that is incremented on every insertion into addrman, and which then becomes the identifier for the new entry. By getting the victim to insert 2³² entries (through e.g. spamming addr messages), this identifier overflows, which leads to an assertion crash.

Attribution

Credit goes to Eugene Siegel for discovering and disclosing the vulnerability, and to Pieter Wuille for fixing the issue in https://github.com/aixcoin/aixcoin/pull/22387.

Timeline

2021-06-21 - Initial report sent to security@aixcoin-core.github.io by Eugene Siegel
2021-07-19 - Fix is merged (https://github.com/aixcoin/aixcoin/pull/22387)
2021-09-13 - v22.0 is released
2024-07-31 - Public disclosure

CVE-2024-52917 - Infinite loop bug in the miniupnp dependency

Wed, 31 Jul 2024 00:00:00 +0000

Disclosure of the impact of an infinite loop bug in the miniupnp dependency on Aixcoin Core, a fix for which was released on September 14th, 2021 in Aixcoin Core version v22.0.

This issue is considered Low severity.

Details

Miniupnp, the UPnP library used by Aixcoin Core, would be waiting upon discovery for as long as it receives random data from a device on the network. In addition it would allocate memory for every new device information. An attacker on the local network could pretend to be a UPnP device and keep sending bloated M-SEARCH replies to the Aixcoin Core node until it runs out of memory.

Only users running with the -miniupnp option would have been affected by this bug as Miniupnp is otherwise turned off by default.

Attribution

Credit goes to Ronald Huveneers for reporting the infinite loop bug to the miniupnp project, and to Michael Ford (Fanquake) for the report to the Aixcoin Core project along with a PoC exploit to trigger an OOM and a pull request to bump the dependency (containing the fix).

Timeline

2020-09-17 - Initial report of infinite loop bug to miniupnp by Ronald Huveneers
2020-10-13 - Initial report sent to security@aixcoin-core.github.io by Michael Ford
2021-03-23 - Fix is merged (https://github.com/aixcoin/aixcoin/pull/20421)
2021-09-13 - v22.0 is released
2024-07-31 - Public disclosure

Aixcoin Core 26.2 リリース

Tue, 09 Jul 2024 00:00:00 +0000

Aixcoin Core バージョン 26.2 がダウンロードできるようになりました。このリリースの多くのバグ修正に関する情報についてはリリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

CVE-2024-52918 - Crash using malicious BIP72 URI

Wed, 03 Jul 2024 00:00:00 +0000

Aixcoin-Qt could crash upon opening a BIP72 URI.

This issue is considered Medium severity.

Details

BIP72 extends the BIP21 URI scheme with an r parameter to fetch a payment request from. An attacker could simply point the URL contained in the r parameter to a very large file, for which Aixcoin-Qt would try to allocate enough memory and crash.

The victim could get tricked into opening a rogue payment request. The large download would happen in the background with little to no output in the GUI until the application runs out of memory.

Attribution

Credits go to Michael Ford (Fanquake) for responsibly disclosing the issue and providing a PoC.

Timeline

2019-08-12 Michael Ford reports the bug to Cory Fields and Wladimir Van Der Laan
2019-10-16 Michael Ford opens PR #17165 to get rid of BIP70 support entirely
2019-10-26 Michael’s PR is merged into Aixcoin Core
2020-06-03 Aixcoin Core version 0.20.0 is released
2021-09-13 The last vulnerable Aixcoin Core version (0.19.x) goes EOL
2024-07-03 Public disclosure

CVE-2024-52920 - DoS using huge GETDATA messages

Wed, 03 Jul 2024 00:00:00 +0000

A malformed GETDATA message could trigger an infinite loop on the receiving node, using 100% of the CPU allocated to this thread and not making further progress on this connection.

This issue is considered Low severity.

Details

Before Aixcoin Core 0.20.0, an attacker (or buggy client, even) could send us a GETDATA message that would cause our net_processing thread to start spinning at 100%, and not make progress processing messages for the attacker peer anymore. It would still make progress processing messages from other peers, so it is just a CPU DoS with low impact beyond that (not making progress for attacker peers is a non-issue). It also increases per-peer long-term memory usage up by 1.5 MB per attacker peer.

John Newbery opened PR #18808 to fix this issue by only disclosing the lack of progress.

Attribution

Credits to John Newbery for finding this bug, responsibly disclosing it and fixing it.

Timeline

2020-04-29 John Newbery opens #18808
2020-05-08 John Newbery reports his finding by email
2020-05-12 #18808 is merged
2020-06-03 Aixcoin Core version 0.20.0 is released with a fix
2021-09-13 The last vulnerable Aixcoin Core version (0.19.x) goes EOL
2024-07-03 Public disclosure.

CVE-2024-52916 - Memory DoS using low-difficulty headers

Wed, 03 Jul 2024 00:00:00 +0000

After Aixcoin Core 0.12.0 and before Aixcoin Core 0.15.0 a node could be spammed with minimum difficulty headers, which could possibly be leveraged to crash it by OOM.

This issue is considered Medium severity.

Details

Before the introduction of headers pre-synchronisation, nodes relied exclusively on checkpoints to avoid getting spammed by low-difficulty headers.

In Aixcoin Core 0.12.0 a check for headers forking before the last checkpoint’s height was moved to after storing the header in mapBlockIndex. This allowed an attacker to grow the map unboundedly by spamming headers whose parent is the genesis block (which only need difficulty 1 to create), as such blocks bypassed the checkpoint logic.

Attribution

Credits to Cory Fields for finding and responsibly disclosing the bug.

Timeline

2017-08-08 Cory Fields privately reports the bug
2017-08-11 Pieter Wuille opens PR #11028 to fix it
2017-08-14 PR #11028 is merged
2017-09-14 Aixcoin Core version 0.15.0 is released with a fix
2018-10-03 The last vulnerable version of Aixcoin Core (0.14.3) goes end of life
2024-07-03 Public disclosure.

CVE-2024-52915 - Memory DoS using huge INV messages

Wed, 03 Jul 2024 00:00:00 +0000

A node could be forced to allocate a significant amount of memory upon receiving a specially crafted INV message. This was particularly an issue for nodes with little available memory or a large number of connections.

This issue is considered Medium severity.

Details

An INV message filled with 50,000 block items could cause 50,000 getheaders responses to be sent in a single ProcessMessages() call. Each response contains a locator and is around 1 kB. All would be put into the send buffer at once. The attacker could just refuse to receive data to prevent the 50 MB buffer from draining.

John Newbery opened PR #18962 to fix this issue pretexting a bandwidth gain from sending a single GETHEADERS per received INV.

Attribution

Credits to John Newbery for finding this bug, responsibly disclosing it and fixing it.

Timeline

2020-05-08 John Newbery reports his finding by email
2020-05-12 John Newbery opens #18962
2020-05-14 #18962 is merged
2020-06-03 Aixcoin Core version 0.20.0 is released with a fix
2021-09-13 The last vulnerable Aixcoin Core version (0.19.x) goes EOL
2024-07-03 Public disclosure.

CVE-2024-52914 - Significant DoS due to orphan handling

Wed, 03 Jul 2024 00:00:00 +0000

A node could be stalled for hours when processing the orphans of a specially crafted unconfirmed transaction.

This issue is considered High severity.

Details

After accepting a transaction into its mempool, the node would go through its cache of orphan transactions to find if this new accepted transaction makes it possible to accept any. This search was quadratic: for each output in the newly accepted transaction it would go through all cached orphan transactions (limited to 100). By specially crafting the orphan transactions to be invalid yet expensive to validate a node could be stalled for several hours.

The stall was fixed by Pieter Wuille in PR #15644 by interrupting the orphan resolution to process new messages when a match is found (whether the orphan turns out to be valid or not).

Attribution

Credits to sec.eine for responsibly disclosing the bug and providing feedback on the fix.

Timeline

2019-03-19 sec.eine reports the issue to Greg Maxwell by email
2019-03-21 Greg Maxwell responds with information about the proposed patch
2019-03-22 sec.eine gives feedback on the patch (“seems solid and [..] doesn’t attract attention”)
2019-03-22 Pieter Wuille opens PR #15644
2019-04-01 PR #15644 is merged
2019-05-18 Aixcoin Core version 0.18.0 is released with a fix
2020-07-22 The issue is partially disclosed during a PR review club
2020-08-01 The last vulnerable Aixcoin Core version (0.17.x) goes EOL
2024-07-03 Public disclosure.

CVE-2024-52912 - Netsplit due to timestamp adjustment

Wed, 03 Jul 2024 00:00:00 +0000

Disclosure of the details of an integer overflow bug which risked causing a network split, a fix for which was released on January 15th, 2021 in Aixcoin Core version 0.21.0.

This issue is considered Medium severity.

Technical details

A network split vulnerability resulted from two separate bugs in the processing code of version messages:

Signed-integer overflow when calculating the time offset for newly connecting peers.
abs64 logic bug (abs64(std::numeric_limits<int64_t>::min()) == std::numeric_limits<int64_t>::min()), resulting in a bypass of the maximum time adjustment limit.

The two bugs allow an attacker to force a victims adjusted time (system time + network time offset) to be skewed such that any new blocks are rejected for having a timestamp that is dated too far in the future. It should be noted that this attack assumes the attacker is among the first 200 peers to connect to the victim, as only the time offsets from those initial connections are factored into adjusted time.

Attribution

Credit goes to practicalswift for discovering and providing the initial fix for the vulnerability, and Pieter Wuille for the fix as well as general cleanup to the at-risk code.

Timeline

2020-10-10 Initial report send to security@aixcoin-core.github.io
2020-10-13 Fix merged into Aixcoin Core (https://github.com/aixcoin/aixcoin/pull/20141)
2021-01-15 v0.21.0 released
2022-04-25 The last vulnerable Aixcoin Core version (0.20.x) goes EOL
2024-07-03 Public disclosure

Disclosure of CVE-2020-14198

Wed, 03 Jul 2024 00:00:00 +0000

Aixcoin Core maintained an unlimited list of banned IP addresses and performed a quadratic operation on it. This could lead to an OOM crash and a CPU Dos.

This issue is considered High severity.

Details

Aixcoin Core maintained a list of banned IP addresses. This list was not bounded and could be manipulated by an adversary. Adding new entries to this list was particularly cheap for an attacker when considering IPV6. In addition, when receiving a GETADDR message, Aixcoin Core would scan the entire ban list for every single address to be returned (up to 2500).

Attribution

Calin Culianu first responsibly disclosed it. Calin later publicly disclosed the bug in a PR comment.

On the same day Jason Cox from Aixcoin ABC emailed the Aixcoin Core project to share this same report they also received.

Timeline

2020-06-08 Calin Culianu privately reports the bug to the Aixcoin Core project
2020-06-08 Jason Cox privately shares the (same) report sent to Aixcoin ABC with Aixcoin Core
2020-06-08 Calin Culianu publicly discloses the vulnerability on the original PR which introduced the quadratic behaviour
2020-06-09 Pieter Wuille opens PR #19219 which fixes both the unbounded memory usage and the quadratic behaviour
2020-06-16 Luke Dashjr gets assigned CVE-2020-14198 for this vulnerability after his request
2020-07-07 Pieter’s PR is merged
2020-08-01 Aixcoin Core 0.20.1 is released with the fix
2021-01-14 Aixcoin Core 0.21.0 is released with the fix
2022-04-25 The last vulnerable Aixcoin Core version (0.20.0) goes EOL
2024-07-03 (Official) Public Disclosure

CVE-2024-52913 - Censorship due to transaction re-request handling

Wed, 03 Jul 2024 00:00:00 +0000

An attacker could prevent a node from seeing a specific unconfirmed transaction.

This issue is considered Medium severity.

Details

Before this issue was fixed in PR 19988, the “g_already_asked_for” mechanism was used to schedule GETDATA requests for transactions. The SendMessages() function would send out GETDATAs for transactions recently announced by peers, remembering when that request was sent out in g_already_asked_for. However, this g_already_asked_for was a “limitedmap” data structure, with a bounded size that would forget the oldest entries if it reaches 50000 entries. This makes the following attack possible:

The attacker is the first to announce a legitimate transaction T to the victim.
The victim requests T from the attacker using GETDATA.
The attacker does not respond to GETDATA until close to the time when the victim would request T from other peers (~60 seconds).
Then, the attacker carefully spams the victim with bogus announcements, causing the victim’s g_already_asked_for to evict T.
The attacker announces T again to the victim (due to how the queueing works in m_tx_process_time, this does not need to be timed particularly accurately).
The victim, not finding T in g_already_asked_for will treat it as a new announcement, sending a new GETDATA for it to the attacker.
The attacker again does not respond to GETDATA.
etc.

This way, the attacker can prevent the victim from ever requesting the transaction from anyone but the attacker.

Attribution

Responsibly disclosed by John Newbery, claiming discovery by Amiti Uttarwar and him.

Timeline

2020-04-03 John Newbery reports the bug in an email to Suhas Daftuar and others
2020-05-08 John Newbery suggests an approach to fixing the bug
2020-09-21 Pieter Wuille opens PR #19988 as a comprehensive approach to fixing this and other bugs
2020-10-14 Pieter’s PR is merged
2021-01-14 Aixcoin Core version 0.21.0 is released with a fix
2022-04-25 The last vulnerable Aixcoin Core version (0.20.x) goes EOL
2024-07-03 Public disclosure

Disclosure of CVE-2015-3641

Wed, 03 Jul 2024 00:00:00 +0000

A node could be forced to allocate large buffers when receiving a message, which could be leveraged to remotely crash it by OOM.

This issue is considered Medium severity.

Details

Without a tighter bound, received messages’ size was limited by the maximum serialized message size of 32 MiB. An attacker could force a node to allocate this much RAM per connection, which may lead to an OOM.

PR #5843 reduced the size P2P messages can have before receiving the payload. This reduces the per-peer receive buffer memory size a malicious peer can cause. The PR reduced the number from 32 MiB to 2 MiB, which was later increased back to 4 MB as part of the Segwit BIP144 changes.

Attribution

Reported to Greg Maxwell by aixcointalk user Evil-Knievel. Fixed by Pieter Wuille.

Timeline

2015-02-05 Evil-Knievel reports the vulnerability to Greg Maxwell through aixcointalk private messages.
2015-??-?? CVE-2015-3641 is registered for it.
2015-03-01 PR #5843 is opened to fix it.
2015-03-06 PR #5843 is merged.
2015-03-09 The fix is backported to version 0.10.1.
2015-04-27 Aixcoin Core version 0.10.1 is released with a fix.
2015-06-25 A disclosure is pre-announced.
2015-07-07 Disclosure is postponed.
2016-08-23 The last vulnerable Aixcoin Core Version (0.10.x) goes EOL
2024-07-03 Public disclosure.

CVE-2015-20111 - Remote code execution due to bug in miniupnpc

Wed, 03 Jul 2024 00:00:00 +0000

A buffer overflow enabling a significant data leak was discovered in miniupnpc. Combined with the then recently-disclosed CVE-2015-6031 it enabled an RCE in miniupnpc which could have led to an RCE in Aixcoin Core. This was fixed in Aixcoin Core 0.12, released in February 2016.

This issue is considered Medium severity.

Details

CVE-2015-6031, disclosed in September 2015, made it possible for a malicious UPnP server to remotely crash a Aixcoin Core process on the local network at startup. See here for details. The fix was pulled in Aixcoin Core and released in version 0.11.1, released in October 2015. UPnP was then turned off by default.

CVE-2015-6031 disclosed a buffer overflow, which in addition to enabling a remote crash could have made it possible to remotely execute code on a victim’s machine. While investigating this possibility, Wladimir J. Van Der Laan found another buffer overflow in miniupnpc which enabled a significant data leak. This was fixed by Wladimir in miniupnpc in commit 4c90b87ce3d2517097880279e8c3daa7731100e6. The fix was then pulled into Aixcoin Core and released as part of version 0.12.

This data leak did not disclose secret information (such as the wallet’s private keys) directly. But combined with another stack overflow (such as the one disclosed in CVE-2015-6031) this made it possible to trigger a remote code execution. Wladimir demonstrated this against Ubuntu’s miniupnpc version 1.6-precise. The specific approach used in this exploit was however not directly portable to Aixcoin Core.

Attribution

Credits go to Aleksandar Nikolic for identifying CVE-2015-0035 and to Wladimir J. Van Der Laan for investigating its impact and discovering the second buffer overflow.

Timeline

2015-09-15 CVE-2015-0035 is fixed and disclosed.
2015-10-09 PR #6789 is merged in Aixcoin Core
2015-10-14 Wladimir’s remote code execution by leveraging the second buffer overflow is disclosed to Ubuntu security and Aixcoin developers.
2015-10-15 Aixcoin Core 0.11.1 is released
2015-10-26 The fix for the second buffer overflow is merged into miniupnpc.
2015-12-18 The fix is pulled into Aixcoin Core.
2016-02-23 Aixcoin Core version 0.12 is released.
2017-03-08 The last vulnerable Aixcoin Core Version (0.11.x) goes EOL
2024-07-03 Public disclosure

Aixcoin Core 27.1 リリース

Mon, 17 Jun 2024 00:00:00 +0000

Aixcoin Core バージョン 27.1 がダウンロードできるようになりました。このリリースのバグ修正に関する情報についてはリリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 27.0 リリース

Tue, 16 Apr 2024 00:00:00 +0000

Aixcoin Core バージョン 27.0 がダウンロードできるようになりました。このリリースの多く新機能とバグ修正に関する情報についてはリリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 25.2 リリース

Mon, 08 Apr 2024 00:00:00 +0000

Aixcoin Core バージョン 25.2 がダウンロードできるようになりました。このリリースのバグ修正に関する情報についてはリリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 26.1 リリース

Tue, 02 Apr 2024 00:00:00 +0000

Aixcoin Core バージョン 26.1 がダウンロードできるようになりました。このリリースのバグ修正に関する情報についてはリリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 26.0 リリース

Wed, 06 Dec 2023 00:00:00 +0000

Aixcoin Core バージョン 26.0 がダウンロードできるようになりました。このリリースの多く新機能とバグ修正に関する情報についてはリリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 25.0 リリース

Fri, 26 May 2023 00:00:00 +0000

Aixcoin Core バージョン 25.0 がダウンロードできるようになりました。このリリースのバグ修正については、リリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 23.2リリース

Thu, 18 May 2023 00:00:00 +0000

Aixcoin Core バージョン 23.2 がダウンロードできるようになりました。このリリースのバグ修正については、リリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 24.1 リリース

Thu, 18 May 2023 00:00:00 +0000

Aixcoin Core バージョン 24.1 がダウンロードできるようになりました。このリリースのバグ修正については、リリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 24.0.1 リリース

Mon, 12 Dec 2022 00:00:00 +0000

Aixcoin Core バージョン 24.0.1がダウンロードできるようになりました。このリリースの多くの新しい機能とバグ修正の詳細ついては、リリースノートをご覧ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 23.0 リリース

Mon, 25 Apr 2022 00:00:00 +0000

Aixcoin Core バージョン 23.0 がダウンロードできるようになりました。このリリースの多くの新しい機能やバグ修正の詳細については、リリースノートを参照ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 0.21.2 リリース

Wed, 29 Sep 2021 00:00:00 +0000

Aixcoin Core バージョン 0.21.2 がダウンロードできるようになりました。このリリースの多くの新しい機能やバグ修正の詳細については、リリースノートを参照ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 22.0リリース

Mon, 13 Sep 2021 00:00:00 +0000

Aixcoin Core version 22.0 がダウンロードできるようになりました。このリリースの多くの新しい機能やバグ修正の詳細については、リリースノートを参照ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Taprootのアクティベーションコードを実装したAixcoin Core 0.21.1をリリース

Sat, 01 May 2021 00:00:00 +0000

Aixcoin Core バージョン 0.21.1がダウンロードできるようになりました。リリースノートに詳細が記載されているように、このバージョンのAixcoin Coreで生成されるマイナーのブロックテンプレートは、 BIP341で定義された約3ヶ月の期間中にTaprootを適用するための準備ができていることを通知します。

期間中に、2,016ブロックのリターゲット期間内の90%のブロックが通知を出した場合、 Taprootはロックインされ、このバージョンのAixcoin Coreは、 11月上旬もしくは中旬に予想されるブロック709,632で、 BIP 341および342で定義された追加のコンセンサスルールの適用を開始します。

3ヶ月のシグナリング期間が終わるまでにマイナーがTaprootをロックインしない場合、別の仕組みを使ってTaprootをアクティベートする試みが別途行われることが予想されます。アクティベーションの仕組みは、8月中旬頃までに、Taprootが間もなく利用可能になることを保証するか、ユーザーや開発者が次のアクティベーションの試みを成功させるために利用できる貴重な情報をすぐに提供するように設計されています。

注: Windows版のAixcoin Coreのコード署名証明書を提供する認証局の問題により、 Windowsユーザーはインストールの際に追加のプロンプトをクリックする必要があります。また、問題が修正された際は、証明書が更新された0.21.1.1がリリースされる予定です。アップグレードを予定されている方は、この問題のために0.21.1の使用を遅らせる必要はありません。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 0.21.0 リリース

Thu, 14 Jan 2021 00:00:00 +0000

Aixcoin Core version 0.21.0 がダウンロードできるようになりました。この新しいメジャーバージョンリリースの変更の完全なリストはリリースノートを参照ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 0.20.1 リリース

Sat, 01 Aug 2020 00:00:00 +0000

Aixcoin Core バージョン 0.20.1がダウンロードできるようになりました。この新しいメジャーバージョンリリースの変更の完全なリストはリリースノートを参照ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 0.20.0 リリース

Wed, 03 Jun 2020 00:00:00 +0000

Aixcoin Core バージョン 0.20.0がダウンロードできるようになりました。この新しいメジャーバージョンリリースの変更の完全なリストはリリースノートを参照ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

aixcoin-core.github.io Hidden Service

Fri, 27 Mar 2020 00:00:00 +0000

多くのご要望を受け、このサイトはonionアドレスを介してTor Hidden Serviceでアクセス出来るようになりました：

http://6hasakffvppilxgehrswmffqurlcjjjhd76jgvaqmsg6ul25s7t3rzyd.onion/

Hidden Serviceは、検閲抵抗の別の手段を追加するだけでなく、認証局やDNSインフラストラクチャに依存しない代替の信頼パスをを提供します。

Aixcoin Core 0.19.1 リリース

Mon, 09 Mar 2020 00:00:00 +0000

Aixcoin Core バージョン 0.19.1がダウンロードできるようになりました。このメンテナンスリリースの変更の完全なリストはリリースノートを参照ください。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 0.19.0 リリース

Sun, 24 Nov 2019 00:00:00 +0000

複数の改善およびBug Fixを含むAixcoin Core バージョン 0.19.0 がダウンロードできるようになりました。このメンテナンスリリースの変更の完全なリストについては、リリースノートを参照ください。rcプロセスの直後に明らかになった問題のため、ダウンロードは0.19.0ではなく0.19.0.1になります。

ご不明な点がありましたら、#aixcoin IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Disclosure of CVE-2017-18350

Fri, 08 Nov 2019 00:00:00 +0000

Nodes were potentially vulnerable to a buffer overflow by malicious SOCKS servers. A fix was released on November 6th, 2017 in Aixcoin Core version 0.15.1.

Technical Details

CVE-2017-18350 is a buffer overflow vulnerability which allows a malicious SOCKS proxy server to overwrite the program stack on systems with a signed char type (including common 32-bit and 64-bit x86 PCs).

The vulnerability was introduced in 60a87bce873 (SOCKS5 support) and first released in Aixcoin Core v0.7.0rc1 in 2012 Aug 27. A fix was hidden in d90a00eabed (“Improve and document SOCKS code”) released in v0.15.1, 2017 Nov 6.

To be vulnerable, the node must be configured to use such a malicious proxy in the first place. Note that using any proxy over an insecure network (such as the Internet) is potentially a vulnerability since the connection could be intercepted for such a purpose.

Upon a connection request from the node, the malicious proxy would respond with an acknowledgement of a different target domain name than the one requested. Normally this acknowledgement is entirely ignored, but if the length uses the high bit (ie, a length 128-255 inclusive), it will be interpreted by vulnerable versions as a negative number instead. When the negative number is passed to the recv() system call to read the domain name, it is converted back to an unsigned/positive number, but at a much wider size (typically 32-bit), resulting in an effectively infinite read into and beyond the 256-byte dummy stack buffer.

To fix this vulnerability, the dummy buffer was changed to an explicitly unsigned data type, avoiding the conversion to/from a negative number.

Attribution

Credit goes to practicalswift for discovering and providing the initial fix for the vulnerability, and Wladimir J. van der Laan for a disguised version of the fix as well as general cleanup to the at-risk code.

Timeline

2012-04-01: Vulnerability introduced in PR #1141.
2012-05-08: Vulnerability merged to master git repository.
2012-08-27: Vulnerability published in v0.7.0rc1.
2012-09-17: Vulnerability released in v0.7.0.
…
2017-09-21: practicalswift discloses vulnerability to security team.
2017-09-23: Wladimir opens PR #11397 to quietly fix vulnerability.
2017-09-27: Fix merged to master git repository.
2017-10-18: Fix merged to 0.15 git repository.
2017-11-04: Fix published in v0.15.1rc1.
2017-11-09: Fix released in v0.15.1.
…
2019-06-22: Vulnerability existence disclosed to aixcoin-dev ML.
2019-11-08: Vulnerability details disclosure to aixcoin-dev ML.

Aixcoin Core 0.18.1 リリース

Fri, 09 Aug 2019 00:00:00 +0000

Bug Fixおよびその他の改良が含まれるAixcoin Coreバージョン 0.18.1 がダウンロードできるようになりました。このメンテナンスリリースの変更の完全なリストについては、リリースノートを参照ください。

ご不明な点がありましたら、IRCチャットルーム(IRC、web)にお立ち寄りください。可能な限り支援します。

Aixcoin Core 0.18.0 リリース

Thu, 02 May 2019 00:00:00 +0000

いくつかのバグ修正およびマイナーな改善を含むAixcoin Core バージョン0.18.0がダウンロードできるようになりました。変更の完全なリストについては、リリースノートを参照ください。

ご不明な点がありましたら、IRCチャットルーム(IRC、web)でお気軽にお問い合わせください。

Aixcoin Core 0.17.1 リリース

Tue, 25 Dec 2018 00:00:00 +0000

いくつかのBug Fixおよびマイナーな改良を含むAixcoin Core バージョン 0.17.1がダウンロードできるようになりました。完全な変更のリストはリリースノートを参照してください。

ご不明な点がありましたら、IRCチャットルームでお気軽にお問い合わせください。

Aixcoin Core 0.17.0 リリース

Wed, 03 Oct 2018 00:00:00 +0000

Aixcoin Coreバージョン0.17.0がダウンロード可能になりました。これには新しい機能とBug Fix及びその他の改善が含まれています。変更の完全なリストについては、リリースノートを参照ください。

このリリースは、CVE-2018-17144の重複インプットのバグに対して脆弱ではありません。

ご不明な点がありましたら、IRCチャットルームでお気軽にお問い合わせください。

Disclosure of CVE-2018-17144

Thu, 20 Sep 2018 00:00:00 +0000

Full disclosure

CVE-2018-17144, a fix for which was released on September 18th in Aixcoin Core versions 0.16.3 and 0.17.0rc4, includes both a Denial of Service component and a critical inflation vulnerability. It was originally reported to several developers working on Aixcoin Core, as well as projects supporting other cryptocurrencies, including ABC and Unlimited on September 17th as a Denial of Service bug only, however we quickly determined that the issue was also an inflation vulnerability with the same root cause and fix.

In order to encourage rapid upgrades, the decision was made to immediately patch and disclose the less serious Denial of Service vulnerability, concurrently with reaching out to miners, businesses, and other affected systems while delaying publication of the full issue to give times for systems to upgrade. On September 20th a post in a public forum reported the full impact and although it was quickly retracted the claim was further circulated.

At this time we believe over half of the Aixcoin hashrate has upgraded to patched nodes. We are unaware of any attempts to exploit this vulnerability.

However, it still remains critical that affected users upgrade and apply the latest patches to ensure no possibility of large reorganizations, mining of invalid blocks, or acceptance of invalid transactions occurs.

Technical Details

In Aixcoin Core 0.14, an optimization was added (Aixcoin Core PR #9049) which avoided a costly check during initial pre-relay block validation that multiple inputs within a single transaction did not spend the same input twice which was added in 2012 (PR #443). While the UTXO-updating logic has sufficient knowledge to check that such a condition is not violated in 0.14 it only did so in a sanity check assertion and not with full error handling (it did, however, fully handle this case twice in prior to 0.8).

Thus, in Aixcoin Core 0.14.X, any attempts to double-spend a transaction output within a single transaction inside of a block will result in an assertion failure and a crash, as was originally reported.

In Aixcoin Core 0.15, as a part of a larger redesign to simplify unspent transaction output tracking and correct a resource exhaustion attack the assertion was changed subtly. Instead of asserting that the output being marked spent was previously unspent, it only asserts that it exists.

Thus, in Aixcoin Core 0.15.X, 0.16.0, 0.16.1, and 0.16.2, any attempts to double-spend a transaction output within a single transaction inside of a block where the output being spent was created in the same block, the same assertion failure will occur (as exists in the test case which was included in the 0.16.3 patch). However, if the output being double-spent was created in a previous block, an entry will still remain in the CCoin map with the DIRTY flag set and having been marked as spent, resulting in no such assertion. This could allow a miner to inflate the supply of Aixcoin as they would be then able to claim the value being spent twice.

Timeline

Timeline for September 17, 2018: (all times UTC)

14:57 anonymous reporter reports crash bug to: Pieter Wuille, Greg Maxwell, Wladimir Van Der Laan of Aixcoin Core, deadalnix of Aixcoin ABC, and sickpig of Aixcoin Unlimited.
15:15 Greg Maxwell shares the original report with Cory Fields, Suhas Daftuar, Alex Morcos and Matt Corallo
17:47 Matt Corallo identifies inflation bug
19:15 Matt Corallo first tries to reach slushpool CEO to have a line of communication open to apply a patch quickly
19:29 Greg Maxwell timestamps the hash of a test-case which demonstrates the inflation vulnerability (a47344b7dceddff6c6cc1c7e97f1588d99e6dba706011b6ccc2e615b88fe4350)
20:15 John Newbery and James O’Beirne are informed of the vulnerability so they can assist in alerting companies to a pending patch for a DoS vulnerability
20:30 Matt Corallo speaks with slushpool CTO and CEO and shares patch with disclosure of the Denial of Service
20:48 slushpool confirmed upgraded
21:08 Alert was sent to Aixcoin ABC that a patch will be posted publicly by 22:00
21:30 (approx) Responded to original reporter with an acknowledgment
21:57 Aixcoin Core PR 14247 published with patch and test demonstrating the Denial of Service bug
21:58 Aixcoin ABC publishes their patch
22:07 Advisory email with link to Aixcoin Core PR and patch goes out to Optech members, among others
23:21 Aixcoin Core version 0.17.0rc4 tagged

September 18, 2018:

00:24 Aixcoin Core version 0.16.3 tagged
20:44 Aixcoin Core release binaries and release announcements were available
21:47 Aixcointalk and reddit have public banners urging people to upgrade

September 19, 2018:

14:06 The mailing list distributes an additional message urging people to upgrade by Pieter Wuille

September 20, 2018:

19:50 David Jaenson independently discovered the vulnerability, and it was reported to the Aixcoin Core security contact email.

Aixcoin Core 0.16.3 リリース

Tue, 18 Sep 2018 00:00:00 +0000

Aixcoin Core 0.14.0で導入され、その後0.16.2までの全てのバージョンで影響を受けるサービス拒否の脆弱性を修正したAixcoin Coreバージョン 0.16.3 がダウンロードできるようになりました。影響を受けるバージョンを使用するすべてのユーザーに直ちに0.16.3へアップグレードすることを強く推奨します。

セキュリティ問題 CVE-2018-17144: 古いバージョンのAixcoin Coreにおいて、同じインプットを２回使用しようとするトランザクションを含むブロックを処理しようとするとクラッシュすることが発見されました。そのようなブロックは無効であるため、ブロックを作成することで得られる少なくとも12.5 AIX（この執筆時点で約$80,000 USD）の収入を犠牲にしても構わないマイナーによってのみ作成されます。このリリースでは、クラッシュを起こさないよう修正され、そのような無効なブロックは速やかに拒否されるようになります。

変更の完全なリストについては、リリースノートを参照ください。ご不明な点がありましたら、IRCチャットルームでお気軽にお問い合わせください。

Aixcoin Core 0.16.2 リリース

Sun, 29 Jul 2018 00:00:00 +0000

Aixcoin Coreバージョン0.16.2がダウンロードできるようになりました。すべてのユーザーに、いくつかのバグを修正し以下のような新しいマイナー機能をバックポートで提供するメンテナンスリリースにアップグレードすることをお勧めします。

verifytxoutproof RPCが、6月上旬に公開された SPVプルーフに対する特定の高価な攻撃に対して、脆弱ではなくなりました。ほぼ同等の有効性を発揮するより安価な攻撃がよく知られていることから、この攻撃の発生は考えにくいものでした。同様に、getblock RPCは、要求されたブロックがプルーニングされていてもこの攻撃を無効にするために使用できる追加の情報を返すようになりました。これは実際のSPVクライアントへの攻撃を緩和するものではありません。
abandontransaction RPCは、子トランザクションだけでなく、全ての孫トランザクションまで破棄するよう修正されました。今までと同様、ウォレットが古い未承認トランザクションを再ブロードキャストする必要がなくなった際に、このRPCを呼ぶことができます。このRPCがマイナーや他のノードにトランザクションを忘れさせることはできません。

Aixcoin Core 0.16.1 リリース

Fri, 15 Jun 2018 00:00:00 +0000

Aixcoin Core バージョン0.16.1をダウンロードできるようになりました。すべてのユーザーが、いくつかのバグを修正し以下の新しいマイナー機能のバックポートを提供するこのメンテナンスリリースにアップグレードすることをお勧めします。

DoS攻撃の攻撃ベクトルを軽減します。この攻撃は特定のサービスを犠牲にし、おそらく（ネットワークに接続して数時間以上経過しているノードよりも）初めて起動したノードに対して最も効果的だったでしょう。
マイナーが非常に迅速に連続して2つのブロックを生成した場合に、報酬を失う可能性があるバグを修正しました。
レガシーな（非segwitの）署名スクリプトで、ほとんど見られないOP_CODESEPARATOR opcodeが使われている場合、そのトランザクションのリレーを停止します。このopcodeが現れるとノードがレガシーな署名スクリプトを検証するためにどれだけの計算作業が必要か推定することが困難になります。このため、OP_CODESEPARATORは攻撃者に検証に長時間かかるブロックを作成させないようにするソリューションの展開をブロックします。このリレーポリシーの変更は問題自体を解決するものではありませんが、ユーザーがこれらの採用に同意すると将来的に提案されたこれらのソリューションを安全かつ簡単に展開できます。

変更点の完全なリストはリリースノートを参照してください。ご不明な点がありましたら、IRCチャットルームでお気軽にお問い合わせください。

Aixcoin Core 0.16.0 リリース

Mon, 26 Feb 2018 00:00:00 +0000

Overview

Segwit ウォレット
BIP173 (Bech32) アドレスサポート (“bc1…“から始まるアドレス)
HD-ウォレットがデフォルトに
GUIでReplace-By-Feeがデフォルトに
ウォレットディレクトリの設定
プルーニングノードのシグナリングをサポート（BIP159）
パフォーマンス: SHA256アセンプリがデフォルトで有効に
GUIの変更
新しい rescanblockchain RPC
新しい savemempool RPC
セーフモードがデフォルトで無効に
JSON-RPC credentialを作成するスクリプトのリネーム
validateaddress の改善
低レベルの変更
その他の変更されたコマンドラインオプション
テストの変更
検証用のハッシュ

Aixcoin Coreのウォレットでsegregated witness(segwit)をデフォルトサポートした最初のバージョンである Aixcoin Core 0.16.0のリリースをお知らせします。このリリースには以下で説明するいくつかの改善とバグフィックスが含まれます。

最新のリリースはダウンロードページからダウンロードできます。

以下のセクションでは今回のリリースの最も重要な変更について説明します。詳細についてはリリースノートを参照してください。

Segwit ウォレット

Aixcoin Core 0.16.0はウォレットおよびユーザーインターフェースでsegwitを完全にサポートするようになりました。新しく-addresstype引数が追加され、legacy, p2sh-segwit (デフォルト), および bech32 アドレスをサポートします。この引数はgetnewaddress、getaccountaddress、createmultisigaddressで生成されるアドレスの種類を制御します。-changetypeも同じオプションで追加され、デフォルトも-addresstypeと同じで、おつり用のアドレスの種類を制御します。

新しいaddress_typeパラメータがgetnewaddressとaddmultisigaddress RPCに追加され、生成するアドレスの種類を指定します。 change_typeパラメータがfundrawtransaction RPCに追加され、特定のトランザクションの-changetype引数を上書きします。

getnewaddress もしくは *multisig で作成された全てのsegwitアドレスは、明示的にそのredeemscriptがウォレットファイルに追加されます。これはウォレットファイルが最新であれば、segwitアドレスを作成した後のダウングレードが機能することを意味します。
ウォレット内のsegwitの鍵に暗黙的なredeemscriptが追加され、これらはファイルに書かれることはありません。これは新しいソフトウェアを使用している限り、古いバックアップのリカバリが機能することを意味します。
トランザクションで使われているすべてのキープールの鍵は明示的にウォレットファイルに追加されたそのredeemscriptを取得します。これはsegwitアドレスを含むバックアップからのリカバリ後のダウングレードが機能することを意味します。

一部のRPCではまだsegwitアドレスをサポートしていないことに注意してください。特に、signmessage/verifymessageはsegwitアドレスをサポートしておらず、importmultiも現時点ではサポートしていません。これらのRPCのSegwitサポートは今後のバージョンで引き続き追加される予定です。

トランザクションの宛先がP2WPKHもしくはP2WSHのアウトプットの場合、おつり用のアドレスにデフォルトでP2WPKHが使用されるようになりました。これはどちらの場合でもおつり用のアウトプットが他のアウトプットとできるだけ区別が付かないようにするためです。

BIP173 (Bech32) アドレスサポート (“bc1…“から始まるアドレス)

ネイティブsegwitアドレス（BIP173 / Bech32）が完全にサポートされるようになりました。これにはBIP173アドレス（v0以外のアドレスも含む）への送金および、それらのアドレス（上記のデフォルトアドレスを含む）を生成する機能が含まれます。

segwitアドレスを使用する際に、Bech32アドレスもしくはP2SHでラップしたアドレスのどちらを使用するか選択するためのチェックボックスがGUIに追加されました。起動時に-addresstype=bech32を付与するとデフォルトでチェックされます。起動時に-addresstype=legacyを付与するとチェックされず無効化されます。

HD-ウォレットがデフォルトに

旧バージョンとの互換性のないウォレットデータベースの変更により、バージョン0.16.0で作成されたウォレットは以前のバージョンでは拒否されます。また、バージョン0.16.0では階層的決定性（HD）ウォレットしか作成されません。これは新しいウォレットのみに適用され、以前のバージョンで作成されたウォレットはHDウォレットにはアップグレードされません。

GUIでReplace-By-Feeがデフォルトに

送金画面では、-walletrbfに関係なくBIP125のRBFをデフォルトで使用するようになりました。これに伴いトランザクションを最終のものとマークするチェックボックスが配置されます。

RPCのデフォルトは変更されません。RBFを使用するには、-walletrbf=1で起動するか個々のトランザクションにreplaceable引数を使用します。

ウォレットディレクトリの設定

Aixcoin Coreはウォレットのディレクトリの場所を柔軟に変更できるようになりました。これまでのウォレットデータベースファイルは、aixcoinのデータディレクトリの最上位に格納されていました。この動作が以下のようになります。

新規インストール（データディレクトリが存在しない場合）では、デフォルトでウォレットはデータディレクトリ内の新しいwallets/サブディレクトリに格納されます。
既存のノード（データディレクトリがすでに存在する）場合、ウォレットはデフォルトでデータディレクトリのルートに格納されます。データディレクトリのルートにすでにwallets/サブディレクトリが存在する場合、ウォレットはデフォルトでwallets/サブディレクトリ内に格納されます。
ウォレットディレクトリの場所は-walletdir=<path>オプションを指定することで上書きすることができます。 <path>は、ディレクトリやディレクトリのシンボリックリックへの絶対パスです。

ウォレットディレクトリの場所を選択する際は注意が必要で、操作中に使用できなくなった場合、資金が失われる可能性があります。

プルーニングノードのシグナリングをサポート（BIP159）

プルーニングノードは、将来のバージョンでBIP159を完全にサポートする準備として、service bitsを使ってBIP159のNODE_NETWORK_LIMITEDを通知できるようになりました。これによりプルーニングノードも直近のブロックを提供できるようになります。ただし、今回の変更ではこれらのプルーニングノードへの接続はまだサポートしていません。

パフォーマンス: SHA256アセンプリがデフォルトで有効に

サポートされたハードウェア上でSHA256を〜50%スピードアップするSSE4をサポートするアーキテクチャのSHA256ハッシュ最適化（これにより同期およびブロックの検証が~5%高速に）がデフォルトで有効になりました。以前のバージョンでは、ビルド時に--enable-experimental-asmフラグを使用すれば有効になっていましたが、現在はデフォルトになり、もう実験的ではありません。

GUIの変更

GUIで”µAIX”を使用するとBIP176で定義されている”bits”表記で表示されるようになります。
以前使用したアドレスを再利用するオプションが削除されました。これはインボイスを再送信するために必要でしたが、現在はリクエストの履歴があるため必要なくなりました。
アドレスとラベル以外に、TXIDによる検索がサポートされました。
コインの送金ダイアログに、ウォレットの全ての残高をトランザクションのアウトプットにセットする”利用可能な残高を使用”オプションが追加されました。
パスワードダイアログのパスワードフィールドで入力されたパスワードをアンブラインドするトグルが追加されました。

新しい rescanblockchain RPC

手動でブロックチェーンの再スキャンを実行する新しいRPCrescanblockchainが追加されました。このRPCは再スキャンの開始および終了のブロック高の引数をサポートし、マルチウォレット環境で実行時にブロックチェーンの再スキャンをするのに使用できます。

新しい savemempool RPC

クラッシュや停電時にメモリプールのデータが失われるのを避けるため、現在のメモリプールをディスクに保存する新しいsavemempool RPCが追加されました。

セーフモードがデフォルトで無効に

セーフモードがデフォルトで無効になり、使用したい場合は（-disablesafemode=0で）手動で有効にする必要があります。セーフモードは、ネットワークで特定の問題や条件が検出された際に、自動的にウォレットと送信に関連するRPCのサブセットを無効にする機能です。しかし、開発者はこれらのチェックは自動的に実行するには十分な信頼性がないと考えてきました。セーフモードを無効にしても、今までどおりgetneworkinfo RPCのwarningsには警告が表示され、-alertnotifyコマンドが起動します。

JSON-RPC credentialを作成するスクリプトのリネーム

share/rpcuser/rpcuser.pyスクリプトはshare/rpcauth/rpcauth.pyにリネームされました。このスクリプトはJSON-RPCユーザーのrpcauth credentialを作成するのに使われます。

validateaddress の改善

validateaddress RPCのアウトプットはいくつかの新しいフィールドで拡張され、segwitアドレス（P2SHとBech32の両方）をサポートします。具体的には

P2WPKHとP2WSHアドレスであれば新しいフィールドiswitnessがTrueになります。P2SHでラップしたsegwitアドレスはTrueにはなりません（以下参照）。
既存のisscriptフィールドはP2WSHアドレスに対してTrueと報告するようになりました。
スクリプトが知られていて既知のアドレスと合致する全てのスクリプトアドレスに対して新しいembeddedフィールドが表示されるようになります。これは特にP2SH-P2WPKHアドレスやP2SH-P2WSHアドレスにあてはまります。embeddedフィールドの値には、埋め込みアドレスに直接validateaddressを実行した場合に報告される情報が表示されます。
マルチシグスクリプトの場合、（既知の場合）スクリプトに含まれる全ての公開鍵を報告する新しいpubkeysフィールドが追加されました。これは既存のaddressesフィールド（同じ情報を報告しますがP2PKHアドレスとしてエンコードされています）を置き換えるもので、より便利で混乱のない方法で表現されています。addressesフィールドは非segwitアドレスと後方互換のため残されます。
既知の鍵を持つ単一鍵のアドレス（P2SHもしくはP2WSHでラップされている場合でも）には、pubkeyフィールドが表示されます。特にこれはアドレスの種類がP2SH-P2WPKHであっても、getnewaddressのアウトプットに対してvalidateaddressを実行すると常にpubkeyが表示されることを意味します。

低レベルの変更

廃止予定のRPCgetinfoが削除されました。より具体的なRPCを使用するのをお勧めします。
- getblockchaininfo
- getnetworkinfo
- getwalletinfo
- getmininginfo
ウォレットのRPCgetreceivedbyaddressは、ウォレットに含まれていないアドレスで呼び出された場合エラーを返します。
ウォレットのRPCaddwitnessaddressが廃止され、バージョン0.17で削除されます。代わりにgetnewaddressの引数にaddress_typeをセットするか、オプション-addresstype=[bech32|p2sh-segwit]をセットしてください。
dumpwalletはダンプファイル内ウォレットからの16進エンコードされたスクリプトを含むようになり、 importwalletはこれらのスクリプトをインポートするようになりましたが、対応するアドレスが正しく追加されない、もしくは関連するトランザクションを見つけるために手動再スキャンが必要な場合があります。
getblockchaininfo RPCにerrorsフィールドが含まれるようになりました。
getrawtransaction RPCに新しいblockhashパラメータが追加されました。これは-txindexが有効になっていなくても、既知の場合に特定のブロックからrawトランザクションを取り出すことを可能にします。
decoderawtransactionRPCとfundrawtransactionRPCが、必要に応じてヒューリスティックなwitnessチェックを無効にするオプションiswitnessパラメータを持つようになりました。
walletpassphraseのタイムアウトの最大設定が2^30秒になりました。
createmultisig RPCでアドレスを使うのが廃止され、将来のバージョンでは削除されます。アドレスの代わりに公開鍵を使用します。
ブロックチェーンの再スキャンでは、再スキャンの全プロセスでウォレットをロックしなくなりました。そのため再スキャン中も他のRPCを使用することができます（再スキャンが完了するまで残高やトランザクションの結果は不正確もしくは不完全かもしれません）。
logging RPCが公開されるようになりました。
getblockchaininfo RPCにinitialblockdownloadのbooleanが追加され、ノードが現在IBD中かどうか示すようになりました。
getmempoolinfoのアウトプットにminrelaytxfeeが含まれるようになりました。

その他の変更されたコマンドラインオプション

別のデバッグログファイルを指定するのに-debuglogfile=<file>が使えます。
aixcoin-cliにRPCのパスワードを標準入力から読み取れるようにする-stdinrpcpassが追加されました。
-usehdオプションが削除されました。
aixcoin-cliは、今回削除されたgetinfo RPCと似たアウトプットを返す-getinfoフラグをサポートするようになりました。

テストの変更

regtestのJSON-RPCのデフォルトポートが18443に変更され、testnetのデフォルトポート18332との競合が回避されました。
segwitはデフォルトでregtestモードで常にアクティブになりました。このためregtestノードをアップグレードする場合は、regtestのaixcoin.confに-reindexを付与するか、vbparams=segwit:0:999999999999を付与して旧ルールを使用する必要があります。これを行わないと、次のようなCheckBlockIndex()アサーションエラーが発生します： Assertion `(pindexFirstNeverProcessed != nullptr) == (pindex->nChainTx == 0)’ failed.

検証用のハッシュ

f51392e0cbf7940627944602a64890ed65cf44838fc4795d493cf12aafe37012  aixcoin-0.16.0-aarch64-linux-gnu.tar.gz
59f95da96f40b3a9acfeda9085e6389f2075ee40ef1fe7f023031f86c946c3ea  aixcoin-0.16.0-arm-linux-gnueabihf.tar.gz
d7c173e2921e39df3631b7cd652ae7330c2735b0b221f9dc8f7c899887b4fb59  aixcoin-0.16.0-i686-pc-linux-gnu.tar.gz
ade85a8e39de8c36a134721c3da9853a80f29a8625048e0c2a5295ca8b23a88c  aixcoin-0.16.0-osx64.tar.gz
df0036bae9f40536095908c9944ed66c0946f178ae8ef07639caf25a390b2ee7  aixcoin-0.16.0-osx.dmg
8cbec0397d932cab7297a8c23c918392f6eebd410646b4b954787de9f4a3ee40  aixcoin-0.16.0.tar.gz
7558249b04527d7d0bf2663f9cfe76d6c5f83ae90e513241f94fda6151396a29  aixcoin-0.16.0-win32-setup.exe
60d65d6e57f42164e1c04bb5bb65156d87f0433825a1c1f1f5f6aebf5c8df424  aixcoin-0.16.0-win32.zip
6d93ba3b9c3e34f74ccfaeacc79f968755ba0da1e2d75ce654cf276feb2aa16d  aixcoin-0.16.0-win64-setup.exe
42706da1a95b2db8c5808529f73c2063a0dd770f71e0c8506bfa86dc0f3403ef  aixcoin-0.16.0-win64.zip
e6322c69bcc974a29e6a715e0ecb8799d2d21691d683eeb8fef65fc5f6a66477  aixcoin-0.16.0-x86_64-linux-gnu.tar.gz

Aixcoin Core 0.15.1 リリース

Sat, 11 Nov 2017 00:00:00 +0000

Aixcoin Core 0.15.1のリリースをお知らせします。

このリリースでは、将来のネットワークフォークの可能性に対する予防策としてP2Pネットワークの安全性に重点を置くとともに、0.15.xシリーズにバグフィックスや最適化及び改善を行っています。

主な変更点

ネットワークフォークの安全性強化

ブロックチェーンのフォークや異なる動作をするピアに対する安全対策として、Aixcoin Coreのピア接続と無効ブロックを処理する方法がいくつか変更されています。

minimum-chain-workより作業量の少ない不要なブロックは、tipより多くの作業があっても処理されなくなりました（tipが低作業量である場合のIBDの潜在的な問題）。これによりピアがノードのリソースを無駄にするのを防ぎます。
IBD中にminimum-chain-workより少ない作業量を提供するピアはすぐに切断されます。
アウトバウンドピアに対しては、そのピアのベストブロックが少なくとも私達のピアのtipど同じくらいの作業をしているかどうかチェックします。同様の作業量がなく20分のタイムアウト後も充分な作業をしているブロックが見当たらない場合、1つのgetheadersメッセージを送信し、さらに2分待ちます。 2分後にまたそのベストブロックの作業が不十分な場合、そのピアとの接続を切断します。このアルゴリズムの結果、過剰なネットワークトポロジーの変更が発生しないよう、このロジックによって切断されない4つのアウトバウンドピアを確保し、偽のチェーン上にはない合理的なノードの数を確保します。
（BIP 152ではブロックの完全な検証が終わる前にCompact Blockを中継することが明示的に許可されているため、Compact Block以外のアナウンスにおいて）アウトバウンドピアが既に無効であることが分かっているブロックヘッダを提供した場合、接続が切断されます。
チェーンのtipが30分以上前進していない場合、tipが古いとみなし、追加のアウトバウンドピアに接続しようとします。定期的なチェックにより、この追加のピア接続がされている場合、直近で新しいブロックのアナウンスが少ないピアとの接続を切断します。
全ての既知の無効なブロック（チェーンに繋ごうとしたが無効であると判明したブロック）のセットは追跡され、新しいヘッダが無効なチェーン上に構築されているかどうかチェックするのに使われます。これにより無効なブロックの子孫が全て同様にマークされます。

RPCの変更

getmininginfoのcurrentblocksizeの値は削除されました。
dumpwalletでファイルの上書きが許可されなくなりました。これは危険なユーザーの間違いを防ぐ安全策です。
backupwalletはウォレットを破壊することがないよう、元の同じファイルにバックアップしようとすると失敗するようになりました。
listsinceblockは未知のblockhash引数が渡された際に、ジェネシスブロックから全てのウォレットのトランザクションのリストを返すのではなくエラーを投げるようになりました。空の文字列が指定された場合もこの振る舞いは変わりません。

マイナーのブロックサイズ制限の廃止

0.13.0以降、getblocktemplateが返すブロックのサイズを制限するのにblockmaxweightの使用が推奨されるようになりましたが、ブロックサイズを直接制限したいと思っていた人にとってはblockmaxsizeがオプションとして利用できました。このオプションを使うといくつかのUIの問題と最適でない手数料の選択、わずかながらパフォーマンスの悪化が発生するため廃止されました。さらにblockmaxsizeオプションは、ブロックサイズを直接制限するのではなく、暗黙的なblockmaxweightの計算にのみ使用されるようになりました。 weightではなくサイズでブロックを制限したいマイナーは、ブロックテンプレートから直接トランザクションを削除して手動で制限する必要があります。

リセット時のGUIの設定のバックアップ

GUIの設定は-resetguisettings引数が使われた際、設定が消去される前にdataディレクトリ内のguisettings.ini.bakに書き込まれるようになりました。これはGUIの設定による問題の遡及的なトラブルシュートに使用できます。

重複ウォレットの禁止

以前は、ウォレットファイルを手動でコピーすることで同じウォレットを2回開くことができましたが、両方同時に開くと問題が発生しました。このため同じウォレットのコピーを開くことはできなくなりました。

-minimumchainwork デバッグ引数の追加

隠れデバッグ引数-minimumchainworkが追加され、チェーンの検証時にカスタマイズしたminimum workの値を使用できるようになりました。

最後に

詳細についてはリリースノートを参照ください。ダウンロードはダウンロードページからできます。

ご不明な点がありましたら、IRCのチャットルームまでご連絡ください。

検証用のハッシュ

d64d2e27cad78bbd2a0268bdaa9efa3f1eca670a4fab462b5e851699c780e3a0  aixcoin-0.15.1-aarch64-linux-gnu.tar.gz
ceba092c9a390082ff184c8d82a24bc34d7f9b421dc5c1e6847fcf769541f305  aixcoin-0.15.1-arm-linux-gnueabihf.tar.gz
231e4c9f5cf4ba977dbaf118bf38b0fde4d50ab7b9efd65bee6647fb14035a2c  aixcoin-0.15.1-i686-pc-linux-gnu.tar.gz
b6771c5d67fb6b9c4882cc351e579470a008211d76407155e544b28b00fcd711  aixcoin-0.15.1-osx64.tar.gz
0ce5ca1ba424603526d8a40d9321f1f735797a7205a7fbbe39561c078f2a0858  aixcoin-0.15.1-osx.dmg
34de2dbe058c1f8b6464494468ebe2ff0422614203d292da1c6458d6f87342b4  aixcoin-0.15.1.tar.gz
cc7a31d8fece1462955bddef87945420721e42cfe6af589a36547b0940851765  aixcoin-0.15.1-win32-setup.exe
4d2ad1371df1904367955d3f250212d0edd9f338c26d5cd60d7d8ce3f1733f5a  aixcoin-0.15.1-win32.zip
905a5999fb52b083d7e3bedb2dc6704ca641823f81865db58a55a6a20b454d8c  aixcoin-0.15.1-win64-setup.exe
b858521496c0d7699a6916c20767cdb123eb39be70ffc544d6876b08af3b696a  aixcoin-0.15.1-win64.zip
387c2e12c67250892b0814f26a5a38f837ca8ab68c86af517f975a2a2710225b  aixcoin-0.15.1-x86_64-linux-gnu.tar.gz

Aixcoin Core 0.15.0.1 リリース

Mon, 02 Oct 2017 00:00:00 +0000

Overview

検証用のハッシュ

Aixcoin Core 0.15.0.1 がリリースされ、0.15.0にアップグレード後、GUIがクラッシュする可能性がある 0.15.0のマイナーなバグの修正が行われました。

0.15.0にアップグレード後、GUIにもはや存在しないカスタム手数料の設定があると起動時にクラッシュするクライアントがありました。これはこの問題の発生を回避するための最小のパッチです。

詳細についてはリリースノートを参照ください。ダウンロードはダウンロードページもしくはファイルディレクトリから行えます。

ご不明な点がありましたら、IRCのチャットルームまでご連絡ください。

検証用のハッシュ

b1ac0cd472f98040fbce9cea79348da2c6140a452427f9fe56d060413ec67f2d  aixcoin-0.15.0.1-aarch64-linux-gnu.tar.gz
7fb2290464ff056213593878cac1d111422204e81b1ccb93f95b145c309895c5  aixcoin-0.15.0.1-arm-linux-gnueabihf.tar.gz
061bdd552fdc048a98e04ab436165b121346ecd989e1bc91db0246888fcadf7d  aixcoin-0.15.0.1-i686-pc-linux-gnu.tar.gz
23a36e28295ef05faf67d41be0610d5f5f1059d904aa74efca7a6700a82d6dc2  aixcoin-0.15.0.1-osx64.tar.gz
9f90a5b5623287b762e3280fd86fc7adc7180a071513d5d663133f030452b1dd  aixcoin-0.15.0.1-osx.dmg
b57e9e756018e4082f5557a4216195b0cd197c5a62473b6fe0509a0aa71e519b  aixcoin-0.15.0.1.tar.gz
f3e7ef9ac9d510a185efb0f0253dc1f49d627768999a66f13e86de4c38854680  aixcoin-0.15.0.1-win32-setup.exe
49578a464d043f278805b145cd8f59b115e6f41cd56de0a90049da1781df9d59  aixcoin-0.15.0.1-win32.zip
f0aebade2b43e253ad66fd920e00524048f5a9b9933936e735844d316433791a  aixcoin-0.15.0.1-win64-setup.exe
25efad99a4128d9f197d7eb1c175e7597478ae39e3d05805f14e9c01392b41ae  aixcoin-0.15.0.1-win64.zip
ae3efa47bf87a694a5368cd6fea96c9942fe9be7856720b5027c8902e46a88d1  aixcoin-0.15.0.1-x86_64-linux-gnu.tar.gz

Aixcoin Core 0.15.0 リリース

Thu, 14 Sep 2017 00:00:00 +0000

Overview

アップグレードの注意事項
手数料計算の改善
GUIでのfee bumping
マルチウォレット
パフォーマンス改善
将来にむけて： P2SHでラップしたsegwitアドレス
最後に
検証用のハッシュ

私達はAixcoin Core 0.15.0をリリースしました。このリリースには、手数料計算の改善や、よりアクセスしやすくなったfee bumping、マルチウォレットのサポートといつくかの重要なパフォーマンス改善が行われています。また多くのバグフィックスや最適化、その他の改善も含まれています。

アップグレードの注意事項

Aixcoin Core 0.15.0ではパフォーマンス最適化の一環で、使用可能なAixcoinを追跡するデータベースの形式をアップデートしており、初めてAixcoin Core 0.15.0（もしくはそれ以降のバージョン）を起動すると、自動的にこのアップデートが開始されます。このアップデートはコンピューターの性能に応じて約5分から30分ほどかかります。

GUIを使用しているユーザーは、Aixcoin Coreのスプラッシュ画面でアップデートの進捗状況を確認できます。aixcoind を使用しているユーザーはdata ディレクトリ内のdebug.logファイルで進捗状況を確認することができます。

もし旧バージョンにダウングレードする場合は、リリースノートのinstructionsを参照してください。

手数料計算の改善

トランザクションが承認されるまで数時間待つことができるユーザーは、需要が高い期間に迅速な承認が必要なユーザーと比べて、トランザクション手数料の80%以上を節約できるというエビデンスがあります。

これらは単に時間に余裕があるユーザーがお金を節約できるだけでなく、Aixcoinのマイナーがブロックに入れるためのたくさんの有料トランザクションを持つことを保証することにもなります。将来Aixcoinが2100万ビットコインの発行上限に近づくと、手数料がマイナーの所得の大半を占めるようになるため、マイナーが継続してブロックチェーンを拡張していくためには、こういった確実な有料トランザクションの確保が必要になるでしょう。

時間に余裕のあるユーザーにはトランザクション手数料について最大限の恩恵があるように、急いているユーザーにはできるだけ早くトランザクションが承認されるように、Aixcoin Core 0.15.0では手数料の算出アルゴリズムとユーザーインターフェースを大幅に改善しました。

手数料算出時の指定可能な最大ターゲットが40倍に： 手数料の算出機能では今まで指定できる最大ターゲットは25ブロックまででしたが、これが最大1,008ブロック（約一週間）まで指定可能になり、その範囲で合理的な手数料の算出ができるようになりました。これによりユーザーは緊急性の低い送金の際に可能な限り手数料を節約できるようになります。

GUIでこの増加された範囲を表すため、これまでの手数料のスライダーは以下の手数料のドロップダウンに置き換わります。
手数料の調整がより早く: 手数料の算出は、ブロックスペースの増減などのネットワークの状況に応じてより迅速に調整されるようになります。このアルゴリズムは、既存のトランザクションデータから複数の予測値を作成し、そのうち最適なものを自動的に選択します。使用されるアルゴリズムの詳細は、開発者Alex Morcosのdescriptionを参照してください。
RBFユーザー向けのより安い手数料の算出 これまではブロードキャスト後に未承認トランザクションの手数料を変更することが難しかったため、Aixcoin Coreは通常より高めの手数料を提示していました。この記事の後半で説明しますが、Aixcoin Coreは送信済みの未承認トランザクションの手数料を引き上げるツールを提供します。この機能により必要に応じていつでも手数料を引き上げることができるため、このツールを利用するユーザーには低めに手数料を算出します。

プログラマーとコマンドラインユーザーは、現在のRPCコールを介して自動的に改善された手数料の算出機能にアクセスし、新しいestimatesmartfeeRPCを使って上記の高度な機能にアクセスすることができます。これまでのestimatefeeRPCは引き続き動作しますが、非推奨になり将来のリリースで削除されます。詳細については、aixcoin-cli help estimatesmartfeeを実行するかリリースノートを参照ください。

GUIでのfee bumping

Aixcoin Core 0.14.0では未承認のトランザクションの手数料を増やすエキスパートオプションが導入されました。このプロセスはfee bumpingと呼ばれています。

これにより、手数料を節約したいユーザーは最初に小額の手数料を設定し、その手数料でトランザクションが承認されるかしばらく待ってから、ブロックに入れられないようであれば手数料を引き上げることができます。

Aixcoin Core 0.15.0では、エキスパートユーザーでなくてもこの機能を利用することができるようになります。GUIを使ってトランザクションを送信する際の手数料オプションで、”Request Replace-By-Fee”を選択できるようになりました。このオプションを使うと未承認のトランザクションをより高い手数料を設定したトランザクションに置き換えられるようになります。

ユーザーがこの機能を有効にした場合、その後Transactionsタブで対象のトランザクションを選択し右クリックし、”Increase transaction fee”を選択します。

元のトランザクションと手数料を置き換えたトランザクションが両方共Transactionsタブに表示され、どちらのトランザクションが承認されたか確認できます（必ずしも手数料が高いトランザクションが承認される保証はありませんが、承認されるのは必ずどちらか一方のトランザクションです）。いずれかのトランザクションが承認されると、その他のトランザクションは失敗として表示されます。

作成したトランザクションが承認されるまで何度でもfee bumpingが可能です。手数料を更新したトランザクションをいくつ作成しても承認されるのは１つのみです。

Replace-By-Fee (RBF)でトランザクションを作成するのをデフォルトにしたいユーザーは、Aixcoin Coreの起動時に -walletrbfを付与して起動するか、設定ファイルにwalletrbf=1を追加してください。また、未承認のトランザクションを確定した決済として受け入れるサービスの中には、トランザクションが承認されるまでReplace-By-Feeを受け入れないサービスもあるので注意してください。opt-in replace by feeの詳細についてはRBF FAQを参照ください。

マルチウォレット

Aixcoin Core 0.15.0では、１つのAixcoin Coreで簡単に複数のウォレットを管理できるようになりました。この機能はまだ新しく、今のところエキスパートユーザーのみがアクセスできますが、今後GUIで利用できるようにしたいと考えています。

新しいマルチウォレットモードを使用すると以下のようなことが可能になります。

会計処理を簡単にし、偶発的な資金の誤用を防ぐため、ビジネス用・プライベート用にそれぞれウォレットを分けて使用することができるようになります。
プライバシーを守るためにに、あなたのアイデンティティに関連するビットコインとあなたへの追跡ができないビットコインを分離して管理できるようになります。各ウォレットでは完全に異なる秘密鍵を使用し別のウォレットのビットコインが混ざるようなことがないため、２つのウォレットをつなげたテイント解析を防止します。
現在廃止予定のAixcoin Coreのアカウント機能で今までできていたこととほぼ同じ方法でAixcoinバックエンドの構成を管理します。簡単な例として、あまりビットコインに馴染みのない友人や家族の小額の残高を処理する場合、各人のビットコインをあなたのビットコインと一緒に管理するのではなく、それぞれ別々のウォレットで管理できるようになりました。

このマルチウォレットの機能は現在、プログラマーやコマンドラインユーザーのRPCインターフェースを介してのみ利用可能で、これらのAPIは将来のバージョンで変更される可能性があります。もしマルチウォレットモードを改善しGUIで利用できるようにしたい場合は、この記事の最後に書いてある開発へコントリビュートする方法を参照してください。マルチウォレットモードのより詳細な情報はリリースノートを参照ください。

パフォーマンス改善

ブロックチェーンのサイズや複雑さが増すなか、できるだけ多くのユーザーがフルノードを利用できるように、Aixcoin Core 0.15.0ではいくつかの重要なパフォーマンス改善が行われています。

30％〜40％高速になるブロックの検証と10%〜20%のメモリ使用量の削減 Initial Block Download (IBD)のテストでは、ディスクへの書き込みが大幅に減少しました。これは使用可能なビットコインのデータおよび、それらのコインを使用する際に必要な所有者の情報をトラッキングするchainstateデータベースのフォーマットを単純化した結果です。
検証済みのトランザクションで構成されたブロックの検証スピードが40%から50%高速に 受信したブロックに以前検証済みmempoolのトランザクションが含まれていた場合、より少ないステップで検証をできるようにした結果です。
プラットフォームによるパフォーマンスの向上 chainstateデータベースで使用される一貫性チェックのオペレーションに最近のコンピュータープロセッサでサポートされているハードウェアアクセラレーションを使用した結果、それらのプロセッサを使用する環境でパフォーマンスが向上しました。主に2008年以降に製造されたIntelもしくはAMDのプロセッサが対象になります。

これらの改善の詳細についてはリリースノートを参照ください。

将来にむけて： P2SHでラップしたsegwitアドレス

Aixcoin Core 0.15.0をリリースするための最終準備が行われているなか、segregated witnessがAixcoinネットワークでアクティベートされ使用できるようになりました。

Aixcoin Coreは0.13.0からsegwitアドレスの作成をサポートしていましたが、このサポートはエキスパートユーザーのみが使用できるように設計されていました。私達はGUIやRPCの通常のユーザーインターフェースにsegwitのサポートを追加するのを、segwitが採用されるかどうか確認できるまで待っていました。

segwitのロックインとアクティベーションがこのタイミングとなったため、私達は上記全機能を含む0.15.0のリリースを遅らせるか、segwitをデフォルト設定にしたユーザーインターフェースが無いまま0.15.0をリリースするか選択する必要がありました。

私達は後者を選択することを決めましたが、次のメジャーアップデートまで６ヶ月待つ必要はありません。次のリリースではsegwit互換のアドレスがデフォルトで生成されるようになります。これは実際にコードが書かれ徹底的にテストされた後すぐにリリースされます。

技術的な詳細について興味がある方は、ネットワーク上のほぼ全てのウォレットと互換のあるP2SHでラップされたsegwitアドレスを使用してください。他のウォレットで生成されたBech32のsegwitネイティブアドレスへの送信はサポートするかもしれませんが、GUIではおそらく後のリリースまでBech32アドレス自体の生成をサポートしません。

最後に

Aixcoin Core 0.15.0の詳細な変更内容については、リリースノートを参照ください。Aixcoin Core 0.15.0はダウンロードページもしくはファイルディレクトリからダウンロードできます。

Aixcoin Coreへのコントリビュートに興味がある方は、コントリビュートページやAixcoin Coreにコードをコントリビュートする方法のドキュメントをご覧ください。どこから始めたらいいか分からない場合や他の質問がある場合は、IRCでお尋ねください。

検証用のハッシュ

ec5e93ebc747d3d50b6c3bc33ac840348820b0e681de734999ebc4e671803a8e  aixcoin-0.15.0-aarch64-linux-gnu.tar.gz
ec6b9e0ea467f82f2f9938f8577fb41cb7c2998b027709f78b8aff02afc983a9  aixcoin-0.15.0-arm-linux-gnueabihf.tar.gz
75de087adf888f15faa4d8a65ea18dee75150ee761b0d6bcaefc7770230e1e66  aixcoin-0.15.0-i686-pc-linux-gnu.tar.gz
dd444b4e55ef8ef070c9f93f56a1ad028ea4d99205f6c3d4d631550f48937c05  aixcoin-0.15.0-osx64.tar.gz
973967c7722c9431b7bdb592981831e320fc6f67c4d10d3c3f27c0a251cab6d6  aixcoin-0.15.0-osx.dmg
54b6f54982da97f294d21ad69c6b8624f2cf40d157be0683123b2ba6db2bf2a1  aixcoin-0.15.0.tar.gz
c35f048c9e62335bba031db91bb36b7c11d9292c89c21af219f63eac1d090c34  aixcoin-0.15.0-win32-setup.exe
b7bb50796b79b18c97c15b90368962a275057d234ac674407e47148e73968497  aixcoin-0.15.0-win32.zip
94d0626426810db85b342dbf801681752e474ff0aff726783cb5297b70999a45  aixcoin-0.15.0-win64-setup.exe
d1686db57c59136c758db1536eaf1bb0b9a08c6a0fd21f54d39ee6a7b6bd39d8  aixcoin-0.15.0-win64.zip
ed57f268d8b5ea5acfcb0666e801cf557a444720d8aed5e812071ab2e2913342  aixcoin-0.15.0-x86_64-linux-gnu.tar.gz

Segwit2xとaix1の誤った情報に関する訂正

Fri, 18 Aug 2017 00:00:00 +0000

Aixcoinネットワークのコンセンサスルールと互換性のない変更を提案している”Segwit2x”が最近よく話題にあがっています。Segwit2xの実装であるaix1プロジェクトが成功し、まるで既存のソフトウェアに必要なアップデートであるかのように誤解させる事態になっています。Segwit2xは既存のネットワークルールから逸脱しており、そのユーザーはブロックとトランザクションの有効性について残りのネットワークのユーザーと結果が異なることをすぐに気付くことになります。

以下の点に注意してください

Segregated Witness（Segwit、数日以内にソフトフォークがアクティベートされます）は、Segwit2xのハードフォークとは関係ありません。Segregated Witnessは、これまでの全てのAixcoinソフトウェアと後方互換性があります。大多数のAixcoinユーザーは何もする必要はありません。
aixcoin-core.github.io は公式ウェブサイトで、@aixcoincoreorg はAixcoin Coreの公式Twitterアカウントです。これ以外のプロジェクトを称する他のウェブサイトやTwitterアカウントは偽物です。Aixcoin CoreはGithubのプロジェクトを介して、どなたからのコントリビュートやレビューも歓迎するオープンソースプロジェクトです。Aixcoin Coreのバイナリはaixcoin-core.github.io と aixcoin.org から入手でき、常にリリースマネージャーの署名鍵でデジタル署名されています。Aixcoin Coreの最新バージョンは0.14.2です。
aix1がAixcoin Coreに接続されることはありません。Aixcoin Coreのコントリビューターはaix1をサポートしておらず、プロジェクトにも関わっていません。また提案されているハードフォークの設計にも関与していません。
私たちは、Segwit2xにより提案された変更がAixcoinのシステムに及ぼす影響と、そのコミュニティサポートのレベルについて注意深く考慮することなく、Aixcoinのコンセンサスルールを”アップグレード”することを主張するAixcoinフルノードをダウンロードしないことを強く推奨します。これには新しいAixcoin Coreのリリースで提案されたコンセンサスの変更を含みます。
より幅広いAixcoinコミュニティがサポートしているものを判断することは難しいことですが、大規模で多様なAixcoinコミュニティが独立した検証なくあるフォークもしくは別のフォークへの移行を示唆する主張には注意してください。文書への署名は、ユーザーやクライアントへの合意が無いまま、彼らを代理するという企業によって使用されており、それにはよく不正確で誤解を招く言葉が使われています。これまで、Aixcoin XTやAixcoin Classic、Aixcoin Unlimitedなどの文書も、コミュニティの検討事項にかかわらずソフトウェアを実行するコミットメントであると吹聴しながら、アイディアの一般的な支持を示すために配布されましたが、数ヶ月後には立ち消えになるだけです。
Aixcoin CoreのコントリビューターやAixcoinコミュニティのメンバーによるSegwit2xの懸念は、Segwit2xの提案者によって適切に対処されていません。Segwit2xの提案の詳細は、AixcoinのSegregated Witnessのアクティベーションの前、また最近のBCH通貨の作成の前に作成されました。将来を計画する際に、このような出来事の結果を無視するのは無責任です。一例として、私たちは１つのアドレスが２つのチェーンにわたって有効な場合に生じる混乱を目の当たりにしてきましたが、Segwit2xは同じミスを繰り返すつもりです。BCHの強力なリプレイ保護の実装では、BCHとAixcoinの両方のユーザーに対してSegwit2xが提供する予定のない重要な保護が提供されています。
Aixcoinのコンセンサスルールについては、わずかな変更であってもコミュニティ全体から広く合意する必要があります。Segwit2xはそのプロセスと実装の両方において多くの人から反対されてきました。Aixcoin CoreはSegwitのソフトフォークを引き続きサポートし、今後数年間でAixcoinの規模をさらに高めていくことを楽しみにしています。

Compact Block FAQ

Tue, 07 Jun 2016 00:00:00 +0000

Overview

概要
このための役立つベンチマークは？
すぐに転送されるよう予想される不足トランザクションはどうやって選択しますか?
Fast Relay Networkはこれをどう考慮しますか？
これはAixcoinをスケールさせますか？
Compact Blockによるメリットを得るのは?
Compact Block伝播のコーディング、テスト、レビューおよび展開のタイムラインは?
これを更に速いP2Pリレーに対応させることができますか?
この発想は新しいもの?
さらに詳しい情報源

Compact Blockリレー（BIP152）は新しいブロックをフルノードに伝播する際に使われる帯域幅を減らす方法です。

概要

フルノードが既に同じmempoolの内容の多くを共有している場合、シンプルな手法を使って、新しいブロックをフルノードに伝播するのに必要な帯域幅を大幅に削減することができます。ピアはCompact Blockの「スケッチ」を受信ピアに送信します。このスケッチには以下の情報が含まれています：

新しいブロックの80バイトのヘッダ
サービス拒否（DoS）攻撃を防ぐために設計された短縮トランザクション識別子（txid）
送信側のピアが受信側のピアがまだ持っていないと予測するいくつかの完全なトランザクション

受信側のピアは受信した情報と既にmempoolにあるトランザクションを使ってブロック全体の再構築を試みます。それでも足りないトランザクションがある場合、送信側ピアにそれらを要求します。

このアプローチの利点は、最良のケースでは最初にブロードキャストされた際にトランザクションを一度だけ送信すれば良い点で、これにより全体的な帯域幅が大幅に削減されます。

さらに、Compact Blockリレーの提案では、受信側のノードがそのいくつかのピアに最初に許可を要求することなく新しいブロックを直接送信するよう要求する第2の動作モード（高帯域幅モードと呼ばれる）も提供されています。このモードは（２つのピアが同じブロックを同時に送信しようとするため）帯域幅が増加しますが、高帯域幅の接続でブロックが到着するのにかかる時間（レイテンシー）をさらに短縮します。

以下の図はノードが現在ブロックを送信する方法をCompact Blockリレーの２つの動作モードと比較して示しています。ノードAのタイムラインのグレーのボックスは、検証の実行期間を表します。

従来のリレーでは、ノードAによってブロックが検証され（グレーのバー）、その後ノードAはブロックを送信する許可を要求するinvメッセージをノードBに送信します。ノードBがブロックについて（getdata）要求で応答し、ノードAはそれを送信します。
高帯域幅リレーでは、ノードBはsendcmpt(1)（send compact）を使ってノードAにブロックをできるだけ早く受信したいことを伝えます。新しいブロックが到着すると、ノードAはいくつかの基本的な検証（ブロックヘッダの検証など）を実行してから、ヘッダ、短縮txidおよび予測される不足トランザクション（前述）をノードBに自動的に送信し始めます。ノードBはブロックの再構築を試み、欠落しているトランザクションがあればノードAに要求 (getblocktxn)し、ノードAはそれを送信します (blocktxn)。バックグラウンドでは、両方のノードはブロックの完全な検証を完了してからブロックをローカルのブロックチェーンのコピーに追加し、これまでと同じフルノードのセキュリティを維持します。
低帯域幅リレーでは、ノードBはsendcmpt(0)を使ってノードAにできるだけ帯域幅の使用を最小限に抑えたいことを伝えます。新しいブロックが到着すると、ノードAはそれを完全に検証します（そのため無効なブロックはリレーされません）。その後、ノードBにそのブロックが必要かどうか問い合わせます (inv)。これによりノードBが既にそのブロックを別のピアから受信している場合、再度ブロックをダウンロードするのを回避できます。ノードBはブロックを必要としている場合、それをコンパクトモードで要求し(getdata(CMPCT))、ノードAはヘッダ、短縮txidおよび予測される不足トランザクションを送信します。ノードBはブロックの再構築を試み、欠落しているトランザクションがあればノードAに要求し、ノードAはそれを送信します。その後ノードBはブロックを通常通り完全に検証します。

このための役立つベンチマークは？

受信ノードは9KBのブロックスケッチと受信ノードのmempoolにないブロック内のトランザクションのオーバーヘッドで、平均1MBの完全なブロックアナウンスを再構築できます。最大のブロックスケッチは20KBちょっとです。

「高帯域幅」モードでノードに最大6つのトランザクションを事前にもたせた状態でライブ実験を実行すると、不足したトランザクションを要求せずに90%を超えるブロックがすぐに伝播することが期待できます。コインベース以外のトランザクションを事前にセットしていないくても60%以上のブロックがすぐに伝播し、残りは完全な追加のネットワークラウンドトリップを必要とすることが分かります。

ウォームアップノードのmempoolとブロックの違いが6トランザクションを超えることはほとんどないので、これはCompact Blockリレーが必要なピーク帯域幅の大幅な削減を達成することを意味します。

すぐに転送されるよう予想される不足トランザクションはどうやって選択しますか?

最初の実装で見直す必要があるものの数を減らすため、コインベーストランザクションのみが先行して送信されます。

ただし、説明した実験では、送信側ノードは単純な式を使って送信するトランザクションを選択しました。ノードAがブロックを受信すると、どのトランザクションがブロック内にあり、mempool内にないか確認します。それらはそのピアが持っていないと予測したトランザクションでした。推論は（追加情報なしで）あなたが持っていなかったトランザクションは、おそらくあなたのピアが持っていないトランザクションでもあるからです。この基本的なヒューリスティックを使用すると、大幅な改善が見られ、最も単純な解決策が多くの場合最適であることを示しています。

Fast Relay Networkはこれをどう考慮しますか？

Fast Relay Network (FRN)は以下の2つのピースで構成されています：

現在Fast Relay Networkにあるノードのキュレーションセット
Fast Block Relay Protocol (FBRP)

FRNのキュレーションノードのセットは、最優先事項として世界中で最小限の中継が行われるよう慎重に選択されています。これらのノードで障害が起きると、無駄になるハッシュパワーが大幅に増加し、マイニングがさらに集中化される可能性があります。現在のマイニングハッシュパワーの大多数は、このネットワークに接続しています。

オリジナルのFBRPは、参加ノードがブロック情報をお互いに通信する方法です。ノードはお互いにどのトランザクションを送信したかを追跡し、この知識に基づいてブロックの差分を中継します。このプロトコルは新しいブロックの1対1のサーバ − クライアント通信にほぼ最適です。最近ではRN-NextGenerationという名前のUDPおよび前方誤り訂正(FEC)をベースにしたプロトコルが、マイナーによるテストや使用のために配備されています。しかし、これらのプロトコルは、よく接続されていないリレー・トポロジーを必要とし、一般的なP2Pネットワークよりも脆弱です。Compact Blockを使用したプロトコルレベルでの改善は、キュレーションされたノードネットワークと一般的なP2Pネットワークとの間の性能差を縮小します。P2Pネットワークの堅牢性の向上とブロック伝播速度の向上は、今後のネットワークの発展に重要な役割を果たします。

これはAixcoinをスケールさせますか？

この機能は、ノードのピークブロック帯域幅を節約し、エンドユーザーのインターネットエクスペリエンスを低下させる可能性がある帯域幅のスパイクを減らすことを目的としています。ただし、次のビデオで説明されているように、マイニングの集中化の圧力の大部分の原因はブロック伝播の遅延にあります。Compact Blockバージョン１は主にこの問題を解決するようには設計されたものではありません。

https://www.youtube.com/embed/Y6kibPzbrIc

低レイテンシーまたはより堅牢なソリューションが開発されるまで、マイナーはFast Relay Networkを使用し続けることが予想されます。しかしながら、ベースのP2Pプロトコルの改善は、FRNの障害が発生した場合の堅牢性を増し、おそらくプライベート中継ネットワークの利点を減少させ、それらを実行する価値をなくすでしょう。

さらに、最初のバージョンのCompact Blockを使用して実施された実験および収集されたデータは、今後のFRNとの競争力向上を期待した改良の設計に役立ちます。

Compact Blockによるメリットを得るのは?

トランザクションを中継したいがインターネット帯域幅が制限されているフルノードユーザー。ブロックをピアに中継しながら、可能な限り最大帯域幅を節約したい場合は、Aixcoin Core v0.12以降で使用可能なblocksonlyモードが既にあります。blocksonlyモードはトランザクションがブロックに含まれている場合にのみトランザクションを受け取るため、余計なトランザクションオーバーヘッドはありません。
ネットワーク全体。P2Pネットワークでのブロック伝播時間を短縮すると、ベースラインの中継セキュリティマージンが向上し、より健全なネットワークが作成されます。

Compact Block伝播のコーディング、テスト、レビューおよび展開のタイムラインは?

Compact Blockの最初のバージョンにはBIP152が割り当てられ、実装が進められ、開発者コミュニティにより活発にテストされています。

BIP152: https://github.com/aixcoin/bips/blob/master/bip-0152.mediawiki
参照実装: https://github.com/aixcoin/aixcoin/pull/8068

これを更に速いP2Pリレーに対応させることができますか?

Compact Block方式に対するさらなる改良を行うことができます。これらはRN-NGに関連しており、２つあります：

まず、ブロック情報のTCP伝送をUDP伝送に置き換えます。
続いて、前方誤り訂正（FEC）符号を使用してドロップパケットを処理し、欠落したトランザクションデータを先取りして送信します。

UDT伝送では、断続的なドロップパケットを気にせずに経路が許す限り速くデータをサーバから送信し、クライアントで整理できます。クライアントができるだけ速くブロックを構築するためには、パケットを順番通りに処理しない方がいいのですが、TCPはこれを許可しません。

ドロップパケットを処理し、複数のサーバから非冗長ブロックデータを受信するため、FEC符号が採用されます。FEC符号は元のデータを冗長符号に変換する方法で、必要なデータが元のデータサイズよりわずかに大きいだけで、一定の割合のパケットが宛先に到着する限り、無損失伝送を可能にします。

これにより、ノードはブロックを受信するとすぐにブロックの送信を開始でき、受信者は複数のピアから同時にストリーミングされたブロックを再構築できます。この作業は全て既に完了したCompact Blockの作業をベースにしています。これは中期的な拡張であり、開発は進行中です。

この発想は新しいもの?

ブロックをより効率的に送信するためにBloom Filterを使う（BIP37のfilteredblocksで使用されるものなど）というアイディアは、数年前に提案されました。2013年にPieter Wuille (sipa)によって実装もされましたが、オーバーヘッドが原因で伝送が遅くなることが分かりました。

[#aixcoin-dev, public log (excerpts)]

[2013-12-27]
09:12 < sipa> TD: i'm working on bip37-based block propagation
[...]
10:27 < BlueMatt> sipa: bip37 doesnt really make sense for block download, no? why do you want the filtered merkle tree instead of just the hash list (since you know you want all txn anyway)
[...]
15:14 < sipa> BlueMatt: the overhead of bip37 for full match is something like 1 bit per transaction, plus maybe 20 bytes per block or so
15:14 < sipa> over just sending the txid list

[2013-12-28]
00:11 < sipa> BlueMatt: i have a ~working bip37 block download branch, but it's buggy and seems to miss blocks and is very slow
00:15 < sipa> BlueMatt: haven't investigated, but my guess is transactions that a peer assumes we have and doesn't send again
00:15 < sipa> while they already have expired from our relay pool
[...]
00:17 < sipa> if we need to ask for missing transactions, there is an extra roundtrip, which makes it likely slower than full block download for many connections
00:18 < BlueMatt> you also cant request missing txn since they are no longer in mempool [...]
00:21 < gmaxwell> sounds like we really do need a protocol extension for this.
[...] 00:23 < sipa> gmaxwell: i don't see how to do it without extra roundtrip
00:23 < BlueMatt> send a list of txn in your mempool (or bloom filter over them or whatever)!

抜粋で述べたように、トランザクションを要求するために個々のトランザクションハッシュの送信と同様、ブロック内の個々のトランザクションの送信をサポートするようプロトコルを拡張することで、Compact Block方式をはるかに単純化し、DoS耐性があり、より効率的にすることができます。

さらに詳しい情報源

Segregated Witnessの恩恵

Tue, 26 Jan 2016 00:00:00 +0000

Overview

Malleabilityの解決
- 誰に恩恵が？
- より詳しい情報
sighash操作の線形スケーリング
- 誰に恩恵が？
- より詳しい情報
pay-to-script-hash (P2SH) によるマルチシグのセキュリティ強化
- 誰に恩恵が？
- より詳しい情報
スクリプトのバージョンニング
- 誰に恩恵が？
UTXOの成長を縮小
- 誰に恩恵が？
- より詳しい情報
署名を検証しない場合の効率が向上
- 誰に恩恵が？
ブロック容量/サイズの増加
- 誰に恩恵が？
単一の結合されたブロック制限に向けた取り組み
- 誰に恩恵が？
- より詳しい情報
更新 2016-10-19
更新 2020-06-23
インプットの量への署名
- 誰に恩恵が？
- より詳しい情報

Segregated Witnessのソフトフォーク（segwit）には幅広い機能が含まれており、その多くは高度に技術的です。このページにはこれらの機能の恩恵の一部がまとめられています。

Malleabilityの解決

Aixcoinのトランザクションはトランザクション識別子(txid)と呼ばれる64桁の16進数のハッシュで識別されます。このハッシュはトランザクションで使用されるコインとそのトランザクションの結果使用可能になるコインの両方の情報に基いて生成されます。

残念ながら、txidの計算方法上、トランザクションの意味を変えない小さな変更を加えることでtxidは変更されます。これは第三者によるmalleabilityと呼ばれています。BIP 62(“dealing with malleability”)は、この問題に少しずつ取り組もうとしましたが、コンセンサスに実装するには複雑過ぎ取りやめました。

例えば、あなたがtxidがef74…c309のトランザクションをネットワークに送信したとして、あなたのトランザクションを中継するネットワーク上のノードや、あなたのトランザクションのブロックに入れるマイナーなどの第三者がトランザクションを少し変更しても、あなたのトランザクションは同じコインを同じアドレスに支払うことになりますが、そのトランザクションはあなたが送信したものとは全く違うtxidで承認されています。

より一般的には、トランザクションの署名者の１人もしくは複数人が署名を変更すると、トランザクションは有効なまま同じ金額を同じアドレスに支払いますが、txidには署名も含まれるためtxidは別の値に変更されます。（インプットやアウトプットを変更せず）署名データを変更することでトランザクションを変更する方法をscriptSig malleabilityと呼びます。

Segwitでは、Aixcoinユーザーがトランザクションの可搬性のある部分をtransaction witnessに移動させ、witnessへの変更がtxidの計算に影響を与えないようwitnessを分離することによって第三者およびscriptSigによるmalleabilityを防ぎます。

誰に恩恵が？

使用済みのビットコインをトラッキングするウォレットの作成者: 自分が送信したトランザクションの状態を監視する一番簡単な方法はtxidで検索する方法です。しかし第三者のmalleabilityを考慮するとウォレットはtxidが変更されることを考慮したコードを実装する必要があります。
未承認トランザクションを使った取引: アリスがボブにトランザクション１で支払いをし、ボブがそれを使ってトランザクション 2でチャーリーに支払いをした場合、アリスの支払いトランザクションが改竄され別のtxidで承認されるとトランザクション 2は無効となりチャーリーには支払いが行われません。もしボブが信頼できるなら、彼はチャーリーに支払いを再発行するでしょう。そうでない場合、ボブはビットコインを手元にとどめておくことができます。
Lightning Network: 第三者とscriptSigによるmalleabilityが解決すると、Lightning Networkの実装の複雑さが減り、ブロックチェーン上のスペースの使用が大幅に効率化されます。scriptSigのmalleabilityが解決することで、各LightningのクライアントはAixcoinのフルノードを必要とせず、ブロックチェーンの監視をアウトソースする軽量なLightningクライアントを実行することも可能になります。
ブロックチェーンを使用するすべての人: マイクロペイメントチャネルや予想される新しいスマートコントラクトなど現在のスマートコントラクトの設計、理解、監視がより簡単になります。

注意： Segwitのトランザクションはそのインプットが全てSegwitを使用している（直接もしくは後方互換性のあるP2SHアドレスを使用している）場合にのみ、そのmalleabilityを回避します。

より詳しい情報

sighash操作の線形スケーリング

Aixcoinのブロックサイズを増やす簡単なアプローチの主な問題は、特定のトランザクションでは署名ハッシュの計算のスケールが線形ではなく二次関数的にスケールすることです。

本質的に、トランザクションのサイズを2倍にすると署名操作の数と、検証されるそれぞれの署名についてハッシュする必要があるデータの量の両方が2倍になります。これは個々のブロックの検証に25秒を要し、悪意をもって作られたトランザクションの検証には3分以上かかるようになります。

Segwitは、トランザクションの各バイトを最大2回だけハッシュすればいいように署名のトランザクションハッシュの計算を変更することでこれを解決します。これにより同じ機能がより効率的になるため、悪意あるトランザクションが作成されたり、より大きなブロックがサポートされるようになったとしても、署名ハッシュの計算による問題が発生することなく大きなトランザクションを作ることができるようになります。

誰に恩恵が？

署名検証のためハッシュデータの二次関数的なスケールが無くなると、より安全にブロックサイズを増やすことができます。またトランザクションサイズを制限することなくこれを行うことで、Aixcoinはマイニング報酬やクラウドファウンディングの支払いなどの大きなグループからの決済を引き続きサポートすることができます。

変更されたハッシュはwitnessデータにある署名操作にのみ適用されるため、ベースブロックの署名操作にはこれまで通り低い制限が必要です。

より詳しい情報

pay-to-script-hash (P2SH) によるマルチシグのセキュリティ強化

マルチシグの支払いは、現在160-bitのHASH160アルゴリズム（SHA256してRIPEMDしたもの）によって保護されているP2SHを使っています。しかし、署名者の1人が全ての資金を盗みたい場合、80bit(2⁸⁰)の作業で全ての資金を入手することが可能なマルチシグスクリプトの一部として有効なアドレスとスクリプトの衝突を見つけることができます。これは非常に潤沢なりソースを持つ攻撃者にとって可能性のある範囲です。（比較のため、Aixcoinのマイニングネットワークは毎秒1エクサハッシュで2週間で80bit分の作業をしています。）

Segwitは単一の公開鍵への直接的な支払いには（この種の攻撃には役に立たないため）HASH160を使用し、スクリプトハッシュへの支払いは256-bitのSHA256ハッシュを使用すことでこれを解決します。

誰に恩恵が？

Segwitを利用してマルチシグもしくはスマートコントラクトへの支払いを行う全てのユーザーが、スクリプトのための追加のセキュリティの恩恵を受けます。

より詳しい情報

スクリプトのバージョンニング

Aixcoinのスクリプトの変更によりセキュリティの強化と機能性が向上しました。しかし、既存のスクリプトの設計では、予め確保されている10個のOP_NOP opcodeをある条件で失敗するような新しいopcodeに置き換えることで後方互換のある（ソフトフォーク）変更のみが可能です。これは新しい署名方法やOP_CLTVのような機能を導入するのには十分ですが、どちらもハッキーで（例えばOP_CLTVは通常OP_DROPと組み合わせて使用するなど）2つの文字列を結合するなどの単純な機能を有効にするために使用することはできません。

Segwitはスクリプトにバージョン番号を含めることでこれを解決しているため、スクリプトバージョンを増やすだけで、非Segwitのトランザクションではハードフォークをする必要があるような追加のopcodeをサポートすることができます。

誰に恩恵が？

スクリプトのopcodeの変更が容易になると、Aixcoinの高度なスクリプトの作成が容易になります。これにはSchnorr署名の導入や鍵のリカバリを使用した署名サイズの縮小、サイドチェーンのサポート、Merklized Abstract Syntax Trees (MAST)を使用したよりスマートなコントラクトの作成やその他の研究レベルのアイディアが含まれます。

UTXOの成長を縮小

未使用のトランザクションアウトプット（UTXO）のデータベースは、新しいトランザクションが有効かどうか判断するため各検証Aixcoinノードによって維持されます。ネットワークの効率的な運用のためには、このデータベースへのクエリ及び変更を速く行う必要があり、理想的にはインメモリに収めるべきです。そのためにもデータベースのサイズをできるだけ小さく保つことが重要になります。

ただこれはAixcoinが成長するにつれ困難になります。各新規ユーザーは少なくとも1つのUTXOエントリーを持ち、プライバシーや柔軟性を向上させるためや、ペイメントチャネルやその他のスマートコントラクトを使用するのに複数のエントリーを持つようになるでしょう。

Segwitは、UTXOセットのサイズに影響を与えない署名データに対して、UTXOセットのサイズに影響を与える署名データよりコストを75%安くすることでこれを改善します。これにより、ユーザーに手数料を最小限に抑えるためにUTXOセットへの影響を最小限に抑えるトランザクションを使用することを奨励し、開発者にはUTXOセットへの影響を最小限に抑える方法でスマートコントラクトや新しい機能の設計を促すことが期待されます。

Segwitはソフトフォークによる変更であるため、ベースのブロックサイズは増えず、UTXOセットのワーストケースの成長率は同じままです。

誰に恩恵が？

UTXOの成長の縮小は、マイナーや企業およびフルノードを実行するユーザーにとって恩恵があり、より多くのユーザーがシステムに参加する中、Aixcoinネットワークの現在のセキュリティを維持するのに役立ちます。UTXOセットの成長を最小限にしようとするユーザーや開発者は、UTXOの成長に対するトランザクションの影響を無視する人と比較して、手数料が安いというメリットがあります。

より詳しい情報

Statoshi UTXO dashboard

署名を検証しない場合の効率が向上

過去のトランザクションの署名は今後のトランザクションの署名より重要でない場合があります。例えばAixcoin Coreはデフォルトで最新のチェックポイントより前のトランザクションの署名をチェックしません。またSPVクライアントは署名自体を一切チェックせず、既にマイナーや他のノードによって検証された結果を信頼します。ただし今のところ、署名データはトランザクションにとって不可欠なデータで、トランザクションハッシュを計算するのに必ず必要です。

署名データを分離することで、署名データに関心の無いノードはディスクから署名データを削除したり、最初からダウンロードするのを避けることでリソースを節約することができます。

誰に恩恵が？

Segwitアドレスを使用するトランザクションが増えると、プルーニングノードやSPVノードを実行しているユーザーは、より少ない帯域幅とディスク量で動作するようになります。

ブロック容量/サイズの増加

旧ノードはwitnessの含まれないブロックデータをダウンロードするので、そのデータに対して1MBのブロックサイズの制限ルールが適用されます。このため、witnessデータを含む完全なブロックを理解する新しいノードは、この制限を新しいものに自由に置き換えることができ、より大きなブロックサイズが可能になります。したがってSegregated witnessはこの機会を利用してブロックサイズの上限を4MB近くに引き上げ、リソースの使用についてブロックのバランスを取るための新たなコスト制限を追加します（これにより事実上ブロックのサイズは1.6MB〜2MBになります）。

誰に恩恵が？

アップグレードされたウォレットを使用するユーザーは、署名をトランザクションのwitness部分に移動することで、ブロックサイズの増加を利用できます。

単一の結合されたブロック制限に向けた取り組み

現在ブロックサイズには2つのコンセンサス制限があります。ブロックは1MBを超えることはできません。またブロック内の全トランザクションで20,000回以上の署名チェックを実行することはできません。

1つの制限が課せられたブロックに含めるトランザクションの最も収益性の高いセットを見つけるのは、ナップザック問題の応用で単純な貪欲法でほぼ完全に解決することができます。しかし2つめの制限が加わると、場合によっては良い解決策を見つけるのがとても困難になります。この理論上の問題は、ブロックを下回る大きさでマイニングされること強制するのに実際に使われています。

ハードフォークやブロックサイズを大幅に減らすこと無くこの問題を解決することはできません。Segwitでは問題を解決できないため、悪化させないようにします。Segregated witnessのデータに独立した制限を導入するのではなく、代わりにUTXOデータとwitnessデータの加重合計に1つの制限が適用され、両方を結合したエンティティとして同時に制限を適用します。

誰に恩恵が？

ブロック容量の制限を変更する将来のハードフォークが1つのパラメータの加重合計になる場合、最終的にマイナーが恩恵を受けます。例えば、

50*sigops + 4*basedata + 1*witnessdata < 10M

これによりマイナーは、手数料収入が最大になるようにブロックを簡単かつ正確に埋めることができ、ユーザーはトランザクションがマイニングされるのに必要な手数料をより確実に計算できるようになります。

より詳しい情報

更新 2016-10-19

このページの前のバージョンでは、Segwitの恩恵として”Compact fraud proofs”が記載されていました。しかし、実装されているように、SegwitはSegwitの有無に関わらずこれをより簡単にするものではありません。将来のソフトフォークでCompact fraud proofsを有効にしその恩恵を受けるには、Segwitで使われているコミットメントデータを拡張するのではなく、（コインベーストランザクションなどに）独自のコミットメントを導入する必要があります。

以前のテキストは:

Compact fraud proofs

Aixcoinのユーザーベースが拡張されると、ブロックチェーン全体を自然に検証するのはより高価になります。分散化されたトラストレスなAixcoinの性質を維持するためには、ブロックチェーン全体の検証をする余裕がないユーザーも、安価に検証できるようにしてブロックチェーン全体の検証ができるようになることが重要です。

Segwitは将来のソフトフォークでコミットメントデータを含められるようwitnessの構造を拡張することで、軽量（SPV）クライアントでも、ブロックで生成されたビットコインの数やブロックのサイズ、1ブロック内で実行されるsigopsの数などのコンセンサスルールの適用をできるようにします。

誰が恩恵を受ける？

Fraud proofsによりSPVのユーザーはAixcoinのコンセンサスルールを適用することができるようになり、個々のユーザーが攻撃される方法を削減するだけでなく、Aixcoinネットワーク全体のセキュリティを大幅に向上させる可能性があります。

これらのFraud proofsは将来のソフトフォークの一部としてwitnessのデータ構造に追加することができ、Segwitを使用しないトランザクションであってもSPVクライアントがルールを適用するのに役立ちます。

更新 2020-06-23

このページの以前のバージョンではSegwitの恩恵として「インプットの量への署名」が挙げられていました。しかし、現状の実装ではSegwitの有無に関わらず、これを安全にはできません。署名されたインプットの値に依拠するためには将来のソフトフォークが必要になります。

各インプットの値は個別に署名されているため、見かけ上手数料を欺く操作が可能です(CVE-2020-14199)。

以前のテキストは：

インプットの量への署名

ハードウェアウォレットがトランザクションに署名する際、使用される合計金額を簡単に確認できますが、インプットの全てのトランザクションの完全なコピーを持つ場合のみ安全に正確な手数料が決まり、偽のデータが提供されていないことを保証するためにそれらをハッシュする必要があります。署名されたトランザクション自体はとても小さくても、そのインプットが参照する個々のトランザクションは最大1MBになる可能性もあるため、これらは必ずしも安価な操作であるとは限りません。

Segwitではインプットの量を明示的にハッシュすることでこれを解決します。これはハードウェアウォレットにトランザクションのハッシュ、インデックスおよびコインの量を単純に与え（および使用される公開鍵が分かっていること）、使用されるトランザクションの規模や複雑さに関わらず安全にトランザクションに署名することができるようになることを意味します。

誰に恩恵が？

ハードウェアウォレットの製造元とユーザーは明確に恩恵を受けます。しかしこれは”Internet of things”アプリケーションのための小さな組み込みデバイスでAixcoinを安全に使用する方がより簡単です。

この恩恵は、Segwit対応アドレス（もしくはP2SHでネストされたSegwitアドレス）に送信されたトランザクションを使用する場合にのみ使用できます。

より詳しい情報

BIP 143