text:
Get public or private key from address with C-lightning
I'm studying Lightning network and I use c-lightning.
I can Get a new address with newaddr method, but I can't find private key.
My address is bcrt1qmckts70jsq2u5886lgcq2yn7xjmp97t09zlrg, how can I retrieve it's public key?
Where Can I find it's private key?
$ bitcoin-cli validateaddress bcrt1qmckts70jsq2u5886lgcq2yn7xjmp97t09zlrgj                                                              │
{                                                                                │
  "isvalid": true,                                                                                │
  "address": "bcrt1qmckts70jsq2u5886lgcq2yn7xjmp97t09zlrgj",                                                                            │
  "scriptPubKey": "0014de2cb879f28015ca1cfafa3005127e34b612f96f",                                                                       │
  "isscript": false,                                                                                │
  "iswitness": true,                                                                                │
  "witness_version": 0,                                                                                │
  "witness_program": "de2cb879f28015ca1cfafa3005127e34b612f96f"                                                                         │
}

lightningd doesn't offer simple RPC commands to dump keys.
If you really need to access the keys the simplest way would be to derive them directly from the hsm_secret.
Keys for onchain transactions (since you mentioned newaddr. The other derivations are more involved) are derived using BIP32 unhardened derivation from m/0/0.
The root seed is derived from the hsm_secret with :
root_seed = hkdf_sha256(hsm_secret, salt=NULL, info="bip32 seed")

There exist tools such as the hsmtools (which currently only derive keys for the commitment transactions but might be extended in the furure) or jb55's clightning-dumpkeys which take care of the derivation for you.


text:
Will c-lightning's `withdraw destination all` take anything from the channel funds?
Will c-lightning's withdraw destination all take anything from the channel funds?
Does the string all that can be  used  to specify  withdrawal of all available funds refer only to onchain funds with "status": "confirmed" in listfunds's result?

The withdraw command makes an onchain transaction to send a given amount of onchain funds to the specified destination. It will not close any channel beforehand to withdraw funds locked there.
Whether or not it will sweep unconfirmed UTxOs as well is specified to the command via the minconf optional parameter, which can be set to 0. See the manpage for more details on the usage of the command.
So, yes, by default it refers only to UTxOs with the status field set to confirmed in listfunds. Note however that withdraw <addr> all will not sweep the reserved UTxOs (those with a reserved_to_block block field superior to the current block height in listfunds's result).

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
What's the advantages of using the block chain as opposed to L2 solutions
I'm looking for a good example and explanation from a software architecture perspective BUT for general audience about the benefits of solving and having blockchain features on Layer 1 not disregarding any Layer 2 solution or blockchain but in fact comparing.
In example any scaling solution for off-chain transaction will definitely face speed issues in comparison to one that was solved on the original design of the blockchain.
It's not a fair comparison because both have their reasons, their strengths and their fame but if you take lightning or æternity state channels you will have some design flaws that should be talked about to help people to understand and decide based on more than just marketing.
Again this isn't in any way a critic towards any of the solution but an example to talk about design and architecture and not about which had better marketing.

I think it's in essence a great question that deserves a decent answer to link to it. I'm thinking of a wanna-be decent answer and i find some terms of your question confusing. First, i think you mean "technological perspective" rather than "software architecture perspective"? Then you state "any scaling solution for off-chain transaction will definitely face speed issues in comparison to one that was solved on the original design of the blockchain". I can't help but say it's plainly objectively wrong. Could you shed some light on this one so i can take a shot at writing an answer ? :)

Thanks for reading my question @darosior . For the first statement I think it's right as I'm speaking about the architecture of the software piece/s rather than technological perspective as a broader concept. For the second statement  that's exactly what I'm trying to get an answer, if you planned such features while you were designing your software and you did it well it should run better and faster that if you put something on top tomorrow to get those features.

Oh, then you were talking about pace in software development ? I misinterpreted it for "The speed of /Bitcoin usage/". Then i think i can write an appropriate answer, thanks!

I'm putting concrete examples of developed technologies that show exactly my concern and question. This is not a theoric question but a practical one on based on architecture practices and software engineering.

Sorry completely forgot about it, will write a response soon with practical examples.

From the point of view of an application developer, it is for now much easier to use layer 1 features.
This is due to being able to externalize your burden on the network.
1. Hey nodes, will you do my job?
Blocks are expensive to produce
You don't need to have much DOS concerns in your application if you are only reacting to onchain payments. But what happens if you do an expensive operation each time your Lightning node accepts an HTLC ?..
Backups are simple
You don't have to think much about backing up the state of your application for your user: your data is public and stored by everyone. Your user only has to back up a very small amount of data.
On Lightning, you are responsible for your own data. That's sometimes surprising to users who have been accustomed to (ab)using the block chain for years :).
In addition, on Lightning in its current form you are in a pretty bad position should you miss a single state backup. But this may be fixed in the future.
The security model is simple(r)
Even if there are some pitfalls and idiosyncrasies in Bitcoin, it's way harder to reason about assumptions you can reasonably make for your software and what you can convey to your user is a reasonable usage of your software.
For instance, "may i allow my user to re-import their HD wallet master account in another wallet?"

Bitcoin onchain: sure, what could go wrong?
Bitcoin offchain: meh. It's not that simple.

The same goes with "may i dig a hole, put my wallet in there, come back in a year, and still be in full possession of my coins ?"

Bitcoin onchain: sure, what could go wrong?
Bitcoin offchain: meh. It's not that simple.

Bootstrapping is simpler
Even if we usually make the analogy to "send coins to", Bitcoin onchain did not require interactivity. Just send the transaction to every single node on the network, make them verify it for you and call it a (lazy) day.
Now with Lightning for someone to start paying they need to find a way to connect to the payee, actually making the above analogy closer from the truth as they are actually transferring data.
For someone to start receiving payments, they also need to "be able" to be paid (have enough inbound liquidity).
Payments get increasingly more secure
Under Lightning's assumptions, a payment will be almost instantly "secure" :tm:
In practice, arguably even more so than a handful of onchain confirmations. However, maybe not more than a hundred. Or not than a thousand, or ten thousands confirmations.
For some applications (such as making very large payments), you may want to use this feature unique to the block chain: don't consider a payment to be made until a reorganization of the block chain that deep would put the entire currency down anyway.
2. Hey nodes, can you be more qualified at my job?
Of course, there are also drawbacks to (ab)using the chain.
Decent payment security is slow to bootstrap
Getting the first confirmation may be infinitely longer than on a layer 2 system. If you ask "if my payment can go through successfully, when is it going to be finalized?":

Bitcoin Lightning: immediately. (this assumes unstuck payments)
Bitcoin onchain: well, lemme explain you the block space market.

UTXO management
This logic is one you can't outsource to the nodes :). It's pretty difficult optimization problem that highly depend on the usage that is going to be made of your software. It takes a deep understanding of the tradeoffs and knowledge of the existing solutions to the developer to make a sensible decision.
On Lightning, you don't have to manage coins. The value is similar to a flux rather than to actual physical, indivisible coins.
Fees orthogonal to payments and fee management
Onchain fees depend on the actual transaction (in the database sense of the term) size, not on the actual payment. They are in addition very unreliable, in theory you really can't know for sure that your transaction is going to make it into a block in advance. You are really hoping for the best.
The counter measures for adapting to this always-moving block space market incur an additional cost in knowledge and understanding (and complexity of implementation) to the application developer, similarly to coin selection (which is tightly related).
"how much is my finalized payment going to cost me?":

Bitcoin Lightning: a proportional fee of x sats per million of sats transferred and a fixed fee of y.
Bitcoin onchain: well, lemme explain you the block space market.

Higher usage cost
As the demand for the finite resource of block space increases, so are average fees premium to be included as soon as possible in the chain. This makes some design of application not possible onchain anymore, re-aligning the incentives of (ab)using the network to incur less burden to the software / user of the software.
Lack of features
Onchain nodes are pretty restricted in what they can verify for you. Some more complex systems can be emulated on a L2 network with different trust assumptions than the base trustless network (eg with sidechains).
The advantage of not doing it onchain here is that it's opt-in: you don't have to make the entire network and economy accept to augment their functionalities in order to bear even more burden than previously.
Some features may be either backward incompatible or present tradeoffs that not everyone would accept. Their addition to the base layer would raise big questions about the censorship resistance of the system and finally the point of using it in the first place.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Is there some kind of USB antenna I can buy to be able to use Bitcoin even when there is no Internet?
Let's say they cut the Internet tomorrow. I will still have my private keys on my offline computer, but I won't be able to sync the blockchain (as won't anyone else) nor would i be able to make any transaction either.
But once I heard something about a satellite beaming down the blockchain at all times or something. And that was in like 2013. Did that ever go anywhere?
Is there some readily sold product which I can order which is like a little antenna which I attach via USB to my PC and which then can receive the blockchain and send coins via some kind of satellite or other form of radio communication in a decentralized manner?

Blockstream have multiple satellite circling around the earth and broadcasting the blockchain or receiving and sending transaction without interruption.
https://blockstream.com/satellite/
They have their own kit to use the service:
https://store.blockstream.com/product/blockstream-satellite-basic-kit/

Note that the satellites aren't owned by Blockstream. They rent bandwidth on existing telecommunication satellites.


text:
Get the scriptPubKey from a Taproot address
I have this function that converts a Bitcoin private key as an integer to a public key and an address.
def get_seg_v1_from_pkey(imported_key):
    imported_key_toint = int(imported_key)
    privKeytoHex = imported_key_toint.to_bytes(32, 'big').hex()
    prv = HDKey(privKeytoHex)
    prv_tnet = TNetHDKey(privKeytoHex)
    pubkey = prv.public_hex
    pub_tnet = prv_tnet.public_hex
    version = 0x01
    address = program_to_witness(version, pubkey[2:], main=True)
    address_testnet = pubkeyhash_to_addr_bech32(pubkeyhash=pub_tnet[2:], prefix='tb', witver=1, separator='1', checksum_xor=0x2bc830a3)
    return pubkey, address, address_testnet

HDKey imports the integer into a proper private key object like what is used in https://github.com/bitcoinops/taproot-workshop. TNetHDKey is a custom function I wrote that does the same thing as HDKey but it stores the private key in a way that makes it easily convertible to a testnet address.
I want to get the scriptPubKey from an address like in this function in https://github.com/bitcoinops/taproot-workshop:
def create_spending_transaction(self, txid, version=1, nSequence=0):
    """Construct a CTransaction object that spends the first ouput from txid."""
    # Construct transaction
    spending_tx = CTransaction()

    # Populate the transaction version
    spending_tx.nVersion = version

    # Populate the locktime
    spending_tx.nLockTime = 0

    # Populate the transaction inputs
    outpoint = COutPoint(int(txid, 16), 0)
    spending_tx_in = CTxIn(outpoint=outpoint, nSequence=nSequence)
    spending_tx.vin = [spending_tx_in]

    # Generate new Bitcoin Core wallet address
    dest_addr = self.nodes[0].getnewaddress(address_type="bech32")
    scriptpubkey = bytes.fromhex(self.nodes[0].getaddressinfo(dest_addr)['scriptPubKey'])

    # Complete output which returns 0.5 BTC to Bitcoin Core wallet
    amount_sat = int(0.5 * 100_000_000)
    dest_output = CTxOut(nValue=amount_sat, scriptPubKey=scriptpubkey)
    spending_tx.vout = [dest_output]

    return spending_tx

Notice these lines in the above function:
# Generate new Bitcoin Core wallet address
dest_addr = self.nodes[0].getnewaddress(address_type="bech32")
scriptpubkey = bytes.fromhex(self.nodes[0].getaddressinfo(dest_addr)['scriptPubKey'])

self.nodes[0] refers to a running instance of bitcoind on your computer. I want to replicate this function without requiring a running instance of bitcoind. In my version of this function I plan on passing in dest_addr because I won't have a bitcoind instance to generate it. Is there a way to get a scriptPubKey from a raw segwit v1 address?

You can use the reference Python implementation of bech32 / bech32m. Decode the address using bech32_decode and get the human readable part, data encoded (the scriptPubKey you are looking for), and whether this address is bech32 or bech32m.

The scriptpubkey for a P2WPKH address is 0x0014{20-byte-key-hash} (from bip141)
You get the keyhash by decoding the address from the bech32 encoding.
You can use this library (I am the author) to do that or to construct the spending output.
>>> from cryptotools import Address

>>> addr = Address('bc1qh2egksgfejqpktc3kkdtuqqrukrpzzp9lr0phn')
>>> addr.type()
<ADDRESS.P2WPKH: 'P2WPKH'>

>>> output = addr._receive(50_000_000)
>>> output.script.hex()
'0014bab28b4109cc801b2f11b59abe0003e586110825'

Thanks for the answer, my address is a segwit_v1 (bech32m). Will cryptotools work with that? And would the answer need to be modified in that case?

Oops sorry I missed that, no taproot support yet.

No problem, thanks for trying


text:
Wallet no longer shows Bitcoin balance
I checked my wallet (Monarch wallet) about a week ago and I had a small amount of bitcoin in  it. I looked at it again a few days ago and it had vanished. I tried recovery, uninstalled wallet and reinstalled, but no luck.
I have been in contact with Monarch support, they say the coin is there, but they have run out of ideas on how to recover. Is there anything I myself can do to recover my wallet, without needing the help of the wallet's support team?

If you are using some wallet software and it ceases to function for you, then you can attempt to recover your wallet using different software. This is of course only possible for wallets which you have complete control over (which means you control the private keys, not custodial accounts where some service provider controls your keys). You can attempt recovery by importing your private keys themselves into new software, or more commonly, you can recover the wallet by using your BIP39 mnemonic seed phrase (usually 12 or 24 words). This seed phrase has become an industry standard, so as long as the wallet you currently use utilizes BIP 39, you should have no problem finding some new wallet software you can perform the recovery with.
Note that the wallet will derive your private keys and bitcoin addresses from the mnemonic seed phrase, and there are many possible derivation paths available. BIP 44/49/84 define standard paths, but there is a possibility the wallet you use will use a non-standard path. In that case, you will need to find out what path was used, and then find some software that will allow you to define a custom derivation path.


text:
I plan to buy any FPGA boards, any idea for a good sources of information? and what coin is profitable?
Do you guys know any good source for newbie FPGA miners?

https://fpga.guide/en/ is a good place for beginners who want to learn about fpga mining. they also have a calculator page so you can find out which coin is the most profitable

emmm, interesting, thank youuu,
have you mine with FPGA already?

Yes, I've been mining with FPGAs for over a year. If you want to start out, I suggest you start with an F1 Mini or something


text:
Throughput of Lightning Network
Is there any reliable source of information regarding the estimation of the number of payments that occur in Lightning Network every day? If the total number is impossible to estimate are there any nodes that publish their throughput i.e. the number of payments they handle every day?

as explained here I showed that the betweeness centrality of a node on the fee graph is proportional to the expected routing fees which again is proportional to the throughput of your node.
So taking your throughput and dividing it by your betweeness centrality score should give you a rough estimate of how much throughput is handled by the network.
That being said. The betweeness centrality is constantly chaning as well as routing fees. Also the entire argument assumes a uniform distribution of sender, receiver pairs (which is highly unlikely) Other than that there are no verifiable sources you can use. You will however find people publishing their logfiles or some statistics. All of that information has to be taken with doubt though

Thank you for the great answer and the very useful video. If you have any source of information regarding nodes that willingly publish their logfiles or stats let me know please as the 1ml website does not provide this information. Thank you again!

Nodes can choose to publish their throughput, but they can also stay private and go very anonymous by using the tor network for their node, this website aggregate most of the public node data https://1ml.com/statistics as they said:

The statistics are aggregated and calculated from multiple nodes within the Lightning Network. Due to the decentralized nature of the Lightning Network, the numbers observed are approximations and nodes that don't broadcast their state are not included.

If you want to see the live update of one of the public node, just pick one of the most recent updated one: https://1ml.com/node?order=lastupdated

Thank you for your answer. I was aware of this website but unfortunately it does not provide the information I want. The updated channels field corresponds to channel openings and closings as far as I know hence it has nothing to do with the number of routed payments. Thank you again!


text:
Can I import my wallet while my btc core is syncing
I'm upgrading my btc core to v0.18.1. I'd like to export my wallet to electrum. Is it possible while syncing? How?

Possible duplicate of https://bitcoin.stackexchange.com/q/6056/5406

Like this?

This guide is intended for users of Bitcoin-Qt who do not want to wait for their wallet to be synchronized with the network, which may take many hours or days depending on the hardware spec. The guide teaches users how to transfer their coins to Electrum bitcoin wallet, which has lower security but a faster startup time.

To answer your question, yes you can.  Syncing the blockchain has nothing to do with your private keys.  Electrum has a list of blockchain servers to use your keys with immediately.

I did that with all the receiving addresses I had on my btc qt wallet but my account doesn't match. I'm missing some btc. Any thoughts?

Is there any way to import the whole wallet? Doesn't seem like it would make a difference but I don't know why I'm missing some btc from my account.

You can dump your Master HD key.  Go to the same console and type dumpwallet (filename) then get the xprv key at the top of the file.

I updated the answer above.

@tgunnoe Downvoted. Bitcoin Core uses a hardened derivation to derive keys from master private key. From the account level, Electrum uses a non-hardened derivation. So the master private keys are not interchangeable between Bitcoin Core and Electrum. What can be done is dumping each key individually and then importing each key in Electrum.

Alright, thanks. edited answer from above. New information for me


text:
Does the btc price depend on the reward?
Hey guys if you answer this question that I am keeping from months ill be happy.
Does the actual bitcoin price depend on the mining profitability?
So is it more profitable mine when the price is high?
Is the same thing with other cryptos?
There is a bitcoin tab on github and I have heard that people can modify it, so why they modify it if they can't change the actual bitcoin code?

Does the actual bitcoin price depend on the mining profitability?

Strictly speaking Bitcoin doesn't have a price, it is a currency that has exchange rates with other currencies.
The exchange rate between BTC and, for example, USD seemingly depends on

market sentiment.
supply and demand.

Changes in production costs, for example due to the halving of the mining reward, have some influence on the exchange rate but not as much as, for example, the influence of government reactions to the Covid-19 pandemic.

Does the actual bitcoin price depend on the mining profitability?

I don't know what the price bitcoin depends, but if I understand your question, it is better to write: The mining profitability depends on the bitcoin price?" now have more sense (in my opinion)
At this question, the answer is yes because if the miner makes X bitcoin from mining action if the price is upper, the miner has more profitability.
Returning to your question: "Does the actual price bitcoin depend on the mining profitability?"
I think the bitcoin price is more complex and doesn't depend only on the mining, but I don't want to talk another on this argument because I don't know the argument.
PS': On this argument, I have read some details on an event did on Litecoin after the halving, I have read that on Litecoin after having the price went down because the miner doesn't mine on Litecoin blockchain.
PS'': The having event is an event to halving the reward of the miner

Is the same thing with other cryptos?

This question depends on the previous answer, but I think only the price market is the same between crypto; someone here might take offense (I'm joking :)) if you "think" the Bitcoin is the same to another crypto.

There is a bitcoin tab on github and I have heard that people can modify it, so why they modify it if they can't change the actual bitcoin code?

What is the github tab? Do you mean this? https://github.com/bitcoin/bitcoin ?
Bitcoin is a project open source, all persons can modify the code Bitcoin but this doesn't mean that the code modified will be approved to the community of bitcoin.

Bitcoin prices are, however, affected by several factors, other than mining energy costs. For instance, they are influenced by the supply of the Bitcoins and their demand in the market. It also depends on the number of other cryptocurrencies like Ethereum, Litecoin, etc. competing with Bitcoin and the crypto exchanges where the trade takes place.
Therefore the cost of production which includes the cost of energy used for mining is one of the several factors that finally affects the price of Bitcoin. The production and price mechanism of Bitcoin is different from those of other produced goods and hence does not depend on the cost of production only.
As high amounts of energy are required for production; producers have also started the use of renewable energy resources especially in the face of the growing concern of energy conservation and global warming.


text:
Why isn't it possible to add an OP_RETURN (or some arbitrary script) inside a taproot script path with a descriptor?
I'm reading the Bitcoin Core's descriptor documentation and I noticed that the raw() SCRIPT expression can only be used at descriptor top-level. Indeed when called with this descriptor getdescriptorinfo returns -5 error with the message Can only have raw() at top level:
tr(c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5,raw(fff97bd5755eeea420453a14355235d382f6472f8568a18b2f057a1460297556))
I assume that raw() is the only way you add an OP_RETURN type commitment in a taproot script path, or at least I couldn't figure out a way to do otherwise. I could think of using the pk() expression with a hash for example, but I guess it's bad to do that.
Why isn't it allowed to commit OP_RETURN type commitments, let alone other arbitrary script, inside a taproot address? Is it a descriptor restriction or a more fundamental limitation?
I read this but I don't think it really answer my point. If descriptors support arbitrary script only at top-level, why then?

The answer is twofold.
First, the Bitcoin Core descriptors are in the process of being extended with Miniscript. In the upcoming version (24.0), Miniscript will only be supported in Segwit version 0 outputs (P2WSH).
Once Miniscript support for Tapscript is added, you will be able to use a lot more Script functionalities in the script paths of a Taproot descriptor.
With regard to arbitrary Scripts, that is including those that are not representable (and therefore not solvable) using Miniscript. There is an ongoing discussion about supporting "partial descriptors", an otherwise solvable descriptor containing a spending path for which we have no solvability information.
A partial Taproot descriptor would allow you to have a rawnode(HEX) in the tree. This is what you need if you want to keep the solvability through the key path, because otherwise you could just use rawtr().

an OP_RETURN type commitment in a taproot script path, or at least I couldn't figure out a way to do otherwise. I could think of using the pk() expression with a hash for example, but I guess it's bad to do that.

Unrelated to your main question, but i don't think it's necessarily bad to use another form of commitment. If you were thinking this because of OP_RETURN outputs pruning from the UTxO set, note this is meaningless in this context.
You could use less expensive methods for committing the data. Such as tweaking a public key. And that would remove the need for partial descriptors.

Thanks for the explanations, to sum it up 1) supporting arbitrary script is out of scope for descriptors and is to be taken care by miniscript 2) descriptors shouldn't allow for spending conditions that we don't fully understand, even if it might be the case in the future.
If I were to do a taproot script with an arbitrary path, I should first write it (how?) and then represent it with rawtr(), is that correct?

For 1), no. Miniscript is about safely supporting more scripts in a general manner, not any script. Miniscript is a subset of Bitcoin Script. Regarding 2) It was indeed the thinking of their initial designer. But see the discussion i linked above. We (contributors in this area, including the original designer) are starting to think partial descriptors should be supported. You are correct that as of version 24.0 you would have to use a rawtr() descriptor to track Taproot outputs with an OP_RETURN in one of the Script path branches.

Ugh, when I wrote "arbitrary script" what I meant was indeed "arbitrary script within what's supported by miniscript", thanks for correcting me. As for 2), is there some tooling that could help writing this kind of script?
Just asking out of curiosity, at this point I'm basically convinced this is a bad idea anyway.

Just noticed your last edit, what I meant was that hacking the descriptors by pushing a pk() with the hash you want to commit in place of an OP_RETURN looks ugly and is probably bad. I'm also thinking about pubkey tweaking but a bit cautious because not sure what libs implemented it besides btcd and lnp/bp and I don't think I can use any of it on this project.

I'm curious what you are trying to achieve now. :) Re the tooling, for Bitcoin Core i'm not aware of say an RPC call that'd allow you to do that. But finding a library that allows you to create a Taproot scriptPubKey from a set of Script leaves shouldn't be too hard? For what it's worth this https://github.com/darosior/python-bip380 will probably feature what you want once i finally implement Taproot descriptors.

It's not clear to me why one would want to commit to an OP_RETURN inside of a P2TR output construction, let alone inside of a descriptor. I feel like there might be a misunderstanding here.
Using the OP_RETURN op-code makes an output script unspendable (and in most cases non-standard). Putting OP_RETURN as the first instruction in a scriptPubKey indicates a NULL DATA output, which permits writing a small amount of data to the blockchain. Because NULL DATA outputs are unspendable, they do not get inserted in the UTXO set, but since they're written out as part of the transaction in the blockchain, they're still published.
A popular application of NULL DATA outputs is the publishing of a commitment, e.g. the hash of a document to prove that it existed at the time, the witness commitment in segwit blocks, or a Merkle root of a whole tree of commitments as with OpenTimeStamps.
Putting an OP_RETURN into a leafscript of a Taptree does not serve the purpose of publishing the data, since only the leafscript used for spending the UTXO in the input will ever written to the blockchain.
If the data should be published per the transaction, it should be a dedicated output.
If the creation of a commitment suffices, it would be enough to tweak the inner public key with the hash of the data. That way, the owner could at a later time publish the data, and attest to the hash by signing with the inner public key. The act of publishing would then be separate from the act of committing, but the commitment would still proof that the data existed at the time of the transaction output creation.

Note that for OpenTimestamps, publishing is never needed, and IIRC OpenTimestamps also supports committing the Merkle root of its tree using sign-to-contract (making an otherwise normal transaction signature commit to it).

Thanks for the answer. I got your point on the distinction between publishing and committing. Interestingly a project like RGB, whose business is commitment and not publishing, do use OP_RETURN inside a taproot leafscript (they call it "tapret" I think). I don't know the rationale for that instead of directly tweaking the internal pubkey as you propose.
As to why I was asking how to put it inside a descriptor, it was because I couldn't think of another way to create the corresponding scriptpubkey using Bitcoin Core RPC. Wether it was a good idea or not is another question :)

Thinking about it a reason to do an OP_RETURN commitment inside a leafscript instead of directly tweaking the internal pubkey might be to commit other scripts in the same scriptpubkey?

Right, but you could just hash your data and use the hash as a leaf. You don't really need an OP_RETURN, do you?

I'm just saying that afaiu some people are doing that, and that they might have a reason for that.


text:
Avalon2 times out when using cgminer on the Raspberry Pi
I am running cgminer on a Raspberry Pi, with the command:
sudo ./cgminer --avalon2-freq 500 --avalon2-voltage 7250 --avalon2-fan 50 -o stratum+tcp://stratum.bitcoin.cz:3333 -u <"username.worker"> -p <"password">

and I get the response:
Started cgminer 4.8.0
Probing for an alive pool
Pool 0 difficulty changed to 8
Stratum from pool 0 requested work restart
AV2 0: No valid shares for over 1 minute, issuing usb reset
AV2 0 attempted reset got err:(0) LIBUSB_SUCCESS
AV2 0 Ava2Write usb write err:(-7) LIBUSB_ERROR_TIMEOUT
AV2 0 attempted reset got err:(0) LIBUSB_SUCCE disabling got 0
AV2 0 Device disappeared, shutting down thread
AV2 0 Failure, disabling!
Hotplug: avalon2 added AV2 1

When I use the command ls -l /dev/tty*, I get:
crw-rw-rw- 1 root root      5,  0 Jan  1  1970 /dev/tty
crw------- 1 root root      4,  0 Jan  1  1970 /dev/tty0
crw------- 1 pi   tty       4,  1 Dec 31 18:22 /dev/tty1
crw------- 1 root root      4, 10 Jan  1  1970 /dev/tty10
crw------- 1 root root      4, 11 Jan  1  1970 /dev/tty11
crw------- 1 root root      4, 12 Jan  1  1970 /dev/tty12
crw------- 1 root root      4, 13 Jan  1  1970 /dev/tty13
crw------- 1 root root      4, 14 Jan  1  1970 /dev/tty14
crw------- 1 root root      4, 15 Jan  1  1970 /dev/tty15
crw------- 1 root root      4, 16 Jan  1  1970 /dev/tty16
crw------- 1 root root      4, 17 Jan  1  1970 /dev/tty17
crw------- 1 root root      4, 18 Jan  1  1970 /dev/tty18
crw------- 1 root root      4, 19 Jan  1  1970 /dev/tty19
crw-rw---- 1 root tty       4,  2 Dec 31 18:17 /dev/tty2
crw------- 1 root root      4, 20 Jan  1  1970 /dev/tty20
crw------- 1 root root      4, 21 Jan  1  1970 /dev/tty21
crw------- 1 root root      4, 22 Jan  1  1970 /dev/tty22
crw------- 1 root root      4, 23 Jan  1  1970 /dev/tty23
crw------- 1 root root      4, 24 Jan  1  1970 /dev/tty24
crw------- 1 root root      4, 25 Jan  1  1970 /dev/tty25
crw------- 1 root root      4, 26 Jan  1  1970 /dev/tty26
crw------- 1 root root      4, 27 Jan  1  1970 /dev/tty27
crw------- 1 root root      4, 28 Jan  1  1970 /dev/tty28
crw------- 1 root root      4, 29 Jan  1  1970 /dev/tty29
crw-rw---- 1 root tty       4,  3 Dec 31 18:17 /dev/tty3
crw------- 1 root root      4, 30 Jan  1  1970 /dev/tty30
crw------- 1 root root      4, 31 Jan  1  1970 /dev/tty31
crw------- 1 root root      4, 32 Jan  1  1970 /dev/tty32
crw------- 1 root root      4, 33 Jan  1  1970 /dev/tty33
crw------- 1 root root      4, 34 Jan  1  1970 /dev/tty34
crw------- 1 root root      4, 35 Jan  1  1970 /dev/tty35
crw------- 1 root root      4, 36 Jan  1  1970 /dev/tty36
crw------- 1 root root      4, 37 Jan  1  1970 /dev/tty37
crw------- 1 root root      4, 38 Jan  1  1970 /dev/tty38
crw------- 1 root root      4, 39 Jan  1  1970 /dev/tty39
crw-rw---- 1 root tty       4,  4 Dec 31 18:17 /dev/tty4
crw------- 1 root root      4, 40 Jan  1  1970 /dev/tty40
crw------- 1 root root      4, 41 Jan  1  1970 /dev/tty41
crw------- 1 root root      4, 42 Jan  1  1970 /dev/tty42
crw------- 1 root root      4, 43 Jan  1  1970 /dev/tty43
crw------- 1 root root      4, 44 Jan  1  1970 /dev/tty44
crw------- 1 root root      4, 45 Jan  1  1970 /dev/tty45
crw------- 1 root root      4, 46 Jan  1  1970 /dev/tty46
crw------- 1 root root      4, 47 Jan  1  1970 /dev/tty47
crw------- 1 root root      4, 48 Jan  1  1970 /dev/tty48
crw------- 1 root root      4, 49 Jan  1  1970 /dev/tty49
crw-rw---- 1 root tty       4,  5 Dec 31 18:17 /dev/tty5
crw------- 1 root root      4, 50 Jan  1  1970 /dev/tty50
crw------- 1 root root      4, 51 Jan  1  1970 /dev/tty51
crw------- 1 root root      4, 52 Jan  1  1970 /dev/tty52
crw------- 1 root root      4, 53 Jan  1  1970 /dev/tty53
crw------- 1 root root      4, 54 Jan  1  1970 /dev/tty54
crw------- 1 root root      4, 55 Jan  1  1970 /dev/tty55
crw------- 1 root root      4, 56 Jan  1  1970 /dev/tty56
crw------- 1 root root      4, 57 Jan  1  1970 /dev/tty57
crw------- 1 root root      4, 58 Jan  1  1970 /dev/tty58
crw------- 1 root root      4, 59 Jan  1  1970 /dev/tty59
crw-rw---- 1 root tty       4,  6 Dec 31 18:17 /dev/tty6
crw------- 1 root root      4, 60 Jan  1  1970 /dev/tty60
crw------- 1 root root      4, 61 Jan  1  1970 /dev/tty61
crw------- 1 root root      4, 62 Jan  1  1970 /dev/tty62
crw------- 1 root root      4, 63 Jan  1  1970 /dev/tty63
crw------- 1 root root      4,  7 Jan  1  1970 /dev/tty7
crw------- 1 root root      4,  8 Jan  1  1970 /dev/tty8
crw------- 1 root root      4,  9 Jan  1  1970 /dev/tty9
crw-rw---- 1 root tty     204, 64 Dec 31 18:17 /dev/ttyAMA0
crw-rw---T 1 root dialout   5,  3 Jan  1  1970 /dev/ttyprintk
crw-rw---T 1 root dialout 188,  0 Jan  2 01:29 /dev/ttyUSB0

Do you mean to be underclocking and undervolting your Avalon?  Can you run the command ls -l /dev/tty* and post the output?

Hey Nick, thanks for your response - do you mean run " ls -l /dev/tty*" as part of the initial command line, or separately after I halt cgminer? Either way, I get "unrecognized command -1"

I meant separately. Use -l, not -1.

I meant that you should edit it into your original post. This is totally unreadable.

so I add that statement at the end of my cgminer command statement?

Can you try sudo ./cgminer -S /dev/ttyUSB0 stratum+tcp://stratum.bitcoin.cz:3333 -u <"username.worker"> -p <"password"> instead?

I get "-S unrecognized option"

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Exchange API - more frequent high and low value
Any way to get high-low values more frequent than every 24 hours from say the Bitstamp API ticker? The link only tells you how to get the value for every 24 hours.
This also seems to be a problem with every other exchange I've tried.

These functions return the high or low over for the past 24 hours.  You can poll the API for this data as often as the API allows for (600 times over 10 mins according to your link). The data that it returns does only consider the past 24 hour prices however.  If you want to find out the high and lower prices over a longer time frame you will need to look at historical ticker data and determine the high and low values returned from the data set that you are requesting.

Where might I find "Historical" data?

Have a look at bitcoincharts for historical BTC data

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
blockchain.info JSON API problem
I'm trying to get the time series for a specific period from Blockchain but the JSON seems to not be there anymore. Does anyone know if the JSON API is not available anymore or it is a temporary issue?
For example when trying to access https://blockchain.info/charts/hash-rate&format=json I get an Unknown Exception.

The JSON export seems indeed to be broken. A quick workaround is to simply get the graph page and extract the needed data from there:
curl -s https://blockchain.info/charts/hash-rate | grep data: | grep -oE '\[[0-9\.,]+\]'

That should give you the JSON array. The array contains a daily sample of the hash-rate starting from timestamp
curl -s https://blockchain.info/charts/hash-rate | grep pointStart | grep -oE '[0-9]+'


text:
Calling JSON commands to armoryd
I know with bitcoind, you can easily start the daemon and call some commands.
But with armoryd, I start it up with a wallet argument.
What are some examples of using the JSON-RPC to call a method for it?
For example, with bitcoind I can type in my shell:
bitcoind listaccounts

Is there a easy way to get my armoryd daemon to do the same?

In your install directory, you should have armoryd.py.  Once you run
python armoryd.py

then you have a daemon.  Now you can run
python armoryd.py help

to get a list of commands like this (which can then be run with python armoryd.py <command>):
{
"backupwallet": {
    "Description": "Back up the current wallet to a file at a given location. The backup will occur only if the file does not exist yet.",
    "Parameters": [
        "backupFilePath - Path to the location where the backup will be saved."
    ],
    "Return Value": "A dictionary indicating whether or not the backup succeeded or failed, with the reason for failure given if applicable."
},
"clearaddressmetadata": {
    "Description": "Clear all armoryd-specific metadata for the currently loaded wallet.",
    "Parameters": [
        "None"
    ],
    "Return Value": "None"
},
"createlockbox": {
    "Description": "Create an m-of-n lockbox associated with wallets loaded onto the armoryd server.",
    "Parameters": [
        "numM - The number of signatures required to spend lockbox funds.",
        "numN - The total number of signatures associated with a lockbox.",
        "args - The wallets or public keys associated with a lockbox, the total of which must match <numN> in number. The wallets are represented by their Base58 IDs. The keys must be uncompressed."
    ],
    "Return Value": "A dictionary with information about the new lockbox."
},
"createustxformany": {
    "Description": "Create an unsigned transaction to be sent to multiple recipients from the currently loaded wallet.",
    "Parameters": [
        "args - An indefinite number of comma-separated sets of recipients and the number of Bitcoins to send to the recipients. The recipients can be an address, a P2SH script address, a lockbox (e.g., \"Lockbox[83jcAqz9]\" or \"Lockbox[Bare:83jcAqz9]\"), or a public key (compressed or uncompressed) string."
    ],
    "Return Value": "An ASCII-formatted unsigned transaction, similar to the one output by Armory for offline signing."
},
"createustxtoaddress": {
    "Description": "Create an unsigned transaction to be sent to one recipient from the currently loaded wallet.",
    "Parameters": [
        "recAddr - The recipient. This can be an address, a P2SH script address, a lockbox (e.g., \"Lockbox[83jcAqz9]\" or \"Lockbox[Bare:83jcAqz9]\"), or a public key (compressed or uncompressed) string.",
        "amount - The number of Bitcoins to send to the recipient."
    ],
    "Return Value": "An ASCII-formatted unsigned transaction, similar to the one output by Armory for offline signing."
},
"decoderawtransaction": {
    "Description": "Decode a raw transaction hex string.",
    "Parameters": [
        "hexString - A string representing, in hex form, a raw transaction."
    ],
    "Return Value": "A dictionary containing the decoded transaction's information."
},
"dumpprivkey": {
    "Description": "Dump the private key for a given Base58 address associated with the currently loaded wallet.",
    "Parameters": [
        "addr58 - A Base58 public address associated with the current wallet."
    ],
    "Return Value": "The 32 byte binary private key."
},
"encryptwallet": {
    "Description": "Encrypt a wallet with a given passphrase.",
    "Parameters": [
        "passphrase - The wallet's new passphrase."
    ],
    "Return Value": "A string indicating that the encryption was successful."
},
"getactivelockbox": {
    "Description": "Get the lockbox ID of the currently active lockbox.",
    "Parameters": [
        "None"
    ],
    "Return Value": "The Base58 ID for the currently active lockbox."
},
"getactivewallet": {
    "Description": "Get the wallet ID of the currently active wallet.",
    "Parameters": [
        "None"
    ],
    "Return Value": "The Base58 ID for the currently active wallet."
},
"getaddrbalance": {
    "Description": "Get the balance of a Base58 address associated with the currently loaded wallet.",
    "Parameters": [
        "inB58 - The Base58 address associated with the current wallet.",
        "baltype - (Default=spendable) A string indicating the balance type to retrieve from the current wallet."
    ],
    "Return Value": "The current wallet balance (BTC), or -1 if an error occurred."
},
"getaddressmetadata": {
    "Description": "Get all armoryd-specific metadata for the currently loaded wallet.",
    "Parameters": [
        "None"
    ],
    "Return Value": "A dictionary with all metadata sent to armoryd."
},
"getarmorydinfo": {
    "Description": "Get information on the version of armoryd running on the server.",
    "Parameters": [
        "None"
    ],
    "Return Value": "A dictionary listing version of armoryd running on the server."
},
"getbalance": {
    "Description": "Get the balance of the currently loaded wallet.",
    "Parameters": [
        "baltype - (Default=spendable) A string indicating the balance type to retrieve from the current wallet."
    ],
    "Return Value": "The current wallet balance (BTC), or -1 if an error occurred."
},
"getblock": {
    "Description": "Get the block associated with a given block hash.",
    "Parameters": [
        "blkhash - A hex string representing the block to obtain."
    ],
    "Return Value": "A dictionary listing information on the desired block, or empty if the block wasn't found."
},
"gethextxtobroadcast": {
    "Description": "Get a signed Tx from a file and get the raw hex data to broadcast.",
    "Parameters": [
        "txASCIIFile - The path to a file with an signed transacion."
    ],
    "Return Value": "A hex string of the raw transaction data to be transmitted."
},
"getledger": {
    "Error": "The function description is malformed."
},
"getledgersimple": {
    "Description": "Get a simple version of a wallet or lockbox ledger.",
    "Parameters": [
        "inB58ID - The Base58 ID of the wallet or lockbox from which to obtain the ledger. The wallet or lockbox must already be loaded.",
        "tx_count - (Default=10) The number of entries to get.",
        "from_tx - (Default=0) The first entry to get."
    ],
    "Return Value": "A dictionary with a wallet ledger of type \"simple\"."
},
"getlockboxinfo": {
    "Description": "Get information on the lockbox associated with a lockbox ID string or, if it exists, the currently active armoryd lockbox.",
    "Parameters": [
        "inLBID - (Default=None) If used, armoryd will get information on the lockbox with the provided Base58 ID instead of the currently active armoryd lockbox.",
        "outForm - (Default=JSON) If used, armoryd will return the lockbox in a particular format. Choices are \"JSON\", \"Hex\", and \"Base64\"."
    ],
    "Return Value": "If the lockbox is found, a dictionary with information on the lockbox will be returned."
},
"getnewaddress": {
    "Description": "Get a new Base58 address from the currently loaded wallet.",
    "Parameters": [
        "None"
    ],
    "Return Value": "The wallet's next unused public address in Base58 form."
},
"getrawtransaction": {
    "Description": "Get the raw transaction string for a given transaction hash.",
    "Parameters": [
        "txHash - A string representing the hex value of a transaction ID.",
        "verbose - (Default=0) Integer indicating whether or not the result should be more verbose.",
        "endianness - (Default=BIGENDIAN) Indicates the endianness of the ID."
    ],
    "Return Value": "A dictionary with the decoded raw transaction and relevant information."
},
"getreceivedbyaddress": {
    "Description": "Get the number of coins received by a Base58 address associated with the currently loaded wallet.",
    "Parameters": [
        "address - The Base58 address associated with the current wallet."
    ],
    "Return Value": "The balance received from the incoming address (BTC)."
},
"gettransaction": {
    "Description": "Get the transaction associated with a given transaction hash.",
    "Parameters": [
        "txHash - A hex string representing the block to obtain."
    ],
    "Return Value": "A dictionary listing information on the desired transaction, or empty if the transaction wasn't found."
},
"gettxout": {
    "Description": "Get the TxOut entries for a given transaction hash.",
    "Parameters": [
        "txHash - A string representing the hex value of a transaction ID.",
        "n - The TxOut index to obtain.",
        "binary - (Default=0) Indicates whether or not the resultant binary script should be in binary form or converted to a hex string."
    ],
    "Return Value": "A dictionary with the Bitcoin amount for the TxOut and the TxOut script in hex string form (default) or binary form."
},
"getwalletinfo": {
    "Description": "Get information on the currently loaded wallet.",
    "Parameters": [
        "inWltID - (Default=None) If used, armoryd will get info for the wallet for the provided Base58 wallet ID instead of the current wallet."
    ],
    "Return Value": "A dictionary with information on the current wallet."
},
"help": {
    "Description": "Get a directionary with all functions the armoryd server can run.",
    "Parameters": [
        "None"
    ],
    "Return Value": "A dictionary with all functions available on the armoryd server, along with the function parameters and function return value."
},
"importprivkey": {
    "Description": "Import a private key into the current wallet.",
    "Parameters": [
        "privKey - A private key in any format supported by Armory, including Base58 private keys supported by bitcoind (uncompressed public key support only)."
    ],
    "Return Value": "A string of the private key's accompanying hexadecimal public key."
},
"listaddrunspent": {
    "Description": "Get a list of unspent transactions for the currently loaded wallet that are associated with a given, comma-separated list of Base58 addresses from the wallet. By default, zero-conf UTXOs are included.",
    "Parameters": [
        "inB58 - The Base58 address to check against the current wallet."
    ],
    "Return Value": "A dictionary containing all UTXOs for the currently loaded wallet associated with the given Base58 address, along with information about each UTXO."
},
"listloadedlockboxes": {
    "Description": "List all lockboxes loaded onto the armoryd server.",
    "Parameters": [
        "None"
    ],
    "Return Value": "A dictionary with the Base58 values of all lockboxes loaded in armoryd."
},
"listloadedwallets": {
    "Description": "List all wallets loaded onto the armoryd server.",
    "Parameters": [
        "None"
    ],
    "Return Value": "A dictionary with the Base58 values of all wallets loaded in armoryd."
},
"listtransactions": {
    "Description": "List the transactions associated with the currently loaded wallet.",
    "Parameters": [
        "tx_count - (Default=10) The number of entries to get.",
        "from_tx - (Default=0) The first entry to get."
    ],
    "Return Value": "A dictionary with information on the retrieved transactions."
},
"listunspent": {
    "Description": "Get a list of unspent transactions for the currently loaded wallet. By default, zero-conf UTXOs are included.",
    "Parameters": [
        "None"
    ],
    "Return Value": "A dictionary listing information about each UTXO in the currently loaded wallet. The dictionary is similar to the one returned by the bitcoind call of the same name."
},
"receivedfromaddress": {
    "Description": "Return the number of coins received from a particular sender.",
    "Parameters": [
        "sender - Base58 address of the sender to the current wallet."
    ],
    "Return Value": "Number of Bitcoins sent by the sender to the current wallet."
},
"receivedfromsigner": {
    "Description": "Verify that a message (RFC 2440: clearsign or Base64) has been signed by a Bitcoin address and get the amount of coins sent to the current wallet by the message's signer.",
    "Parameters": [
        "sigBlock - Message with the RFC 2440 message to be verified. The message must be enclosed in quotation marks."
    ],
    "Return Value": "A dictionary with verified message and the amount of money sent to the current wallet by the signer."
},
"relockwallet": {
    "Description": "Re-lock a wallet.",
    "Parameters": [
        "None"
    ],
    "Return Value": "A string indicating whether or not the wallet is locked."
},
"sendlockbox": {
    "Description": "E-mail ASCII-encoded lockboxes to recipients.",
    "Parameters": [
        "lbIDs - A colon-delineated list of Base58 IDs of lockboxes to send to an email recipient.",
        "sender - The email address of the sender.",
        "server - The SMTP email server.",
        "pwd - The email account password.",
        "recips - The recipient or, if the string is delineated by a colon, a list of recipients.",
        "msgSubj - (Default=Armory Lockbox) The email subject."
    ],
    "Return Value": "A string indicating whether or not the attempt to send was successful."
},
"setactivelockbox": {
    "Description": "Set the currently active lockbox to one already loaded on the armoryd server.",
    "Parameters": [
        "newIDB58 - The Base58 ID of the lockbox to be made active."
    ],
    "Return Value": "A string indicating whether or not the lockbox was set as desired."
},
"setactivewallet": {
    "Description": "Set the currently active wallet to one already loaded on the armoryd server.",
    "Parameters": [
        "newIDB58 - The Base58 ID of the wallet to be made active."
    ],
    "Return Value": "A string indicating whether or not the wallet was set as desired."
},
"setaddressmetadata": {
    "Description": "Set armoryd-specific metadata associated with Base58 addresses.",
    "Parameters": [
        "newAddressMetaData - A dictionary containing arbitrary metadata to attach to Base58 addresses listed with the metadata."
    ],
    "Return Value": "None"
},
"signasciitransaction": {
    "Description": "Sign an unsigned transaction and get the signed ASCII data.",
    "Parameters": [
        "unsignedTxASCII - An ASCII-formatted unsigned transaction, like the one used by Armory for offline transactions.",
        "wltPasswd - (Default=None) If needed, the current wallet's password."
    ],
    "Return Value": "A dictionary containing a string with the ASCII-formatted signed transaction or, if the signing failed, a string indicating failure."
},
"unlockwallet": {
    "Description": "Unlock a wallet with a given passphrase and unlock time length.",
    "Parameters": [
        "passphrase - The wallet's current passphrase.",
        "timeout - (Default=10) The time, in seconds, that the wallet will be unlocked."
    ],
    "Return Value": "A string indicating if the wallet was unlocked or if it was already unlocked."
},
"verifysignature": {
    "Description": "Take a message (RFC 2440: clearsign or Base64) signed by a Bitcoin address and verify the message.",
    "Parameters": [
        "sigBlock - Message with the RFC 2440 message to be verified. The message must be enclosed in quotation marks."
    ],
    "Return Value": "A dictionary with verified message and the Base58 address of the signer."
},
"watchwallet": {
    "Description": "Send an e-mail notification when the current wallet spends money.",
    "Parameters": [
        "send_from - The email address of the sender.",
        "smtpServer - (Default=None) The SMTP email server.",
        "password - (Default=None) The email account password.",
        "send_to - (Default=None) The recipient or, if the string is delineated by a colon, a list of recipients.",
        "subject - (Default=None) The email subject.",
        "watchCmd - (Default=add) A string indicating if emails from the sender should be sent or, if set to \"remove\", emails from the sender that are currently being sent should be stopped."
    ],
    "Return Value": "None"
}
}

Source: armoryd.README in the install folder

Good answer! It looks like the closest analogue to what the asker is looking for is listloadedwallets.


text:
Market orders in Cryptsy and BTC-E
Looking at the dynamics of the Cryptsy and BTC-E trading engines you aren't able to place market orders.  The orders just seem to be limit orders at the best market rate.  For example, I want to buy 20 bitcoins at $700 and the best offer is $700 with 15 coin volume.  The offer should get knocked out and the remainder of 5 should be subtracted from the next best offer.
My question is why this doesn't seem to be the case with BTC-E and Cryptsy?  If your order volume at market is greater than available volume at set rate it sets up a limit order until the order is filled.
Can anyone confirm this and explain why they do it?

There's nothing a market order can do that a limit order can't do. To place a market order, just place a limit order for the amount you want to buy at the worst price you are willing to pay.

It makes sense to me, if you're telling them you want to buy 20 BTC at $700 USD why would it purchase the remaining 5 BTC at a price higher than you wanted? If you want to buy the 20 BTC immediately, then look at the order book and figure out the price you'll need to enter to have enough volume to fulfill your order. Or use a service like BTX Trader which interfaces with multiple exchange APIs and offers features like market orders, which really just look at the order book and figures out the price for you for an additional comission.
And as to why many exchanges dont offer market orders? Who knows, they're immature? If it really bothers you, it isnt that hard to interface with their API and write a script to place market orders.


text:
When opening a LN channel using LND, what does 'push-amt' do?
I set up Lightning node (LND) and wanted to receive a payment. Autopilot for managing the channels always creates channels w/ zero remote balance, thus nobody can route a payment to/through my node.
The command for manual channel opening is lncli openchannel [command options] node-key local-amt push-amt. If I specify nonzero push-amt, the remote balance is then, unsurprisingly, nonzero.
But what I find very confusing is "whose" money that was? Have I just given my peer free bitcoin?
The help command for openchannel push-amt states: the number of satoshis to push to the remote side as part of the initial commitment state (default: 0).

The money now belongs to the counterparty in the channel you opened. In every one of your channels, whether you opened them or they were opened to you, "local balance" refers to your spendable/forwardable balance and "remote balance" refers to the counterparty's.
Don't worry though, if your node stays online reliably, then others will open channels with you, giving you inbound capacity. At this stage there's not much else you can do.

In case those money now belong to the counterparty, I just wonder what's the purpose of this option? It's basically equivalent of opening a channel followed by sendpayment. That's harmful behaviour. I still think I misunderstand something. Why would anyone want to just give the counterparty free money to load the channel? That doesn't make any sense to me.

Yes, my understanding is that it's equivalent to opening a channel and performing a payment. Why is that harmful behavior? The point of a payment channel is being able to perform payments. This option lets you combine opening and paying in one action.

My problem was that I had LN node running for about 10 days (24/7, port forwarding set correctly, alias Chainanalytics). And for the whole time nobody had opened a channel giving money to their side. I couldn't receive any payment. So I consequently thought I opened them incorrectly and I had to "tell" the peers via that command "to put the specific amount" of their money into initial channel state. I did it several times, cs it fixed the problem of being unable to receive payments. I thought when I close the channels, the money will be sent back to my wallet. Instead I just made a giveaway.


text:
Static Wallet Address
How do I make my account static so the address stays the same. The bitcoin wallet address keeps changing and I need to figure out how to make it stay the same

Hi Kristina, which wallet software are you using?--Also, generally address reuse has downsides for the financial privacy of you and your business partners, and very few upsides. Perhaps it would help if you described why you want to keep a fixed address rather than using a new address for every payment as is recommended.

I'm trying to get something deposited into my bank account and they have the wallet address but they want me to verify that it's a static so the address didn't change.

There really isn't ever a reason to have a static bitcoin address, as @Murch mentioned in the comments, doing so has very real downsides, and no real upside.
That said, your wallet will (and should) present you with a new address for each and every payment you receive, however, any past address your wallet has presented to you will continue to work to receive funds in the future.
In other words, if you open your wallet and copy down the address, but then open/close your wallet 100 times (and get presented with 100 different addresses in the process), that won't change anything about the validity of that original address. You can still receive funds to it, it is still a part of your wallet. Any good wallet will eventually contain a large collection of addresses!

I'm trying to get something deposited into my bank account and they have the wallet address but they want me to verify that it's a static...

I'm curious who the 'they' is in this. Its hard to say without more information, but odd requests like this are sometimes the hallmarks of a scammer.

A wallet can have many addreses not just one.
Each of those addresses lasts forever and never changes. You can receive as many transactions as you want to any address that you pick.
Re-using one address means a loss of privacy (other people can see transactions to that address) - this is why your wallet creates a new address every time you click the address button.
Elsewhere in your wallet's menus you will find a list of all generated addresses. It might just show the ones that have already received money but some wallets will allow you to see all the addresses, including ones that have not yet been used in any transaction.

Your question and comments use words like "account", "deposited", "bank account" but remember Bitcoin is cash, not an account.

Not having a fixed address is idiotic, has absolutely no upsides except to people who want to be deceptive.  There is no relevance whatsoever to a floating not static address other than to make crypto completely useless for legitimate stable use.
It seems trolls hit every comment section telling people that they want that address to change.  Having it change makes bitcoin a freaking toy.
Generate a paper wallet and stick with it if saboteurs in the coding community continue to flood the ether with "meta" address wallets that have absolutely no repeatability and no usefulness except for criminal use.  There, you got real advice.


text:
Cryptographic digital signatures
I have a doubt since the public keys are known to everyone, so someone could falsify a transaction by writing down a deposit from a public address to another public address in a new block and solving the proof of work, but for a transaction to be valid, it has to be signed the signature is nothing more than the combination of the public key and the private key so according to me in the text of the block I should enter a transaction signature field I asked and this is how the block does contain a signature field the strange thing is I searched several block browsers and none of them included the signature field information.
I asked the forums, why didn't they do it? and what they answered me is that for block browsers that information is irrelevant because it is assumed that the transaction has already been signed but it omits this field in the information they show in the block browser so my question is where can I download all the complete information of a block that does not omit any detail?

Hello, welcome to bitcoin.stackexchange! This is an english-language website, so I've edited your question and replaced the text with an english translation. If the translation does not accurately reflect your question, please feel free to edit it appropriately.

the signature is nothing more than the combination of the public key and the private key

Here's an example of a digital signature process

Source
The signature process in Bitcoin is different but it still involves a mathematical process which takes as input the data to be signed and a private-key. The process emits a number we call a digital signature. Checking the digital signature involves a different process that takes as input the data that has been signed, the signature itself and a public-key (not the private key).

The structure of a transaction is described in the protocol documentation - which includes signature values in the unlocking script for an input.
That web-page gives a fully worked out example including
Input 1:
 6D BD DB 08 5B 1D 8A F7  51 84 F0 BC 01 FA D5 8D  - previous output (outpoint)
 12 66 E9 B6 3B 50 88 19  90 E4 B4 0D 6A EE 36 29
 00 00 00 00

 8B                                                - script is 139 bytes long

 48 30 45 02 21 00 F3 58  1E 19 72 AE 8A C7 C7 36  - signature script (scriptSig)
 7A 7A 25 3B C1 13 52 23  AD B9 A4 68 BB 3A 59 23
 3F 45 BC 57 83 80 02 20  59 AF 01 CA 17 D0 0E 41
 83 7A 1D 58 E9 7A A3 1B  AE 58 4E DE C2 8D 35 BD
 96 92 36 90 91 3B AE 9A  01 41 04 9C 02 BF C9 7E
 F2 36 CE 6D 8F E5 D9 40  13 C7 21 E9 15 98 2A CD
 2B 12 B6 5D 9B 7D 59 E2  0A 84 20 05 F8 FC 4E 02
 53 2E 87 3D 37 B9 6F 09  D6 D4 51 1A DA 8F 14 04
 2F 46 61 4A 4C 70 C0 F1  4B EF F5

 FF FF FF FF                                       - sequence

The 48 is a OP-PUSHDATA opcode that pushes the next 4816 (7210) bytes onto the stack. Then there is a 41 that pushes the remaining 4116 (6510) bytes as a separate item on the stack. The data items on the stack include a DSA digital signature.
The structure of a ECDSA signature is a little esoteric but it is usually about that length.
The remainder of the scriptsig is likely other values and/or opcodes that creates the data items on the stack that can be fed to the locking script from the referenced transaction to verify the signature using the public-key of the recipient in the referenced transaction who is the spender in this.
There are several types of standard script and so the above is only a rough description  of the simplest sort. To fully decode every transaction you have to identify the type of script for each output contained (or referenced).

Note that in ECDSA, it isn't actually true that signing is "encrypting with the private key" - that's an explanation that's only correct for RSA as far as I know. In ECDSA, there is no encryption whatsoever. It's just an algorithm that takes private key and message.


text:
Could the Bitcoin network freeze someone's assets?
Strictly as an example, let's say some businessman owns a lot of Bitcoin, and he makes a disparaging comment online about a certain country that happens to have the majority of Bitcoin miners.
Could this country's leadership force its miners to freeze his assets by never accepting blockchains that contain transactions involving them?

In the short term, yes. If a government, or other entity, could convince 51% of mining power to ignore blocks with particular transactions in them, the rest of the miners would quickly learn that they do not get paid for blocks that include those transactions or that are built on top of blocks that include those transaction.
One wrinkle is that many miners participate through mining pools that do not tell them what transactions they are mining. Any pools whose blocks didn't "stick" would soon be unable to pay those with the mining hardware. But miners are free to switch pools. A government could press on both mining pools and individual miners.
However, what happens in the long term is a bigger question. If the economic majority of the users of the bitcoin blockchain believe that this happening destroys bitcoin's value proposition, they could (at least in theory) decide to change the mining algorithm or even switch to some other technology like proof of stake. Another possibility is that bitcoin would just gradually start shrinking and soon be eclipsed by other blockchains that displayed more censorship resistance.
It's also possible that many might agree with the particular instance of censorship and decide that, whether or not they like it, it's not worth making radical changes or leaving bitcoin. So it's possible that, in effect, bitcoin could wind up tolerating censorship.
For people who are concerned about it, there are actions non-miners could take. For example, there could be gradual adoption of node software that refuses to accept censorship. If miners who build on the branch with censorship don't get paid for their blocks because nodes don't accept them, they become irrelevant.
Each node individually decides when to consider a block confirmed enough to rely on it. If demonstrated censorship is deemed by enough economically important nodes to deem a block unreliable, then miners would be in a stand-off with participants like exchanges.
So it's unclear exactly what the consequences of such a situation would be. Because miners are heavily invested in mining hardware, they would likely try as hard as they could to avoid situations whose outcomes are unclear.

Miners generally have no clue about which person owns which Bitcoin.
Miners in other countries also mine blocks successfully from time to time  and so your hypothetical snarky businessman would probably not experience an actual freeze.
I have the impression most miners are in it for the money and don't really care that much about the attitudes of the people they take money from in the form of offered transaction fees. They might even relish taking money from someone who disparaged their country -- Assuming the disparager was foolish enough to make their Bitcoin addresses public.

Related

Questions tagged [Privacy]
Questions about Anonymity

"foolish enough to make their Bitcoin addresses public" -- I guess the question comes down to whether someone can keep that info private

"Miners in other countries also mine blocks successfully from time to time" - but does this matter if the majority will refuse to accept blockchains that have some "blacklisted" numbers in them? I'm basically talking about a 51% attack against a particular individual.

See links appended to answer.


text:
bitcoinjs - mandatory-script-verify-flag-failed (Signature must be zero for failed CHECK(MULTI)SIG operation)

I'm trying to follow the below transaction example by magic eden and extend it to support multiple buyers and seller (in red). However I am having difficulties when I add more than one signature from another party (with one seller it broadcasts okay). The transaction builds and signs fine but when I try to broadcast it to the network it results in the error mandatory-script-verify-flag-failed (Signature must be zero for failed CHECK(MULTI)SIG operation). Using native segwit addresses for this (no-tr).
What am I missing or doing wrong?
Using the bitcoinjs library here is what I have so far (only the red):
Seller signing:
let psbt = new bitcoin.Psbt({ network });

const [ordinalUtxoTxId, ordinalUtxoVout] = ordinalOutput.split(":");
const tx = bitcoin.Transaction.fromHex(await getTxHexById(ordinalUtxoTxId));

try {
    tx.setWitness(parseInt(ordinalUtxoVout), []);
} catch {}

const input = {
  hash: ordinalUtxoTxId,
  index: parseInt(ordinalUtxoVout),
  nonWitnessUtxo: tx.toBuffer(),
  witnessUtxo: tx.outs[ordinalUtxoVout],
  sighashType:
    bitcoin.Transaction.SIGHASH_SINGLE |
    bitcoin.Transaction.SIGHASH_ANYONECANPAY,
};

psbt.addInput(input);

psbt.addOutput({
  address: paymentAddress,
  value: price,
});

Buyer Signing (ignoring padding inputs and outputs):
// Add inscriptions inputs and outputs
for (const signedPsbt of sellerSignedPsbts) {
    // Add inscription output
    psbt.addOutput({
        address: receiverAddress,
        value: signedPsbt.data.inputs[0].witnessUtxo.value,
    });

    // Add payer signed input
    psbt.addInput({
        ...signedPsbt.data.globalMap.unsignedTx.tx.ins[0],
        // ...signedPsbt.data.inputs[0],
        witnessUtxo: signedPsbt.data.inputs[0].witnessUtxo,
        // nonWitnessUtxo: signedPsbt.data.inputs[0].nonWitnessUtxo,
        // finalScriptWitness: signedPsbt.data.inputs[0].finalScriptWitness,
    });

    input++;
}

// Add seller payment outputs for payee
for (const signedPsbt of sellerSignedPsbts) {
    // Add payer output
    psbt.addOutput({
        ...signedPsbt.data.globalMap.unsignedTx.tx.outs[0],
    });
}

Merge seller and buyer signed psbts:
const buyerSignedPsbt = bitcoin.Psbt.fromBase64(signedBuyingPSBTBase64);

for (let index = 0; index < signedListingsPSBTBase64.length; index++) {
    const sellerSignedPsbt = bitcoin.Psbt.fromBase64(signedListingsPSBTBase64[index]);

    buyerSignedPsbt.data.globalMap.unsignedTx.tx.ins[BUYING_PSBT_SELLER_SIGNATURE_INDEX + index] = sellerSignedPsbt.data.globalMap.unsignedTx.tx.ins[0];
    buyerSignedPsbt.data.inputs[BUYING_PSBT_SELLER_SIGNATURE_INDEX + index] = sellerSignedPsbt.data.inputs[0];
}

// broadcast buyerSignedPsbt

Regtest Base64 psbt
Seller Signed 1
cHNidP8BAFICAAAAASOmBfmvfvsLtR13NFmTe7a1PqExPjrG3n11nxrkWj8tAQAAAAD/////ATBuFgAAAAAAFgAUWFy3jcqHhb9Q8bNzCelM6HJWOowAAAAAAAEBH4gTAAAAAAAAFgAUWFy3jcqHhb9Q8bNzCelM6HJWOowBCGwCSDBFAiEAzLuOeIyXt/12KDkqD+mGRj105SHJHC1HdshaQ0fg0ocCID2ZxLyTs4NLZvynw5dKIrXetdQv+J0S9KrMJuznDJFRgyEDYTg80B9Vdeb/4anKg9DSL98+B2HsIPk6jUQNJEKFadEAAA==
Seller Signed 2
+PSZaCbgm2ZSnbSI9pFk/2DFLekqsj91nGUx2AQAAAAD/////ATBuFgAAAAAAFgAUWFy3jcqHhb9Q8bNzCelM6HJWOowAAAAAAAEBH4gTAAAAAAAAFgAUWFy3jcqHhb9Q8bNzCelM6HJWOowBCGsCRzBEAiA686mylIphxLrBDMStAv3a5srPBlXkSbsFMtUPIS/04QIgBooAkEWVhDcpJdNToJpO8GmF+Tv9bTqxNLjKbBCxc0ODIQNhODzQH1V15v/hqcqD0NIv3z4HYewg+TqNRA0kQoVp0QAA
Buyer Signed
[encoded data, 5852 characters]
Merged TX (Giving error)
0200000000010622b671902466b23559ab4a5f1d28170044d930bc30fe39dc7de86866883507230400000000ffffffff22b671902466b23559ab4a5f1d28170044d930bc30fe39dc7de86866883507230500000000ffffffff23a605f9af7efb0bb51d773459937bb6b53ea1313e3ac6de7d759f1ae45a3f2d0100000000ffffffffe1a68087fe3d265a09b826d994a76d223da4593fd8314b7a4aac8fdd67194c760100000000ffffffffacf181ceea3dae5d029e45bf945c29c64182f28136e67926466d9d42c3c239710600000000ffffffff0d83286e5ec76fad55b96ce49f6585977ad7d07181511efb475122dd153123140200000000ffffffff097017000000000000160014af4f1135eec1e4c147655026fd0bb48d01ca647c8813000000000000160014af4f1135eec1e4c147655026fd0bb48d01ca647c8813000000000000160014af4f1135eec1e4c147655026fd0bb48d01ca647c306e160000000000160014585cb78dca8785bf50f1b37309e94ce872563a8c306e160000000000160014585cb78dca8785bf50f1b37309e94ce872563a8c90410100000000001600141f3307885b7a03192e660fbc5be85c376acb33eeb80b000000000000160014af4f1135eec1e4c147655026fd0bb48d01ca647cb80b000000000000160014af4f1135eec1e4c147655026fd0bb48d01ca647c268b0f0000000000160014af4f1135eec1e4c147655026fd0bb48d01ca647c024730440220115b86808796fa77b1c293d462d42ed34277f7c3c32ef619ba6cdaaf73b8bdad0220435877b881d91b79e6f8d51030c93b6de34238eb3a56162605c43048a7463522012102049807ad8fc8667fa9d26535b423b03f63bcb4ead6638608b7d72b5795f06523024730440220433648280f8717e5a38b61b127454ec927846ffa100372ff3c9b6546f98331d202206e8272b0c23a9fcc7ae042a925559ec6fa66d0c05c197132b04ab27e0e84b1f5012102049807ad8fc8667fa9d26535b423b03f63bcb4ead6638608b7d72b5795f0652302483045022100ccbb8e788c97b7fd7628392a0fe986463d74e521c91c2d4776c85a4347e0d28702203d99c4bc93b3834b66fca7c3974a22b5deb5d42ff89d12f4aacc26ece70c915183210361383cd01f5575e6ffe1a9ca83d0d22fdf3e0761ec20f93a8d440d24428569d10247304402203af3a9b2948a61c4bac10cc4ad02fddae6cacf0655e449bb0532d50f212ff4e10220068a0090459584372925d353a09a4ef06985f93bfd6d3ab134b8ca6c10b1734383210361383cd01f5575e6ffe1a9ca83d0d22fdf3e0761ec20f93a8d440d24428569d10248304502210097ffb975eccd16401ec311688af93f60d534f9fb74a11695dea0ceebd1b20ad802203e3da5fa00bd40bb773b3aded2269e353e29221275ae72c99436c22afe8de777012102049807ad8fc8667fa9d26535b423b03f63bcb4ead6638608b7d72b5795f065230247304402207328307bea68a39942bbcb459d0ed201407c93a147868fc187dad1b95db5cbdb02205df5f94a1f2713f5b14c060eb7f00a724a63e0ff6f1df081ff6aee7afb892f14012102049807ad8fc8667fa9d26535b423b03f63bcb4ead6638608b7d72b5795f0652300000000

Can you also share the transaction itself?

@VojtěchStrnad Sorry for the delay, I have updated the post with regtest psbt txs. Any assistance is appreciated.

For completeness, can you also share the final serialized transaction that produces the error?

@VojtěchStrnad Added the final merged transaction giving the error.

The PSBT you've added doesn't seem to be finalized. Can you post the actual final raw transaction that Bitcoin Core error on when you pass it so sendrawtransaction?

That is the final one? Is it missing something because on https://bip174.org/ it appears to display correctly. All the final script witnesses of the inputs are present?

The final transaction should not be a PSBT anymore but a normal bitcoin transaction in hexadecimal format.

You are correct. I have updated the post with the hex tx that was broadcast.

@VojtěchStrnad I know it can be done, just wondering what I am doing differently compared to this transaction.
https://mempool.space/tx/1c37709bb3956cf0afb019f4e81072ec03e6cff6033f8932ed872495aaef6f83

Solution:
Figured it out, basically everything was correct except for the padding of the inputs to make the seller psbt (1 input and 1 output) line up in the same position.
For example:
Input 1 - 3000   Output 1 - 9000
Input 2 - 3000   Output 2 - Input 4
Input 3 - 3000   Output 3 - Input 5
Input 4 - 10000  Output 4 - To Seller 1 (Seller PSBT 1, need to be inline with Input 4)
Input 5 - 10000  Output 5 - To Seller 2 (Seller PSBT 2, need to be inline with Input 5)
Input 6 - Price  Output 6 - Change


text:
Verify Hash from bitaddress.org without the original HTML file
Can I verify that I used an authentic version of bitaddress.org if I only have the SHA256 hash string I generated from the HTML file?
>> sha1sum bitaddress.org.html

How can I do this on Linux? After that, can I be certain that only I have access to the private key?
On the website I can read:

If you are familiar with PGP you can download this all-in-one HTML page and check that you have an authentic version from the author of this site by matching the SHA256 hash of this HTML with the SHA256 hash available in the signed version history document linked on the footer of this site.

Obtain the HTML containing the javascript.
$ wget https://raw.githubusercontent.com/pointbiz/bitaddress.org/master/bitaddress.org.html
--2024-02-16 12:19:23--  https://raw.githubusercontent.com/pointbiz/bitaddress.org/master/bitaddress.org.html
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.108.133, 185.199.111.133, 185.199.109.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.108.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 937206 (915K) [text/plain]
Saving to: ‘bitaddress.org.html’

bitaddress.org.html             100%[====================================================>] 915.24K  1.54MB/s    in 0.6s

2024-02-16 12:19:24 (1.54 MB/s) - ‘bitaddress.org.html’ saved [937206/937206]

Calculate the SHA256 hash
$ openssl dgst bitaddress.org.html
SHA256(bitaddress.org.html)= dec17c07685e1870960903d8f58090475b25af946fe95a734f88408cef4aa194

then check this against the published hash
$ wget https://www.bitaddress.org/CHANGELOG.txt.asc
--2024-02-16 12:27:23--  https://www.bitaddress.org/CHANGELOG.txt.asc
Resolving www.bitaddress.org (www.bitaddress.org)... 185.199.108.153, 185.199.110.153, 185.199.109.153, ...
Connecting to www.bitaddress.org (www.bitaddress.org)|185.199.108.153|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15710 (15K) [application/pgp-keys]
Saving to: ‘CHANGELOG.txt.asc’

CHANGELOG.txt.asc               100%[====================================================>]  15.34K  --.-KB/s    in 0.001s

2024-02-16 12:27:24 (10.0 MB/s) - ‘CHANGELOG.txt.asc’ saved [15710/15710]

$ grep SHA256 *asc
CHANGELOG.txt.asc:bitaddress.org-v3.3.0-SHA256-dec17c07685e1870960903d8f58090475b25af946fe95a734f88408cef4aa194.html

But really you need to independently verify the PGP signature using public keys from an independent trusted source.

Thank you very much! I can find the public key here:
https://www.bitaddress.org/pointbiz_bitaddress.org.asc
As well as here https://bitcointalk.org/index.php?topic=43496.0 and here https://github.com/king7777/pointbiz.github.io/blob/master/ninja_bitaddress.org.txt
This is what you mean by "independently verify the PGP signature using public keys from an independent trusted source", right?

Yes, that is what I meant.

I just noticed that the .asc file from the last link differs from the first two. Nonetheless I get a good signature and the same primary key fingerprint for both files. The last file also gives me an additional good signature from "pointbiz pointbiz@bitaddress.org". I think these are just two versions from the same key, right?


text:
What is the advantage of using truncated HASH256 over CRC32?
Some of the checksums in Bitcoin are the first 4 bytes of the HASH256 of the data. HASH256 is just double SHA256, so SHA256(SHA256(data)). What is the advantage of that over using a dedicated checksum function, like CRC32?

Hi dbv, in case it is relevant, you seem to be asking about a specific application of checksums, but there are many different places in which checksums appear. Not all of them use the construction you describe, for example checksums in Bech32 and Bech32m addresses use BCH codes.

Hi Murch, thanks for clarification. I updated the question.


text:
Access restored but encrypted/locked old wallet (2013 version)
I Installed Bitcoin Core v25.0.0 and restored my old wallet backup made in 2014 (with bitcoin core version of 2013) successfully. The wallet is shown, status is encrypted and locked.
Trying to unlock the wallet with the passphrase results in this error:
BerkeleyDatabase: Error -30974, can't open database wallet.dat (code -1)
The backup was made on a Linux machine, the recovery on Windows.
Does anyone have any suggestions on what may be the case and how to resolve this?

The error code -30974 indicates that the database system (Berkeley DB) is having some issue with opening the database file and thinks that it is corrupted and that a recovery procedure needs to be run.
One way to try to resolve this is to use the bitcoin-wallet tool's salvage command. Note that this is essentially a last resort tool as salvaging is known to cause issues for non-corrupted wallets. I recommend that you ensure that there are backups of your wallet prior to using salvage.

If moved your wallet file between systems, there might be a version mismatch between the BerkeleyDB versions used to create and open the wallet. Some bitcoin core versions also had some bugs. Sometimes there is a problem with wallet.dat file itself. The wallet.dat file could be corrupted. This can happen if Bitcoin Core was closed improperly or the system crashed(or also there could be a bug).


text:
Does Bitcoin Core have any monitoring support?
Does Bitcoin Core have any monitoring support? I would like to monitor my bitcoin core node.

If you want to monitor your peers, you can use a tool created by 0xB10C. Here's the link https://github.com/0xB10C/peer-observer
Also there is an article for setting up the peer-observer and visualising peers using Prometheus and Grafana https://bytecorner.dev/peer-observer-monitor-your-bitcoin-peers

Bitcoin Core doesn't have any code for Prometheus support. There is a closed issue discussing it, with links to other related discussions and potential solutions, such as USDT (User-space, Statically Defined Tracing).


text:
How to run bitcoind in a low memory environment
I have a Raspberry Pi with 925 MB of memory. Bitcoin Core, operating as a full node, uses between 600-900 MB. How can I reduce bitcoind's memory usage?
I tried setting maxmempool to its minimum allowed value, 5. What about maxreceivebuffer and maxsendbuffer? Would setting these to a low value reduce memory usage?

Short comment before writing a full answer: a 5 MB mempool isn't particularly useful. You might as well disable the mempool entirely with -blocksonly.

@PieterWuille That's a good suggestion. I didn't know about that option. It probably lowers memory usage, too. In fact, this Reddit post on running a node on a 512 MB Raspberry Pi mentions using that flag, too.

With -blocksonly you don't have any mempool at all.

The largest consumers of memory are:

The memory pool (reduce with -maxmempool, or disable entirely with -blocksonly if you don't care about unconfirmed transactions).
The UTXO cache (reduce with -dbcache, at the cost of potentially much slower syncing).
The signature cache (reduce with -maxsigcachesize).

In addition, you can also reduce the maximum number of connections (-maxconnections) or the number of RPC threads (-rpcthreads).
A viable minimum configuration without mempool could be -blocksonly -dbcache=20 -maxsigcachesize=4 -maxconnections=4 -rpcthreads=1.
Some advice is also included in the documentation under https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-memory.md

-blocksonly alone brought my node's memory footprint down to about ~700 MB. I also have -banscore set to 1, which seems to help get rid of spammy nodes that flood my node with bad transactions.

Was still crashing with me! But setting also maxmempool=100 was causing bitcoind to be at ca. 570MB RSS, that works on my 1GB VPS.

I used the follow options: blocksonly=1
dbcache=50
maxorphantx=10
maxmempool=100
maxconnections=32 and bitcoind is running smoothly on my raspberrypi with the follow Memory footprint VSZ 422524 and RSZ 266956

carefully set blocksonly=1，in my case when i set this parameter,the txid cant be added to mempool and stucked for a very long time.no errors in log.

Some more details available at:
https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-memory.md

Followed your parameter:
bitcoind -blocksonly=1 -dbcache=50 -maxorphantx=10 -maxmempool=100 &

Now I have only 286M memory used with bitcoind running.

Please don't use the "answer" box to write "thank you" type comments.  Please take the [tour] and check this faq on deleted answers.

In my opinion this answer does add a bit more new information so I don't think it needs to be deleted

Why are you setting -maxmemool if you already have -blocksonly? Seems redundant to me but I might be missing something.


text:
What percentage of nodes currently support segwit?
What percentage of nodes currently support segwit?
It seems Bitnodes could figure this out, but I can't find such a stat on its website.

According to Luke-Jr's statistics, 96.15% of nodes are advertising the Segwit P2P protocol service bit, which implies that they support segwit.


text:
What are output descriptors?
I have heard about output descriptors or wallet descriptors. It is not clear to me what they are. What do they allow me to do? How does that improve my experience using Bitcoin?

An output descriptor (note that output descriptor and wallet descriptor refer to the same thing) is a human readable string that represents an output script (a scriptPubKey) and everything needed in order to solve¹ for that script. Descriptors also have a bech32-like checksum which allows for the descriptor to be given to others with less risk of accidentally mistyping or losing some characters in the descriptor string.
Descriptors are unambiguous as to the public keys to use (derivation paths for extended keys are explicit) and the scripts to use. This makes them suitable for importing to other wallets without confusion. In contrast, traditional import mechanisms support only keys with special versioning to indicate the scripts to produce, and don't provide the derivation paths. This creates a situation where a user imports an extended key into a wallet but is unable to see their addresses because that wallet uses a different derivation path than the original wallet. Descriptors avoids this issue entirely by specifying the derivation paths (if any) and the scripts to produce.
A descriptor wallet is one which stores output descriptors and uses them to create addresses and sign transactions. By abstracting away address creation and transaction signing to a largely standalone module, such wallets can upgrade to using new address types much more easily.
For most users, the only visible effects will be in wallet import/export. Descriptors will only be shown during exporting, and descriptors should only be handled by the user when they want to import their wallet. Wallets that use descriptors internally shouldn't have any noticeable effect to the user.

¹: Solve - Solving a script means that one would be able to create a final scriptSig/witness with valid signatures if they had a private key. This means that all public keys and other scripts are available.

There are lots of address types (P2PKH, P2SH, P2WSH etc), some are multisigs, some are BIP32. Descriptors help the wallet software figure out what the address string actually is. If this is abstracted away from the user then the user doesn’t need to know but they are really useful for the wallet software. They let the wallet software figure out how to spend from it basically. You have some funds at an address, you import those keys to a new wallet, the descriptor helps the wallet figure out how it can spend from that address. If the existing wallet generated the address then the descriptor isn’t needed but if it didn’t it needs to know how to spend from it.

As a user, is there anything I need to do extra?

I don’t think so. Maybe the descriptor could be useful for the user to see in some cases if they want to know more about the funds in individual addresses or in individual UTXOs. But as I said if that is all abstracted away and the user just sees an overall balance they don’t need to do anything. Other than to upgrade to the new version of a wallet that uses descriptors

What data is needed to figure out the address type is stored in the seed? Or how is that managed?

The address type is not stored in the seed. That is private material that you’d need to know to spend from an address of any type. So the seed is generally referred to as the list of words you store that allow you to spend from any address in a HD wallet. A HD (hierarchical deterministic) wallet generates a tree of addresses that can all be spent from if you know that seed. However, you could have multiple HD wallets with different seeds and completely independent trees of addresses. Or you could have addresses that aren’t part of a HD tree and are just standalone addressses. So the descriptors help the wallet (or the technical user) keep track of what addresses are part of which HD trees, which addresses are standalone and not part of any HD tree, which are multisig etc etc. It can get very messy without descriptors.

I guess my question is how descriptors are stored?

You mean the location in the filesystem? Or the format in which it is stored? I’d need to check on these.

When a wallet looks at an address, how does it know which descriptor was used to generate it? Does it just go through all possible options and see if something matches, like what happens during during the initial discovery of used addresses?

If there is a descriptor e.g. wpkh this will tell the wallet what kind of address it is. If there isn’t a descriptor then sometimes the wallet will be able to recognize what kind of address it is and sometimes it won’t. If it is a pre-SegWit wallet then it won’t recognize bech32 addresses for example. With no descriptors and a HD tree of addresses then it will go through like 10 different addresses to assess if there are any funds before it gives up and assumes there are no more funds at any further addresses in the tree. If there is a descriptor you can literally tell the wallet don’t stop at 10 because I’ve got some funds sent to the 100th address in the tree.

What would be situations when there is a descriptor and when there isn’t one?

If the wallet that generated the addresses uses descriptors. If the wallet that generated the addresses doesn’t have descriptors implemented/doesn’t use descriptors then it doesn’t matter if new wallet you’re uploading keys to has implemented descriptors because it won’t receive any descriptors. For descriptors to be passed between two wallets the wallet that generated the addresses needs to use descriptors/have descriptors implemented and the wallet the addresses are being transferred to needs to recognize those descriptors.

So the wallet that generated the addresses needs to store them and users need to also back up the descriptors? Or at least have them available if they switch wallets?

Descriptors are like additional metadata to be stored with each address. If a wallet you are transferring to wants to take advantage of descriptors they need to receive the descriptor with the address. It is like handing over an address and a short description of that address rather than just the address and telling the new wallet to figure it out.

And if I don’t transfer the descriptors, I can still import the wallet and use it as normal? Or do I lose something?

Yeah you can throw away the descriptor at any point and not use it from that point forward. (Go back to a world before descriptors existed.) You only lose the benefits of descriptors that we’ve been discussing.

Anyone know of any wallets using descriptors as a default wallet creation option?

Wallets supporting output descriptors are listed here.
For more information on descriptor wallets see Andrew Chow's presentation at Advancing Bitcoin 2020 or his blog post on what's coming to the Bitcoin Core wallet in 0.21.
These questions were asked by members of the Bitcoin Design community.


text:
What is it that makes BIP149 safer to activate than BIP148?
There are currently two BIPs floating to enable a "user activated softfork" of Segregated Witness.
BIP148 is meant to activate by flag day on August 1st 2017 whereas enforcing nodes stop accepting blocks that don't signal readiness for segwit.
BIP149 proposes to initiate a second activation process based on BIP8 once the current versionbit (BIP9) activation times out unsuccessfully. From my understanding, BIP8 is the same as BIP9 except that at the end of the activation cycle it goes into LOCKED_IN instead of timing out.
Isn't it just a semantic difference, whether a subset of all nodes defines the proposal as LOCKED_IN or the same subset of nodes outright rejects non-signalling blocks until the proposal goes to LOCKED_IN?
What makes BIP149 safer to activate?
I don't see a significant difference or that the former would decrease the chance of a chainsplit significantly except for the longer waiting time until it is activated.

BIP 149 is different in that it does not enforce orphaning of blocks that don't signal readiness for SegWit. Instead just the supporters enforce the rules on any blocks that contain SegWit data and allow regular blocks to be mixed into the chain. Thus, miners that don't change anything will build on the SegWit chain.
To split the network, miners would need to deliberate fork the chain, either by continuously rejecting every SegWit block and outpacing the BIP149 chain, or by mining a block with an invalid SegWit transaction that legacy nodes accept and SegWit nodes reject and building on top of that.


text:
I keep hearing about MAST, what is it and what does it do?
So, somebody asked me about MAST yesterday.
Apparently, it's formalized in BIP114 – Merkelized Abstract Syntax Trees.
I couldn't explain what it was and what advantages it'll bring us.
What are MAST, and how will they help with scaling?

From what I've read and heard about MAST, it's an alternate version of pay-to-script-hash that uses a Merkle root instead of a regular hash digest.  It combines this idea with that of an abstract syntax tree, which is a data structure that compilers use to parse source code.  By "Merkelizing" a syntax tree, it allows redeemers to only expose the parts of the script being used for redemption.
This means that you can have more complicated scripts than are currently allowed by the 10,000 byte or 201 OP code limit.  Let's say there's a redemption script whose conditions look something like this:
A OR (B AND (C OR D)) OR ((E OR F OR (G AND H)) AND NOT I)

Right now, this script would be too complicated to fit inside the limit.  By forming it into a syntax tree and Merkelizing it, a redeeming transaction would only have to expose the conditions that were met.  For example, just A would redeem it, and so would just B and C.  This fits inside the size limit, while also never revealing the unused conditions that could have been used to redeem the UTXO.  There's a complexity gain without introducing the risk of DOS attacks, as well as a privacy gain.
I'm unsure how this will directly help with scaling, but since it allows for more complex scripts without a transaction size increase, it certainly won't hurt.  It's just another building block at the disposal of a developer, which they can then hopefully use to solve some future problem.

Nit: a NOT condition in a script directly below an AND/OR tree makes no sense. If I is not allowed to sign, he just won't sign :)

@PieterWuille, you caught me!  I just thought I needed a NOT in there somewhere ;-b

@PieterWuille, also, for the record, nobody would ever have to know that particular branch was there...which is sort of the point :)


text:
Can I download blockchain updates from somewhere?
I use Bitcoin only on rare occasions - say once every month. I want to avoid long waiting times for downloading and verifying blocks that consequently await me when I reopen bitcoin-qt. There are many options available for downloading the whole block chain when one starts out (like the blockchain torrent or the blockchain on Sourceforge). However, these options are full of warnings that tell you they should NOT be used when updating the block chain on an existing wallet but rather only when installing from scratch.
Are there similar ways of more quickly updating the blockchain by downloading recent blocks from some other source?
Note: I am not looking for other clients, but specifically for alternative blockchain download options for bitcoin-qt.

Downloading is not the bottleneck here, its the verifying of the downloaded information. Why not keep Bitcoin open minimized to contribute to the network?

There's not, keep your client open or use a 3rd party wallet which doesn't require you to run a bitcoin client (blockchain.info wallet or coinbase)

authors: нестеров юрий