5
Any script can be used in P2SH/P2WSH technique. Using arbitrary scripts in transaction outputs cause grows of UTXO database and other problems.
4
Varying the signature per input helps prevents some attacks during multi-party transaction construction.
Consider a coinjoin involving Alice and Bob. Alice selects one of her UTXOs for the coinjoin. Bob chooses a UTXO for his input, but he actually selects ones of Alice's other UTXOs that reuse the same address as the one she selected. Alice does not ...
3
Do all the miners have one global pool filled with transactions
Different full nodes have a different version of the mempool. Transactions are broadcasted to the bitcoin network on a best effort basis. If a transaction never reaches a node, it would not include it in the mempool. It would not learn about this transaction until it is included in the block by ...
3
You only need to use OP_PUSHDATA1 if you are trying to push more than 75 bytes of data onto the stack.
For pushing smaller sized values onto the stack, you can use the opcodes 0x01 to 0x4b to indicate the number of bytes being pushed. Thus, to push a single byte of value 210 (0xD2) onto the stack, you would use the byte sequence 0x01 0xd2.
To push a 16-bit ...
3
Is there a particular reason why a size of 8 bytes was chosen
Probably not.
In the original Bitcoin source code, many of the primitives used in data structures were simply the in-memory representations of those primitives. For integers, this is a 32 bit (4 byte) little endian integer. However 32 bits is not enough to represent all of the satoshis that ...
3
No, the number that can be represented by the varint has no effect on the maximum number of inputs. That number is far too large. Rather the maximum number of inputs is constrained by the block size.
If it really matters to you what the maximum number that a varint can represent is, it's just the maximum value for a 64-bit integer. That's 0xffffffffffffffff....
3
bitcoind has a decodescript method.
$ bitcoin-cli decodescript "512102974ffd58d960908d6f2930fbcc4aa288580d05b35a70869e9a8ada3d080acf392103ef884166c7bd20324fd7f959dc680989a6a8b0d62c348defa900fcd4d31200f152ae"
{
"asm": "1 02974ffd58d960908d6f2930fbcc4aa288580d05b35a70869e9a8ada3d080acf39 03ef884166c7bd20324fd7f959dc680989a6a8b0d62c348defa900fcd4d31200f1 2 ...
3
‘Batching’ generally refers to making payments to multiple addresses, all within a single bitcoin transaction. Put differently, this means you would craft a transaction with many outputs, each one paying out a different customer, for example.
In your case, you are trying to consolidate funds (UTXOs). The outcome is similar: a more efficient use of block ...
2
This null script event what is it due to? Is there any phenomenon I am not aware of?
There is no script needed to spend the transaction vout referenced in the input because it was not locked with a key. For example, the txid of the first transaction referenced is c3d8d15a3ca1b50fc2519cbcb79f1db3b6be164c176c7ad51c7a5ec2e97ffa7b with output index 204. Below ...
2
It stands for:
45505446 - EPTF - Electrum Partial Transaction Format
ff - Separator
00 - EPTF Version - This is currently always 0.
You can verify this quickly by running a python interpreter.
Python 3.6.7 (default, Oct 22 2018, 11:32:17)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> b'EPTF\xff'....
2
I don't think this is possible. Most, if not all, block explorers and blockchain indexers do not completely disassemble scripts and index them so that they are searchable. No software or service I know of allows you to search by opcode use in a transaction. It would be pretty useless for a service to provide this as probably no one would actually use it and ...
2
The following scriptPubKey describes the desired contract:
OP_IF
OP_DUP OP_HASH160 <Bob's pubKeyHash>
OP_ELSE
<now+30 days> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_DUP OP_HASH160 <Victor's pubKeyHash>
OP_ENDIF
OP_EQUALVERIFY OP_CHECKSIG
Bob can spend the output using the scriptSig <Bob's signature> <Bob's pubKey> OP_TRUE
...
2
Those transactions spend Pay-To-Pubkey outputs. These are not special or strange and are actually the very first kind of outputs to ever exist in Bitcoin. These outputs simply do not have an associated address type which is why block explorers do not show an address for them.
Also, just because a block explorer can't show an address type does not mean that ...
1
Bitcoin does not have the concept of account balance. Anyone who can provide a valid signature to the locking script of a particular transaction output can spend those bitcoins. As a result when you spend your bitcoins in a transaction, you have to include the transaction id and the output no. from which you earned those bitcoins. The nodes maintain a set of ...
1
Since OP has asked for a specific reference, I'll copy some relevant text from the Mastering Bitcoin reference book. I cut some of the less relevant info out, and added bolded emphasis that is relevant to OP's question:
From chapter 8 - Transaction Pool:
Transaction Pools
Almost every node on the bitcoin network maintains a temporary list of ...
1
To push data to the stack, if there is no opcode (i.e. there is no opcode for the number 210, but there are for the numbers 1-16: OP_1 - OP_16), you need to provide a push op. Since 210 can be represented in a single byte:
OP_10 0x01 210 OP_ADD
^ ^ ^ ^
| | | | pop the top 2 items, add, and return result
| | | Push number 210 to ...
1
Kind of.
There is no "the pool" or "the mempool" (which is what I assume you are talking about when you say "the pool"). Rather each node maintains its own mempool which may be different from another node's mempool. Because each node receives a given transaction at different times, the amount of time a transaction spends in the mempool will also vary from ...
1
The output being spent is a native segwit output. If you look at the transaction that created it, you get 0014644a61cf83439e53b5dd413bec63c98c9e39c107 for the lock script, which is a native segwit p2wpkh output.
Spending a purely segwit output requires no value to be set for the scriptSig (unlike for a p2sh-p2wpkh).
The address is shown as unparsed as ...
1
That limit (which is different today) pertains to node policy and transaction standardness. It is important to keep in mind that something that is non-standard is not necessarily invalid. Validity and standardness are two different things, although standardness is a subset of validity.
A transaction smaller than the standardness minimum can still be valid. ...
1
The third parameter is just your outputs script (actually it's the whole outputs part of a transaction) so depending on which address you want to send the funds it will change.
It's using the same format as in bitcoin transactions. The data are serialized like this
TYPE | Description
VARINT | Number of outputs to create
8 byte | Amount to send to the ...
1
The inputs of a transaction have absolutely no ability to effect the outputs in any situation. They can only define who can spend, not the conditions for how they go about spending it.
1
For a P2PKH anyone-can-spend, just send to the address 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH -- its private key is the integer 1, or in WIF format, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn. Anyone can spend from this address since the private key is known to all.
Only top voted, non community-wiki answers of a minimum length are eligible
