Bitcoin Forum
June 22, 2024, 01:46:17 AM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / Re: Resubmission of a modified transaction with the same fee on: April 20, 2023, 11:15:06 AM
Quote
In the rare case that someone used transaction malleability to change the TXID, then nodes would reject this new transaction since it does not meet the criteria for the increased fee as per BIP125. The original transaction would remain in the mempool.

Thanks a lot for the information! That answers my main question.

And thanks as well to everybody else who contributed to this discussion!
2  Bitcoin / Development & Technical Discussion / Resubmission of a modified transaction with the same fee on: April 19, 2023, 01:36:23 PM
Hey everyone,

I'd like to understand how Bitcoin nodes behave when receiving retransmitted transactions using the replace-by-fee mechanism. Specifiically, I have the following questions:

  • What happens if the transaction is resubmitted (following an initial transaction with the RBF flag set) with identical inputs and outputs but with recomputed signatures, changing the transaction ID? Is this considered a different transaction, violating the rule that the fee must increase by a specific amount? Or would the transaction be accepted and added to the mempool? Obviously, only one of the two transactions would ever be added to a block.
  • Assuming that this modified transaction is not accepted, would the original transaction be evicted from the mempool as well?
  • Assuming that this modified transaction is not accepted, is it still correct that the transaction would be silently dropped without affecting the sending peer's banscore?
Thanks in advance for any insightful reply!
3  Bitcoin / Development & Technical Discussion / Re: non-mandatory-script-verify-flag Error for P2WPKH Input (Rust) on: August 26, 2022, 09:05:30 AM
I ran the code again with more output:

  • Public key: 0377f5de845ac601f24e7cbf2e4abcc9e1040cd4ae971ecaa00837b1c74684e15b
  • Address: bcrt1qh3zle7xs34azdyycg8cpf9wx5nxjpcqyqv4eyc
  • Input spent with value: 625000000
  • Transaction to sign: 0100000001ceac446d9350730c2a886220bed7ae154ca3f717897819091d5e72dcd0f0895e00000 00000ffffffff0200e1f505000000001600148be949ae15ee4b5da9af0ce2bf8d3f3c43c582da26 dc4a1f00000000160014bc45fcf8d08d7a26909841f01495c6a4cd20e00400000000
  • Sighash: d7e5696f18363b58c84b8d57014d291c9f7ebbac562d219f7e7014b9a5685bbf
  • SEC1 signature: c10c09b210914e49f295c07c9f96352e085df9d2c4272292239445d6f89483bc64c9903bebaba4b bf998d217c80375c36b60b212a824b63435e30205b2ed5a6a
  • DER signature: 3045022100c10c09b210914e49f295c07c9f96352e085df9d2c4272292239445d6f89483bc02206 4c9903bebaba4bbf998d217c80375c36b60b212a824b63435e30205b2ed5a6a
  • DER signature with Sighash type: 3045022100c10c09b210914e49f295c07c9f96352e085df9d2c4272292239445d6f89483bc02206 4c9903bebaba4bbf998d217c80375c36b60b212a824b63435e30205b2ed5a6a01
  • Signed transaction: 01000000000101ceac446d9350730c2a886220bed7ae154ca3f717897819091d5e72dcd0f0895e0 000000000ffffffff0200e1f505000000001600148be949ae15ee4b5da9af0ce2bf8d3f3c43c582 da26dc4a1f00000000160014bc45fcf8d08d7a26909841f01495c6a4cd20e00402483045022100c 10c09b210914e49f295c07c9f96352e085df9d2c4272292239445d6f89483bc022064c9903bebab a4bbf998d217c80375c36b60b212a824b63435e30205b2ed5a6a01210377f5de845ac601f24e7cb f2e4abcc9e1040cd4ae971ecaa00837b1c74684e15b00000000

Could anybody please pinpoint where things go wrong?
4  Bitcoin / Development & Technical Discussion / Re: non-mandatory-script-verify-flag Error for P2WPKH Input (Rust) on: August 19, 2022, 04:19:11 PM
Thanks for the clarification!
As stated above, I'm using the code

Code:
let mut hash_cache = sighash::SighashCache::new(&txclone);
    for (index, input) in transaction.input.iter_mut().enumerate() {
        let value = get_value(input, own_utxos);    // Look up the value by finding the corresponding UTXO
        let sighash = hash_cache
            .segwit_signature_hash(index, &own_address.script_pubkey(), value, SIG_HASH_TYPE)
            .expect("Creating the segwit signature hash failed.");


to create the sighash. This is the standard bitcoin::util::sighash function, which should yield the correct sighash if I'm not mistaken.
Is this the wrong function? Or is there a problem with the inputs? The index, value, and SIG_HASH_TYPE should be fine, so that would leave the script pubkey (but again, this is a standard bitcoin::Address...).
5  Bitcoin / Development & Technical Discussion / Re: non-mandatory-script-verify-flag Error for P2WPKH Input (Rust) on: August 19, 2022, 02:31:09 PM
Sorry, I forgot to mention that I'm working in RegTest mode (as you guessed correctly), so the address (bcrt1q3055nts4ae94m2d0pn3tlrfl83putqk6qnjp0d) does exist and has sufficient funds in my local chain.

As you can see in my code, I switched to using the segwit_signature_hash function to (hopefully) get the right piece of data that needs to be signed.
I read BIP-143 and concluded that only the transaction digestion algorithm changed but not the signing algorithm itself. Did I misunderstand this part?
6  Bitcoin / Development & Technical Discussion / non-mandatory-script-verify-flag Error for P2WPKH Input (Rust) on: August 19, 2022, 11:50:57 AM
Hi everyone!

I'm trying to create a transaction programmatically (in Rust) that spends an output associated with a P2WPKH address. This is the relevant code snippet:

Code:
fn sign_transaction<SignFun>(
    own_public_key: &[u8],
    own_address: &Address,
    own_utxos: &[Utxo],
    mut transaction: Transaction,
    key_name: String,
    derivation_path: Vec<Vec<u8>>,
    signer: SignFun,
) -> Transaction
where
    SignFun: Fn(String, Vec<Vec<u8>>, Vec<u8>) -> Fut,
{

    let txclone = transaction.clone();
    let mut hash_cache = sighash::SighashCache::new(&txclone);
    for (index, input) in transaction.input.iter_mut().enumerate() {
        let value = get_value(input, own_utxos);    // Look up the value by finding the corresponding UTXO
        let sighash = hash_cache
            .segwit_signature_hash(index, &own_address.script_pubkey(), value, SIG_HASH_TYPE)
            .expect("Creating the segwit signature hash failed.");

        let signature = signer(key_name.clone(), derivation_path.clone(), sighash.to_vec()).await;

        // Convert signature to DER.
        let der_signature = sec1_to_der(signature);

        let mut sig_with_hashtype = der_signature;
        sig_with_hashtype.push(SIG_HASH_TYPE.to_u32() as u8);
        let witness_bytes = vec![sig_with_hashtype, own_public_key.to_vec()];
        input.witness = Witness::from_vec(witness_bytes);
    }

    transaction
}


SIG_HASH_TYPE is simply EcdsaSighashType::All.

I get the following serialized transaction:
Code:
010000000001016e97eae878274b6663923994bf7622c72ed41ce71d9d5d4091905378eeb0e5fa0000000000ffffffff0200e1f505000000001976a9148f7918f50cfd908ff82294a12c926f0fc52b0d1d88ac3e160d8f000000001600148be949ae15ee4b5da9af0ce2bf8d3f3c43c582da02483045022100999dd2a10b036d6b599d7d6b205f62b4dd14aca4b4c0d12224c0daa35c34bbea022025702dd922f94bd5b9444f798ab4ad7bcdbdd53568d7a45c6086a3e6f81b20d4012103366e75877b80252ff39e76229fe6d88d14e1150256bfdd27e7726b6b2cb23c0200000000

When trying to submit it, I get the following error:

Code:
error code: -26
error message:
non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation)

When decoding the transaction (using decoderawtransaction), everything looks okay as far as I can tell but I might be missing something.

Note that I adapted the code from the following working example that signs a P2PKH input:

Code:
...
let sighash = txclone.signature_hash(index, &own_address.script_pubkey(), SIG_HASH_TYPE.to_u32());

let signature = signer(key_name.clone(), derivation_path.clone(), sighash.to_vec()).await;

// Convert signature to DER.
let der_signature = sec1_to_der(signature);

let mut sig_with_hashtype = der_signature;
sig_with_hashtype.push(SIG_HASH_TYPE.to_u32() as u8);
input.script_sig = Builder::new()
    .push_slice(sig_with_hashtype.as_slice())
    .push_slice(own_public_key)
     .into_script();
input.witness.clear();

Can anybody spot a mistake in the code? Am I signing the wrong data?
If you need additional information, just let me know.
Thanks!
7  Bitcoin / Development & Technical Discussion / Re: How many IPv6 nodes are dual-stack nodes? on: July 08, 2022, 03:12:03 PM
Thanks for your reply!
8  Bitcoin / Development & Technical Discussion / Re: How many IPv6 nodes are dual-stack nodes? on: July 07, 2022, 05:10:39 PM
Thanks a lot for your answers!
I agree with Dave that probably most nodes that offer an IPv6 endpoint are dual-stacked.

Quote
Is this just something you'd like to know "for fun" or are you curious about how decentralised cryptocurrency is.

I'm working with IPv6-only machines and I'm wondering if there could be a security risk when connecting only to the advertised IPv6 addresses.

For example, if the number of IPv6 nodes is small and these node are separate machines, an attacker might try to get them all to extend a fork. However, if these machines are part of the IPv4 network as well, this risk is reduced because the nodes still obtain the proper blocks.

Does anybody see security risks when running IPv6-only machines?
9  Bitcoin / Development & Technical Discussion / How many IPv6 nodes are dual-stack nodes? on: July 07, 2022, 09:35:35 AM
Hey everyone!

I have a question regarding IPv6 nodes. According to websites such as bitnodes.io, there are +1000 active IPv6 nodes and +6000 active IPv4 nodes (not counting  the nodes behind .onion addresses).

How many of the IPv6 nodes are actually dual-stack nodes, providing access via IPv4 and IPv6? In other words, how many of the IPv6 nodes are also counted in the set of IPv4 nodes?

I wonder if this can be determined or at least estimated somehow.
If there is no good way to accurately answer this question, what do people in the forum think? How do you run your node(s)?

Thanks in advance for any information you can share!
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!