From 698072e0c914958ed732f8f3daccb9535f1650d6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pawe=C5=82=20Lewandowski?= <35259896+pawellewandowski98@users.noreply.github.com> Date: Fri, 8 Nov 2024 09:17:37 +0100 Subject: [PATCH] feat(ARCO-281): check commit message format and PR title (#632) --- .nojekyll | 0 BIP-239.md | 89 + README.md | 590 ++++++ api.html | 22 + api.md | 2329 ++++++++++++++++++++++ arc.json | 1653 +++++++++++++++ building_block_diagram.png | Bin 0 -> 45275 bytes building_block_diagram.puml | 69 + dist/index.css | 16 + dist/logo.png | Bin 0 -> 10282 bytes dist/swagger-initializer.js | 21 + dist/swagger-ui-bundle.js | 3 + dist/swagger-ui-bundle.js.map | 1 + dist/swagger-ui-es-bundle-core.js | 3 + dist/swagger-ui-es-bundle-core.js.map | 1 + dist/swagger-ui-es-bundle.js | 3 + dist/swagger-ui-es-bundle.js.map | 1 + dist/swagger-ui-standalone-preset.js | 3 + dist/swagger-ui-standalone-preset.js.map | 1 + dist/swagger-ui.css | 3 + dist/swagger-ui.css.map | 1 + dist/swagger-ui.js | 2 + dist/swagger-ui.js.map | 1 + errors.md | 50 + index.html | 49 + message_queue.png | Bin 0 -> 14212 bytes message_queue.puml | 40 + oauth2-redirect.html | 79 + 28 files changed, 5030 insertions(+) create mode 100644 .nojekyll create mode 100644 BIP-239.md create mode 100644 README.md create mode 100644 api.html create mode 100644 api.md create mode 100644 arc.json create mode 100644 building_block_diagram.png create mode 100644 building_block_diagram.puml create mode 100644 dist/index.css create mode 100644 dist/logo.png create mode 100644 dist/swagger-initializer.js create mode 100644 dist/swagger-ui-bundle.js create mode 100644 dist/swagger-ui-bundle.js.map create mode 100644 dist/swagger-ui-es-bundle-core.js create mode 100644 dist/swagger-ui-es-bundle-core.js.map create mode 100644 dist/swagger-ui-es-bundle.js create mode 100644 dist/swagger-ui-es-bundle.js.map create mode 100644 dist/swagger-ui-standalone-preset.js create mode 100644 dist/swagger-ui-standalone-preset.js.map create mode 100644 dist/swagger-ui.css create mode 100644 dist/swagger-ui.css.map create mode 100644 dist/swagger-ui.js create mode 100644 dist/swagger-ui.js.map create mode 100644 errors.md create mode 100644 index.html create mode 100644 message_queue.png create mode 100644 message_queue.puml create mode 100644 oauth2-redirect.html diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 000000000..e69de29bb diff --git a/BIP-239.md b/BIP-239.md new file mode 100644 index 000000000..b4fad2c59 --- /dev/null +++ b/BIP-239.md @@ -0,0 +1,89 @@ +
+ BIP: 239 + Layer: Applications + Title: Transaction Extended Format (TEF) + Author: + Simon Ordish (@ordishs) + Siggi Oskarsson (@icellan) + Comments-Summary: No comments yet. + Comments-URI: - + Status: Proposal + Type: Standards Track + Created: 2022-11-09 ++ +## Abstract + +Regular Bitcoin transactions do not contain all the data that is needed to verify that the signatures in the transactions are valid. To sign an input of a Bitcoin transaction, the signer needs to know the transaction ID, output index, output satoshis and the locking script of the input transaction. When sending a Bitcoin transaction to a node, only the previous transaction ID and the output index are part of the serialized transaction, the node will look up the locking script and output amount of the input transaction. + +We propose an Extended Format (EF) for a Bitcoin transaction, that includes the locking script and the amount in satoshis of all inputs of the transaction. This allows a broadcast service to validate all aspects of a transaction without having to contact a node or an indexer for the utxos of the inputs of a transaction, speeding up the validation. + +## Copyright + +This BIP is licensed under the Open BSV license. + +## Motivation + +Verifying that a transaction is valid, including all signatures, is not possible at the moment without getting the unspent transaction outputs (utxos) from the transactions that are used as inputs from a Bitcoin node (or a Bitcoin indexer). This lookup of the utxos always happens inside a Bitcoin node when validating a transaction, but for a broadcast service to be able to fully validate a transaction (including the fee being paid) it also needs to look up the utxos being spent, which complicates scalability, since this lookup needs to happen on a node (via RPC), that might be too busy to react within an acceptable time frame. + +A broadcast service would be able to validate a transaction almost in full if the sender would also send the missing data (previous locking scripts and satoshi outputs) from the utxos being used in the transaction. When creating a new transaction, the previous locking scripts and satoshi outputs are needed to be able to properly sign the transaction, so the missing data is available at the time of the transaction creation. Serializing the transaction to Extended Format, instead of the standard format, is at the point of creating the transaction no extra work, but does make it much easier for a broadcast service to validate the transaction when being received, before sending the transaction to a node. + +The main motivation for this proposal is therefore scalability. When incoming transactions contain all the data that is needed to validate them, without having to contact an external service for missing data, the broadcast service becomes much more scalable. + +## Specification + +Current Transaction format: + +| Field | Description | Size | +|-----------------|------------------------------------------------------|--------------------------------------------------| +| Version no | currently 2 | 4 bytes | +| In-counter | positive integer VI = [[VarInt]] | 1 - 9 bytes | +| list of inputs | Transaction Input Structure |