text:
What is the source of 1 Satoshi transactions from suspicious addresses (1Sochi.. for e.g.)
I can't link to one on block chain because are never confirmed, one example from my wallet software:
6dd2861a4f6d025742f6306588f2929f476e8f3b2d25c1487cc245e0a402675c: Seen by 1 peer. Pending/unconfirmed.
     from 1SochiWwFFySPjQoi2biVftXn8NRPCSQC / 3c462f4626dd2fa8e802a5b476f206e9133a69c0bb47b1454b7c44b385d93a92:0
       to 1HULKKRbsP9TcLZcokZ7XHJL1Bf1a2jH3k 0.00000001 BTC
       to 1P2G2EP3c1PvXcn5ZpmYZvR5KkAdYNeYXb 0.00000001 BTC
       to 13d5SNKqE9Q94osrZNZfzRjUTuyBRJECbT 0.00000001 BTC
       to 1fMS4VF4bZvv9WcU8PPP9VVHto3tyfdan 0.00000001 BTC

... etc

Could you edit down your answer to 2-4 lines?

yes, I have seen these on an address that I own as well

Yes, I see them, not that you have compiled them in this pulpy mass for me to see.
However I do not see what is suspicious about these addresses, nor their various splashings about.
They look like the playful work of some bored young men.


text:
How do I lookup Blockchain sizes for crypto-currencies like Litecoin and Dogecoin?
I am new to mining cryptocurrencies. I am planning to set up a wallet for both Litecoin and Dogecoin. I am just curious on asking what are the current total blockchain sizes of both coins? This is to prepare me to download them ahead of time.

This question appears to be off-topic.

Could be improved to read "How can I know in advance the total blockchain size of a crypto-currency, at any single point in time, without having to install the client and wait for the blockchain to download?" In which case it'd be much more useful and less time- and coin- dependent

Bitinfocharts.com lists stats for the main cryptos including the block chain size. You will find "Blockchain size" near the bottom.

It is hard to locate that webpage in the internet searches. I found it faster from stack results :V

You can go to http://block-explorer.com/ and http://dogechain.info/ to see the latest number of each currency. In each blockexplorer the latest block is in the first row so you can see the total amount of blocks from the id of this block.
As of now(25th Dec. 2013) Litecoin is roughly 500000 blocks and Dogecoin 30000 blocks.
From an estimation of my dogecoin wallet the average block is about 30 MB (based on 2,4 GB data and 77000 blocks) but it highly depends on the current amount of transactions.

He asked for the size of the blockchain. Not the number of coins in circulation.

What do you want? On that date there were 30000 doge BLOCKS and 500000 litecoin BLOCKS. The amount of coins at that time was much higher considerring that one block of doge is 1000000 doge. I don't see a problem and no real reason to downvote my answer. The only thing he could have wanted would be the size in bytes but this is not what you are complaining about.

Please edit your answer, it's not clear: it seems you're answering the number of "coins" for each crypto-currency rather than "blocks". If you could providea screenshot or slightly more info in the text, it'd be way better (y). And much, much better, should you add a formula to translate the # of blocks to the bytes size on harddisk, even if just approximately

I understand your comment and tried to improve my post but I do not think it is that hard to look at a table that you have to include a screenshot as a help.

https://bchain.info/LTC/ has blockchain size in lower right hand corner.

source: Stack Exchange

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

authors: วิโรจน์ ชมเชย

sort: votes


text:
How long will it take for OpenCoin to distribute the 50 billion XRPs?
Out of the 100 billion XRP that can ever exist, the founders kept 20 billion while OpenCoin received the remainder of 80 billion. From that 80 billion OpenCoin will sell 30 billion to fund ongoing development beyond the initial angel investment, and the remaining 50 billion will be given away to spur adoption.
How long will it take OpenCoin to distribute the remaining 50 billion? One year from now, how many XRP will OpenCoin give away to each unique new user? What is the smallest amount that OpenCoin will eventually give away, over time? If there is no specific answer to the time, can OpenCoin provide a range (for example, between 5 and 50 years)? Is there a reasonably estimable lower limit on the time required to give away the 50 billion? Is there an upper limit on how much will be handed out (i.e. will anyone ever receive 50,000 XRP again as part of the giveaway)?
Answers, even if partial, appreciated.

possible duplicate of How will Ripples be distributed?

Definitely not a duplicate because neither of those questions asked what the smallest amount of XRP that will be handed out eventually. Is it 200? 500? Will it always be 10,000 or more?

The short answer is that nobody knows. In the short term, the rate of XRP release will be used to manage the network's growth. Once it transitions to a distributed network, that won't be an issue any more and it will likely then be limited just by how quickly we can give them away.

One year from now, how many XRP will OpenCoin give away to each unique new user? What is the smallest amount that OpenCoin will eventually give away, over time?...Is there an upper limit on how much will be handed out (i.e. will anyone ever receive 50,000 XRP again as part of the giveaway)?

@VinnieFalco: I can't say for sure, but I don't foresee it ever getting less than 500 or more than 50,000.

What would be some example circumstances where the amount of the giveaway would be raised to 50,000 again? Considering that now it's at what, 30,000 and falling (at a rate of 5,000 per week)?

@VinnieFalco: One would be if it proves to be more difficult than we expected to find enough people to give XRP to. But 50 billion over 50 thousand is only a million, so I would consider that unlikely. My guess is that it will probably be 5,000 - 15,000 for most of the giveaway. (I actually don't monitor the giveaway or take part in the discussions over the process except when it impacts the technical operation of the network. So I don't know as much about those plans as you might think I do.)

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


text:
Which transactions get into blockreconstructionextratxn?
Bitcoin Core has a cache for transactions that aren't in the node's mempool but could be in other mempools, and so are cached for improved compact block reconstruction. This cache holds up to 100 transactions by default and this number can be changed with the blockreconstructionextratxn configuration option.
What interests me are the inclusion and eviction criteria for this cache. Does it only hold transactions evicted from the mempool, or also transactions that were never accepted into the mempool due to policy? If that's the case, what policy does it use to prevent DoS attacks? And when the cache is full, how does it determine whether to include a transaction and evict another, and which one to evict? Is it based on feerates, first-in-first-out, or something else?

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


text:
How do Electrum/Sparrow/Caravan generate multisig addresses?
I'm trying to "manually" confirm the Bitcoin addresses that Electrum, Sparrow, and Caravan generate from a deterministic multisig addresses.
As an example, I have the following 2-of-2 wallet:
Seed words #1:
legal thumb play interest flash will lucky jar outdoor guard vendor found crucial develop spring valley example supply fortune pole right acid alert page

Seed words #2:
begin siege speak boat before mad solve dance lawsuit point machine cake tragic fiber waste equip loan syrup cloud credit shock choose chest finish

Using Ian Coleman's BIP39 Tool, I can confirm the Master Public Key (xpub) with the following steps:

Enter the seed words under BIP39 Mnemonic
Under Derivation Path, Select the BIP32 tab
Under BIP32 Derivation Path, enter m/45'/0 (for legacy multisig)
Copy the BIP32 Extended Public Key

The resulting xpub matches with what Electrum generates when entering those seed words as a 2-of-2 legacy multisig wallet. The example xpub's are:
Wallet #1 xpub:
xpub6B7nJf6xmWPjeVpdSwePjDmUJxRWSVf3vXu47AYKiLTyW7rPUyysKVU8TtRJ9VXtAVNHjx6EsueiE9Mw7JyP4dVhZjJF4ViVAJNaoZo49uw

Wallet #2 xpub:
xpub6Ab52xTpcFNYToaXBT6opdaqo18rKSYA3rnum4XuE8pLW9N748QJq1PP5z93KSfbpfMVRLqsYgZYwfNmzomqkw4kvopD1PuXS4DuNaY4ZBi

The first address in this multisig wallet is 3BWrS4WXB61sppUN7zxgAqxzjcSvML7jWC. When I enter those xpubs into Sparrow Bitcoin Wallet (with Script Type Legacy (P2SH) and Derivation m/45') I get the same address. Caravan also gives the same address.
My question is this: how do I "manually" generate that first Bitcoin address?
I've tried using Ian Coleman's Multisig Tool, Bitcore, coinbin Bitcoin Wallet, and the addmultisigaddress command from Bitcoin core. They all require "Public Keys" of the addresses from the two wallets. Where can I find/generate those Public Keys (preferably using some sort of browser-html or command line tool)? I've tried using the Public Key's generated at the bottom of the BIP39 Tool from above, but no combination of those keys in any of the tools results in the same generated address.

The full derivation path appears to follow BIP 45, but not quite exactly. The actual public keys are being generated from the xpub at the path m/45'/0/0. For the  first address, the derivation paths for the public keys will be m/45'/0/0/0. You can get these pubkeys using Ian Coleman's BIP 39 tool by going to the BIP 32 tab and entering m/45'/0/0 as the derivation path. Then scroll down to the derived addresses and select the first one.
You should see that the first pubkey from the first mnemonic is 03ae50de983900d2898d975cd71c8520c88da868acc434e259775ee58b5e4ce311 and the first pubkey from the second mnemonic is 03c2367af137659943c11ee02aa88ec9b2ca5b424183b8d3a6990db1907bc475ae. If you enter these into any multisig generating tool, you should get the address you are expecting.
For example, Bitcoin Core's createmultisig:
$ bitcoin-cli createmultisig 2 '["03ae50de983900d2898d975cd71c8520c88da868acc434e259775ee58b5e4ce311","03c2367af137659943c11ee02aa88ec9b2ca5b424183b8d3a6990db1907bc475ae"]'
{
  "address": "3BWrS4WXB61sppUN7zxgAqxzjcSvML7jWC",
  "redeemScript": "522103ae50de983900d2898d975cd71c8520c88da868acc434e259775ee58b5e4ce3112103c2367af137659943c11ee02aa88ec9b2ca5b424183b8d3a6990db1907bc475ae52ae",
  "descriptor": "sh(multi(2,03ae50de983900d2898d975cd71c8520c88da868acc434e259775ee58b5e4ce311,03c2367af137659943c11ee02aa88ec9b2ca5b424183b8d3a6990db1907bc475ae))#eq5t5j72"
}

Perfect. Setting the derivation path to m/45'/0/0 generated the public keys that match the address generated from Electrum, etc.

You are making multisig addresses, so the first thing to change is to select BIP141 not BIP32 tab.
Under BIP141, go to script semantics drop down menu. Select P2WSH 1-1 multisig.
Then manually adjust the derivation path just above.
You'll get 1 of 1 msig addresses below.
Use the Zpub give and enter into Electrum to generate a 1 of 1 msig wallet - not sure if Electrum allows a 1 of 1 msig wallet.
If not, you need to make 2 keys with Ian Coleman (that's one way of many), extract 2 Zpubs, ignore the addresses, make a 2 of 2 Electrum wallet with those Zpubs, print the addresses, make a duplicate wallet with those Zpubs using Sparrow or Specter, and finally compare the address list is identical to Electrum's.

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


text:
Derive Segwit Addresses From xPub or zPub using PYTHON
Summary
I'm pulling my hair out trying to understand a couple of concepts. I would like to use a Segwit wallet in my Ledger Nano S to derive unhardened(?) child public keys (and thus segwit addresses) that match those that my Nano produces. I want to do this using Python 3. I believe creating an address like this is called a "watch wallet", or at least it is described in the Bip32 docs like this:

This permits for example a webshop business to let its webserver generate fresh addresses (public key hashes) for each order or for each customer, without giving the webserver access to the corresponding private keys (which are required for spending the received funds).
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Motivation

This is precisely what I'm trying to do using Python for my Django application. I do not want to use a third party service as I'm told not to trust giving out my extended public key (xPub). I want to use the xPub from my Ledger Nano S. Actually, I'm not entirely sure if my Nano S uses an xpub or a zpub, but I have asked this in a separate question.
Does Ledger Nano S Have an xPub or a zPub for Bitcoin wallets?
Regardless, I have converted the "xpub" key to a "zpub" key and attempted to derive new keys from both using MANY different python modules and with zero success in creating an address that matches or even looks similar to that which my Nano produces.
What I've Tried
For the sake of eliminating answers that suggest methods I've already tried here is a complete and exhaustive list of every method I have tried, with links to all similar questions on Stack Exchange.
At first I tried btclib along with Pycoin.
Note: in all examples I'm attempting to use the Bitcoin Testnet
from btclib import bip32
from pycoin.networks.registry import network_for_netcode

network = network_for_netcode("XTN") # XTN for the Testnet, BTC for the Mainnet
xpub = "x(z/t)pub-big-long-key-that-starts-with-tpub-zpub-xpub"

child_xpub_key = bip32.derive(xpub, "84'/1'/0'/0/0")
key = network.parse.bip32(child_xpub_key)

print(str("Key: {}").format(child_xpub_key))
print(str("Address: {}").format(key.address()))

Similar to this question:
Derive public key from xpub?
I get an error using the "hardened" derivation path and in order for the error to go away I can only use the path 84/1/0/0/0. I have even tried path 0 and 0/0. Of course the path my Nano gives me includes the ('). From my understanding this derivation path is for zpub keys but even if I convert to zpub it doesn't give me an address that matches my Nano. I assume this is because I should be using Bip44 or Bip84 to derive addresses? Correct?
The next thing I attempted to use was bip_utils
from bip_utils import Bip44, Bip44Coins
key_str = "x(z/t)pub-big-long-key-that-starts-with-tpub-zpub-xpub"
bip44_ctx = Bip44.FromExtendedKey(key_str, Bip44Coins.BITCOIN_TESTNET)

This code works, however the example code given at the bip_utils github page suggests that the next line of code should be:
# Derive account 0 for Bitcoin: m/44'/0'/0'
bip44_acc = bip44_ctx.Purpose().Coin().Account(0)

Which gives me the error
Bip44DepthError: Current depth (3) is not suitable for deriving purpose

I already know that I don't want m/44'/0'/0' but the docs give no clue how to change the path and looking at the source code didn't help me either.
Then I tried using pybitcointools by the famous Vitalik Buterin. He even has a part in the docs about "watch wallets":

For security reasons the seed and xprv should ideally be held in cold storage only. If a web application needs to be able to provide addresses on demand, the solution is to use a watch wallet, generated from the xpub. For example, let's take the Dash xpub from a previous example:

from cryptos import *
coin = Dash()
xpub = 'xpub-some-xpub-key'
wallet = coin.watch_wallet(xpub)
wallet.is_watching_only
wallet.new_receiving_address()
wallet.new_change_address()

I'm thinking "this is it, Vitalik is my hero! He know's what I'm looking for!" But NO, this sample code only works for Dash, apparently. When I change the class to Bitcoin(), none of the "watch_wallet" methods described in the docs work, or rather they don't exist. No where is an example of how to make this work with Bitcoin.
Conclusion
Of all the methods I tried, at least btclib didn't give me any errors. I could be using these python modules incorrectly or perhaps there is a better python module/class that I should be using. Any direction would be helpful. Thank you in advance.

You could do that with python-bip32 but you'd need to convert the whatever-pub to a proper xpub before, see https://github.com/darosior/python-bip32/pull/21. EDIT: actually you mentioned xpubs as well, in this case you can checkout the usage here https://github.com/darosior/python-bip32#usage

Since you can't traverse through hardened paths with xPubs ledger is displaying not the Master xpub but the xpub at the derivation address 84/0'/0' or whatever your account number is. From there you need two additional derivations of 0/0 to get the final 84/0'/0'/0/0 public key.
The resulting public key can be used to derive either a P2PKH address (non-segwit) or a P2WPKH address (segwit). Xpub and Zpub are both encodings of the same key but Zpub additionally instructs the wallet to derive a P2WPKH address from it. Ledger doesn't make use of this standard and prefers to encode it with the more general Xpub encoding (which provides no instruction).
Using my toy Python library you can use the following script to derive your addresses:
from cryptotools import Xpub

MY_XPUB = 'xpub-as-shown-in-ledger'

key = Xpub.decode(MY_XPUB)

pubkey0 = key/0/0
print(pubkey0.address('P2WPKH'))  # Tell the wallet that you want a P2WPKH address

if you want testnet addresses set the envvar CRYPTOTOOLS_NETWOK = 'test'

It worked like a charm! Thank you. I took a good look through the source code and I forked it as well. I understand that you have a disclaimer about security. Is there anything I should be aware of?

Pycoin now supports segwit xpub after this commit. It is able to parse xpub/ypub/zpub and derive addresses. Ledger is still using incorrect prefix for segwit xpub and you may have to convert the xpub to ypub/zpub appropriately


text:
Compute checksum for Bech32 address
The Bitcoin Wiki page for Bech32 addresses explains how one can create a bech32 address from a public key. In step 6 it says-

Compute the checksum by using the data from step 5 and the H.R.P (bc for MainNet and tb for TestNet)

I went through the bip 173 wiki page which explains the checksum process. However I do not know python and cannot understand most of it.
How does one compute the checksum? Is there some library I can use? I mainly develop in Java/Kotlin/C++. Either an explanation of the python code on the bip173 page or libraries/code snippets in the languages I develop in will be greatly appreciated.

You may want to look at the reference implementation section: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#reference-implementations
It lists implementations for various languages, including C, C++, and JavaScript

Just to add to this answer, this pr on the github page has the java example.


text:
Installed latest Bitcoin-Qt, fully synced, but 'getreceivedbyaddress' etc doesn't work?
I downloaded and installed Bitcoin-Qt 0.8.6, fully synced the block chain (according to the software itself) and now trying some basic commands through the console.
For some reason, getreceivedbyaddress <address> always returns zero, even for addresses that I know contain some bitcoins.
For example: getreceivedbyaddress 1Dorian4RoXcnBv9hnQ4Y2C1an6NJ4UrjX gives 0.00000000 (mini-screenshot), yet we can all verify that this address actually did receive bitcoins (see comment).
Restarted the software several times, restarted my PC, and also tried doing this from the command line using bitcoind instead of the Bitcoin-Qt user interface, still the same result.
Am I doing something wrong or misunderstanding Bitcoin-Qt?

Can't post more than 2 links, but here's to show that this address indeed has a positive BTC balance: https://blockchain.info/address/1Dorian4RoXcnBv9hnQ4Y2C1an6NJ4UrjX

The answer is here: http://bitcoin.stackexchange.com/a/19739/1878

try bitcoind listaddressgroupings see if that shows which address the BTC are in.

getreceivedbyaddress only works for your addresses, i.e. those for which the private key is in your wallet.  Those are the only addresses for which bitcoin-qt keeps indexed transaction data.  Getting balance and transaction information for arbitrary addresses is unfortunately not supported by bitcoin-qt; sites like blockchain.info write custom software that manually parses the block chain.
See also this answer.

Thanks, that explains it. Is there a way to (perhaps temporarily) add such addresses to my wallet? Because I don't have the private key, I can only do so in a read-only way (like a 'watch only' wallet or address) but is this supported at all by Bitoin-Qt / bitcoind?

Now that I think of it, perhaps this could be faked by somehow importing this address in an encrypted wallet, with a dummy private key? Bitcoin-Qt won't ask for my password (and hence, not use this private key at all) until I actually try to spend something...?

@Monty: I believe that bitcoin-qt does not have support for watch only wallets, though other clients might. Your encrypted wallet suggestion might work, I suppose, but it sounds like a lot of work.

I believe that getreceivedbyaddress only reports on addresses that are in your wallet.  It doesn't allow you to look up arbitrary addresses, like the 1Dorian one.


text:
What can be done in order to improve privacy in bitcoin transactions?
Privacy should be default and  not an optional property - even when using stealth addresses or confidential transactions, your bitcoin balance and transactions in the wallet are transparent to anyone. All of these are awful characteristics for a currency.
We all live in post  Snowden era of full spectrum surveillance, and ridiculous anti-cash propaganda. Cash is government’s  legal tender and is protected by law.  But the implacable war against cash payments waged by big government and banks worldwide is gaining new momentum. The excuse or reason given by our rulers for suppressing cash is to keep society safe from terrorists, tax evaders, money launderers, and other villains, real or fictional. But their main and real intention is to limit or even prohibit cash, in order   to force the public at large to make payments through their financial system in order to enforce their unstable fractional-reserve banks and, more importantly, to expand the ability of governments to monitor on and keep track of their citizens’ private financial transactions.
Fungibility is an essential property of money that makes every unit of this currency interchangeable. One can pay the service or a product with a coin or a paper note, and the receiver does not  care where it came from, as long as this banknote or coin isn’t counterfeited, he will accept it and exchange products or services for that banknote. This is how physical cash works. Creating Bitcoin fungibility is not a trivial task, as far as I understand. There is high probability that anyone who interacts with you knows exact amount of bitcoins  in your wallet.  Tor can not keep private your wallet linkage to other wallets.
Real question is -- How  we can enforce fungibility on a transparent blockchain where every transaction is visible?

I would like to see someone explain how they can know the exact amount of bitcoins in my wallet. Transaction linkage does not define borders between wallets, and it is only feasible to know which transactions re-use the same address to presume linkage within a single wallet. At best you get a single point partial wallet state once the utxo's are spent. No-one knows what other utxo's are mine.

Pieter Wuille posted an answer earlier today that covers some of what is already being explored in the pipeline for additional privacy.

... but improvements are continuously being worked on (search for things like MAST, TumbleBit, Layer-2 payments, Taproot, signature aggregation, scriptless scripts, confidential transactions, ...)

In addition, further ideas like change obfuscation have recently been seen on the [bitcoin-dev] mailing list.
There will no doubt be even further suggestions in time.

Bitcoin Fungibility  does not exist.  One can not say "I don't know where my bitcoins are coming from."

@jjpcondor Neither can one say "I don't know where my cash is coming from." any more than that. Even if it arrives in an anonymous envelop we presume it is not a donation and some customer instructions are attached. Yes, you can see with Bitcoin how a utxo was created but, it is not infinitely possible to link utxo's to individuals, not even currently. To link utxo's to individuals there must be mechanism's of disclosure.

I can tell you how people's privacy is revealed, so that scammers can be traced often. By considering all points you maximize your privacy while using bitcoin:

connect your wallet to your own Bitcoin node, not to unknown nodes
never re-use addresses
Stay in the Bitcoin world, so never use central exchanges to buy or sell bitcoin
Use mixers which are open source and dezentral
Never co-spend mixed coins with other coins from you otherwise the mixing was a waste of time. The same applies if you exchange bitcoin into Monero forth and back.
Make sure the wallet you're using is trusted
If using software wallets (risky) make sure that you can control the priv key and never use it if another person opened it for you and handed over with the security advice to change the password (he knows the seed and will empty your wallet or knows the addresses)
If you send Bitcoin to third parties address use the same address type if possible (e.g. send BTC from a 1.... address to a 1... address and from a 3... to a 3... address and from a bc1... to a bc1... address.
Use payjoin transactions if possible
The more output addresses your transactions have the more difficult is it to reveal te privacy.
Hide your wallets IP address behind TOR
Find a safe way to protect your private keys and seeds.

You're right. Especially if there are more than two outputs it's getting difficult to find out the change address.

yeah, a lot of requirements, where comparison to reality doesn't match. But at first: the question is probably not the right one for this forum - mostly opinion based... IMHO it would find a better home in a discussion board, where it can be discussed back and forth. Bitcointalk.org would be a good candidate. But I can't resist, it's too fascinating! Btw: in your enumeration you forgot pornography :-)

But their main and real intention ...

This is a suspicion, and hardly to be proved. But I am with you: war on money has started, because in rich countries there is a tremendous  dependency on the taxes of less and less employees (usually in the working class). These jobs are now in eastern Asia... As this is reducing income for the government, they print enormous amounts of money - out of thin air. Along with the private banks - out of thin air. And looking at the laws for taxes, they have been changed to the advantage of the rich class in the last 35 years. In the US you are already a tax slave of your country! Even working in a foreign country, you still pay taxes "home" - I think this is what is called land of liberty and freedom. Anyhow: along with the tax issues there is also a value issue. The major currencies have all lost value over the years, roughly doubling the prices every 15-20 years (inflation). Along with extreme debts (China is holding majority of US debts), a new dependency came into the game in the last 20 years. Pressure to get an understanding of money flow is enormous, so not only individuals (slaves of the governments) feel the pressure, also the international relationships gets burdened... Pessimistic approach would be to see the end of this capitalistic system, having burnt all its fuel, and now starting to implode.

Fungibility is an essential property of money

yes. But was Bitcoin designed to be what you state? I don't think so. It was a way to improve money transfer over the internet circumventing banking systems and intermediaries. This goal has been achieved, along with a minimal set of privacy, by not re-using addresses. And certainly not buying with bitcoin over the internet :-)
Now again the reality is this stupid "HODL" idea (based on scarcity of a value), and if at the end everyone holds their coins, it has no value cause it is out of circulation. But then it is secure:-)
What you are touching is maybe Monero or Zcash and similiar, and the ideas are already exchanged in the bitcoin world. Elements Alpha sidechains is a playground for hardcore bitcoin devs, to evaluate new features, Schnorr and CT are already there. I am confident, that we'll see more coming, as requirements increase.
Security might not be the number one goal for everyone:
Looking at the way how many people used Windows over all the years, knowing it would be vulnerable, patching it all the time, and still postulating to be secure is a joke. Now all these people go into mobile, and provide their data for nothing - no need to spy on the phones anymore (hence less viruses). The vast majority of people want to have things easy and working, and not complicated to be managed. And when it comes to security, it gets tough...
Why high level bitcoin security with fungibility is not yet here (my speculation now)? Too many people just want to make "quick money". And I don't mean it negative (I might even be one of them). Too many people are not even interested in privacy. Looking at the posts in reddit, and to a certain extent here, more and more questions are exchange specific for 18year old graduates, and not technological (wow, what a complaint!). The necessity for bitcoin to provide privacy seems to decay, people don't care if bitcoin is a vehicle to transport value over the internet, cause it is more profitable to speculate with crypto currency's values.
O tempora o mores!

How we can enforce fungibility on a transparent blockchain where every
  transaction is visible?

You can't - when you enforce s.th. on bitcoin, then you loose the censorship free system. No. Please. Really!


text:
How does cryptsy.com allocate trades for many orders with same price
How does cryptsy.com allocate trades for many orders with same price ?
Orders can come from one or many accounts, my question applies to both situations, but it's obviously more interesting how they are executed when orders come from multiple accounts from different people. For example, if I see order for 100 BTC and want to attach my order for 0.1 BTC to the same price tag, what are my chances of getting a deal ? Do I get a deal only after all 100BTC exchanged ?
Obvously my question applies to both types: buy and sell orders.
Do other exchanges have same order allocation schema as Cryptsy ? If not, what allocation schemas do they use ?
Examples of possible allocations that I can think of:
1) First Come First Serve - earliest order gets deal first
2) Last Come First Serve - latest order gets deal first
3) Proportional - deal amount is distributed between orders proportional to amount of these orders.
4) Minimal split - system picks closest amount to avoid splitting orders into many small fractions.
5) Small orders first, Large Last - close as many orders as possible to keep minimum number of open orders in the system.
6) Each account gets equal share from new deal regardless of order size or time
7) Random per account - equal probability for each participating account to get a deal
8) Random per order - gives incentive to make many smaller orders rather than one large order

possible duplicate of How do buy and sell orders work?

No exchange could ever use #2, it'd give an unfair advantage to those entering at last minute - high frequency trading only, no humans allowed! Numbers 3, 7 and 8 would still favor last-minute traders, though less than #2. #4 or 6 seem to me the only ones to be fair appart from #1

While I have done no research whatsoever to prove it, I am pretty sure that only FIFO, 1) is used. Everything else is way more complicated and/or easy to game.

At Cryptsy the order is First In First Out influenced by the account's trading history. If the server were to receive buy orders at the same time assuming there is enough coins at the specified price to fill the orders, the server looks at each account and the one with the most trading history gets processed first, then in order to the account with the least trading history. I work for Cryptsy, I'm Brad!

According to this answer it allocates according to rule #1 - First Some First Serve.

So much "First Come, First Served", actually, that occassionally I've placed a buy order some satoshis below the topmost sell price and get it served with 2 different events at 2 prices, even though the total amount of coins offered at top sell price has not been depleted.


text:
Doubt about Bitcoin SCI
What's up guys... I'm trying to figure out what's the best shopping card interface I should use. I want a PHP based, simple to work with. Was looking on bitfreak sci, looks good, but the negative point is that the client need to keep the session openned until the server recognize the payment (at least for what I understood, if I'm wrong correct me). So, 2 things I want to know: have any other SCI that the client don't need to keep session openned for the payment to be recognized? I know the bitcoin payments take some time to be validate, but some SCI that don't work with the user's browser session. Let's suppose a user make payment and just close his browser, it still able to recognize his payment?
And other question is about the addresses created by the SCI... How can I access those addresses to pick up the money?

Am I correct to assume you mean shopping cart interface? If so I have a good recommendation. I am not affiliated with coinpayments.net besides being a very happy customer of theirs. They charge 0.5% + network fee to process a payment and send it to the address of your choice or hold it for you until you decide where to withdraw it to. They do all the payment processing for A LOT of coins and have tons of shopping cart plugins: https://www.coinpayments.net/merchant-tools-plugins
For a while I was trying to get coinbase API to work, as they charge 0% to process the "first $1,000,000" :P but it's only bitcoin and I ended up wasting days trying to configure it and get their support team to send me a valid certificate. Coinbase is great for converting to USD but their merchant services are a bit lacking. Coinpayments has amazing support and unless you're processing $100,000s 0.5% is absolutely worth it.
Edit: They also will process the payment even if a client makes a payment to you and then leaves the page. Their sessions last 5 hours which can be risky during a big crash but I have not had any problems with them.

but the negative point is that the client need to keep the session openned until the server recognize the payment (at least for what I understood, if I'm wrong correct me)

My Bitcoin SCI script doesn't stop processing the payment if the session expires. It will just start a new session. The session variables are used in the script to hold temporary data which can be recovered if the session expires. But if the client IP changes it will not allow the transaction to complete for obvious reasons. If the client closes the page they will be able to complete the transaction but only if they saved the URL of the transaction page and if their IP address hasn't changed. In the case where the client pays and then leaves the page before completing the transaction you have several options, but it really depends on how you integrate the script into your own site.


text:
How will Ripple affect Bitcoin exchanges?
Will every Bitcoin exchange be under pressure to also operate as a Ripple gateway in order to gain access to the additional liquidity that Ripple creates for markets?

As Ripple appears to allow one to create exchange listing for any pair of currencies, it might very well server as an exchange unto itself. It is possible that the project will replace the traditional exchanges, possibly turning them into Gateways to put money in and out of the system instead.
Then again, that might be far in the future - at the present time there is a healthy amount of scepticism surrounding how safe the Ripple system is, so not a lot of people would be willing to abstract their money even further with it than they are used to.

Do you happen to have a source (URL) for that scepticism about the safety?

@Joshua It's an overall feeling I get when talking to people about Ripple. If you are part of the BF, here is a topic where people express some of their concerns - https://bitcoinfoundation.org/forum/index.php?/topic/84-ripple/ - people are still looking into the code, pondering the safety of consensus approach to ledger creation, discussing the way ripples are distributed, problems after the initial launch and so forth.


text:
I withdrawed a small amount of BTC from Coinbase Pro to Electrum and it was immediately sent to another address
Weird... I took out a small amount of BTC from Coinbase Pro, generated a new receiving address in Electrum, and as soon as the transaction came in, the BTC was transferred to an address which I do not control...
Here is the withdrawal transaction:
63b1674c7f62e6c33d342518cc580b86de90ed4f1b77c67c76d1cb80cafe47a6
And here the one that sent the BTC out:
dd7660c0cc1e19f2e42faad42ca4ee8e92a7dc15da083a5277ff33b9a1badaeb
I really do not understand, I have also imported the receiving address into bitcoind, which is still syncing.
Any help would be highly appreciated.

There have been fake versions of Electrum that steal money. What is the version number you have and what website did you get it from?

I got it from electrum.org, it was version 4.1.5

Have you verified the GPG signatures from an independent source?

Yes, I did. This is why I really do not understand how this was possible.

And also, the outgoing transaction appeared at the very same time as the incoming transaction, with 0 confirmations. What I noticed, is that a much higher fee was paid for the outgoing one.

Could your computer have been compromised and infected with malware that steals private keys?

Nope. I scanned the computer several times, and I use BitDefender on my Win 10 partition. In my KALI partition, which I went to check after, Electrum was showing the same transactions... Luckily, I tried with a very small amount, but I am afraid some people might loose much more...

I can't answer on the why and the how, but when you focus on the receiving address (1CfaunqrVpcXmpLheUVWeSP1KPsKDha1Nb), there is some weird things.

You can find it in some presentation about "what blockchain is?" > What is blockchain

You can also find it on some powerpoint presentation about "Blockchains transforming the domain industry" where you can see that typing some domain name can route a payment to an address (this one was taken as example). Unstoppable Domains

This address is often used as an example in websites and presentations.
Is there any chance it was on your clipboard, following a copy from.. somewhere?
You can search it on a random search engine to see by yourself.

I noticed that this address was around the net, also, I noticed that the first transfer towards this address was from   1BoatSLRHtKNngkdXEeobR76b53LETtpyT, another well known address (vanity), but to answer your question, no, I did not have them in my clipboard...

Also, I inserted my newly generated address into the Coinbase Pro transfer dialog, as you can see from the transaction details. I am not really a newbie in crypto, but this one just left me speachless...

Yes, for the clipboard, I was thinking about your computer, where you have electrum.

No, I did not have anything in the clipboard except the newly generated receiving address.

I think you can download a Coinbase cold wallet. You don't need to install Electrum at all. In that case, a handling fee will be incurred. If you don't understand, you can easily lose your coins.


text:
Using EQUALVERIFY with different public keys, but generated from the same seed
I am building certain system that involves Bitcoin and therefore I need to understand well how it works under the hood.
In order to receive funds, for every new transaction new public key and its hash should be generated. I assume that is done via extending the parent public key and generating new child key for every transaction. All of that makes sense, up until the point when the user who previously received funds, let's say Mike, decides he wants to use funds he received and send them to someone else, let's say Alice. In that situation he has to construct unlocking script with signature and public key that he submits to stack in addition to locking script attached to his previous address where he received funds. Locking script also (in addition to operators) has a public key. Now, at one point EQUALVERIFY function will be executed which is supposed to compare public key hash from locking script and the one from unlocking script and see if they are the same.
My question is, if for every transaction new public key is generated, then how will we even know which public key was used for certain transaction? Although, all of the keys are generated by same user and global seed, they can differ and as far as I understood EQUALVERIFY just performs basic equality operation. It doesn't check if two public key in some way originate from same seed. That would mean that if public keys from both scripts are not exactly the same, EQUALVERIFY will return FALSE.
I believe I am missing some piece of this process.
Thanks!

Multiple keys can indeed be derived from the same master key or seed, but it's important to realize that this results in distinct public keys as well as distinct private keys. The public key is converted to an address, handed out, transactions are received on that address, and to spend the received output then, the public key is revealed together with a signature with the corresponding private keys.
In other words, the blockchain and the nodes verifying it do not know or care which keys were generated from the same seed. That is purely a local wallet decision. Nodes just see distinct public keys, and signatures with their corresponding private keys. In fact, the very earliest wallet software did not use seed/master key derivation, and just used randomly generated keys for every new address.
To determine which private key to sign with (and which corresponding public key to reveal), wallets just keep a map around from all public key hashes they have generated to the information about their derivation (which index in the derivation, possibly which parent key it was derived from).
When setting up a new wallet using existing seed phrase the wallet can potentially reconstruct the map of the keys easily. Since all the child keys derived from the parent are derived in a deterministic way, the wallet can just derive hundreds or even thousands of potential keys and addresses where transactions might have landed at some point of time. Then the blockchain can be checked for those addresses and see if the record about them exists on the chain and if they indeed received any funds.

Thanks for the comment. Yes, the network doesn't care which keys where derived from the same seed, but that is not what I was doubting. I have just added a diagram above to maybe more precisely define my problem. The wallet does need to provide some public key for unlocking the unspent output and from the locking script he can only see the already hashed key (address), so he doesn't know what the key should be and since there can be many keys derived from the same seed, he also doesn't have a mechanism to get the right key. (That is why I introduced the seed and etc. in the story). More clear?

The wallet just keeps a list around of all public keys and their hashes it has ever generated, so they can be regenerated (along with the private keys) whenever needed.

So then wallet basically tries all possible keys before one of them works for a given locking script? What if the wallet gets deleted and you need to recover it on some other device using seed phrase? Then wallet will no longer have any list of keys it generated before.

It is sensible for a wallet to maintain a list of generated pairs of private and public keys. This list can be indexed by public key hash. This is not explicitly required by network protocols, not explicitly by consensus rules. These are implementation details - different developers can do things differently.

Thank you for your comment, but if that is correct can you please see and try to answer my comment above regarding if the wallet then tries to unlock the script with all the keys before one actually work and what if I restore my wallet with phrase on other device (because there will be no map/dictionary there)?

It doesn't need to try to unlock with everything. The wallet software can just generate a map of information "public key hash H is key number N" for each, up to say a few 100 or 1000 keys. To detect incoming payments, it looks up the pubkey hash in the output in this map. If found, the wallet knows it can spend it (namely with key number N, which can be rederived when needed). This information can be, but doesn't need to be, stored in the wallet, but it can also be recomputed whenever needed. Deriving keys takes milliseconds or less.

@PieterWuille Thank you! I think I get it now. I edited your question with the precise thing I was wondering when asking the question. Hope you will take a look if I understood it correctly now.


text:
Help decoding transaction on bitcoin testnet
I'm trying to learn more about bitcoin and I'm trying to decode a transaction I made to myself on testnet and I can't seem to figure out a couple of things
Here is the output of getrawtransaction:
getrawtransaction 'f013fd7f27a8c78fd52ad95253e7330dd7e5c6490f480cecd95359cfb1abcbdd' true
{
  "txid": "f013fd7f27a8c78fd52ad95253e7330dd7e5c6490f480cecd95359cfb1abcbdd",
  "hash": "f6f699d7587a455e516be97b81b79d318d40ca9a8cc4f3382e4ba355808f7c83",
  "version": 2,
  "size": 223,
  "vsize": 142,
  "weight": 565,
  "locktime": 2133079,
  "vin": [
    {
      "txid": "246f7eb126789462a13b56658fc8095118ea9499b0c41ca5402fa38f97681d2b",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "304402200eb3153139da95c29755baaddb1f8038ad1bd850f46b56d467875d91eb49599502204a19b6798bbdbd019f0bcf63a3412d4f99f923b19a33377c714d06a6f77a71fa01",
        "036abeb6881115996db7d8fc9845adf6dabc66e03ca04ff9ff6d15d64fed1cf4b1"
      ],
      "sequence": 4294967293
    }
  ],
  "vout": [
    {
      "value": 0.00009858,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 07a715962bfe8aec6637ea4abe38e412aa8f9f77 OP_EQUAL",
        "hex": "a91407a715962bfe8aec6637ea4abe38e412aa8f9f7787",
        "address": "2MswgsrCPRvvB6umFyCYJB6L5FFjnoce2AS",
        "type": "scripthash"
      }
    },
    {
      "value": 0.00010000,
      "n": 1,
      "scriptPubKey": {
        "asm": "0 f864afee2f6d17a22c420ee61ea21aff5d76ebd4",
        "hex": "0014f864afee2f6d17a22c420ee61ea21aff5d76ebd4",
        "address": "tb1qlpj2lm30d5t6ytzzpmnpags6lawhd675fh8265",
        "type": "witness_v0_keyhash"
      }
    }
  ],
  "hex": "020000000001012b1d68978fa32f40a51cc4b09994ea185109c88f65563ba162947826b17e6f240000000000fdffffff02822600000000000017a91407a715962bfe8aec6637ea4abe38e412aa8f9f77871027000000000000160014f864afee2f6d17a22c420ee61ea21aff5d76ebd40247304402200eb3153139da95c29755baaddb1f8038ad1bd850f46b56d467875d91eb49599502204a19b6798bbdbd019f0bcf63a3412d4f99f923b19a33377c714d06a6f77a71fa0121036abeb6881115996db7d8fc9845adf6dabc66e03ca04ff9ff6d15d64fed1cf4b1578c2000"
}

Questions:

The address I sent some test BTC to is 2MswgsrCPRvvB6umFyCYJB6L5FFjnoce2AS. But, I don't know what 07a715962bfe8aec6637ea4abe38e412aa8f9f77 is and I can't seem to duplicate it. I can't even duplicate 2MswgsrCPRvvB6umFyCYJB6L5FFjnoce2AS.  By duplicate I mean I can't seem to recreate that label given the public key from my wallet.  The public key is 02381296c094c7284621bf3b25fb086a531d5035b7982604d15f9223cda758c7bc, so from that shouldn't I be able to take the RIPEMD160 HASH, prepend add 0x6f, take the double hash, take the first 4 bytes, then encode that into base-58 (version + hash + checksum) and get the above address? What am I doing wrong because I'm not getting that.
What are the 2 bytes after the first 4 bytes (Version)?  Bytes 5-6, which is 0001?
What about bytes 113-114?  Which is 0247 (in the raw hex dump)?  What does that represent?

Edit: output from testnet wallet:
getaddressinfo "2MswgsrCPRvvB6umFyCYJB6L5FFjnoce2AS"

{
  "address": "2MswgsrCPRvvB6umFyCYJB6L5FFjnoce2AS",
  "scriptPubKey": "a91407a715962bfe8aec6637ea4abe38e412aa8f9f7787",
  "isscript": true,
  "iswitness": false,
  "script": "witness_v0_keyhash",
  "hex": "00145ec830fe309c79964f739c66bdc0619d754a4e33",
  "pubkey": "02381296c094c7284621bf3b25fb086a531d5035b7982604d15f9223cda758c7bc",
  "embedded": {
    "isscript": false,
    "iswitness": true,
    "witness_version": 0,
    "witness_program": "5ec830fe309c79964f739c66bdc0619d754a4e33",
    "pubkey": "02381296c094c7284621bf3b25fb086a531d5035b7982604d15f9223cda758c7bc",
    "address": "tb1qtmyrpl3sn3uevnmnn3ntmsrpn4655n3npp07k4",
    "scriptPubKey": "00145ec830fe309c79964f739c66bdc0619d754a4e33"
  },

Addresses that start with 2 on testnet or more precisely scripts that are like OP_HASH160 <hash> OP_EQUAL are P2SH scripts and the hash is created by computing HASH160 of a redeem script. Your redeem script seems to be a P2WPKH one which makes your address a P2SH-P2WPKH address. Your redeem script that has to be hashed is OP_0 <160-bit hash of public key>
It is a indicator that this transaction contains witnesses. See BIP-141.
02 is indicating there are 2 witness items and 47 is the size of the first witness item using compact integer format.

Hey, thanks for the answer.
So, you mean do the RIPEMD160 hash of "0x00 + publicKey", which is the redeem script,
then do the "RIPEMD160" of that, add the network prefix, double hash that, grab the first 4 bytes as checksum, then do base58checkencode?
I'm still kinda lost on the exact steps. Here is the output from the testnet wallet for that address/label (see question above, I edited it)

@btcnewb Hash160 = SHA-256 followed by ripemd-160. The script hash is the hash160 of the redeem script. You prepend the version byte to that, compute the checksum as the double sha-256 hash of "version+script hash", append the first four bytes of that hash, then Base58 encode. The steps are similar to this procedure and this answer.


text:
How to generate an invoice with flexible amounts for Lightning Network
I try to create a lightning invoice for donations. I want my donors to be able to determine the amount themselves.
For my question I have looked for an answere in the internet. Unfortunately, my search results didn't help me.
As background could helb my Lightning Full Node (Umbrel) and Blue Wallet App. Of course I'm open for other software too.
Do you know a good tutorial or can you explain, what I have to do?
Edit: thanks @Sachin Meier. With your help I have found a kind of BOLT11-How-to. I have to confess that neither your explanation nor the How-to helps me. Could anybody provide a noob secure introduction please?

Lightning Invoices (BOLT11) allows for invoices to have a zero amount. If you generate a zero amount invoice, the sender can use it to pay any amount.
When you use zero amount invoices, you have no control over how much you receive, and will need to make sure the sender sends the amount you expect.
Zero amount invoices do have a vulnerability:
Channels:
A <-> B <-> C
If C attempts to pay a zero-amount invoice to A, say they pay 10,000 sats. B can receive the 10,000 sats and forward only 5,000 sats to A. Since A doesn't know how much C intended to send, they see this as a valid payment and return the preimage to B. Thus B can "steal" 5,000 sats.

In terms of generating zero-amount invoices, just enter zero as the amount. If the wallet throws an error, they don't support zero-amount invoices and you'll need to try another wallet.

thanks. I will figure it out


text:
what kind of a double spend attack is a career attack?
there is an article that name different type of double spent attach like  "Several variations of attacks could allow miners with bad intentions to double spend. Included are the Finney attack, race attack, 51% attack, career attack, and unconfirmed transaction attacks."
but I couldn't find anything on career attack. what is this type of attack?
https://www.investopedia.com/terms/d/doublespending.asp

Can you link to the article?

https://www.investopedia.com/terms/d/doublespending.asp

It might be another name for a race attack
See https://www.europeworldnews.com/double-spend-or-double-spend-attack-on-bitcoin-myth-or-reality/

Career attack
The Race Attack is a type of duplicate spending that affects Bitcoin merchants or users who accept payments without confirmation. Basically this attack is that the attacker makes a payment to a merchant with some coins and at the same time carries out another transaction with these coins to send them to another address that he controls. By manipulating the commissions of both transactions (lowering the commission of the first and increasing the commission of the second), these types of attacks can be more likely to succeed. Especially when the mempool is overloaded and miners only prioritize transactions with higher fees.


text:
Shell Script - Block Sequence check and add missing block
I am trying to scan blocks lets say from 1 to 10.
lets say
(3,1,4,8,2,7,9,10)
min block = 1 , max block = 10
expected sequence = 1 to 10
missing blocks= 5,6
I need a shell script that is going to pick up the missing block in the range and add them to create a new set. Sorting is not needed though
Best Regards,

I’m voting to close this question because it is unrelated to Bitcoin.

@PieterWuille, I just modified my question. I am trying to scan the bitcoin blockchain and filter out transactions based upon the addresses that belong to me. I am missing some blocks.

This seems to be a question about shell-scripting. You can probably ask on stack overflow about how to find missing numbers in an unordered list. In any case, you should post the shell-script you have written so far, or a simplified version, and explain how it's output differs from what you need.

@RedGrittyBrick That is fine ! Here is another question that was answered https://stackoverflow.com/questions/2727809/finding-the-missing-values-in-a-range-using-any-scripting-language-perl-pytho ? What is the bias for ? I can still find a solution to the problem but the responses don't encourage to post questions anymore

You are more likely to find an answer about subject X on a site that has large numbers of visitors with experience in subject X than you will on a site about subject A which only occasionally involves the use of something from subject X. It is an attempt to be helpful


text:
Settlement scalability after general adoption
How can bitcoin & lightning support a full planet adoption rate of settlements?
Just trying to understand how this works, and whether or not this might be a problem.
Lets imagine Bitcoin is finally adopted, and most people use it. For 8000M-10.000M inhabitants that means probably between 2000M and 5000M "households" or individual Bitcoin account parties.
Imagine most of those households follow the regular recommendations, they will hold their own coins in their own wallets.
For daily usage, they will have a considerable part of their BTC locked up in the Lightning Network, so they can spend quickly even small amounts of satoshis.
But, also per recommendations (last time I checked) they should want to settle their BTC from time to time to the layer 1 Bitcoin network. Specially if they want to save that money, which is what Bitcoin gives you that fiat took away by design.
So if millions of parties want to settle at a pace of 7 transaction per second we get:

2000M parties would be able to settle every 3306 days, meaning 1 settlement per 9 years!
5000M parties would do 8267 days per settlement, 1 settlement every more than 22 years!

Let's do the it other way around. Imagine we want to know how many tps we need if 2000M-5000M parties want to settle monthly. That means between 800 tps to 2000 tps.
I understand that we want the Bitcoin blockchain to be as lean as possible, so all history fits on a regular computer you can have at home, not a huge expensive cloud instance, which would make the network centralized.
But still, how can bitcoin & lightning cater for a full planet adoption rate of settlements?
Maybe we need to forget about individual holdings as adoption grows?
Maybe people wanting to settle will be a minority? (less than 18Millions parties monthly for instance)

I think your misunderstanding comes from a few points which I will try to cover as best as I can:
1: The scalability of bitcoin is not meant to rely on the base layer.
The base layer of bitcoin is meant to be a completely robust, byzantine fault tolerant, backwards compatible, censorship resistant, and 100% verifiable ledger. To achieve this you need to make certain kinds of trade offs, and you also need to realize the fundamental assumptions of anything you may be changing. For example, if the core software were to "hard fork" in a way that would make old scripts defunct, it would ruin the coins of the original bitcoin supporters which is obviously not in the benefit of the network. Bitcoin was designed in a way that allows us to work with in a relatively modular consensus mechanism, every single upgrade that has been done to Bitcoin is done through SOFT forks which have never rendered old bitcoin scripts defunct. Thus the choice to deal with the limitations has actually lead to our transactions becoming extremely small and succinct over time in order to save block space, and increase transactions per block. We can even include several participants in a single signature which starts to scale down the block size even more. The point is, the base layer of bitcoin is the only example of a completely backwards compatible long-term modular and scaling up each year network that exists. If you compare it to ETH for example( their chain is over 1TB and is newer than bitcoin, that is not scalable at all, i literally have 3$ on my eth address from 2 years ago that is more expensive in fees to move than the eth costs and it has not changed, seems like a ponzi scheme to me honestly) , the bloat of transactions is not even close due to the way they handle memory in the EVM. Bitcoin solves this by not shooting itself in the foot in the first place, and focusing on backward compatible code that fits within soft fork upgrades.
2: The scalability of bitcoin (and any other blockchain) DOES rely on alternative layers built on top of bitcoin.
Lightning network is only the FIRST most popular example of a protocol that uses satoshis that already exist in order to produce a network effect of near instant payments. There are many issues with lightning network, but that being said there are more layers being built than just them. There is the liquid "financial" side-chain developed by blockstream, in which you can participate in decentralized swaps which also have faster finality times than the base layer. There is rootstock, a "pow-peg" side chain which uses merge mining to brige people in and out of the system, they allow smart contracts to be built on top of them and have a faster settlement time than the btc base layer.
ALL of these extra layers on top of bitcoin enable the scalability, and if you haven't noticed we are literally within the first few years of them even existing.
3: What are the implications?
The implications are that max scalability is NOWHERE NEAR complete for bitcoin, and no one has stopped working on it at any point. It is probably true that we could have more people working on the issue, but if you have been paying attention the vast majority of the "crypto" space is not concerned with backwards compatibility, decentralization, soft forking, consensus, decentralized layering, compression, or even scalability. Instead the majority of the space continues to chase the carrot on the stick of flashy ape-like marketing schemes and un-realistic yield farming re-hypothicatoion scenarios. There really is a more positive outlook on the future of bitcoin scalability if you care to dig in to the existing work being done.

Thanks for the very complete answer!

I wonder if that multiple parties signature feature can allow for "shared funds": a  single transaction output being shared by N participants with constraints such as participant A can spend up to X, participant B up to Y, and so on. In essence a single transaction output can become tenths or hundreds or individual transactions under the hood. I guess not. We probably require another layer o side chain to keep the accounting and some new op codes to allow for checking those constraints in the base layer.

No problem, it is important to understand how new this all is relative to other fields of study so it is understandable that everyone has questions relating to how it all works. Its better that people ask some questions rather than no one asking anything. To answer the second part, I am not as much of an expert as I would like to be on bitcoin multi-signatures however I am quite optimistic that the scenario you have described is possible to accomplish. I have heard similar descriptions of multi-sig protocols before, but as for the specific one I unfortunately do not know.

A 2 of 2 multi-sig format works basically like this: p1 has funds f1 p2 has funds f2
In utxo model chains such as bitcoin these funds (f1, f2) are called outputs or unspent outputs. To lock them together in a multi-signature one of them can fund some kind of script which basically says provide the valid signature for public key p1 AND p2 in order to spend the output within this script. Then when it is funded by the other party it retains the same characteristic, you can also set a timelock on the contract so that the initiator can reclaim their funds if the co-party does not cooperate.

The type of signature you describe is basically an any of n so it would allow any parties to sign the script at any time assuming they have some valid output they can spend in this script. I imagine this only takes a bit of extra logic to say something like: it is possible for p1 to spend output f1 without the signature of p2 in this case. But like I said, I am still learning about the technical details. Either way this is a highly important field of research and I encourage you to study it if you are interested in setting it up yourself. I am still getting started with bitcoin scripting

I found this and plan to use it to study the topic soon, I will also be opening a question to verify the information here is still valid to use. https://www.soroushjp.com/2014/12/20/bitcoin-multisig-the-hard-way-understanding-raw-multisignature-bitcoin-transactions/

But, also per recommendations (last time I checked) they should want to settle their BTC from time to time to the layer 1 Bitcoin network. Specially if they want to save that money, which is what Bitcoin gives you that fiat took away by design.

No, you don't need to close or splice-out from a channel "from time to time". A lightning network channel can be indefinite, though you need your node or watchtowers to be online so they can notice if someone tries to publish an old state on the timechain (blockchain), and if you catch them doing so you can claim the whole channel balance.
I know I'm not answering you question at a whole but just wanted to make this clear.

Thanks for your reply!
I guess I need to look again into how lighting actually works and specially about the security posture.
I guess my worry is if, when there are hundreds of millions of users if we may hit some scalability issue. I am totally fine with people not wanting to settle in layer 1, the problem would be they cannot even if they wanted to.

The demand for transactions reflects in the transaction fees.
If they become prohibitively expensive for additional adoption, Bitcoin will either have to adapt or it will tremendously suffer as a payment network (on top of the difficult accounting compliance we already have for individuals).
Two possible solutions I see:

Modify Lightning so that you can expand channels to new addresses without having to publish anything on the blockchain. I don't know how feasible is this.
Increase block size. Hopefully in the future, storage, bandwidth, and processing power will be cheap enough to still have a lot of network nodes in spite of the larger blocks. And hopefully those transaction fees will sustain enough proof-of-work mining to keep the network secure (as of now, including the block reward, we have >$900k/h which I think is plenty). This was the approach taken by Bitcoin Cash and Bitcoin SV, but sadly the market did not reward them with adoption.

Failing to do either of the two will mean Bitcoin will become an asset only for people who can afford to burn a lot on transaction fees. Which means, centralized ownership.
It looks like a proof-of-work cryptocurrency is a trade-off between centralized ownership (high txn fees) and centralized mining (large block size). The ideal point on this spectrum remains to be discovered.

you cant commit to things on the blockchain off the blockchain, that makes no sense. I have my issues with lightning, but to imagine that its the only scalability solution for bitcoin represents a lack of willingness to do the research. Lightning is merely the most popular member of the first round of bitcoin scaling layers.

There is no reason for the receiving end of a transaction to commit to the blockchain, if the sender does not attack. Ideally the sender could just give them the un-broadcast transaction. In case of an attack by the sender, the recipient could broadcast it.

That is not true, when someone spends coins to you that is the receiving end of the blockchain. If that spend is not registered on chain you can spend it again registering the off-chain spend illegitimate.

Just being able to rebroadcast is not  enough, you need the sender to send to a multi-signature 2 of 2 with a timelock that the receiver agrees to. The sender needs to send the receiver a hash pre image that they can use to unlock the senders side of the coins. You cannot just rely on rebroadcasting without timelocks. Better yet if there is no need for reversal you should make it  only spendable by the multisig that way only the second party could spend and the first party could just send them a hash preimage.


text:
Why is the Taproot Merkle path length limited to 128?
From BIP341:

Why is the Merkle path length limited to 128? The optimally
space-efficient Merkle tree can be constructed based on the
probabilities of the scripts in the leaves, using the Huffman
algorithm. This algorithm will construct branches with lengths
approximately equal to log2(1/probability), but to have branches
longer than 128 you would need to have scripts with an execution
chance below 1 in 2128. As that is our security bound, scripts that
truly have such a low chance can probably be removed entirely.

This is an excellent explanation why one really doesn't need a Merkle tree deeper than 128, but it doesn't explain why it's not allowed. Would this open the protocol to some sort of attack? I don't see how a script path spend with a few thousand branch steps would be worse than multiple individual transactions with shorter branches. Or it is just a standard to set a limit like this in a protocol when confident enough that nobody could ever need to go over it?

@Murch I believe that OP by "a few thousand branches" means "a single control block with a few thousand Merkle branch steps". The actual number of possible branches isn't relevant here, as only one gets revealed.

Observation by Pieter is correct. I'm definitely not suggesting the limit isn't generous enough, as no one will be going around constructing Merkle trees with 2^128 different valid conditions anytime soon. But constructing an output with a spendable Merkle path 128 branches long is very much possible.


text:
Standardize wallet format
What's the status of wallet format standardization? Is there any proposal or work-in-progress around? If not, how come nobody urges to define standard wallet formats yet?
This is especially needed for HD wallets where the seed phrase alone is virtually useless as long as each wallet software is free to use different derivation methods, branches, gap limits and other proprietary parameters.
Say I use software A to create a HD wallet and A derives the master private key after hashing the seed phrase with N rounds of SHA256 or whatever function. The software also tracks the creation time to speed up the sync in case we want to do a rescan.
Due to a critical bug software A corrupts my wallet. The only thing I was told to remember at the time was the seed phrase. Thank God I wrote it down, my coins are safe and I want to restore them with more secure software B. Unfortunately, software B defaults to M rounds of MD5 before deriving the master private key from the seedphrase. But I'm a lucky boy and I can choose both the derivation algorithm and the number of rounds. Err.. wait: I'm not a geek and this stuff is just sci-fi. After all, wasn't I supposed to just remember the seed phrase?
However, suppose we are lucky enough to find the exact derivation algorithm, here comes the gap limit: what's the software A default gap limit? Ask Google? WAT? Without the exact gap limit we may be missing transactions we're not even aware of. Scan the whole branch with a ridiculously high gap? Yes, why not, but who knows the A's branching structure? Are we really sure that it used the external/internal chain convention? Are we ready to scan billions and billions of addresses?
Last but not least, without knowing the seed creation time the sync process is much slower and may waste a lot of bandwidth on a mobile device.
I think these are very strong arguments for the skeptical user, it's unacceptable that people may lose coins just because nobody agreed on an universal format, both for static and HD wallets. Forum threads on how to restore a backup into another software are extremely common and I guess a BIP on wallet formats is in order. Why struggle with things like multisignature when the fundamentals are still uncovered?
Given the above I couldn't blame those who won't use such a currency to store their real-life money, honestly I wouldn't either.

Your argument is valid, and I agree with you, but I don't think this is a question.

A guess: People may feel that trying to standardize a wallet format would stifle innovation, by making it impossible to create features that required wallet changes not anticipated by the standard.  Likewise, given this issue, even if there were a standard, vendors might be reluctant to adopt it.

Standardization should not prevent one from adding his own customizations, it rather ensures that a handful of essential features are implemented by all vendors.

But if those customizations aren't understood by other vendors, then what's the point?

I guess I'm just not understanding your vision of what such a standard might look like.  If it's going to ensure that any wallet file written by any conforming implementation is completely usable by any other conforming implementation, it seems to me it will have to be quite rigid.

As Nick pointed out I moved this to an actual thread, I also tried to make my point clearer.


text:
How can Auroracoin be the 4th crypto-coin by market cap if it's unreleased yet?
Auroracoin has become the 4th biggest crypto-currency measured in market capitalization. How can an as-yet unreleased coin have market value if it's not available for exchange (either for fiat or for another crypto-coin) anywhere??? In fact, save for the storage accounts of its creator, noone has an Auroracoin yet. So whence comes its valuation and thus its market cap???
As much as I admire the stated intentions of Auroracoin's creators and their ingenuity for turning stuff traditionally seen as BAD (premining, universal and compulsory registration for all citizens) into GOOD, this market cap point makes me a bit suspicious.

Ódinsson must be so proud: Auroracoin's success (if not to potential recipients it's at least deemed valuable by the market) has spurned imitators trying to salvage other national economies: spaincoin.org copies Aurora verbatim (save on a much larger scale) and now zimcoin.org . The latter's organizers will try to run a "central bank" of sorts for it, backing it up with BTC, LTC and commodities. And they'll try also exchanging old Zimbabwean dollars for Zimcoins! Good luck with both ideas

10,500,000 AUR were premined and are not yet available to the public. 10,610,000 AUR have been mined so far, so only 110,000 AUR are actually in circulation. That makes for a true market cap of only 110,000 x $32 = $3,520,000.

Yes, I understand the 50% pre-mined part. What I don't get is why each is worth USD $27.86 if no-one but the creator has them (as of now, still 15 days for launch-day), no-one has traded them yet and thus there have been no trades at any exchange to allow the market to imbue a value onto it...

Actually, they are traded on many exchanges, like Cryptsy, Mintpal, etc. You're right that the value doesn't make sense. But people are easily fueled by hype and aren't always rational. And there could be market manipulation going on.

Turns out I was wrong. It is mineable right away and it is actively being traded in different exchanges, as cryptorush.in and cryptsy. What hasn't happened yet is the release of the pre-mined coins (50% of final amount), which will be given to Icelandic citizens.
Too bad the official page isn't clear about this (info on pools and exchanges is a bit hidden in the forums), nor does it list anywhere a list of exchanges dealing with it or pools for mining it - the cryptocointalk page linked first states all that.

Also it's minable on Multipool.us

The Aurora coin has been released, and can be mined, however even if this where not the case, And the coin had not yet been released the simple fact that the Government of Iceland  are backing it and the 50% pre-mine could account for this capitalization.

Can you provide a citation for "the Government of Iceland are backing it"?

As far as I know, the gov. of Iceland is not backing it and no-one but the creator can mine it. Can you please support both propositions with links to documents stating otherwise?

The Auroracoin page states the following: "The Airdrop will start to take place on March 25th 2014. A national ID database, created by the government will be used for this purpose."  http://auroracoin.org/  So it seems like they are claiming the government is if not backing it at least in some way complicit.


text:
What exactly is the relation between Bisq and Bitcoin Core?
What exactly is the relation between between Bisq and Bitcoin Core? It seems like Bisq can function perfectly well without Bitcoin Core, but if you do run Bitcoin Core at the same time, it appears to have issues (sometimes) with syncing the Bitcoin network. (Whatever that means in terms of Bisq, since it's clearly not a fullnode Bitcoin wallet.)
I've tried to figure, read and ask my away to the answer to this question for a long time now, but I've just been ignored.
In what technical/concrete ways does Bisq use/depend on Bitcoin Core, other than allowing you to easily click a button inside of Bisq to open up Bitcoin Core with the fields pre-filled in?
If it works without Bitcoin Core installed, is there some benefit in allowing Bisq to "utilize" Bitcoin Core?

As Bisq is not a full node wallet, it must connect to a full node in order to be able to receive transactions and learn when a transaction confirms. Without a local instance of Bitcoin Core, it will simply connect to a random node on the internet (there are some built in discovery methods for how it can find a node to connect to). If Bisq detects that you are running a node locally (i.e. you are running Bitcoin Core as well), it will instead connect to your local node and get its information from there.
Since Bisq relies on BIP 37 which Bitcoin Core has turned off by default since 0.19.0, you will need to enable this feature by adding peerbloomfilters=1 to your bitcoin.conf file. Otherwise Bisq will be unable to receive Bitcoin transactions. This is likely the syncing issues you are running into.
For some more information about local node settings in Bisq, you can read https://bisq.wiki/Connecting_to_your_own_Bitcoin_node.

Can I ask why exactly Bisq would be relying on some weird Google-made BIP from 2012 when even Bitcoin Core has (apparently) rejected it?

The BIP was made by a person who was working at Google at that time, but it is not a Google made BIP. BIP 37 was the primary way to implement SPV and Bitcoin Core implemented it for a long time. However there are alternative SPV methods now such as BIP 157/158, but many older software still rely on BIP 37.

Is there some security risk on enabling this flag in bitcoin node? (https://github.com/bitcoin/bitcoin/issues/9540)


text:
Coinbase customer service
Does anyone know how to get a hold of a human being on the phone at coinbase? Or the contact info of a good crypto lawyer? Their customer support is lacking. I have a stuck transaction going on two weeks with them. I'm worried they are going to change my coinbase receiving address on me and just steal my transaction.

Hi Dave, welcome to Bitcoin.SE. Please note that customer service questions are off-topic here.

Hi @dave is your deposit TX confirmed on the blockchain?

Hello Dave, please stop repeating the same questions. Instead, please edit your question to provide more information as you go through related questions and clarifications. Thanks.

No, blockchain.info doesn't even recognize the hash. Sry but I just want the community to be aware of crypto companies performances out there. Don't want this to happen to someone else.


text:
How does collaborative exit work in Ark?
It’s not clear for me how a collaborative exit works, in particular how atomicity is achieved.
I would assume the ASP will fund an on-chain transaction, paying to Alice, in return for a VTXO forfeit from Alice.

Will the payment to Alice be an additional output on the next pool transaction or a new transaction?

How atomicity is achieved if it is a new transaction? Does it also use a connector from the new pool transaction?

The collaborative exit is very similar to a regular in-Ark transaction. Instead of swapping your vtxo for another vtxo in the new vtxo tree, you swap your vtxo for an actual output on the Ark round tx. You will obviously have to pay some more fees for this type of transaction, but the atomicity works in exactly the same way: through the connector output that you use as an input to your forfeit tx.
In the diagram below, Alice is "lifting" her vtxo A* out of the Ark into output A_out.

Clarification: what you called the Ark tx is what I called the Pool tx, right?

Exactly, yeah. The transaction that is the result of an Ark round. Yeah "Ark tx" is probably a bad name because that's what in-Ark txs could also be called. Maybe "Ark round tx" would make sense. I don't think "pool" is the right word; in Bitcoin, pools usually indicate collaborative custody, which is not the case in Ark. In Ark there is no collaboration between users at all, the ASP is basically a middleman between all txs.

Yeah, we really need to work on nomenclature: onboarding vs lifting, round tx vs pool tx, funding tx vs lifting tx, etc.


text:
Why is my P2WSH OP_IF/NOTIF argument not minimal?
I have created an HTLC with the following Bitcoin script using bitcoinlib-js:
const redeemScript = bitcoin.script.compile([
    bitcoin.opcodes.OP_IF,
    bitcoin.opcodes.OP_SHA256,
    secretHashBuffer,
    bitcoin.opcodes.OP_EQUALVERIFY,
    bitcoin.opcodes.OP_DUP,
    bitcoin.opcodes.OP_HASH160,
    recipientHash, // Hashed recipient public key
    bitcoin.opcodes.OP_ELSE,
    bitcoin.script.number.encode(lockduration),
    bitcoin.opcodes.OP_CHECKLOCKTIMEVERIFY,
    bitcoin.opcodes.OP_DROP,
    bitcoin.opcodes.OP_DUP,
    bitcoin.opcodes.OP_HASH160,
    senderHash, // Hashed sender public key
    bitcoin.opcodes.OP_ENDIF,
    bitcoin.opcodes.OP_EQUALVERIFY,
    bitcoin.opcodes.OP_CHECKSIG,
]);

I am able to unlock the funds with in the OP_IF branch by using the correct secret, and spending from the recipient public key. However, I am encountering an issue when attempting to redeem funds via the OP_ELSE branch of the script using the timelock lockduration and broadcasting using the sender public key.
The specific error I get is:
error code: -26
error message:
non-mandatory-script-verify-flag (OP_IF/NOTIF argument must be minimal)

I believe the error stems from how I am encoding my values. I am building a PSBT which I then sign with xverse and convert into a raw transaction using bitcoin-cli finalizepsbt cHNidP8BAFMCAAAAAa/...
Firstly I create the PSBT
import * as bitcoin from 'bitcoinjs-lib';
import crypto from "crypto";

export function createRefundPSBT(
    secretHash: string,
    lockduration: number,
    scriptPubKeyHex: string,
    htlcTxId: string,
    htlcOutputIndex: number,
    refundAmount: number,
    recipientPubKey : string,
    senderPubKey : string,
    recipientAddress : string,
    networkType : string
  ) {
    const network =
      networkType === "testnet"
        ? bitcoin.networks.testnet
        : bitcoin.networks.bitcoin;

    const secretHashBuffer = Buffer.from(secretHash, "hex");

    // Recreate the HTLC script using the provided secret
    const recipientHash = bitcoin.crypto.hash160(
      Buffer.from(recipientPubKey, "hex")
    );
    const senderHash = bitcoin.crypto.hash160(Buffer.from(senderPubKey, "hex"));

    const redeemScript = bitcoin.script.compile([
      bitcoin.opcodes.OP_IF,
      bitcoin.opcodes.OP_SHA256,
      secretHashBuffer,
      bitcoin.opcodes.OP_EQUALVERIFY,
      bitcoin.opcodes.OP_DUP,
      bitcoin.opcodes.OP_HASH160,
      recipientHash, // Hashed recipient public key
      bitcoin.opcodes.OP_ELSE,
      bitcoin.script.number.encode(lockduration),
      bitcoin.opcodes.OP_CHECKLOCKTIMEVERIFY,
      bitcoin.opcodes.OP_DROP,
      bitcoin.opcodes.OP_DUP,
      bitcoin.opcodes.OP_HASH160,
      senderHash, // Hashed sender public key
      bitcoin.opcodes.OP_ENDIF,
      bitcoin.opcodes.OP_EQUALVERIFY,
      bitcoin.opcodes.OP_CHECKSIG,
    ]);

    const scriptPubKey = Buffer.from(scriptPubKeyHex, "hex");

    console.log("Creating PSBT");

    // Create a PSBT
    const psbt = new bitcoin.Psbt({ network: network })
      .addInput({
        hash: htlcTxId,
        index: htlcOutputIndex,
        sequence: 0xfffffffe, // Necessary for OP_CHECKLOCKTIMEVERIFY
        witnessUtxo: {
          script: scriptPubKey,
          value: refundAmount,
        },
        witnessScript: redeemScript,
      })
      .addOutput({
        address: recipientAddress,
        value: refundAmount - 3000, // Subtract a nominal fee
      })
      .setVersion(2)

      .setLocktime(lockduration);

    console.log("PSBT to be signed:", psbt.toBase64());

    return psbt.toBase64();
  }

Then I sign it with xverse wallet using a front end and attempt to finalize the PSBT.
// This script is for refund

import * as bitcoin from 'bitcoinjs-lib';
import varuint from 'varuint-bitcoin';

function witnessStackToScriptWitness(witness: any) {
    let buffer = Buffer.allocUnsafe(0);

    function writeSlice(slice: string) {
        buffer = Buffer.concat([buffer, Buffer.from(slice)]);
    }

    function writeVarInt(i: number) {
        const varintLen = varuint.encodingLength(i);
        const currentLen = buffer.length;
        buffer = Buffer.concat([buffer, Buffer.allocUnsafe(varintLen)]);
        varuint.encode(i, buffer, currentLen);
    }

    function writeVarSlice(slice: string) {
        writeVarInt(slice.length);
        writeSlice(slice);
    }

    function writeVector(vector: any) {
        writeVarInt(vector.length);
        vector.forEach(writeVarSlice);
    }

    writeVector(witness);
    return buffer;
}

function getFinalScriptsSpecial(inputIndex: number, input: any, script: any, isSegwit: boolean, isP2SH: boolean, isP2WSH: boolean) {
    if (!input.partialSig || input.partialSig.length === 0) {
        throw new Error(`Cannot finalize input #${inputIndex}: Missing partial signatures`);
    }
    if (!input.witnessUtxo) {
        throw new Error(`Cannot finalize input #${inputIndex}: Missing witness UTXO`);
    }
    if (!script) {
        throw new Error(`Cannot finalize input #${inputIndex}: Missing script`);
    }

    const signature = input.partialSig[0].signature;
    const pubkey = input.partialSig[0].pubkey;

    const finalScriptWitness = witnessStackToScriptWitness([
        signature,
        pubkey,
        Buffer.from([0]), // Byte array for OP_FALSE or 0, is this correct?
        //Buffer.alloc(0), // Or is this correct?
        script
    ]);

    return {
        finalScriptWitness: finalScriptWitness
    };
}

export function prepareFinalRefundPSBT(
    witnessHexWithdraw: string,
    psbtBase64: string,
): string | null {

    let psbt: any;

    try {
        psbt = bitcoin.Psbt.fromBase64(psbtBase64);
        psbt.isSegwit = true;
        psbt.isP2SH = false;
        psbt.isP2WSH = true;

        psbt.finalizeInput(0, getFinalScriptsSpecial);

        //adding witness script hex back in from bitcoin-cli decodepsbt <psbtBase64> because psbt.finalizeInput removes it for some reason
        psbt.data.inputs[0].witnessScript = Buffer.from(witnessHexWithdraw, 'hex');

    } catch (e) {
        console.error(`Error finalizing PSBT: ${e}`);
        process.exit(1);
    }

    return psbt.toBase64();
}

This gives me a finalized PSBT which I convert into a raw transaction. Here is the raw transaction decoded:
{
  "txid": "d773911f5e0c2bd4590794676e7c95bd2e33d8156c22e64c80e8c5bf4cfcbece",
  "hash": "5f1025270b4f2b298d2a90647c2640cc222815d0df3e2d38b72b9e37b04c14ff",
  "version": 2,
  "size": 285,
  "vsize": 134,
  "weight": 534,
  "locktime": 1,
  "vin": [
    {
      "txid": "fa69f9cee0b3fffb419084ccdaa19dbc319ca23965d3e6a9444210449b92a194",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "3045022100cf0ca0b7cbdda5e0c6733d508031c160cb93c7f4e9fcc6bafed4e50e7c23dd6e02200bc9a300ed5d6ec1202de946a59b4fdbb07136d5ffc43f8f5fe1e8fae6d291cd01",
        "0269bf7a1301185625758c324221cf6614e4a4104f90f83f633a8790f62919aa0a",
        "00",
        "63a820ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb8876a914a5102a75c05993aa082ca365b5ba7f49bed517586751b17576a914a5102a75c05993aa082ca365b5ba7f49bed517586888ac"
      ],
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 0.00007000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 836676150f0f5892416d8bd9bc5e923b494677f3 OP_EQUAL",
        "desc": "addr(2N5E1FYfiQgM5U8aTvU1btZYpiTVPE9ReaK)#00u0x08a",
        "hex": "a914836676150f0f5892416d8bd9bc5e923b494677f387",
        "address": "2N5E1FYfiQgM5U8aTvU1btZYpiTVPE9ReaK",
        "type": "scripthash"
      }
    }
  ]
}

Then I try to broadcast the transaction
bitcoin-cli sendrawtransaction 0200000000010194a1929b44104244a9e6d36539a29c31bc9da1dacc849041fbffb3e0cef969fa0000000000feffffff01581b00000000000017a914836676150f0f5892416d8bd9bc5e923b494677f38704483045022100cf0ca0b7cbdda5e0c6733d508031c160cb93c7f4e9fcc6bafed4e50e7c23dd6e02200bc9a300ed5d6ec1202de946a59b4fdbb07136d5ffc43f8f5fe1e8fae6d291cd01210269bf7a1301185625758c324221cf6614e4a4104f90f83f633a8790f62919aa0a01005963a820ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb8876a914a5102a75c05993aa082ca365b5ba7f49bed517586751b17576a914a5102a75c05993aa082ca365b5ba7f49bed517586888ac01000000

And I am met with the following error:
error code: -26
error message:
non-mandatory-script-verify-flag (OP_IF/NOTIF argument must be minimal)

Could it be this part of the txinwitness that is not minimal?
"00",

Should it instead be
"0",

Or perhaps even
"",

Or is there some other reason my OP_IF/NOTIF argument is not minimal?

In SegWit (by standardness) and Taproot (by consensus), the arguments to OP_IF and OP_NOTIF must be minimal, i.e. be either the empty vector or the one-byte vector 01. Your transaction uses 00, which is neither.
The code that composes your witness stack should probably be:
const finalScriptWitness = witnessStackToScriptWitness([
    signature,
    pubkey,
    Buffer.from([]),
    script
]);

Thank you <3, this worked for me

Yep that did it. :) Thank you for the help


text:
Why is there a 5 days gap between genesis and block 1?
I remember reading somewhere that it was because Satoshi wanted to make sure everyone had time to download the client and setup everything, but now that I think about it I’m not satisfied with this response (and I can’t find where I read that anymore). Everybody that downloaded the client waited 5 days to start mining? Why would they? Because Satoshi asked them?
Do we have a clear explication as to why there is 5 days between Genesis and block 1?

While the Genesis block is timestamped 3rd of January, the hash of the Genesis block is astonishingly low. It has been theorized that Satoshi set himself a more challenging target for the Genesis block than strictly necessary and it might have taken some time until the block was found. It is also possible that he set the earlier date to match the headline of the Times which juxtaposed his goals so nicely.
Beyond that, the original software was designed not to start mining until it had found another peer on the network. Bitcoin 0.1 was only announced to the mailing list on the 8th of January at 19:27 UTC, and then the second node would have only appeared on the network once someone else’s interest was piqued enough to downloaded and run the software. Block 1 is timestamped 2009-01-09 2:54 UTC, 7 hours and 27 minutes after the email announcement.
While, Difficulty 1 was hard enough that it took until December 2009 for the difficulty to increase for the first time, it only took until 4:12 UTC for the next ten blocks (~7.8 min per block) to be published, so the gap between announcement and Block 1 is probably best explained by the second node only coming online shortly before Block 1.


text:
How do I know which UTXOs are safe to spend?
When we do a transaction, we pick UTXOs we want to spend. Sounds simple, just pick UTXOs with total value >= the amount you want to spend.
But then inscriptions, rare sats etc. come into play. Now, some UTXOs are not safe to spend.
How do I pick UTXOs, which are safe to spend? Is there an easy way to make sure a UTXO doesn't have rare sats/inscriptions/anything else before spending it?

Take a look at Murch's post on coin selection.  It's not specifically about inscriptions etc, but very worthwhile nonetheless.

@HannahVernon thanks! Will check this

How do I pick UTXOs, which are safe to spend? Is there an easy way to make sure a UTXO doesn't have rare sats/inscriptions/anything else before spending it?

Those UTXOs are still "safe" to spend if they comply with Bitcoin consensus rules. However, if you want to avoid spending UTXOs that adhere to the rules of an external metaprotocol (e.g., ordinals) outside Bitcoin's consensus rules, you need to run the software of that metaprotocol or use a wallet that is aware of its rules.

thanks, will try to find APIs for the specific "metaprotocols" that are popular then

Is there an easy way to make sure a UTXO doesn't have rare sats/inscriptions/anything else

No.
There isn't an easy way, because there is no central coordination of these forms of graffiti and externally assigned meanings. Nor can there be.
This is especially true when you include "everything else"
All these things are outside the use cases provided for by the creator of bitcoin. They are external, just as the US treasury's department of engraving and printing don't keep track of doodles on $1 banknotes and don't keep track of trade in $1 banknotes with "lucky" serial numbers


text:
Why didn't my TX get rejected?
Here is the address I'm going to talk about:
https://mempool.space/testnet/address/tb1p3yyenp8ppqyze8th3pnng33l7c4sl80yx02s5achpf62v340xvpstngz04
In this address there are 3 transactions I chained together:

Receiving an inscription.
Receiving 175 sats, so that the address is able to send the received inscription.
Sending the inscription to itself, paying 175 sats to miners for the tx fee (so the "dust" utxo was both successfully created and spent!).

These transactions were broadcast to the public mempool.space api (this request: https://mempool.space/testnet/docs/api/rest#post-transaction).
What I don't understand is why didn't the node reject the transaction, which sent 175 sats to this address? Isn't there a dust limit, below which you are not supposed to go? Am I safe to do things like these?

The dust limit for P2TR used by Bitcoin Core is 330 sats, which is indeed more than 175. However, it is only a standardness rule that nodes and miners are free to ignore.
In the case of testnet, Bitcoin Core's default was historically to ignore many standardness rules, including the dust limit. This was only changed in v26 (in PR #28354), so there are likely still many nodes on testnet accepting non-standard transactions, either because they haven't upgraded yet or because they're manually overriding the new default – as is likely the case with the mempool.space testnet node.

Am I safe to do things like these?

Testnet is a safe place for testing pretty much anything. However, you might want to make sure your code still works when you set acceptnonstdtxn=0 so you don't run against standardness rules when moving to mainnet.

I see, thanks, so if I bump all P2TR transactions to the 330 sat minimum, I'm going to be fine on the mainnet, right?

@Maxgmer Yes, see updated answer.

As Vojtěch explains, the transaction is non-standard. You can see this here on mempool.space: https://i.sstatic.net/ZLJpSEqm.png


text:
Security of Vanity Addresses
I found a vanity address with this verified tool: https://github.com/JeanLucPons/VanitySearch
And now I hold my private key, with BTC I am used to only the recovery seed and I don't know what position I am currently in.
Can I get the seed somehow or does the private key replace it?
The primary thing I'm concerned about is I want to receive all funds in the store at my own address and I want it to be as secure as the address I get in any other wallet.
Thank you very much for your time.
EDIT:
I'm doing research, but this topic seems very complex to me and I'm afraid of getting something wrong and putting myself at unnecessary risk, but what I've understood so far: a private key is +/- the same as a seed except that the seed "controls" the entire wallet, while the private key only controls a specific address, so I should have the funds safe even now and no further steps are needed.
I imported the private key into Electrum and encrypted the file.

Can I get the seed somehow [...]

No.

[...] or does the private key replace it?

Not exactly, they are obviously different things. However you need to keep a secure backup of the private-key in the same way you would the seed or seed-phrase.

I imported the private key

Remember that this key will not be restored by restoring your wallet from a seed-phrase (AKA recovery-phrase or backup-phrase). You will have to import it again. There is a risk you will forget or not take adequately comprehensive backups and lose money.

I want it to be as secure as the address I get in any other wallet.

You'd arguably have to inspect the vanity generator source code carefully and only run it offline on a machine that has never been connected to a network and which never will be (unless associated non-volatile storage is all carefully wiped - including unallocated space and taking into account wear-levelling where relevant.)

Thanks a lot for the advice, I was still figuring some things out and my current setup looks like this: generated address + seed offline in a clean OS and import this into the hardware wallet. And thanks to you I know that if anything happens to the hardware wallet I don't actually care about the seed recovery and I only have the seed stored offline in encrypted form stored in multiple places, does this setup sound safe enough?


text:
secp256k1 library building for C++
The title says it all. How can I compile secp256k1 for use in a personal project. I have #include secp256k1.h but keep getting unresolved external linkers. I believe this is due to the lack of a compiled library. I have never compiled a library before and was looking for some guidance. I am on windows 11 and have not tried to compile this library only dragged and dropped the downloaded github repo. looking for some guidance on how to compile this library.
The library: https://github.com/bitcoin-core/secp256k1
Many thanks

You're going to have to give a bit more information. What steps did you take? What do you exactly see? What operating system is this on? Update your questions with more details.


text:
Trying to import from from blockchain.info to multibit, getting error "There were missing dates. Have to go back to genesis block."
I have a wallet on blockchain.info. I would like to load it in to multibit. I copied the text of the encryped wallet and saved it as wallet.aes.json. I then try to load it in to multibit. After correctly entering in the password, I receive the error "There were missing dates. Have to go back to genesis block."
I have tried resetting the blockchain both "from the date of the first transaction" as well as October of 2010, which is more than 2 years before the creation of this wallet. However, I still get the same error.
Your assistance is much appreciated!

The format of the blockchain.info wallet isn't ideal for importing into MultiBit. It works but MultiBit has to go back to the genesis block to make sure it gets all the transactions.
That is what the "There were missing dates. Have to go back to genesis block." message is for. It's basically saying - "Hey, this is going to take a while".
When you do the import it is best just to let MultiBit work away through the blockchain. On a reasonable spec PC with WiFi it takes about 30 minutes to chug through the blockchain.
This functionality is mainly in MultiBit so that is something happens to the blockchain.info server, users can still access their bitcoin.

Thanks. I have been running multibit for a couple days and still get the error. Is there something I need to do under "reset blockchain and transactions" to get it to the right point? I tried "reset from the date of first transaction" and "Specify Date Reset" to a couple years ago. I tried resetting it back much further, but then the client hangs saying "Resetting".