I'm not really sure what you mean. Yes, Bitcoin scripts can be infinitely complex, but hashes are only hashes (the "H" in P2SH), there are only so many opcodes, and the "only" thing your code needs to make sure is that when everything is combined and executed, the end result is "TRUE" (i.e. a single 01 in the stack top element, and no other stack elements). Pretty trivial. These two pages accomplish just this, fast and easy relying only on relatively easy-to-understand javascript: https://bitcoin-script-debugger.visvirial.com/https://bip32jp.github.io/english/createp2sh.htmlI have coded my own quick and dirty Python script that creates valid raw transactions from self-made sigscript and redeemscript (as in the OP), the output can indeed be broadcast with Bitcoin Core without a problem. In other words, they must be considered standard (if we by standard mean "doesn't get caught in Bitcoin Core's 'isStandad' function"), and they propagate normally through the network (i.e. the other standard nodes have problems with them) and are confirmed, mined and included in blocks, as expected. I still find it fascinating that no wallet software does this natively, as I think this is the most simple form of a Bitcoin transaction - they don't even have signatures! Take Peter Todd's (in)famous SHA1 transaction puzzle for example; the solution could not have been created in Bitcoin Core, but very well broadcast with it. What's I'm gonna do next to automate the process further is to make an Electrum plugin. Which will yield the end-result I was looking for all along. A simple GUI-solution. I do think it's a little sad I can't do it in Bitcoin Core (without forking it, which at this point is not desirable). What I meant was having Bitcoin Core automatically create the scriptSig for you for an arbitrary script is not feasible. As in it isn't possible to have sendtoaddress automatically construct, sign, and send the transaction if it has arbitrary scripts because Core doesn't know how to make the scriptSigs for those arbitrary scripts. Those sites are for you to create the scriptSig manually, which I guess is what you are asking: to be able to provide the scriptSig manually. |
|
|
|
I find it a little funny you can easily create a transaction here, and then later broadcast it in Bitcoin Core without a problem at all, but not create it within the client. These transactions thus pass "isStandard", The node IsStandard check is a little looser than the wallet's check for standard scripts. It isn't looking for standard script templates because it doesn't need to. but you have to rely on third-party tools (web services or simply Notepad++ - it's not THAT difficult) to assemble them.
But how do you have a piece of software know how to make the scriptSig/scriptWitness? You have to hard code it, or make something that's smart enough to figure it out own its own. Hardcoding means that the developers have to think of literally every possible script and write scenarios for them. That's basically impossible because there is basically an infinite number of possible scripts. And something smart enough to cover all scripts is also not really possible. Miniscript is something that does the "smart enough to figure it out own its own" but within a very limited subset of script that can be reasoned about. |
|
|
|
Locktime said "optional" in docs:
It is optional, but since you are using positional arguments instead of named arguments, it must be provided when you want to provide an argument positioned after it. Because you are doing positional arguemnts the parser doesn't know what each position corresponds to if one is missing. To actually not provide it, you have to use named arguments. That would look like: {
"jsonrpc": "1.0",
"id": 6,
"method": "walletcreatefundedpsbt",
"params": {"inputs": [{
"txid": "a77564bb72336febc5fe620bc67586dcc014bad6bb1c3aa53e3b01bb6159f241",
"vout": 0,
"sequence": 0
}, {
"txid": "a77564bb72336febc5fe620bc67586dcc014bad6bb1c3aa53e3b01bb6159f241",
"vout": 1,
"sequence": 0
}],
"outputs": [{
"tb1qgz5yfluv3n0sjcadxhmm3dk4xrwlglr88vsj8k": 0.00349723
}],
"options": {
"subtractFeeFromOutputs":[0]
}
}
}
|
|
|
|
If it really is the case that importmulti for P2SH with scriptPubKey and redeemscript can only produce watchonly-addresses in Bitcoin Core, I don't understand why the function exists in the first place since the public address alone is, of course, enough for watchonly.
importmulti can be used to import private keys and import scripts for which you already have the private keys for (e.g. adding a multisig to the wallet where you have one of the keys). importmulti is also useful for adding scripts and keys to your wallet so that you can use PSBT with those things. |
|
|
|
|
The argument following the outputs is an integer for the locktime. The options come after that.
|
|
|
|
src/bitcoin-cli -regtest importmulti '[{"watchonly":true,"timestamp":"now","redeemscript":"522102c3e42b212b6d9481869af2afda4861ebe3299b29c714d19b2fbd47564a40be102102d6b1958d3de900d3da6d0465437c331d8fa2645fa1d353d7fe3d9a84f7de30fc2103f0012c00c703d1ee5e1314dd6f07263ae65ba0fe40694071982c72c5eaf1521a53ae","scriptPubKey":"a9145acce455c2046881eb1c3c82f42d9ff128b1fe9187"}]'
src/bitcoin-cli -regtest importmulti '[{"watchonly":true,"timestamp":"now","redeemscript":"522102c3e42b212b6d9481869af2afda4861ebe3299b29c714d19b2fbd47564a40be102102d6b1958d3de900d3da6d0465437c331d8fa2645fa1d353d7fe3d9a84f7de30fc2103f0012c00c703d1ee5e1314dd6f07263ae65ba0fe40694071982c72c5eaf1521a53ae","scriptPubKey":{"address":"2N1XLFgxmv2KRNycNe2zKSEKSj3RgV4Z8df"}}]'
Both import the same thing. The second one just uses the notation to give an address instead of a raw scriptPubKey. |
|
|
|
|
The status changes are largely up to the author. At a certain point in the lifetime of a BIP, the author stops caring to update the status or just forgets that that's a thing to do.
w.r.t BIP 174, it could probably be changed to final status. But Final also implies a finality and that the BIP won't change. However BIP 174 does change from time to time, especially as new fields get added to it. It makes me a little uncomfortable to have it be Final but then still add things and change things in it.
|
|
|
|
Feels like a stupid JSON formatting thing; please help!
It isn't. Bitcoin Core only accepts a fix set of standard script formats. Your redeemScript is not one of those, so it gives a warning about it. Note that this is just a warning and the script and address are still added to your wallet. However because Bitcoin Core does not recognize the type of script, it is unable to produce a valid input for that script. It can only produce inputs for the standard scripts. |
|
|
|
But, this Bech32 address is longer - bc1qgdjqv0av3q56jvd82tkdjpy7gdp9ut8tlqmgrpmv24sq90ecnvqqjwvw97.
I'd also like to know why this address is longer than the usual, e.g. bc1q5shngj24323nsrmxv99st02na6srekfctt30ch?
The longer address is for a Pay 2 Witness Script Hash output. These contain the SHA256 of a script, which is longer than the hash160 of a pubkey in the shorter P2WPKH address. |
|
|
|
It's easier to do this by changing fRequireStandard for CMainParams in chainparams.cpp then starting Bitcoin Core with -acceptnonstdtxn. What else can we think of?
Hm, fees. I don't my node to say no to zero satoshi transaction fees. What do I change here (and/or elsewhere)?
Start Bitcoin Core with -incrementalrelayfee=0 -minrelaytxfee=0 -blockmintxfee=0 -dustrelayfee=0. You'll probably want to also increase -maxmempool, -limitancestorcount, -limitancestorsize, -limitdescendantcount, and -limitdescendantsizeWhat more... the maximum number of different sorts connections needs to be addressed, here: https://github.com/bitcoin/bitcoin/blob/master/src/net.hI'm thinking that several numbers must be changed here, especially the two values that end with "=8" (I can't write the names of the functions out, Cloudflare - interestingly - blocks me when I try to write them) should be changed to "=500" or so. You might not want to increase the maximum number of connections. You'll probably run out of file descriptors. |
|
|
|
In Window > Information it only shows me the directory where the blockchain is downloaded, but the wallet.dat file is not there. I haven't found a Bitcoin folder in the /user/Appdata/Roaming folder where the wallet.dat is usually stored. It seems strange to me as I searched for wallet.dat in the whole C drive and only wallet.dat of Electrum is in /user/Appdata/Roaming. Bitcoin core doesn't show up.
Wallets are stored in the datadir (i.e. where the blockchain is downloaded) unless you specified it to go somewhere else with -walletdir. It should be in <datadir>/wallets. You can also look at the debug.log file. There should be a line that looks like 2020-01-07T19:00:30Z BerkeleyEnvironment::Open: LogDir=<datadir>/wallets/database ErrorFile=<datadir>/wallets/db.log
The path to the directory containing your wallet file will be everything before /database and /db.log |
|
|
|
|
At the protocol level, Bitcoin doesn't use addresses. It uses a custom scripting language. Addresses are merely a human shorthand for some kinds of scripts. These scripts have a standard form, so when software sees those scripts, it can produce the corresponding address. However not all (and in fact most) scripts correspond to addresses.
What you are looking at is a Pay to pubkey script. This does not have an address. Thus no address is shown.
|
|
|
|
Hi everyone,
In the latest version of Bitcoin Core ver. 0.20 there seems to be no Bitcoin folder in the C:\Users\ABC\AppData\Roaming - hence wallet.dat is not stored in there.
Does anyone have experience with this and knows where it's now stored please?
It didn't change. Defaults like these don't just change, especially if there was nothing wrong with them. You probably chose a different datadir. Go to Window > Information and it will list the datadir path in that window. |
|
|
|
I would much rather do it that simpler way. However when I run `getblockchaininfo`, the key 'initialblockdownload' is always blank. All the other keys have values but that one does not [chain] => main
[blocks] => 637966
[headers] => 637967
[difficulty] => 15784217546288
[mediantime] => 1594035307
[verificationprogress] => 0.99999916914354
[initialblockdownload] =>
[size_on_disk] => 1911635625
[pruned] => 1
[pruneheight] => 636460
[automatic_pruning] => 1
[prune_target_size] => 1999634432
The JSON-RPC interface won't return a blank value for something in a JSON object, that's not allowed. It's probably returning false and your software is interpreting that to be blank or null. |
|
|
|
A scenario where this could happen is that a person is running two instances of the bitcoin software (in 2010, the software had cpu mining capabilities) on different machines with the same wallet file. Under this scenario, it is likely that he had copied the data from one machine to the other, which includes the wallet file. Then set both machines to start mining. Because they are using the same wallet, they will use the same pubkeys in their blocks.
but wallet files of early bitcoin core versions (before 0.13/2016 i believe) weren't deterministic and as far as i can tell the miner was getting a new keypair before mining which meant generating a new key would have given it an entirely different pubkey to mine to. Exactly, I would like to see what @achow101 thinks of that. Prior to 0.13, wallets had a keypool of 100 keys. Even with it being non-HD, there was still a lookahead of 100 keys, that's why you didn't have to backup the wallet every transaction. The keys in the keypool were still randomly generated. However it seems that the keypool feature wasn't introduced until 0.3.14 in October 2010. The latest version available at the time of these blocks being mined appears to be 0.3.2. I had thought that the keypool feature was implemented earlier than it actually was. The miner in the original software generated a new key every time it started. A new key would also be generated when it had found and submitted a new block so it would be using a new key on the next block it worked on. This new key was randomly generated. So what I described previously was not possible at this point in time. The only other reasonable explanation I can think of is the miner simply modified his software to use a fixed pubkey. |
|
|
|
A scenario where this could happen is that a person is running two instances of the bitcoin software (in 2010, the software had cpu mining capabilities) on different machines with the same wallet file. Under this scenario, it is likely that he had copied the data from one machine to the other, which includes the wallet file. Then set both machines to start mining. Because they are using the same wallet, they will use the same pubkeys in their blocks. So what happened is that this miner got lucky and both machines mined blocks. It is not unusual to see blocks with times very close to each other. It just means that the miner got lucky. This address isn't dormant/dead address either. It received and sent bitcoins later in 2010 and even in 2015. However, the two original coinbase transactions are interesting because one 8e23... mined coins were spent, but the mined coins from 5559... transactions were not.
This "address" (it isn't an address actually. blockchain.info is displaying this incorrectly) has only sent Bitcoin once. This "address" received Bitcoin in 2015 from a low amount spammer. These spammers will just send small amounts of Bitcoin to random addresses, usually for tracking purposes. Additionally, the particular scriptPubKey used in the coinbases is a P2PK scriptPubKey. This scriptPubKey does not actually have an address. If you look for just this scriptPubKey, you will find it was only used in those 2 coinbase transactions. It is not unusual for an "address" with multiple UTXOs to create a transaction that leaves out some of its UTXOs. Nothing strange about that. Are the coins from 5559 actually legit and unspent?
Yes. Just because they haven't moved doesn't mean they aren't. |
|
|
|
|
We would have to see your code. You are probably missing something in the JSON object constructions.
There's an easier way to check this. Bitcoin Core has an internal check called IsInitialBlockDownload. The boolean result of this is output in getblockchaininfo as the initialblockdownload field. When that becomes false, you can be reasonably sure that the node is fully synced. So you can just poll the getblockchaininfo RPC and wait for initialblockdownload to become false.
|
|
|
|
The current hidden RPCs are: invalidateblock
reconsiderblock
waitfornewblock
waitforblock
waitforblockheight
syncwithvalidationinterfacequeue
dumptxoutset
estimaterawfee
setmocktime
mockscheduler
echo
echojson
These RPCs are pretty much used only for tests and shouldn't be relied on for normal use. Their APIs may not be stable and may change at any time. These RPCs may also be removed at any time. |
|
|
|
Read doc/build-windows.md. It describes two methods for compiling on Windows: Cross compiling using the Windows' Subsystem for Linux or building using Visual Studio. The build instructions for Visual Studio are linked to another document, build_msvc/README.md |
|
|
|
|
Show Posts
