text:
How to decrypt Bitcoin private key that is encrypted with PKBDF2-SHA256 and iterations and salt
I have exported wallet with encrypted keys and that wallet provider is closed. Is there a way to decrypt priv that is encrypted with PKBDF2-SHA256, iterations and salt. I think I remember the password I have used to encrypt the wallet.
The wallet provider is coinprism. The back-up is in the following format (JSON file)
{
  "keys": [
    {
      "addr": "<BTC_address>",
      "priv": "<97 length encrypted private key>",
      "encryptionMode": "PKBDF2-SHA256",
      "iterations": 2000
    }
  ],
  "salt": "<salt>"
}

Yes, but what wallet provider is it? The format of the exported wallet is important.

The wallet provider is coinprism. The back-up is in the following format (JSON file)
{"keys":[{"addr":"<BTC_address>","priv":"<97 length encrypted private key>",
"encryptionMode":"PKBDF2-SHA256","iterations":2000}],"salt":""}

@ieatpizza Do you think, this private key can be decrypted. I have the password.

I recently came across the same issue with an old wallet.
Luckily they still have an old repo on github with a decrypt tool that you should be able to use to decrypt your wallet and get the private key.
The repo is here:
https://github.com/Coinprism/backup-decrypt-tool

I'm not sure how versed you are with programming, but here's a quick summary of what I did to get it working and successfully sweep the funds into a separate wallet:
1: Firstly download the project, or if you have git you can simply clone it:
git clone https://github.com/Coinprism/backup-decrypt-tool.git

2: The tool is a .NET project written in C#. Tou will need to install .NET Core 2.0 Runtime in order to build the tool.
You can donload the install for windows here: https://dotnet.microsoft.com/download/dotnet/2.0/runtime
3: Once installed, open your terminal and navigate to the Coinprism.BackupDecryptTool directory inside the project.
From here you can build and run the tool using the following command:
dotnet run

4: Provided it successfully builds, you will be prompted to enter your info:

enter the the "priv" value from your backup as the "Encrypted value to decrypt"
enter the "salt" value
finally enter your password

5: The tool will decrypt your wallet and spit out the unencrypted private key and the corresponding bitcoin address.
Check that the address being displayed matches the one in your backup. If they are different, then check your info. Most likely your password is incorrect.
6: once you have the correct private key, you can sweep the funds using a bitcoin wallet.
I used Electrum wallet, as that runs locally and has a simple feature to sweep funds from a private key. You can put in any destination address as you wish while sweeping.


text:
How does headers-first prevent disk-fill attack?
Checkpoints prevented an attack where a node could mine many many low-difficulty blocks from an early point in the blockchain and serve those blocks to syncing nodes who would see their disks fill up. This is described in https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial_Block_Download#Checkpoints.
Now since checkpoints are removed, we would be vulnerable to this attack. But it is stated in (https://bitcoin.stackexchange.com/a/75735/69518) that this is prevented by the newish headers-first synchronization mechanism.
How does the headers-first synchronization prevent the disk-fill attack?
A syncing node downloads all headers from a single peer. If that peer only sends headers from its malicious low-difficulty branch, won't the syncing node try to download all those blocks, and get it's disk filled?

To add to the other answer, since Bitcoin Core 24.0, there is an additional protection implemented against low-difficulty header spam: header pre-syncing.
To recapitulate, since the headers-first synchronization introduced in Bitcoin Core 0.10.0, blocks are never downloaded before their headers are known and verified to have sufficient work (which means: enough to within one day of the active chain tip, and more than the preconfigured minimum chain work). This means we already don't need to worry about low-difficulty block spam anymore. The blocks are just not downloaded unless they're part of a chain that's proven to be good enough.
Yet, a weaker problem remained: a peer could start giving us (multiple) chains of headers that never amount to anything valuable. Since the headers are sent in forward order, there is no way to know at the beginning how good the result will get. The old solution (checkpoints) is unsatisfactory: it relies on updated software with hardcoded overrides on what chain is acceptable. As of Bitcoin Core 26.0, the checkpoints remain, but haven't been updated since 2014. By now, mining has become so much cheaper per hash, that an attacker could realistically start an attack after the last checkpoint.
Since Bitcoin Core 24.0, a new solution has been implemented: headers pre-syncing.
The idea is that the header synchronization (which precedes the block synchronization) is split up in two phases:

In a first phase, header presyncing, headers from a peer are downloaded and verified, but not stored, because we don't yet know whether they'll end up being good enough. Instead, only a very compact (salted) hash of these headers is kept (in per-peer memory, discarded upon disconnect).
In a second phase, header redownloading, the same headers are downloaded again from the same peer, and compared to the stored hash(*). If there is a match, they're fed to full header validation, which stores them, and will trigger block download.

This approach comes at a cost - the header synchronization is effectively performed twice, doubling its bandwidth cost (which is still small compared to full block download), but removes the last reliance on checkpoints in the codebase. They'll likely be removed in some future version.
(*) A simple hash wouldn't be sufficient, as we need the ability to verify headers along the way, not just the end. The actual structure consists of a single 1-bit salted hash every ~600 blocks. To compensate for the (extremely) small hash, upon redownloading, there is a buffer of ~14000 headers that are downloaded before validation. Only if all the ~23 1-bit hashes in those 14000 headers match, then the beginning of the buffer is fed to validation. This means every header has some 23 bits checked against it before validation, which would cost an attacker millions of tries to succeed against.

since checkpoints are removed, we would be vulnerable to this attack

Where did you see that checkpoints are removed?  They're still in src/chainparams.cpp as of current master (commit f8bcef38f).

How does the headers-first synchronization prevent the fill-disk attack?

Headers-first prevents a related attack where the client would accept "orphan" blocks---block with no known parent---and store them until their parent was received.  This prevented wasted bandwidth and sped up validation in the normal case but made disk-fill attacks easier in the pathological case.

Headers first allows Bitcoin Core to discover the most proof of work block chain (headers chain) that its peers know about before downloading any blocks, which allows it to ensure any blocks it receives are on that chain.  This, in turn, means that it never needs to download or store orphan blocks.

A syncing node downloads all headers from a single peer. If that peer only sends headers from its malicious low-difficulty branch, won't the syncing node try to download all those blocks, and get it's disk filled?

That's correct, and that's why checkpoints are still used in the code as far as I know.  My understanding is that, for the ultimate removal of checkpoints, three things were desired:

Minimum chainwork: a feature coded into a node that tells it the legitimate chain must have at least X amount of chainwork, with X being set to the value for a recent block near the time of a software release.  This replaces the original use of checkpoints in preventing network-level attackers from feeding clients long, low-PoW chains containing valid blocks but which aren't the consensus best block chain.  This was deployed in Bicoin Core 0.13.2.

Assumed Valid Blocks: a feature designed to replace the secondary use of checkpoints for (optionally) speeding up Initial Block Download (IBD) by skipping validation of signatures in old blocks.  This was deployed in Bitcoin Core 0.14

A minimum difficult soft fork: a change to directly address the block-fill (or header-fill) attack you described by raising the minimum difficulty at various epochs in the block chain to correspond roughly with the actual observed increases in difficulty.  This would make it more expensive for an attacker to feed fake blocks to a node.  To the best of my knowledge this has not yet reached the BIP stage and I'm not sure it's currently being actively championed.

For reference, this topic was discussed in the 2017-03-02 Bitcoin Core developer meeting: https://bitcoincore.org/en/meetings/2017/03/02/#discussion

Yes, seems I was wrong in assuming that the old checkpoints had been removed. So without the minimum difficulty soft fork, we're still vulnerable to the disk-fill attack from the last checkpoint, which is at height 295000. The difficulty has increased about 1000x since then, so the attack may be feasible.
I also see a line
'
// The best chain should have at least this much work.
consensus.nMinimumChainWork = uint256S("0x000000000000000000000000000000000000000000f91c579d57cad4bc5278cc");
'
Which seems to require any chain to have a lot of PoW to be considered ok.

I see there's a nMinimumChainWork parameter, that's used in https://github.com/bitcoin/bitcoin/blob/f8bcef38fb9be48f0f5908a6c4c0cbe8c5a729d6/src/net_processing.cpp#L1511. That should cover our asses?

AFAIK, that doesn't prevent header-fill attacks.  An exclusive peer can still feed you a header chain with 5 trillion diff-1 headers for about the same cost of producing a block at the tip.  80 bytes per header times 5 trillion is 400 terabytes, though probably something else breaks before then (like block header time rolls over).

Right. But let's see how many headers we need before consensus rules break. We need montonically increasing MTP. which means that the block timestamps need to increase at least one second per block, right? So we can't have move block headers than there are seconds since genesis block (+/- a few hours). That's about 315,360,000 blocks. 315 million block headers is "just" 25GB. That's fine, since the node should have 200 GB to spare at header sync. This of course relies on 1) Monotone MTP is verified on header sync and 2) Blocks from the future are not allowed during header sync.

@Kalle: an attacker can produce multiple low-difficulty branches if there was no protection against flooding by low-difficulty headers. Also, blocks only need a timestamp that is strictly larger than the median of the past 11 ones - that translates to incrementing the timestamp every 6 blocks AFAIK.

Summarizing the comments gathered: You can't quickly produce a long branch of low-difficulty headers from the last checkpoint with minimal increasing timestamp, because that would force your difficulty to go up. You're better off producing many 1-block branches from last checkpoint. The current difficulty is 1000x that of the last checkpoint, so if the whole network's hash rate cooperated, they couldn't currently produce more than ~6000*80=480kB of headers per hour. I think I can relax for now. Thanks for clarifications @Pieter, I should've consulted my own book before posting about MTP :-)

This answer is outdated since the introduction of headers pre-syncing in Bitcoin Core 24.0 (PR 25717).

source: Stack Exchange

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

sort: votes


text:
It only takes 20,000 computers to alter the Bitcoin blockchain?
Google says

As of now, there are roughly 12,130 public nodes running on the Bitcoin network.

So in a nearby small city, there are 70,000 people. If 1 household is assumed to have 3 people on average, there are 23,333 households.
Does that mean if each household runs a Bitcoin node using a US$5000 PC and provides some "fake data", now these 23,333 nodes become the majority and can alter the Bitcoin blockchain any way it wants to?
P.S. Maybe "fake data" is too vague.  How about: it is not all fake data, but just 1 fake entry that says, "transfer 10 BTC from address 1 to address 2?"

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

The blockchain is not determined by a majority vote and does not necessarily change if a significant portion of nodes claim an alternative chain is the main chain. Rather the main chain is determined by each node independently, and all nodes arrive at the same conclusion independently because they all are following the same set of rules.
So even if an attacker were able to have more nodes than honest nodes, and those nodes were broadcasting an alternate chain, all of the blocks in that chain would still have to pass validation by the honest nodes before those honest nodes will accept those blocks. This means that all transactions must be valid, the proof of work for every block must be valid, etc. That alternative chain must be valid for it to be accepted by other nodes, regardless of how many malicious nodes claim that it is the main chain.
If the alternative chain contained "fake data" that is invalid, then the entire chain would be rejected as invalid and no honest node would accept it. If the alternative chain is fully valid, and if it has more cumulative work than what honest nodes currently consider to be the main chain, then the honest nodes would switch to that alternative chain.

I have tried transferring 0.1 BTC from my Exodus, Coinbase Pro to Crypto.com and it took 1 hour or perhaps even close to 2 hours. It said it needed 3 or 6 confirmations or something. So I guess it does not mean 3 or 6 confirmations from 3 or 6 nodes, but rather, it check hundreds of random computers and consider it 1 confirmation... and so it hits hundreds of computer and they all land on the "bad guys", the probability is really small.  If it lands on one "honest guy", then the confirmation is not established and considered invalid. Is that how we can understand it?

No. Confirmations is the number of blocks into the blockchain you must go to find the transaction that contains your transaction. 1 confirmation means that the latest block in the chain contains your transaction. 2 confirmations means that the 2nd most recent block contains it. 3 means the 3rd most recent, and so on. Confirmations is not related to nodes verifying your transaction. Of course a transaction can only be confirmed (has at least one confirmation) if the block that includes it is valid.

What you are describing is an eclipse attack -- if the city ran enough nodes with the "faulty" blockchain they could make a node connecting to the network believe that that blockchain was the reality. This chain however would differ in the hashes that it contains so clients would reject it.
There are checkpoint hashes within that are hard-coded into clients:
Which blocks get to be checkpoints?
The "fake data" you describe would be easy to disambiguate from a higher proof of work chain (which cannot be faked no matter how many computers you have because it requires a tremendous number of hashes that have accumulated from all the miners over many years).

An eclipse attack is surrounding a victim node with only attacker nodes, so that it cannot learn about the true chain. Just spinning up more nodes is not nearly enough for that. As long as the victim has any connection to the honest network, even just a single one, they'll learn about the true chain and switch over.

what if it is not all fake data, but just 1 fake entry that says, "transfer 10 BTC from address 1 to address 2?"

Any invalid transaction would be detected by an honest node and that chain would be discarded

You're linking to another question where the answer is "none", which directly contradicts what you're saying. There are no checkpoints.

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


text:
What are the maximum useful memory limits for a Bitcoind full node?
In contrast to this question about running Bitcoind in a low-memory environment, I have an opposite use-case.
I want to run a bitcoind full node (no wallet) on a Linux server with lots of memory but not particularly fast disks. What are the maximum useful memory constraints (dbcache=, maxmempool= and total amount of page cache) that you can give to bitcoind to maximize its performance? That is, at which point does giving more memory to bitcoind start yielding diminished returns?

After a point, there's no reason to increase memory usage further.

dbcache is useful up until the point where you have the entire UTXO in memory (4GB+ in 2021), and then increasing it further does not a lot other than increasing the time to shutdown the node safely (up to many minutes on a slow disk)

maxmempool will increase performance by allowing more transactions (and their validity) to be ready for their inclusion in a block, but only up to the point where you are including all of the possible transactions that miners are likely to include.

blockreconstructionextratxn will allow the node to store more transactions which are not in the mempool, but are still valid. This increases the efficiency of compact block transmission as sometimes transactions will be evicted from your mempool but may be in other people's. This setting notably is in number of transactions, not megabytes.

maxorphantx increases transaction relay efficiency by keeping copies of transactions which could not be connected to a parent (and therefor can't be validated!), but might become valid in the future by the arrival of their parent. This setting is also in number of transactions, not megabytes.

These are about as far as you can go just by tweaking the settings in bitcoin.conf.

A "hot rod", "no cost considered" Bitcoin Core node would look a bit different.
The entire UTXO would be stored in a ramdisk (to prevent a cold dbcache ever occurring), with the obvious cost that unexpected shutdowns would result in a complete loss of synchronization state. As many cores as possible would be in use, the node would make connections to other nodes owned by the operator for maximum efficiency, and those nodes would be tuned to have as many high quality peers as possible.
You can go a long way towards making extremely performant nodes with not an unreasonable financial outlay if there's a reason to do so, it's just a matter of optimizing the right parameters and limiting bottlenecks that are normally caused by the network being optimized for stability and correctness.

"After a point, there's no reason to increase memory usage further"
That's precisely what my question is about. What exactly is that point?

As written in the answer, the limit for dbcache is the size of the UTXO database, which is around 4GB today (depending how it is stored). The other ones are as far as I'm aware are not documented enough to be able to state sensible limits.

"blockreconstructionextratxn will allow the node to store more transactions which are not in the mempool, but are still valid" - why are they not in the mempool?

They conflict with another transaction in the mempool, but this does not make them invalid.


text:
What do "support" and "resistance" mean?
I'm still very much a newbie to all this and would like to get some help.

By 'support' and 'resistance' assume you mean in the context of trading an asset. If so, then, simplistically, support means a level at which the value of the asset could become attractive for incremental buyers. Resistance means the value which the asset may be having a hard time breaking out of (likely due to people selling at those levels)

Thank you for answering! I am still very new to this and would like to learn more. I was trying to search videos youtube about it but there were so many to sift through so I figured I should just ask. Thank you!


text:
Hacked or Cracked i lost coins
Left wallet qt alone for some months, then started it up and during sync coins disappeared?

possible duplicate of Balance still not available?

There is a chance that someone took your coins by hacking into your computer and copying your wallet.  However, if this is the case, you should be able to load your wallet and see the out payment transactions.
Alternatively, search your payment address at BlockChain.Info  BlockChain.Info is possibly the best block explorer for bitcoin.  It's a good place to do research.

After BlockChain it looks like I was not the only one Juked

Is there anyway to catch the Bugger?

Nope.  Sorry, but that's the nature of the currency.

Why Mine? there seems to be an easier way to get Coins!!

John, I'm not sure I understand that last question.  I'm not talking about mining coins.  I'm providing a way for you to do research on your old wallet.  If the coins were never spent, you still own them.  However, if your balance on all of your accounts is 0, someone has emptied your account.

I researched the way you helped me and found one tag relating to a court case in Poland and another to Silk Road I think I was hacked and Hence my comment about Hackers seem to get coins Easier than Mining!

Sorry, Just Peeed Off

Ok, I understand.  Yes, that's a different question (and one that wouldn't be welcomed on a StackOverflow site.)  However, if you would like to find ways to obtain bitcoins, other than mining, there are many sites that can help.  Feel free to start a newbie post on either Bitcointalk.org or reddit.com/r/bitcoin.  Personally, I prefer BTC Talk.  Regarding the loss of your coins, there is nothing you can do to recover them.  Once they are spent, they are spent.  If you do not know the recipient, there is no way of finding out who they are, unless they've been dumb and published their address.

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


text:
Rolling forward [hash-of-the-block]
can somebody explain me what's the meaning of a Rolling forward after a reindex of the chain in the log of bitcoind?
Thanks in advance

Can you add a link to the source of that phrase to your post?

@VojtěchStrnad sure, and sorry for not doing it sooner


text:
weird block check after a reindex
is it normal that after a reindex the block check restarts strangely fast up to a certain point? My node was already synced.

The GIF is not speeded up. It's the real speed of the sync...
Thanks in advance..

That looks normal. Reindexing essentially means deleting the block index and the chainstate databases. The result is that blocks will be read from disk and re-verified and the databases rebuilt. With many blocks, this can go quite quickly since the blocks are relatively easy to verify, some checks may be skipped, and blocks don't need to be downloaded over the network.

This is especially true for the first ~100,000 blocks which are mostly empty.

Thank you so much.


text:
What was Bitcoin's Supply in the Pre-Alpha Release? (posted by Cryddit on Bitcointalk in 2013)
So I'm doing some research into this Bitcoin code that apparently pre-dates the first release of Bitcoin v0.01 https://bitcointalk.org/index.php?topic=382374.0
There's a lot of differences in this code when compared to v0.01 , But I'm mainly interested in the supply of Bitcoin implied/outlined in this apparent first/early draft code of Bitcoin.
I've tracked down two parameters that imply the supply would either have been 20 Trillion Satoshi’s TOTAL (2 Billion Bitcoin)
OR
It would have been just 2 Billion Bitcoin units TOTAL, with NO decimals/sub-bitcoin satoshi units, because of coding semantics?
So I'm here for a second opinion from the experts!
Hopefully I can express this well and my math is correct:
"The second big coding difference is that the initial block reward is not 50.00000000 Bitcoin BUT 10000.0000 Bitcoin(?). This doesn’t imply a total supply of 2.1 Qudrillion Satoshis (21 Million Bitcoin), BUT 20 Trillion Satoshi’s TOTAL instead (2 Billion Bitcoin)!
Notice the decimal place difference here too. In Satoshi’s first draft of Bitcoin, he envisioned there being only four decimal places, instead of eight. But the coinbase reward was also significantly larger at 10000 Bitcoin per block, instead of 50.
Furthermore, the halving was scheduled for every 100000 blocks, instead of 210000 blocks. The block time target was aimed at 15 minutes instead of 10 minutes too. This implied a halving of approximately every 34 months, or 2.85 years. Not every four years."

The above two code sections seem to be relevant here. But notice the first only has a value of 10000. While this section of code in v0.01 is 50*COIN where COIN is 100 million units.
Does this then imply that there were no decimal place/satoshi units in this first draft of Bitcoin, because there is no " * COIN " or " * CENT " on top of the 10000 base reward?
the second line of code where we have " 10000 * CENT " (where CENT also = 10000) implies a number system of 10000.0000 units. BUT, since this is missing from the first picture of code, are there even any satoshi/decimal units here effectively?
Thank you for your consideration and insights into this code!

detailed write up on this question and answer here: https://stacker.news/items/458544/r/BITC0IN
boils down to:

One fun nuance of C++ code is that integers are truncated when used as Satoshi did. This ends up somewhat reducing the total supply of Bitcoin in this 2008 code, from what looks like 2 billion bitcoin at first.

The result of this truncation on supply is a very specific total: 19,999,898,800,000 satoshis or 1,999,989,880 Bitcoin. Thanks to MrRGnome for pointing this out: "it's possible Satoshi didn't even realize this rounding was happening."


text:
Why does estimatesmartfee not return < 5 sats/vB even for long confirmation times?
We find that estimatesmartfee will not return results lower than 5 sats/vB, even though many transactions are completing at much lower fee rates.
Looking at the implementation of estimatesmartfee, it bounds the result to the higher of three values:
CFeeRate feeRate{fee_estimator.estimateSmartFee(conf_target, &feeCalc, conservative)};
if (feeRate != CFeeRate(0)) {
    CFeeRate min_mempool_feerate{mempool.GetMinFee()};
    CFeeRate min_relay_feerate{mempool.m_min_relay_feerate};
    feeRate = std::max({feeRate, min_mempool_feerate, min_relay_feerate});
    result.pushKV("feerate", ValueFromAmount(feeRate.GetFeePerK()));
} else {
    errors.push_back("Insufficient data or no feerate found");
    result.pushKV("errors", errors);
}
result.pushKV("blocks", feeCalc.returnedTarget);

Therefore we need to ensure min_mempoool_feerate and min_relay_feerate are both below 5000 sat/vKB on the nodes used for estimation.

Looks like min_relay_feerate seems to come from m_min_relay_feerate{opts.min_relay_feerate} in src/txmempool.cpp which comes from DEFAULT_MIN_RELAY_TX_FEE defaulted to 1000

min_mempool_feerate coming from mempool.GetMinFee() seems to inherit a minimum from incremental_relay_feerate{DEFAULT_INCREMENTAL_RELAY_FEE} where DEFAULT_INCREMENTAL_RELAY_FEE default is 1000

Does anyone know what else holds it this high?

Turned out we had an override for minrelaytxfee in the config file:
# Mempool
minrelaytxfee=0.00005

Hi Chris, thanks for returning to answer your own question! Welcome to Bitcoin Stack Exchange.


text:
How to fix this error?: Signature must be zero for failed CHECK(MULTI)SIG operation (code -26)
I'm trying to unlock money from P2SH 2NG4PEU9rya1fcqAfSvQQAteaUkvc54J1fF, but the library is not used by https://www.youtube.com/watch?v=U2bw_N6kQL8
When I combine the Tx, I hash the Tx with SHA256 twice, then sign it with ECDSA (not used library).
After I verify that the signatures I have are valid and collect the signed tx (Signed Tx) and distribute the Tx to the bitcoin network (testnet), the problem I encounter is "Unacceptable signature: unnecessarily high S-value."
and then edit this thread.
https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki
After I did this method, the result of S is less than R, but there is another problem. "Signature must be zero for action. Failed CHECK(MULTI)SIG"
But Script it not multisig
But here is still a problem. So I don't know how to solve this problem. and don't know how to ask this question to the point
Private Key:
| hex = 82d6cfc556c25e3fd02eb384bd95ba4fd217911836ce5b19fb34c864f6a5a9f4
| dec = 59180209569427299317707189507794282735328653532808969125005524031929026193908

Public Key:
| x = 00aa36a1958e2fc5e5de75d05bcf6f3ccc0799be4905f4e418505dc6ab4422a8db
| y = 1fabeb6911ae2715032944ca90d452b30192b5539e4dfb0c386013321fcada8c

Unsigned Transaction:
| 0100000001fc3adf56a9b345dd394479b5438365777ba7d91eb3954d9f2b5e2c7a68d06b980000000029030c3725b1752102aa36a1958e2fc5e5de75d05bcf6f3ccc0799be4905f4e418505dc6ab4422a8dbacfdffffff01d36f0300000000001600149058b7a55f5d5f88667a01fd66dd59e379002f5d0c372500

Message (doubleSHA256): 40a9f18c88d0f16989742b5fde90c52097c6c52feb37f7bf912140998b0713f4

Signatures:
| r = 85481222987935817085579092069107947283118149501178124668858153032995539683302
| s = 23241719739309219792817770422392736282205653387772946202874350868806068363298

Signed Transaction:
| 0100000001fc3adf56a9b345dd394479b5438365777ba7d91eb3954d9f2b5e2c7a68d06b980000000073483045022100bcfca85cc0582a456aefd52539747bf24342b360f821d66a570fb7b754b687e60220336258e21892cea41ea90a8a8538b0af4081c605f2f7a73821f871066c2060220129030c3725b1752102aa36a1958e2fc5e5de75d05bcf6f3ccc0799be4905f4e418505dc6ab4422a8dbacfdffffff01d36f0300000000001600149058b7a55f5d5f88667a01fd66dd59e379002f5d0c372500

{
  "txid": "53a4886fa2f89864c0b874b0db03836b4cbb1b9b13fa45d0ca262cf321138c5d",
  "hash": "53a4886fa2f89864c0b874b0db03836b4cbb1b9b13fa45d0ca262cf321138c5d",
  "version": 1,
  "size": 197,
  "vsize": 197,
  "weight": 788,
  "locktime": 2438924,
  "vin": [
    {
      "txid": "986bd0687a2c5e2b9f4d95b31ed9a77b77658343b5794439dd45b3a956df3afc",
      "vout": 0,
      "scriptSig": {
        "asm": "3045022100bcfca85cc0582a456aefd52539747bf24342b360f821d66a570fb7b754b687e60220336258e21892cea41ea90a8a8538b0af4081c605f2f7a73821f871066c206022[ALL] 030c3725b1752102aa36a1958e2fc5e5de75d05bcf6f3ccc0799be4905f4e418505dc6ab4422a8dbac",
        "hex": "483045022100bcfca85cc0582a456aefd52539747bf24342b360f821d66a570fb7b754b687e60220336258e21892cea41ea90a8a8538b0af4081c605f2f7a73821f871066c2060220129030c3725b1752102aa36a1958e2fc5e5de75d05bcf6f3ccc0799be4905f4e418505dc6ab4422a8dbac"
      },
      "sequence": 4294967293
    }
  ],
  "vout": [
    {
      "value": 0.00225235,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 9058b7a55f5d5f88667a01fd66dd59e379002f5d",
        "desc": "addr(tb1qjpvt0f2lt40csen6q87kdh2eudusqt6atkf5ca)#6fsn5mx5",
        "hex": "00149058b7a55f5d5f88667a01fd66dd59e379002f5d",
        "address": "tb1qjpvt0f2lt40csen6q87kdh2eudusqt6atkf5ca",
        "type": "witness_v0_keyhash"
      }
    }
  ]
}

How do I solve this problem?
// jdk 20

object EllipticCurve {

    // * Secp256k1
    private val A = BigInteger.ZERO
    private val B = BigInteger.valueOf(7)
    private val P = BigInteger("FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F", 16)
    private val N = BigInteger("FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141", 16)
    private val G = Point(
        BigInteger("79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798", 16),
        BigInteger("483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8", 16)
    )

    // * จุดบนเส้นโค้งวงรี มีพิกัด x และ y
    data class Point(val x: BigInteger, val y: BigInteger)

    // ──────────────────────────────────────────────────────────────────────────────────────── \\

    /*
    * < Elliptic Curve cryptography >
    * ในส่วนนี้เป็นการคำนวณค Public Key
    *
    * อ้างอิงจาก:
    * https://github.com/wobine/blackboard101/blob/master/EllipticCurvesPart5-TheMagic-SigningAndVerifying.py
    * */

    // * https://www.dcode.fr/modular-inverse
    fun modinv(A: BigInteger, N: BigInteger = P) = A.modInverse(N)

    fun doublePoint(point: Point): Point {
        val (x, y) = point

        // ! (3 * x * x + A) % P
        val slope = (BigInteger.valueOf(3) * x * x + A) % P

        val lam_denom = (BigInteger.valueOf(2) * y) % P

        val lam = (slope * modinv(lam_denom)) % P

        val xR = (lam * lam - BigInteger.valueOf(2) * x) % P

        val yR = (lam * (x - xR) - y) % P

        // * จุดใหม่ที่ได้หลังจากการคูณด้วย 2 บนเส้นโค้งวงรี
        return Point(xR, (yR + P) % P)
    }

    fun addPoint(point1: Point, point2: Point): Point {
        if (point1 == point2) {
            return doublePoint(point1)
        }
        val (x1, y1) = point1
        val (x2, y2) = point2

        val slope = ((y2 - y1) * modinv(x2 - x1)) % P

        val xR = (slope * slope - x1 - x2) % P

        val yR = (slope * (x1 - xR) - y1) % P

        // ! จัดการพิกัด Y ที่เป็นค่าลบ
        val yResult = if (yR < BigInteger.ZERO) yR + P else yR

        return Point(xR, yResult)
    }

    fun multiplyPoint(k: BigInteger, point: Point? = null): Point {
        // * ตัวแปร current ถูกกำหนดให้เป็น point ที่รับเข้ามา หากไม่มีการระบุ point ค่าเริ่มต้นจะเป็นจุด G ที่ใช้ในการคูณเช่นกับ private key
        val current = point ?: G

        // * แปลงจำนวนเต็ม k เป็นเลขฐานสอง
        val binary = k.toString(2)

        // * เริ่มต้นด้วยจุดเริ่มต้นปัจจุบัน
        var currentPoint = current

        // * วนลูปตามจำนวน binary digits ของ k
        for (i in 1 until binary.length) {
            currentPoint = doublePoint(currentPoint)

            // * ถ้า binary ตัวที่ตำแหน่ง i เป็น '1'  ให้บวกจุดเริ่มต้น (current) เข้ากับจุดปัจจุบัน (currentPoint)
            if (binary[i] == '1') {
                currentPoint = addPoint(currentPoint, current)
            }

            // * Debug
            //println("binary[i] = $i:")
            //println("Current Point: $currentPoint \n")
        }

        // * ส่งคืนจุดที่คำนวณได้
        return currentPoint
    }

    // ──────────────────────────────────────────────────────────────────────────────────────── \\

 object ECDSA {

        /*
        * https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
        */

        fun SignSignature(privateKey: BigInteger, message: BigInteger): Pair<BigInteger, BigInteger> {
            val m = message
            val k = BigInteger("42854675228720239947134362876390869888553449708741430898694136287991817016610")
            //val k = BigInteger(256, SecureRandom())

            val point = multiplyPoint(k)
            val kInv = modinv(k, N)

            val r: BigInteger = point.x % N
            var s: BigInteger = ((m + r * privateKey) * kInv) % N

            // * https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki
            if (s > N / BigInteger.TWO) s = N - s else s

            return Pair(r, s)
        }

        fun VerifySignature(publicKeyPoint: Point, message: BigInteger, signature: Pair<BigInteger, BigInteger>): Boolean {
            val (r, s) = signature

            val w = modinv(s, N)
            val u1 = (message * w) % N
            val u2 = (r * w) % N

            val point1 = multiplyPoint(u1)
            val point2 = multiplyPoint(u2, publicKeyPoint)

            val point = addPoint(point1, point2)
            val x = point.x % N
            return x == r
        }

        // * https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki
        fun toDERFormat(signature: Pair<BigInteger, BigInteger>): String {
            val (r, s) = signature
            val rb = r.toByteArray()
            val sb = s.toByteArray()

            val der_r = byteArrayOf(0x02.toByte()) + rb.size.toByte() + rb
            val der_s = byteArrayOf(0x02.toByte()) + sb.size.toByte() + sb
            val der_sig = byteArrayOf(0x30.toByte()) + (der_r.size + der_s.size).toByte() + der_r + der_s
            return der_sig.joinToString("") { String.format("%02x", it) }
        }

    }

    fun toDERFormat(signature: Pair<BigInteger, BigInteger>): String {
            val (r, s) = signature
            val rb = r.toByteArray()
            val sb = s.toByteArray()

            val der_r = byteArrayOf(0x02.toByte()) + rb.size.toByte() + rb
            val der_s = byteArrayOf(0x02.toByte()) + sb.size.toByte() + sb
            val der_sig = byteArrayOf(0x30.toByte()) + (der_r.size + der_s.size).toByte() + der_r + der_s
            return der_sig.joinToString("") { String.format("%02x", it) }
        }

}


text:
How to spend P2WSH address with full redem script and witness program?
I just put few dollar in here.
Bech32 Address: bc1qx6c07u2s6pu6d5ede8ee9hmynahp9edgg764cm58gfxmryk3ryqsxarnnv
Witness Script Hex 76a914b1217062623d9101426f61593cb1abc3e44ed00488ac
Witness Script Asm
OP_DUP OP_HASH160 14<b1217062623d9101426f61593cb1abc3e44ed004> OP_EQUALVERIFY OP_CHECKSIG
Witness Version 0
Witness Program 36b0ff7150d079a6d32dc9f392df649f6e12e5a847b55c6e87424db192d11901
ScriptPubKey Hex    002036b0ff7150d079a6d32dc9f392df649f6e12e5a847b55c6e87424db192d11901
ScriptPubKey Asm OP_0 20<36b0ff7150d079a6d32dc9f392df649f6e12e5a847b55c6e87424db192d11901>
show me how to spend this, feel free if you want to just take the fund of it, i do this for educational for security building P2WSH address from P2SH redemscript hash160.

That is not P2TR as it as a witness version of 0. P2TR is witness version 1. It appears to be a P2PKH nested inside of a P2WSH.

Perhaps this sort of testing would be better directed at Testnet or Signet?

sorry, i was missspell the type of Addresses, yes it's P2PKH nested inside of a P2WSH

i make the address for mainnet.

This is P2PKH nested inside P2WSH. What you provide is just witness script. To spend P2WSH transaction, you also need to provide witness items(varying upon witness script), which can fulfill the condition of witness script. It's not enough even if witness script matches witness program, as witness script will be executed when matches.
For P2PKH nested inside P2WSH, you need to provide valid signature and public key(from secp256k1) as well as witness script in the order of <signature> <public key> <witness scipt> at witness items. Public key must be digested into b1217062623d9101426f61593cb1abc3e44ed004 when OP_HASH160, and its private key must generates signature which can be verified with public key when sign transaction appropriately. What you need to provide mostly same with P2PKH but with P2PKH script as witness script.


text:
How do I create a Namecoin address?
My mining pool has merged with Namecoin, and I need a Namecoin address. How do I create one ? Do I need to install another client ?

You can either install a client, or use some Namecoin-Bitcoin exchange (like BTC-E) to obtain an address. It`s generally the same as getting a Bitcoin address really, only a bit less popular.

I think I had read that BitParking deposit addresses were single-use, and not for repeated mining payouts.

@StephenGornick I'm not really sure if it's a rule or a suggestion. I guess I'll change my answer regardless. Thanks for pointing it out, I don`t really use the service too much.

where can I get namecoin client?

If you know Python, then there is a library called Coinkit that you can use to create Namecoin addresses:
https://github.com/halfmoonlabs/coinkit
It has step by step instructions as well, but you'll do something like
pip install coinkit
once installed, open python and:
from coinkit.keypair import NamecoinKeypair
create a new private-key and NMC-address pair:
keypair = NamecoinKeypair()
You can get the private key by:
keypair.private_key()
And the corresponding namecoin address as:
keypair.address()

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


text:
How would the network respond to an ability to crack the private keys?
I'm wondering how future-proof the BTC network security is.
Suppose some technological advancement (e.g. quantum computing and/or some ingenious algorithm) were to allow easily cracking the private keys.
How would the BTC network respond to such an ability if it was anticipated at least a year or so in advance? What would the response be if one morning such an ability was discovered/announced?

This would be a global issue, not just Bitcoin related
If someone discovered how to extract the private key from an arbitrary ECDSA public key in an economically viable timeframe, then there would be serious ramifications for many other economies that depend upon that branch of mathematics. For example, international banking, secure data transmission and many other users of cryptography would need to manage the change so it would not just lie on the Bitcoin community to save it.
That said, the response would depend on the nature of the attack. It may be that the attack could be easily mitigated by constantly changing private keys in which case a fairly minor update could be built into the various clients to support this.
If the problem was with the choice of cryptographic algorithm then work would have to take place to find an appropriate replacement that was not subject to the given attack vector, and then to apply that to protecting the integrity of the transactions taking place through the blockchain.
From a community point of view, there is already a process in place to manage these kinds of responses (see BIP) which has had several successful uses when critical bugs or attacks have been uncovered.


text:
Virtual currency used as alternative currency
Would it be feasible for a virtual currency to be used in the same way as alternative currencies such as Berkshares and Brixton Pounds ? Furthermore, do you think it is possible to make it independent of conventional currencies such that it is held to a standard, say a basket of household goods ?

Are you talking about Bitcoin (or an alternate chain) or just virtual currencies in general?

Bitcoin in particular. If it isn't suitable then ideas on what would be.

Perhaps this would be relevant to you? https://bitcointalk.org/index.php?topic=101197 We're considering implementing a POC of this.

@ripper234 Will have a good read through. Have you had a look at the idea of minimum income being discussed in Germany and Switzerland ? http://en.wikipedia.org/wiki/Guaranteed_minimum_income

No, not sure of the relevancy.

It is not relevant in this immediate context. However, this is one of the directions being considered by reformists. In the meantime, alternative currencies might not only a means to limit exchange to a locality. They could also serve as a means of survival in the event of a sharp economic downturn. In this respect, virtual currencies would definitely hold some advantages.

This link might also offer a few leads on what alternative currencies can offer offer conventional ones.
http://en.wikipedia.org/wiki/Monetary_reform

While there's no technical issue preventing the use of Bitcoin and its' associated engine for any number of alternate currency types, the problem you're likely to run into with your question is the addition of a central issuer. Bitcoin is explicitly designed for distributed issuance of funds according to a carefully designed algorithm that requires distributed proof-of-work. It would be non-trivial to chance the issuance mechanism.
That said, if you have a talented programmer, Bitcoin is open-source under the MIT license and you're welcome to modify it as you see fit, just know that it's probably not going to be as easy as your question seems to indicate it should be.

Thanks for the input David. Could you go further into explaining why a central issuer would be necessary ? I do understand that alternative currencies such as Berkshares are localized. Also, am I correct in thinking that Bitcoin requires purchase with, say USD, for issuance ?

Bitcoin does not require purchase with any fiat currency for issuance. Issuance happens via an activity commonly called "mining" - miners perform huge amounts of complex math that help secure the transaction history against fraud and in exchange, they are rewarded with a set amount of Bitcoin. It may be worth reading the "How Bitcoin Works" page on the wiki for an overview.

@JamesPoulson: I don't think there's any way to hold a currency to a standard without either a central issuer or good samaritans willing to take huge losses. Without a central issuer to regulate supply, too much currency can be in circulation and the currency's value can fall, separating the currency from the standard it's supposed to stay pegged to. The standard could only be held by a good Samaritan who buys up the currency at a loss until the standard is reached again. Who would do that?

@DavidSchwartz I'm not sure I get all of that but how about substituting regulation with some "gameplay" or internal rules ? That's probably the intention behind the way Bitcoin is designed. As for inflation, there could be two possible solutions. Have a sort of "tax" or have units that expire after a given time or condition. What do you think ?

@JamesPoulson: See if you can come up with a way to make such a system work. I don't think you can. Who wants a monetary system with taxes or expiring units? What's the benefit of such things?

@DavidSchwartz I won't hide that these ideas are coming from the monetary reform perspective. Here's where the idea of using a tax (might not be the appropriate word...) to tackle inflation comes from.
http://www.youtube.com/watch?v=DthcVZsFKmo

@DavidSchwartz There is a topic on expiring currencies on this link, the reasoning being that it would encourage monetary flow: https://bitcointalk.org/index.php?topic=2462.0 . However, this article from mises.org suggests it could be a red herring and such a measure might not be appropriate, especially for people who aren't happy about state interventions. http://mises.org/daily/324 . This is where the idea of or gameplay or a ruleset comes in the idea being to protect the average consumer while leaving the market free within given confines or safety rails.

@DavidSchwartz Here is a further link relevant to idea of expiring currency: http://en.wikipedia.org/wiki/Freigeld

Bitcoin is a standalone alternative currency with no dependency or "backing" from any other entity.  The rate it trades at is the result of supply and demand.
The alternative currencies Berkshares and Brixton Pounds are representative currencies.  A Berkshare represents 95% of a dollar.  For example, you can go to a bank in the region and exchange one Berkshare and get back $0.95 USD.
Participating local merchants will accept the BerkShare at a 1:1 ratio with the dollar.  They aren't necessarily losing the 5% as a customer discount though because after the merchant receives that Berkshare, it can then be used to pay contractors or to make purchases from other merchants.
The funds then circulate over and over within the community.
If the merchant happens to end up taking in too many BerkShares and needs make purchases where payment is in dollars, the BerkShares can always be redeemed back to dollars at the rate of $0.95 per BerkShare.
Most of the benefit goes to the consumer who converts dollars to BerkShares because this effectively provides a 5% discount on all purchases made using Berkshares.  When the merchant then goes to spend these, there is no direct benefit because a full $1 of value was exchanged for each BerkShare.
The merchant might find that offering this 5% discount is something that is more than offset with stronger business locally, or the mechant desires improved relations with its customers and benefits from building and supporting a stronger local community.
This all works because BerkShares are not issued elsewhere, and they cannot be redeemed elsewhere.
With Bitcoin, there is no containment.  A merchant could offer a discount for all bitcoin payments, but because that bitcoin can be redeemed anywhere, the funds aren't necessarily retained in the local community.  There's no harm to offering this other than the potentially harm to margins, but going this route misses completely the original incentive of a community currency -- a reasonable method to encourage the community to increase commerce locally.
Here's the main reason this wouldn't work when using bitcoin just yet though.
Technically the backing for the BerkShare could be a bitcoin, or an ounce of silver even if you really wanted.  But the problem is that you then expose the community members (consumers and merchants) to exchange rate risk.
But let's say this community (consumers and merchants) were willing to take on the exchange rate risk.  There are more problems.
BerkShares does have a cost to administer -- the bills must be printed and there must be exchange to and from dollars, etc.  With BerkShares, apparently the local community together subsidizes that.  But the person holding the BerkShare is at no time not ever able to get back at least the $0.95 of value that was spent to acquire it.
If there were a method to transact electronically, then there wouldn't be the cost of the bills, but that is asking the consumer and merchant to incur costs that would be seen as excessive.  So it would probably need to be paper-based or a coin monetary instrument representing the amount of backing held by an issuer.
And that again is a roadblock.  The dollars backing BerkShares are held in a federally insured bank and BerkShares is responsible to ensure that no BerkShares are counterfeits.  This does not translate well for bitcoin, as there is no "federal bank" to store the bitcoins with.  Maybe with M of N a workable method to "bank" the coins would be accepted.
There are a lot of options for something like this, but really no incentive as the goal of the community currency is to introduce friction that encourages commerce to remain local.
Bitcoin is built to bypass any artificial frictions.
Now individuals and merchants in the community are free to begin using bitcoin without it being promoted as some type of community currency.  It would be something novel where the merchant might attract new customers, but doing so doesn't necessarily bring the same results along the lines of what the BerkShares' goal is intended to bring.

Now some enterprising individual could probably build a mobile wallet app that monitors the blockchain & tries to spend "tainted" coins (where the taint means how much of the payment's pedigree is from other merchants in the community).  Payments using these tainted coins would be awarded a discount from the merchant who in turn receives the same discount by re-spending the coins within the community. That way you end up with no issuer, and no overhead costs for managing this. The main problem is this would give up identity (e.g., merchants would need to register or claim receiving addresses.)


text:
When closing the channel for LN - how to calculate the fee for the blockchain transaction?
To be clear: Following is not about fees in Lightning Network. Following is about fees on blockchain for transaction which closes the channel in LN.
Channel closing transaction can be created months before broadcasting to blockchain network. How the fee for the blockchain transaction is calculated without knowing the (far) future situation in mempool?
Is replace-by-fee possible for LN's closing transaction? There are different types of closing transaction — maybe answer is different for each type of closing transaction.
Is the fee calculation related to current situation in mempool? I found some calculations here, but I didn't found any relation to dynamically changing situation in mempool.

If worried about the original closing transaction having too high of fees:
The signed closing transaction that you're worried about (with too high of fees) has not yet been broadcast to the network, so no harm no foul (yet).
If the two parties are cooperative, they can just agree to sign a new transaction with lower fees and broadcast that to close out the payment channel (this should be advantageous for both of them anyway).
If the two parties are NOT cooperative, it might be best to just broadcast the original closing transaction and eat the fees.

Is replace-by-fee possible for LN's closing transaction?

Replace-by-fee only applies to transactions that have already been broadcast to the network. Also, they only help if you're increasing fees, not decreasing them, so it doesn't apply to this situation.
If worried about the original closing transaction having too low of fees:
If the two parties are cooperative, you can just sign a new closing transaction with higher fees and broadcast that.
If the two parties are NOT cooperative, just broadcast the original closing transaction and hope that the transaction does not get stuck in the mempool. Also make sure that the original closing transaction has a high enough fee that there is little worry about it getting stuck in the mempool. Even somewhat non-cooperative parties should be willing to re-sign and lower the fees to close out the payment channel. Overall, this is the trickier scenario to predict.

Is replace-by-fee possible for LN's closing transaction?

Again, replace-by-fee only applies to transactions that have already been broadcast to the network. Also, this would require a cooperative party.

No, I'm (most) worried about too low fee, and not cooperative party.

@CoperNick I updated my answer with more conditional scenarios. It's still a tricky problem that you're bringing up.

Thanks. After your update I see potential attack scenario on channel with more than one balance updates with different transaction fees. Maybe see you in next question.

Isn't "Child pays for parent" another way to resolve a closing transaction having too low fees? I.e. broadcast the closing transaction with small fees and broadcast a subsequent dependent transaction with high fees.


text:
Front running in Bitcoin
Have you ever witnessed any front-running case in Bitcoin?
All front running cases are related to Ethereum smart contracts, auto market makers and uniswap.
Thank you

Front-running (in the case you're referring to) is a concept related to on-chain trading, where miners order transactions to affect the exchange rates of smart contracts. Since bitcoin does not currently support smart contracts, ordering of transactions cannot affect the miner, as there is nothing to front-run.

I agree with @Prayank's comment here, but think this answer overall is still more accurate: the reality is simply that Bitcoin simply doesn't have exchanges with on-chain order books like Ethereum has, so no money is to be made by reordering the execution of those.

on-chain bonding curves (aka trading with a liquidity pool as your counterparty) seem to be the primary target of frontrunning, moreso than order books I think


text:
who attaches dependent transactions? Sender or receiver
I am wondering who can attach dependent transactions to a transaction not confirmed and is in the Mempool.
Is that the sender or the receiver?
Assume Alice wants to send 20 BTC to Bob. Her transaction is still waiting in the Mempool. Can Alice depend on another transaction for this one? Or can Bob do that?
What are the incentives?
Thank you

Is your question about Child Pays For Parent (CPFP)? Your wording is a little confusing, you cannot "attach dependent transactions" to an existing transaction, you can only make your transaction depend on it (the inverse relation).

Thanks for your response. I want to know how descendent and ancestor fields are created in Mempool per transaction. Each has a fee, size and count field.
Based on your answer, it means Bob(receiver) can depend on a new transaction to the previous one.
does depending a transaction need some kind of permission?
Thank you

What exactly do you mean by Mempool? The website mempool.space?

Mempool: Mempry pool
A waiting pool in which submitted transactions are waiting for the confirmation of the miner

A transaction is dependent on all transactions whose outputs are spent, and it can only be confirmed after all its ancestors are confirmed (this can be within the same block, just in the correct order). This has a few implications:

If a transaction is replaced or double-spent, all its descendants become invalid, because they are now spending non-existent inputs.
If a descendant transaction pays a higher fee than its ancestor, this creates an incentive for miners to confirm both (this is called Child Pays For Parent or CPFP).

You can attach a dependent transaction to a transaction as long as you are the recipient of one of its outputs. If the transaction contains a change output, this also includes the sender. Depending on a transaction has no impact other than potentially incentivizing miners to confirm it faster.

Is there any cost associated with that? I mean, is it free for the sender to depend transaction?

All transactions bid with their transaction fees for the blockspace they occupy. So it depends on the amount of data in a transaction, and the feerate it's trying to achieve. If it wants to reprioritize a parent transaction it must add the additional fees to do so. So generally, a CPFP transaction will be more expensive than other transactions.


text:
withdrawal fee in crypto
I have a question related to the withdrawal fee. I can find transaction fees, but not withdrawal fees in crypto platforms.
Could you please let me know how I can find out more about this type of fee? I am interested to see if its trend is smooth or volatile? Is that specific per platform/exchange or crypto asset. I could find various descriptions that I could not wrap around my head.
I wanna see if this fee can affect investors' decisions on liquidation and etc?
Thanks.

The intent of the original creators of Bitcoin was to create a currency where there was no need for trusted third parties like banks or other financial institutions.
If you use Bitcoin as money, in the way originally intended, there are no withdrawal fees because you can keep or spend money without withdrawing it from a business/institution.
Bitcoin is cash, not an account.
You could go against the intent of Bitcoin's creators and, instead of looking after your money yourself in your own wallet, you can give your money to a business and ask them to look after your money for you. That business is regarded as a custodian of your money.
Then withdrawing money means asking that business to give you your money back by creating a Bitcoin transaction to send to your self-managed non-custodial wallet an amount of money equal to the amount you originally gave them less any fees you agreed to in their terms and conditions when you created an account with them. This is like using an ATM to withdraw money from a dollar-denominated bank account as cash in the form of physical dollar bills (banknotes). But remember that Bitcoin was created so that you didn't ever need to use and trust a third party to look after your money or to spend it.
If, for whatever reason, you decide to trust a third party business to hold your money for you instead of holding it yourself, the fees they charge depend purely on the business you are dealing with. To find out about fees charged by a particular business you must communicate with that specific business.
I think it is simpler not to give them money, then there can be no fees.


text:
How does using a Turing-complete programming language compromise the security of the network?
I have read many places that the decision for Ethereum to use a Turing-complete programming language sparked a lot of concerns over security. From my understanding, not using a Turing-complete programming language leads to a more secure network. Why is this the case?

Related: The Bitcoin scripting system is purposefully not Turing-complete - why?

It is much easier to formally verify the behavior space of Bitcoin script vs. Solidity.
For example, the DAO project suffered from reentrancy vulnerabilities, given that one could not predict the behavior of anonymous smart contracts when they were called/sent funds to (fallback function, now deprecated).
There are formal verification efforts for Solidity, but this increases the design difficulty tremendously, and one must ask whether it is worth the turing-completeness.


text:
Says "confirmed" but never received
I sent someone bitcoin through cash app and it says confirmed but the recipient said they never received it, is there a reason this could be happening? Or is there a way for me to get it back from the block chain?

There is no way to actually get it back. You can always check if they really received it by going to blockchain explorer and track the transaction here:
https://www.blockchain.com/explorer
Sometimes the transaction might not show up on the receivers transaction tab but adds up to their wallet. Via the link you can paste their wallet and check by yourself if you sent it to the correct address. If it says confirmed they have received it for sure.
If this doesn't help you can directly contact the app support.


text:
address format is different from bitcoin core response from btcd
For now, I'm generating WIF and address using golang btcutil package programmatically.
    wif, err := btcutil.NewWIF(privateKey, conf, false)
    if err != nil {
        return nil, err
    }
    strPrivateKey := wif.String()

    // Address
    address, err := child.Address(conf)

    walletKeys[i] = WalletKey{WIF: strPrivateKey, Address: address.String(), EncodedAddress: address.EncodeAddress()}

After generating wif, I import this wif using bitcoin client importprivkey
err := b.client.ImportPrivKeyRescan(privKeyWIF, label, false)

And then, I make sure this private key is added into wallet using getaddressesbyaccount "label" command.
Somehow listed address and first generated address seems different.
I'd like to know why it's different.
Thanks in advance.

Addresses are hashed and encoded pubKeyScript. There are different types of address you can derive per a single public-key (or say also private-key). Most prominent ones are P2PKH, P2SH-P2WPKH, native P2WPKH (bech32).
I expect that the address type you are deriving from BTCD is different then the one your getting from Core.
Since a Core 0.16 (until now time of writing Aug 2018), the default address derivation format is "p2sh-segwit" (P2SH-P2WPKH, starting with 3). I could imaging that BTCD still derives you P2PKH addresses (starting with 1).
Since 0.16, Core has that addresstype argument where you can pass in "legacy" or "bech32" in order to generate either traditional P2PKH addresses or new Bech32 ("bc1...") addresses

I found that cause.

wif, err := btcutil.NewWIF(privateKey, conf, false)

That third parameter is compress and it should be true.
In the ends, generated address by golang and shown on bitcoin core after importprivkey command was matched.
Thanks!


text:
Is there authoritative documentation on how to generate a P2WPKH address?
I Googled and found some BIPs but looking through bitcoincore.org, I could not find documentation on the process to generate a P2WPKH address.
Looking through other random articles, I see the process is roughly something like:

Start with a compressed public key
Perform SHA-256 followed by RIPEMD-160 hashing on it
Add a witness version byte
Encode using Bech32

Again, these are just random internet articles so not authoritative and may be missing steps and/or important details.
So where can I find something authoritative? If a source doesn't exist, how is one meant to implement the steps required to generate?

BIP141 and BIP173 should provide a complete specification on how to create and encode P2WPKH outputs. If there isn't a specific problem you're facing, your question might get closed for being too vague.

@VojtěchStrnad Thank you. I think I did read one of those but couldn't formulate the complete picture. Maybe the other has the missing info I need. Will take a look.

Here it is, with links to BIPs: https://en.bitcoin.it/wiki/Bech32

Thanks. I should've mentioned, I did read through that before I posted the question, but wasn't sure on the site's authoritativeness. Any thoughts?

Native segwit version 0 outputs are specified in BIP 141. The address format for native segwit version 0 outputs is specified in BIP 173.
The BIPs include specifications of the respective standards, link to reference implementations, and either provide test vectors (BIP 173) or include tests in the reference implementation (BIP 141).


text:
Other users' coins instead my own?
I found some advices about anonymity, however one sentence is unclear for me
The quote comes from https://en.bitcoin.it/wiki/Anonymity

The protection that this method offers is significantly reduced if you are trying to anonymize more than about 10% of the total number of Bitcoins that the eWallet service holds. You'll end up getting your own coins back instead of other users' coins. Withdrawing Bitcoins more slowly and in smaller increments will help reduce this problem. Sending coins to an eWallet service in the largest single transfer possible will also help.

I don't get idea of "your own coins" - as far as I know there is no "coin" as an identifiable whole, just a log of transactions which balances as ones "bitcoins amount". What was the author intent to express by this sentence?

Yes, you are right. There are no "coins". There is only an ability to write some data (transactions) into one global file (blockchain).
But it is possible sometimes to track who is an author of transaction. For example, I am buying something in online shop (with delivery) and paying bitcoins for it. Now the shop knows my name and my address (for postage). The spending transaction has a "change address". If I use the same address for change - the shop owner would also know (with some probability) the amount of bitcoins in my wallet! Some people may think that this is not good, especially if they have large amount of funds.


text:
BitcoinJ seems to be calculating balance incorrectly
My application is using bitcoinj-0.11.3. I am using Wallet.getBalance(balanceType) to read wallet balance.

For AVAILABLE I get 8.94106037
This is supposed to include all confirmed transactions.
For ESTIMATED I get 22.43822671.
This mode assumes that all of the transactions in the memory pool are included into the blockchain.

Knowing my transactions this looks inaccurate as confirmed by blockr which indicates a balance of 24.48442767. Note that this doesn't include unconfirmed transactions.
So, there are two inaccuracies here:

22.43822671 vs 24.48442767
AVAILABLE shows ~9 when it should show ~24.

While blockr balance seems right my funds keep in pending state. I suspect that wallet balance calculation is somehow wrong.
[Edit]:
Might also help the output of Wallet.toString :
Wallet containing 22.43822671 BTC (available: 8.94106037 BTC) in:
  5 pending transactions
  79 unspent transactions
  390 spent transactions
  0 dead transactions

I think this also answers to Nick question that I am not scrambling numbers while converting the BigInteger.

I notice that getBalance returns a BigInteger. Are you converting this into a float at any point? That might be the cause of the minor innacuracy.

People occasionally use testnet to test large block chain reorganizations (reorgs), sometimes creating forks of 2,000 blocks or more.  Those reorgs break lots of software.  It might be worth backing up your data directory and then telling BitcoinJ to rescan for transactions from its earliest key-creation date---if a reorg created the problem, that should fix it.  (If that works, let me know and I'll turn this into an actual answer.)


text:
Calculating the mining profitability of Novacoin
I've been researching altcoins and keep coming across some staggering figures. I think it's just too early to do math, but if I were to farm novacoins for example calculator here and I have pretty much no cost (0 power and 0 hardware), my rig can run 500-600 Mhash/s (aka 500,000-600,000khash/s since that's what the calc uses), lets ignore difficulty increase. The calculator says I can make ~$100 PER DAY. This can't be right, can someone figure out what I'm doing wrong here?

Closely related: How much Bitcoin will I mine right now with hardware X?

Well it sort of is related but with the difficulty right now it's not logical. Im mostly trying to figure out if I flubbed my math, am crazy, or should quit my day job.

NVC uses Scrypt as it's hashing algorithm, like LTC. If that 500-600 MH/s figure is for Bitcoin, your speed will be significantly lower for NVC.

I edited it for you. I should note that my hardware is still rated for about 500 Mh/s according to the litecoin wiki.

There is nothing in the Litecoin wiki list https://litecoin.info/mining_hardware_comparison that does 500 Mhash/sec. The entries in that table are in Khash/sec and the largest entry is 1500. I bet your machine actually does 500 Khash/sec meaning you will earn about 10 cents per day.

Then, I guess we could delete this, as it is too localized and unlikely to help anyone else?

If you already have the hardware and do not pay for your power consumption, then it follows that you would always have 100% profit. If you pay for your own power consumption, you need to be aware that performing mining calculations all day will significantly increase your computer's power usage in comparison to being idle.
I haven't checked the validity of the calculator, but you can calculate your potential mining yield from your mining power and the current difficulty.
Check out this answer on How much Bitcoin will I mine right now with hardware X? for a formula.
Then, it depends on whether it is actually possible to sell the coins that you gained (whether there is a market for it), and whether the above information is acurate, otherwise, it might well be possible to make a good amount of money mining altcoins.

I'm just finding it hard to believe that I can make $100 per day with my 270x. I'm at work and forgot to set up teamviewer this morning, but I'll try my hand at mining altcoins tomorrow/later tonight.


text:
What are the analogous steps between transfer of value from buyer to seller with traditional P.O.S. solutions vs. with bitcoin
Recently I built a site that allows purchase of items with bitcoin, also paypal and credit cards.  In testing I haven been struck by how different the experience of purchasing online with bitcoin is vs. traditional methods. It takes much longer from the point of confirmation of sale to the "acceptance" of the payment (the point after which the workflow can move on to fulfillment).  It also takes more user input and action.  It's difficult on the surface of it to understand how this can be the case when transferring value from one person to another seems so much quicker and easier than traditional alternatives.
It occurs to me that part of the difference may be due to fundamental differences in what is taking place. Is a credit card transaction directly analogous to a bitcoin transaction, or instead does a credit card transaction only match a bitcoin transaction considered along with the bank and other transfers on either end of it? Are there other differences or considerations to make when comparing the two experiences procedurally?  I am unsure.
Coming up with strongly analogous steps between these two procedures of transferring value from a buyer to a seller might reveal choking points/areas of improvement for Point of Sale with bitcoin or highlight the differential value of bitcoin's approach.
So what are the analogous steps between the two experiences?

For example, you might consider waiting for confirmations of a Bitcoin transaction to be analogous to waiting for the chargeback time limits to expire for a credit card transaction.  That is the time after which you can be confident that the money is absolutely yours.  Given that, in some cases, credit card transactions can be charged back over a year later, Bitcoin's 1-hour timeframe no longer seems so bad.

On another note, I'm unclear what "human interaction" you refer to as part of a Bitcoin transaction.

One difference in the chargeback period and confirmations from the perspective of the purchaser is that delivery of the good or service is not held back until the chargeback period's completion. So maybe there's an opportunity to go ahead and continue the workflow before the first confirmation? I guess as it's only an hour, delivery won't often take place before there's an opportunity to correct orders with transactions that don't confirm. It's really just a matter of whether the user facing status says "payment received" for that time period. That doesn't seem like a big deal. Thanks!

Human interaction should more properly be "user actions and input".  And the big problem isn't that there is significantly more user action and input, it's more that it's further spaced apart I think.  With a credit card, there can be as few as three fields to fill out and one button press immediately after and the process is done. I can see instantly that my payment is reflected and my product will be delivered.

Same thing with bitcoin? I'm presented a 32 character code to copy. Then I have to go to my desktop and open an app (or go to a website and sign in) to access my wallet. Take 5 min downloading missed transactions. Paste in the address. Go back to the browser and copy and paste the total cost. Send the transaction. Maybe wait an hour for confirmation (though maybe not anymore ;} ). OK the payment should have posted, but how often does the website check? Wait another 5-10 for the website to reflect it. OK finally, we can see the updated order status.

Unless we are talking big purchases, I think it would be more usual to have a sufficient amount on a lightweight wallet on your phone. Then it is 1) scan the presented QR code, 2) check amount and recipient, 3) press send. Which to me is actually less work than 1) fish your credit card from your wallet,  2) enter name, copy cc number, end date, security code, 3) enter verified by Visa password. ;)

I think the answer is that a credit card company is vouching for you when you make a purchase. The seller does not know you, but they know the credit card company, and they know the credit card will give them their funds. The credit card company in turn knows you, and has deemed you credit-worthy. This is why it's called "credit" ... from the latin credere: "to believe" or "to trust". The credit card company believes that you will pay your bill at the end of the month.
Bitcoin is like cash... except that handing over physical cash takes a fraction of a second, but handing over digital cash takes approximately 10 minutes in the case of bitcoin (less with alt coins that add to their block chains at a faster rate).
The seller could decide that if this is a repeat customer (who has bought successfully with bitcoin once or more times before) to extend credit themselves, and just assume the transaction will be validated. Then, at the time of sale, the transaction will be just as quick as a legacy credit card transaction would.
Some alt coins are building in reputation via marking (such as Bitmark) which will go a long way towards allowing sellers to make immediate credit decisions even from buyers new to them. I think this is somewhat analogous to a built-in FICO score for a particular wallet.

I agree with this, I would go beyond and say that maybe "extending the credit" should be the default action if possible. Kind of a "blacklist" rather than "whitelist" approach, where so long as you are not high risk for trying to double spend (or any other offense that can take place before confirmation--excuse my ignorance here) you go right through checkout and fulfillment workflow, how this "high risk" determination would be made, I do not know and would like to hear opinions.
I think I will implement this on one of my dogecoin sites and see how it goes.

block.io seems to have a whitelist to attack this problem. as long as an address is a "greenaddress" (on the whitelist) coins sent from it can be used on receipt. Virtually instantly.  This is a novel approach to this problem.


text:
Error validating transaction: Transaction orphaned, missing reference (TESTNET)
RAWTRANSACTION HEX

02000000000101ccfa268b70e83439c7d7e0cedf5c17b0446ec514e4e890af468cbf0179b278b200000000220020df63ee1a6210873eeb7d10e286a0fad13a7982fe685d35fa0c2d5a915f4a52f9ffffffff01606d0000000000001976a9146a231411dfa9f88dd3f0e3e2ee3d68ef90c3930a88ac011b0a28c30fb9118ed1da72e70ac4f89c0164756e8a021d517577768800000000

DECODE.
Decoded Transaction
{
    "addresses": [
        "2NFS3VQLTMALkZzDh1zP7X4XF1K5mfjMJ6F",
        "mqC9wgGY254enSQKhDbtdtuGWLXKfHWBQQ"
    ],
    "block_height": -1,
    "block_index": -1,
    "confirmations": 0,
    "double_spend": false,
    "fees": 1000,
    "hash": "b8a8af826dd000035ab4387b4e9f8351a3e2f2b2115a048ac86866a1302a6530",
    "inputs": [
        {
            "addresses": [
                "2NFS3VQLTMALkZzDh1zP7X4XF1K5mfjMJ6F"
            ],
            "age": 2582025,
            "output_index": 0,
            "output_value": 29000,
            "prev_hash": "b278b27901bf8c46af90e8e414c56e44b0175cdfcee0d7c73934e8708b26facc",
            "script": "0020df63ee1a6210873eeb7d10e286a0fad13a7982fe685d35fa0c2d5a915f4a52f9",
            "script_type": "pay-to-script-hash",
            "sequence": 4294967295
        }
    ],
    "outputs": [
        {
            "addresses": [
                "mqC9wgGY254enSQKhDbtdtuGWLXKfHWBQQ"
            ],
            "script": "76a9146a231411dfa9f88dd3f0e3e2ee3d68ef90c3930a88ac",
            "script_type": "pay-to-pubkey-hash",
            "value": 28000
        }
    ],
    "preference": "low",
    "received": "2024-03-15T05:08:37.0168363Z",
    "relayed_by": "3.238.117.234",
    "size": 150,
    "total": 28000,
    "ver": 2,
    "vin_sz": 1,
    "vout_sz": 1,
    "vsize": 127
}

unlocking script is 0a28c30fb9118ed1da72e70ac4f89c0164756e8a021d5175777688
witness
0020df63ee1a6210873eeb7d10e286a0fad13a7982fe685d35fa0c2d5a915f4a52f9
can someone please help me to fix this ?

Transaction orphaned, missing reference

I suspect your prev_hash is wrong, maybe you used the wrong endianness?
Related: https://github.com/bitcoinjs/bitcoinjs-lib/issues/1332

Update after further information:

i build the transaction on [...] bc-2.jp/tools/txeditor2.html

I suggest checking the items I have marked with arrows

i build the transaction on this site. @redgrittybrick
bc-2.jp/tools/txeditor2.html
the txid is 078ad0a16bc2eaf304ce27655a5d6a013b5243327fcb2b4791395b8b79076d8c

@Tepan: see updated answer.

i make by hands using new unlocking script
Base58 address 2N7g6hoqwLo7KRgUNJTJFMXsx6jsJZk5D8C
Redeem Script Hex 51040928a14851
Redeem Script Asm OP_1 0928a148 OP_1
Redeem Script Hash Hex 9e4614600a7607b3f1de255dec5fd98bf62b822b
ScriptPubKey Hex a9149e4614600a7607b3f1de255dec5fd98bf62b822b87
ScriptPubKey Asm OP_HASH160 <9e4614600a7607b3f1de255dec5fd98bf62b822b> OP_EQUAL

010000000158c8ec75419da95ffb2b72ebb57c814b3ab2575d95db3541c9a7fcf8207b86b6000000000751040928a14851ffffffff01d0010100000000001976a9146a231411dfa9f88dd3f0e3e2ee3d68ef90c3930a88ac00000000
still same..
Error validating transaction: Transaction 87a9646b64b384d7fb2ec7ea842796f2ddb59ccc064b8946f273639f5f890287 orphaned, missing reference b6867b20f8fca7c94135db955d57b23a4b817cb5eb722bfb5fa99d4175ecc858.
can you help me to spend that fund (tesnet TBTC) ?


text:
Can you generate password from a decrypted and encrypted bip38 keys?
I made 5 bip38  wallets on bitaddress.org all with the same password.  all the keys generated started with number 6.
I loaded bitcoin on to each of these addresses , and later decrypted one of them with the key and password, which gave me the key starting with number 5, so I then swept the address.
A few months later I forgot the password with bitcoin still on the other addresses. I still have the key starting with 6 and the key starting with 5 for the wallet I decrypted, so would I be able to somehow use these keys to generate the password? Its not much btc but I could do with the cash now. any ideas anybody?

I think you are effectively asking whether there is a "known plaintext attack" on AES256.
A quick Google search suggests there isn't.


text:
What is the largest value that the x & y coordinates respectively can be/reach
We are all familiar with the x & y coordinates of the curve parameters used in bitcoin (or at least we should be).
In terms of being a collective point on graph, we know that the starting point G is also used as a limiting point when carrying out ADDITION & DOUBLING operations... We also know that our graph is a finite curve with it's limits set to G as well.
My Question is, Is there a maximum point X and Y can individually reach?
And if there is, What is the highest point that the X & Y coordinates can reach?

It is easy to find the largest integer solutions to the curve equation y2 = x3 + 7 mod p, where p = 2256-232-977, by simply trying numbers from high to low until you hit a solution.
The highest possible X coordinate is p-3, in point (115792089237316195423570985008687907853269984665640564039457584007908834671660, 109188863561374057667848968960504138135859662956057034999983532397866404169138).
The highest possible Y coordinate is p-1, in point (92132010145575487545665274145875605628664750442204984300260952401046764123763, 115792089237316195423570985008687907853269984665640564039457584007908834671662).
We cannot possibly compute what the corresponding private keys for these points are. Doing so would amount to breaking the discrete logarithm problem.

Glad to see you're still up and running. Thanks as always for your insightful & easy to understand responses.

And what if the Discrete Logarithm Problem is broken... Would it be such a bad thing? I mean I know a lot of digital security & financial data (if not all) rely on these yet to be broken algorithms, but still I'm sure the algorithm to break our standard would open new doors into advanced technologies.

The security assumption that underlies Bitcoin's transaction signing scheme is that the discrete logarithm for the secp256k1 curve is computationally infeasible. In theory, of course developments or breakthroughs can happen that break it, but since that would let whoever has access to such an algorithm take any BTC they want, I'd say that yes, that would be a bad thing.

But my comment above wasn't about whether that would be good or bad, just that it is extremely unlikely to have already happened. There is an extremely large incentive to break the DL for secp256k1 (taking any BTC). If someone could break it, with today's technology and computation power, they would.

True, I guess it would be bad.. But what if they limited what they took to the btc's most likely owned by the assumed Satoshi? Or perhaps even Satoshi himself (on demon time) having a back door decides to have a go at some btc's.. I know the latter would be devastating but the former doesn't seem that bad

Looking more closely, it doesn't look like those X and Y coordinates are p-2 and p-7 respectively. Specifically, the first X coordinate looks like p-2^32+3533. Are you sure it's correct?

@VojtěchStrnad Ehh, you're right. I must have made a typo when computing these. Fixed, I hope?

@AncientTides Even a credible possibility that someone can break the secp256k1 discrete logarithm problem would be devasting to Bitcoin. How could whomever holds this knowledge be trusted to only use it in some subjectively-defined "good" way? The whole point of Bitcoin was not to have to trust anyone to make the right decisions like this.

@PieterWuille Looks good now, thanks.


text:
Various caches are defined in the Bitcoin source code. What do these caches refer to?
The source code is as follows：
//! -dbcache default (MiB)

static const int64_t nDefaultDbCache = 450;

//! -dbbatchsize default (bytes)

static const int64_t nDefaultDbBatchSize = 16 << 20;

//! max. -dbcache (MiB)

static const int64_t nMaxDbCache = sizeof(void*) > 4 ? 16384 : 1024;

//! min. -dbcache (MiB)

static const int64_t nMinDbCache = 4;

//! Max memory allocated to block tree DB specific cache, if no -txindex (MiB)

static const int64_t nMaxBlockDBCache = 2;

//! Max memory allocated to block tree DB specific cache, if -txindex (MiB)
// Unlike for the UTXO database, for the txindex scenario the leveldb cache make
// a meaningful difference: https://github.com/bitcoin/bitcoin/pull/8273#issuecomment-229601991

static const int64_t nMaxTxIndexCache = 1024;

//! Max memory allocated to all block filter index caches combined in MiB.

static const int64_t max_filter_index_cache = 1024;

//! Max memory allocated to coin DB specific cache (MiB)

static const int64_t nMaxCoinsDBCache = 8;

I have 5 questions.

What do these caches represent?
What is the relationship between UTXO cache and these caches?
What is the relationship between levelDB's own cache and UTXO cache?
What is the current UTXO cache size?
What does the memtable in levelDB correspond to in the Bitcoin system?


text:
Will BTC script be Turing complete in future?
I want to know if BTC script will have loops in it in the future?

Turing completeness includes the capability to run programs that might not terminate or that might terminate after a very long time. This would cause the blockchain to stall, hence it is a must to keep the number of instructions to be run predetermined (like BTC) or to be run according to a budget (like ETH).

it is impossible to determine whether a program will ever halt. – This is a common misconception. The halting problem states that there exists no algorithm which can determine for any program with all possible inputs if it will eventually halt. But there are techniques to prevent infinite loops and the like for arbitrary programs. See for example the Linux kernel eBPF verifier.

@forest Thank you, removed the misconception

@user253751 Then Script is currently Turing complete colloquially?

@user253751 Craig Wright described a systematic way of creating loops using TOALTSTACK. I can't find that paper anymore online however I have a copy of the PDF if it's useful for you.

Bitcoin itself will never itself offer any kind of Smart Contract functionality, like the Turing complete EVM. Rootstock (RSK) however, is smart contracts platform (turing complete programming) that works alongside Bitcoin to offer the same functionality. It's been in development for some time and I suspect now it will integrate with Lightning, and thus work very well. I haven't tried it out though. https://www.rsk.co/Whitepapers/RSK-White-Paper-Updated.pdf


text:
Does the future SIGHASH_ANYPREVOUT capability hurt the privacy of Taproot lightning channels?
One of the advantages I've heard about Taproot is that all transactions will appear identical to a blockchain observer. This would of course also be true for lightning channel open/close transactions as well which would be a great privacy benefit for lightning users.
For what I understand of the proposed ANYPREVOUT upgrade, it will build on top of Taproot but will need to use a different length pubkey. Would it be possible for an observer to scan the blockchain for this pubkey length in order to determine which transactions are using ANYPREVOUT, and are therefore likely to be lightning related? Or is it possible to somehow hide this inside Taproot in such a way that privacy can still be maintained?

The foundation of a channel is a multisig output which can't be distinguished from other outputs when using musig and taproot.
The mutual channel close is just a regular tx spending this output so I'd say it'll be hard to detect this as a lightning Chanel without other data (similar as with current channels)
However the unilateral close is different and leaves a footprint of the channel state. I think the update transaction that is used to kick of the settlement tx might have the detectable structure that you have been referring to. (I'd actually like to ask you for your source)

I'm aware of the limitations in current Taproot proposal in the event of a non-cooperative close. What I'm wondering though is if anyprevout would impact even the cooperative case since it is proposed to use a different pubkey length? Unless I'm misunderstanding something (most likely) then it seems like anybody using the Eltoo protocol with anyprevout would have their channel operations easily visible onchain. My source for the pubkey length difference is this snippet from AJ Towns on the Stephan Livera podcast: https://youtu.be/8S7D_FdZfE8?t=2978

I think the update txs use anyprevout but in the case of the mutual close it will just be a regular spend as mentioned without the need of anyprevout. (There won't be any update tx in the mutual close as partners can negotiate the spend from the funding TX directly - unless I am missing something, which also could happen.

Ok interesting. So in that case the use of anyprevout for eltoo would only be visible if the channel was closed unilaterally? That's more like the original Taproot assumption. If simply scanning the chain for 33 byte pubkeys is possible then eltoo doesn't seem to have much privacy despite the scaling benefits it can bring


text:
python-bitcoin-utils - sendrawtransaction RPC error: {"code":-25,"message":"bad-txns-inputs-missingorspent"} when trying to broadcast my tx?
I am trying to create a bitcoin transaction to send all of the funds from tb1qj6zz96g8xgrwpgmdlvmkrjlwzz54sf47086yc9 to tb1qxgm8j0cq7tnftef3t563psl56gtmzxanm5c9uy. tb1qj6zz96g8xgrwpgmdlvmkrjlwzz54sf47086yc9 has 0.00036698 btc as shown on this block explorer, https://blockstream.info/testnet/address/tb1qj6zz96g8xgrwpgmdlvmkrjlwzz54sf47086yc9.
I have this script to create a bitcoin transaction:
from bitcoinutils.utils import to_satoshis
from bitcoinutils.setup import setup
from bitcoinutils.transactions import Transaction, TxInput, TxOutput
from bitcoinutils.script import Script
from bitcoinutils.keys import PrivateKey as utilPrivKey
from bitcoinutils.constants import SIGHASH_ALL, SIGHASH_ANYONECANPAY

setup('testnet')

# private key for tb1qj6zz96g8xgrwpgmdlvmkrjlwzz54sf47086yc9
priv = utilPrivKey.from_wif('PRIVATE KEY FOR SENDING ADDRESS')

pub = priv.get_public_key().to_hex()
addrs_for_script = priv.get_public_key().get_address()

# private key for tb1qxgm8j0cq7tnftef3t563psl56gtmzxanm5c9uy
recPrivKey = utilPrivKey.from_wif('PRIVATE KEY FOR RECEIVING ADDRESS')

# This UTXO has 0.00009839 btc
txin1 = TxInput("102172a062da813c3aa8cc2fb3d523cf2db300e54cd680c2129c23c97db9dd8e", 0)

# This UTXO has 0.00026859 btc
txin2 = TxInput("b3fcae0b28b387475a123c056298aec0ba3759cd019f9d0975f5af0874f395ff", 1)

addr = recPrivKey.get_public_key().get_segwit_address()
addr_non_seg = recPrivKey.get_public_key().get_address()

# the script code required for signing for p2wpkh is the same as p2pkh
script_code = Script(['OP_DUP', 'OP_HASH160', addrs_for_script.to_hash160(),
                        'OP_EQUALVERIFY', 'OP_CHECKSIG'])

# remaining 0.00005 is tx fees
txout = TxOutput(to_satoshis(0.00031698), addr.to_script_pub_key())

# create transaction from inputs/outputs -- default locktime is used
tx = Transaction([txin1, txin2], [txout], has_segwit=True)

txsign1 = priv.sign_segwit_input(tx, 0, script_code, to_satoshis(0.00009839), SIGHASH_ALL | SIGHASH_ANYONECANPAY)
tx.witnesses = [ Script([txsign1, pub]) ]

txsign2 = priv.sign_segwit_input(tx, 1, script_code, to_satoshis(0.00026859), SIGHASH_ALL)
tx.witnesses.append( Script([txsign2, pub]) )

signed_tx = tx.serialize()
print("raw tx below this line")
print(signed_tx)
print("raw tx above this line")

So why is my script not working? Below is the signed transaction that my code spits out:
020000000001028eddb97dc9239c12c280d64ce500b32dcf23d5b32fcca83a3c81da62a07221100000000000ffffffffff95f37408aff575099d9f01cd5937bac0ae9862053c125a4787b3280baefcb30100000000ffffffff01d27b0000000000001600143236793f00f2e695e5315d3510c3f4d217b11bb302473044022079fd0fe64aef8599bbac5283058c0c1cf1964ef28a40caf3c26ee809d00b82f30220678e83dc39f6cd219159a4d289353be66ef7b18a00ff6f4a77f466991ca13e3e81210279b144f9caaea4f7619baf6a431caa5939db1d8894fa85c721829e1d4ac31d8d0247304402202857ee846e750dc6aea5b326c22e570a495e255e1b67511d5a2981205da69a0b02201980773e1fa733495f605eba9151a10e194ff8dfe8155f93ac8140fcac6ac43c01210279b144f9caaea4f7619baf6a431caa5939db1d8894fa85c721829e1d4ac31d8d00000000
But when I put it into https://blockstream.info/testnet/tx/push to broadcast it, I get sendrawtransaction RPC error: {"code":-25,"message":"bad-txns-inputs-missingorspent"}

This error message bad-txns-inputs-missingorspent mean that one of your transaction input are either spent or not found in the UTXO set, but there is a few error in your code, you are using the same private key for both inputs, use the correct one for both input, you used priv each time, and also since you are using P2WPKH you dont need SIGHASH_ANYONECANPAY.
Here would be a corrected version of your code:
from bitcoinutils.utils import to_satoshis
from bitcoinutils.setup import setup
from bitcoinutils.transactions import Transaction, TxInput, TxOutput
from bitcoinutils.script import Script
from bitcoinutils.keys import PrivateKey as utilPrivKey
from bitcoinutils.constants import SIGHASH_ALL, SIGHASH_ANYONECANPAY

setup('testnet')

# private key for tb1qj6zz96g8xgrwpgmdlvmkrjlwzz54sf47086yc9
priv = utilPrivKey.from_wif('SENDING WALLET PRIV KEY')

pub = priv.get_public_key().to_hex()
addrs_for_script = priv.get_public_key().get_address()

# private key for tb1qxgm8j0cq7tnftef3t563psl56gtmzxanm5c9uy
recPrivKey = utilPrivKey.from_wif('RECEIVING WALLET PRIV KEY')

# This UTXO has 0.00009839 btc
txin1 = TxInput("102172a062da813c3aa8cc2fb3d523cf2db300e54cd680c2129c23c97db9dd8e", 0)

# This UTXO has 0.00026859 btc
txin2 = TxInput("b3fcae0b28b387475a123c056298aec0ba3759cd019f9d0975f5af0874f395ff", 0)

addr = recPrivKey.get_public_key().get_segwit_address()
addr_non_seg = recPrivKey.get_public_key().get_address()

# the script code required for signing for p2wpkh is the same as p2pkh
script_code = Script(['OP_DUP', 'OP_HASH160', addrs_for_script.to_hash160(),
                        'OP_EQUALVERIFY', 'OP_CHECKSIG'])

# remaining 0.00005 is tx fees
txout = TxOutput(to_satoshis(0.00031698), addr.to_script_pub_key())

# create transaction from inputs/outputs -- default locktime is used
tx = Transaction([txin1, txin2], [txout], has_segwit=True)

txsign1 = priv.sign_segwit_input(tx, 0, script_code, to_satoshis(0.00009839), SIGHASH_ALL | SIGHASH_ANYONECANPAY)
tx.witnesses = [ Script([txsign1, pub]) ]

txsign2 = priv.sign_segwit_input(tx, 1, script_code, to_satoshis(0.00026859), SIGHASH_ALL)
tx.witnesses.append( Script([txsign2, pub]) )

signed_tx = tx.serialize()
print("raw tx below this line")
print(signed_tx)
print("raw tx above this line")

Awww so close. I think you're misunderstanding what the second private key is being used for. The first private key is using 2 UTXOs to send to the address of the second private key. I could have used an address instead of a second private key. Anyway this is my code that worked in the end. You can incorporate this into your answer and maybe improve the code if you want and I'll mark it accepted https://gist.github.com/ChristianOConnor/24c0eed382bd85603d9b560a933df45d.

Alright, I modified my answer with your code


text:
How do wallet developers earn money?
Does anyone know how the Bitcoin wallet developers earn money?
Do they live on only donations? Is it possible to survive on only donations?
Why would they develop wallets if they don't make any profit from it? :)

Are you asking about the people who develop the core client, or people who make alternative clients?

I am asking about online wallets :)

You should know that lots of things in life come for free. Specifically when it comes to software, lots of professional developers would rather develop things "their own way" for free, instead of getting paid and "being forced to do it". Most open source developers also simply enjoy the act of creating things. They're engineers and scientists that care more about people using their inventions, rather than an economical compensation.
However, as you say, at the end of the day developers have to eat and pay the bills too. If I remember correctly the MultiBit developers will add an option to automatically send a portion of the fees you use for transactions towards themselves. However, I've read this news on some blogs and not directly from the MultiBit developers: http://www.coindesk.com/cash-strapped-multibit-developers-charge-transaction-fee/
But at the end of the day, if you're a developer of a famous bitcoin wallet, you'll have no problems finding a job to earn some money. So money isn't really an issue for most of open source developers. I'd argue that money would actually poison the open source philosophy. You're more in it for the act of creating, for the reputation and fame, for the feeling of doing something nobody has ever done before.

Some developers don't make money from making some open source projects - but they can always use it to showcase their portfolio to get hired to some company.
Android Bitcoin Wallet is earning money from donations.
Blockchain info recieved about 30.5 M funding to invest in growth - they are building a brand and maybe that can offer some consultancy to other bitcoin startups.
Xapo - they are making money from fees on bitcoin to debit card conversion.
Coinkite sells bitcoin cards and terminals and make money from withdrawals from merchant accounts.


text:
Why does ScriptSig contain public key, since it can be recovered from the signature and message?
Using ECDSA, given a signature and the message signed, it is possible to recover the public key. So it seems to be a waste of up to 65 bytes in each transaction. Why does bitcoin do it? Which cryptocurrencies use the key recovery approach?

it is possible to recover the public key

Yes. But this operation is slow (comparing with other bitcoin script operations). May be Satoshi Nakamoto did not know about it. Anyway, the hard-fork required to implement it. So, you are welcome to create hard-fork or altcoin with this feature implemented.
Have a look to this discussion: https://bitcointalk.org/index.php?topic=6430.0 I can not explain better