text:
Why does bitcoin have a value?
I got this pretty good question the other day - why does bitcoin have a value at all?  After all it's nothing - who is willing to pay for nothing?

I think I have a pretty good answer for this question myself, but I'll see if anyone else comes up with something before I post it :-)

And dollars are paper the value derived from them is because you have to pay taxes using them, otherwise they are just paper.

Like any other asset that has a market price, it's all a matter of supply and demand.
The supply side is relatively trivial, the protocol allows for a fixed amount (25 bitcoins at the time of writing) to be produced every tenth minute, this reward is cut in half at regular intervals, and with this algorithm there will never be more than 21 million coins.  However, scarcity by itself is not sufficient, there needs to be a demand as well.  There are many factors behind the demand, I believe none of them are sufficient alone, but some may be more important than others.

A working currency needs to be scarce, divisible, portable, durable, fungible and easy to verify.  Bitcoin scores pretty well on those attributes and was the first digital currency to do so.  However, it's not alone a guarantee to success.  Other cryptocurrencies (aka "alt-coins") may be competitive on all the above.
The belief that Bitcoin will be a viable means of paying for goods and services in the future.  This may cause a sustainable and predictable value.  As an example, assume that 21 million people are buying bread with bitcoins, and in average they'd like to hold enough bitcoins in their wallets to buy 10 breads.  For a brief moment, let's assume this is the only use-case scenario.  With 21 million bitcoins in circulation, that means every user by average has one bitcoin in the wallet.  The value of a bitcoin would then be ... exactly ten breads!
A belief that Bitcoin is "digital gold", a useful means of storing value.  Someone even says ... "payments aren't important, bitcoin is the digital gold, and gold is rarely used for payments" - I believe that's dangerous.  Gold has been established both as a currency and as a "holder for value" for millennias, while Bitcoin hasn't even been around for a decade.  Traditionally almost every currency was both backed by gold and pegged to gold, so all until the 1970s one would indirectly use gold for paying for goods and services.  Gold also has unique characteristics suiting this purpose, gold cannot easily be replaced by other metals while Bitcoins can easily be replaced - i.e. if another altcoin gets more popular than Bitcoin for payments, I predict the BTC-value will drop pretty fast.
Speculation - people hoard bitcoins because they expect the market price to increase further in the future.  As of today, this is probably the biggest driver of demand, and it's by itself enough to spur a price growth, but it may not be sustainable.  Critics compare Bitcoin to a ponzi scam, a pyramide scheme and tulip mania.  Even though none of those comparitions quite hit the mark, if the value is only driven by speculation there is a risk that at some point there may be a crack and the value may fall very fast (like it did when MtGox failed).
Trust in the scarcity.  The risk that the 21M hard limit will be increased through a protocol change is considered small.  However, Bitcoin doesn't have a monopoly on cryptocurrency as such, it's easy to create new altcoins, and there are already hundreds of altcoins which could theoretically replace Bitcoin.
Trust in the security of the transactional system.  The blockchain and proof-of-work delivered by the miners ensures that a transaction remains irreversable and that bitcoins cannot be double-spent.  The cryptographical algorithms used for signing transactions ensures that nobody but the owner of the bitcoin can spend the bitcoin.  It has been argued that the market cap of any cryptocoin have an upper bound in the security of the system; the market cap can never become so big that it would be profitable to buy the processing power needed to successfully double spend or brute-force-engineer private keys corresponding to existing valuable public keys.  Reversely, the same argument can be used to prove that Bitcoin is a secure network (at least when neglecting the risk of phishing, robbery, social-engineering, gaining access to wallets through security holes, exploits or lax password security, missing backup, etc).  The fact that the ledger is secured by an extreme amount of processing work may be one of the points where Bitcoins really excel compared to competitors.
The network effect - this is the (only) thing where Bitcoin excels on the altcoins.  (Almost) everyone that accepts cryptocurrency accepts Bitcoins - but only some few accepts other cryptocurrencies.  Never underestimate the network effect.  Bitcoins may become worthless very fast if some other cryptocurrency takes it's place.
Usefulness for criminal purposes; Bitcoin is perceived to be anonymous, it can be very anonymous if one wants it to be, it crosses borders easily and without regulatory oversight, hence it's the ideal currency for ransom, tax evasion, drug smuggling, crime-as-a-service, etc.  I sure do hope that this is a smaller driver for value than the usefulness for legitimate payments for goods and services.

More than a year later, and all answers have 0 points, weirdly enough.  Quite subjectively of course, but I deem my own answer to be the best, so I chose to accept it as the best answer.

Bitcoins have a value because their supply is limited and people want them. If someone is willing to buy a Bitcoin for $400, then it makes sense for you to value a Bitcoin at $400 because you know that you can sell it to them for $400.
This is essentially the same reason dollars have value. You value a dollar because you have a reasonable expectation that you can trade it for clothes or groceries in the future.

Why do euros or dollars or pounds on your bank account have value? After all, they're nothing. They don't even exist, money on a bank account is purely fictional. Who's willing to pay (or work) for something that doesn't even exist?
The reason a bitcoin has value is because of its utility (an extremely efficient, fast, easy, frictionless, safe, unrestricted money and payment system) combined with its scarcity.
Water is useful, but generally not scarce. My toenail clippings are scarce, but not useful. But the more people consider something to be useful (and with Bitcoin, there are plenty of reasons why people find it useful) the higher the demand. Yet the supply is limited, and price is essentially determined by demand vs supply, thus it has value.

YOUR toenail clippings are scarce, but they are relatively fungible with other toenail clippings, and toenail clippings in general is not that scarce.  I'm pretty sure your toenail clippings will have great value if you're really famous and it's easy to verify that it was yours. :-)

Fiat money, within the right jurisdiction, has both a very strong network effect and a legal status, hence a very strong expectation that they can be exchanged for goods and services.

Sure, many people put trust in their government and thus in its fiat money system. But personally I put more faith in money that by definition doesn't need a government. Gold has always been a highly trusted store of value (why? there's no government who issues gold, nor any jurisdiction that applies to it). Well, iin many aspects, Bitcoin is like gold.

Bitcoin has value because it is used as a medium of exchange(currency) between buyers and sellers of goods.  Currency solves the problem of having goods for sale that someone needs. Let's take an example from ancient times before currency existed.  For example you have chickens and you collect their eggs, someone else wants those eggs but they don't have anything you want in exchange. Let's say the other person has a goat and let's say a third party does have something you need, cow's milk. How do you exchange your eggs for cow's milk when the person holding this item doesn't wasn't what you have.  In this example we find out the milk holder does want a goat, so we could make a convoluted trade with all the parties where each party determines the value of the goods they hold and the goat could be traded for the milk, which could then be exchanged for the eggs you have and everyones happy right? Not everytime will this work so currency was created and maybe it just started out as IOUs on paper.  Who would trust these IOUs? If someone didn't pay their debt the system crumbles.
Now enter the concept of crypto currency.  Every token (or maybe IOU in this example) had a defined value (how many tokens/coins you hold) the system is able to determine who has how many tokens and they can be spent on a trustless manner (meaning no one can spend a coin they don't control, based on cryptographic proofs and the shared ledger) this allows anyone to pay any other individual as many tokens as they feel the item they are exchanging for is worth.  This value gets determined by the market price someone is willing to pay for a token today. When bitcoin began it was near worthless, but as people began to realize it's utility as a mechanism of exchange with no borders and no one party in control it began being used at near zero value. Over time more and more people began seeing this utility and this the market drove the price to what it is today.
I encourage you to further research the beginnings of currency and what its implications were when it began. It gave the person with eggs the ability to pay for the milk that they needed without having to jump through hoops and hoping someone needed what they have for exchange by creating a solution out of nothing.
Hope this answers your question.


text:
How to use Backup .dat?
I had a Bitcoin wallet with come coins, backed it up (have the .dat file and a .csv file) but recently had to reinstall my Operating system which sadly wiped all my programs.  Now I have a new wallet but do not know how to access my coins using the .dat...  any hints?

Find where you wallet file is located which will be different depending on which operating system your using. Then replace the new wallat.dat file with your old one. If you haven't downloaded the block chain yet, then just start up Bitcoin-qt and once it downloads your coins will be in your wallet. Otherwise you will need to re-scan the blockchain at which point your wallet will have your bitcoins in it.

source: Stack Exchange

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

sort: votes


text:
Is it possible to create more ripples?
Currently there are only 100 billion ripples (XRP), which are slowly being distributed, and a fraction of a ripple is destroyed with each transaction.
In the future if we run out of ripples, or if the developers decide that they need to have more ripples for some reason (to pay their bills?), then would it be possible to create more? If yes, what is the exact process of doing this? Does it require consensus? Or is it just an edit-compile-deploy?

To answer your first question, AFAIK, that's not one of the rules that the ripple network votes on, just like bitcoin doesn't vote on transactions requiring signatures.

@NickODell Not a duplicate, as I am asking specifically how to create more ripples (not whether we'll run out of them).

I'd argue that the answer still is a duplicate in that it explains that there is no likelihood of running out of Ripples. Plus I think it makes it clear that there is no provision in the protocol for more Ripples. Sure, just like bitcoin, you could create a hard fork to change that, but at that point the protocol is fundamentally changed. It wouldn't be ripple anymore, just some new ripple2 protocol that might be backwards compatible with Ripple.

@DavidOgren Something must be wrong with my computer, because I'm not seeing that the other question answers how to create more ripples. In Bitcoin more coins can be created if "everyone" agrees. I'm asking if this is also possible in Ripple, and how it is done (e.g. in Bitcoin you change the code of all the nodes, essentially changing the protocol).

Can anybody point where exactly the protocol guarantees that no more than 100 billions of ripples can be in circulation?

@Bitripple See here: http://bitcoin.stackexchange.com/questions/10240/how-to-create-more-ripples

No. The amount of Ripples is fixed and, unlike with Bitcoin, available from the day it was created. The amount is fixed to 100 billion.
However, this amount is for the main "Ledger" which is currently used by everyone using Ripple. You can see a ledger as similar to a Bitcoin block chain. Everyone can, if he would like, create a new Ledger, just like everyone can start a new block chain.
Currently, though, there is only one Ledger really used and that's the one the Ripple founders started together with Coinbase and consists of 100 billion Ripples.
These 100 billion Ripples or XRP are dividable into "drops", which are 1 millionth of a Ripple. This means that 100 million billion drops exist.
With the transaction fee for Ripple currently on 10 drops, this means that even with thousand transactions per second, they will only run out in 634,195 years.
(Disclosure: Since Ripple is fairly young, I'm also new to it. I did some reading and tried to understand it's foundations, taking the Ripple wiki as primary reference. It's very much possible that I misunderstood some aspects of the system or that the wiki is not fully correct.)

Two corrections: drops are a millionth, 100 billion total.

Sorry, mistakes by typing too fast, I used both 200 and 100 and I used the right drop value for the calculation. Thanks for noticing!

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


text:
How big is the Ripple network?
The size of the Bitcoin network is available here:
http://bitcoinstatus.rowit.co.uk/
As the page says, they do this by listening for Address messages that are broadcast over the network.
Since the Ripple server is now open-source, we can expect a number of individuals and companies to start running their own nodes. Is there a way to estimate the size of the network, either using an RPC command on the server, or by modifying the server code itself to collect some information about the peers?
I would be interested in the following numbers:

Number of public servers
Number of validators

I imagine the first one could be obtained by querying peers recursively. Unfortunately the RPC interface is only available to 127.0.0.1 by default. As for the second metric, I'm guessing we can get this by looking at the ledger.

I would estimate that there are 30 public servers and 11 validators as I'm typing this answer.
I estimated the number of public servers by connecting to a number of servers and collecting the node keys of every server connected to them. While node keys are free to change, each server has a unique node key while it is connected. This is used to drop duplicate connections. So this should count each public server once.
I estimated the number of validators by collecting the validator public keys of every validation I saw published over a five minute period. I counted the number of unique validation keys.
I can't see any reason these counts could be too high, but they certainly could be missing some.

So you connected to server A, which is in turn connected to servers B and C, and it gave you the unique node keys of B and C (as well as its own). How did you do this? Did you use an RPC command? What about server D, which is connected to C, but not to A?

I used the peers command. And I connected to almost half the servers in the process. Since most servers try to have at least 10 connections, that should have almost 100% coverage.

A new feature peer finder is being developed. This will allow every server to maintain a fairly complete map of the network topology (for all non-private servers).


text:
What is a deterministic wallet?
It sounds as if it's a process that enables a wallet to be rebuilt from a passphrase, or from several fragments scattered about. Could someone provide a detailed technical explanation?

You've hit the nail on the head. A deterministic wallet is any system which uses a passphrase or other snippet of data to build a keypair in a repeatable manner. So long as you remember the passphrase, the keypair can be re-generated from it, so storage is no longer a security concern. There are several methods for generating deterministic wallets, but my favorite is Casascius' Bitcoin-Address generator (C#, Windows, binaries here)

Normally, when you send money you also generate a new private/public key for the "change" to return. therefore every time you send money your wallet.dat grows a little bit.
The Basic Idea of the deterministic wallet: instead of a database with lots of private/public keys you start with a single private key, from which all future keys can be calculated.
This has many advantages. It is trivial to back up and transferable. it could be used from multiple computers.
afaik, webcoin.ch uses this concept. The current "official" client not.

Caveat - the wallet doesn't generate an address every time, it generates them in chunks of 100 and reuses them. So, backing up a wallet once every ~ 50 transactions should be safe.

exactly, but the pre-generation of keys is not exactly the scope of this question, therefore the explanation "trivial to back up" should be sufficient.

It does not generate them in chunks of 100. It maintains a pool of 100 keys, and every time one is used, a new one is added. This will change though with encrypted wallets in 0.4.0, as keys cannot be generated safely when the wallet is locked.

A deterministic wallet is any wallet for which a given private key can be predictably recovered with just:

the original secret seed
the identifier / sequence number of the desired keypair

There are two types of deterministic wallets:

sequential deterministic wallets
hierarchical deterministic wallets

With a sequential deterministic wallet, the seed is a passphrase or sequence of characters that can be repeatedly incremented and hashed to generate new private keys.
For example, if I use the passphrase:
'shepherd mais pack rate enamel horace diva filesize maximum really roar mall'

...then I can create the first 100 private keys by doing the following:
hex(sha256('shepherd mais pack rate enamel horace diva filesize maximum really roar mall 0'))
hex(sha256('shepherd mais pack rate enamel horace diva filesize maximum really roar mall 1'))
...

And as long as I am consistent with how I modify the original passphrase, I can easily recover any given passphrase that I wish.
A hierarchical deterministic wallet, on the other hand, starts with a single keypair as the master keypair. The private key of this keypair is the secret seed.
Each keypair has children. And the public key of a given child of a given parent node in the tree is generated by performing elliptic curve multiplication on the parent's public key.
The private key of the child can be recovered by the owner by performing the same multiplicative operation on the parent's private key. This is because mPubkey/Pubkey = mPrivkey/Privkey.
The cool thing about this is that you can give a server a public key and that server can generate new addresses for you without ever having to know your private key.
...
If you're looking for a python implementation of sequential deterministic wallets, I put one together here: https://github.com/blockstack/pybitcoin (or just do "pip install pybitcoin").
I don't have a working implementation of hierarchical deterministic wallets quite yet, but for that I'd check out this python implementation or this ruby implementation.

@Ryan so this means parent always knows the public and private key of child but reverse is not true.

Is this function ( deriving a child private key from the master private key) a one way function?

Another example using deterministic wallets is the BCCAPI, which is a library for making light-weight secure Bitcoin clients. http://code.google.com/p/bccapi/

Primary Bitcoin Improvement Proposals (BIP) associated with deterministic, specifically hierarchical deterministic (HD) wallets to facilitate portability between implementations to avoid vendor lock-in are BIPs 32, 39, 44. BIPs get into the technical details. May want to examine libbitcoin for command line interface examples for applying BIPs 32, 39, and 44.


text:
Can Bitcoin help charitable organisations ensure payments go to the right people?
One common problem when organisations, such as charities or governments, donate money to good causes is that it becomes very hard to track where the money went.
For example, there are accusations of money unintentionally being used to purchase weapons instead of providing food. Naturally, the organisations handing out the money do their best to keep track of it, mainly relying on accounting and reporting procedures, but these chains become complex and there are many ways to obfuscate the money trail.
Is there a way, even if it is not yet implemented, that Bitcoin would be able to provide a better solution than existing in this scenario?

By itself Bitcoin doesn't provide a complete solution however it could be used in conjunction with a trusted non-governmental entity to track charitable flows.  The issue is that while Bitcoin provides public and irrefutable evidence of monetary transfers it doesn't (and shouldn't) provide information on who owns those accounts.  It would require some mechanism of registering ownership of accounts similar to how an SSL cert is used to not just encrypt traffic but to also validate ownership of the site.
Using a system of cert authorities and public key encryption one could create "public and verified" addresses.  This has potential uses beyond just Charities.  The Bitcoin network itself should always remain psuedo anonymous.  It was designed to have properties of digital cash and trying to force verified identities into the network would be a mistake.
A better solution would be building a framrwork that allows entities to volentarily have their identitiy validated.  They could then be issued a digital cert which would enable them to sign an address making it public & verified.
Many businesses would benefit by linking an anonymous Bitcoin address to their real world identity to improve the trust and confidence of customers and suppliers. Remember Bitcoin is irrevocable so this present unique challenges if it were ever to become mainstream.  If a major store (Amazon for example) decided to accept bitcoin and was hacked, the attacker could replace Amazon payment address(es) with their own. Unsuspecting customers would be paying the wrong entity and would have method of reversing those fraudulent transactions. The larger the sales volume the more tempting the target.  In the Amazon example even if the attack was detected within minutes a sizeable amount of funds could be diverted.
To protect against this thread an entity could use a "public & verified" payment address.  Wallets & browsers could implement changes to warn users that an address in unverified, similar to how browsers use SSL today to provide warnings or assurances to users.

Yes and no, let me elaborate:
No 1) If you get a Bitcoin address from someone, you can assume it belongs to them. On the other hand, someone could pretend to be that person, and you have no way to double check using Bitcoin-only means. A wire transfer address could potentially be checked and traced to who owns it.
No 2) When you send coins to someone through Bitcoins, you can't track much, asides whether they spent the coins or not using a Block Explorer. Sending money through banks leaves a more defined trail, as the accounts are assigned to someone. Someone might try laundering money, but generally you could potentially check what they did with the money (to some extent, assuming the bank cooperates).
Yes 1) If you send someone Bitcoins, they still remain anonymous, and nobody without getting to your wallet can know how much coins you have. If you send coins to the people in need, or charities you can trust, you can be almost sure that nobody will steal coins from them (for example, if a corrupt government knows how much you have in your bank account, they can put some pressure on you to get your money).
Yes 2) If you send Bitcoins to people or organizations that are working against the corrupt government (for example, women's right movement activist in a women-oppressing country), the government has no means of cutting them away from the coins, or figuring out who supports them. This allows you to finance such people without endangering either you, or the unpopular person or organization.
All in all, Bitcoins allow you to send coins to anyone and nobody can stop either you or them from participating in the transaction. On the other hand, it requires more trust and allows for even smaller ability to trace the money once it is sent.

I'm unconvinced about both "No"s since they could be circumvented by mandating that each link in the money chain is attached to a known Bitcoin address that is in turn attached to a known entity (person or corporation). The known addresses don't have to be made public, just known to those checking the chain.

Yes, they can be mitigated, but those are also things you have to keep in mind.


text:
Is it possible to execute a double-spending attack in Ripple during a network split?
From the spec (emphasis added):

Under a net split, a ledger may be closed by the minority of network, this ledger may be discarded in the future.

Does this mean it would be possible to spend twice, once on each side of the split?
Even if the transaction is merely rejected later, you could trick a merchant into accepting your payment, then take delivery, and then let the network reject the transaction once the split is resolved. Is this correct? How would the minority of the nodes know that they're separated from the rest of the network?

Ripple should be immune to this attack because a transaction is not considered validated until an overwhelming majority of validators (that you care about) have signed a receipt saying that they have processed it (by validating a ledger that includes it either in that ledger or in one of its prior ledgers). If the network had split, you could not receive receipts from an overwhelming majority of validators.
Ripple servers have an internal "gate". They continue to track the network, try to reach a consensus, sign validations, and so on. But they don't report transactions as confirmed to clients until they pass this internal gate. To pass the gate, a ledger must have sufficient validations from trusted sources. Once a ledger meets that threshold, the gate is advanced to just past that ledger and everything up to that new point is considered fully validated.
Anything after the gate is in flux, subject to consensus with other validators. Everything behind the gate is forever committed. The overwhelming majority of validators have committed to it.
If you are on the minority side of a split (or even the slight majority side of a bad split), no transactions will pass the gate. The network will be unusable, but nobody will rely on a transaction that gets undone when a split is resolved.
In exchange for immunity to this attack and in exchange for Ripple's fast confirmations with no proof of work needed, a price is paid. One can imagine situations where transactions might fail to pass the gate even though there's no network split. For example, if a large number of validators suddenly stop validating all at the same time, you might think you're split off from them, and manual intervention might be needed to permit any transactions to pass the gate.

But since it's very easy to become a node (just need an IP and a computer), wouldn't a large entity with enough interest be willing to make these sort of attacks by disguising themselves as honest for a while (to gain trust) and then attack with these sort of double-spends? Again, all it takes is IPs, not proof-of-works.

@LucaMatteis No, for two reasons. First, IPs are not enough. You have to actually get people to trust you and collusion is the one thing they are selecting trusted endpoints to avoid. Second, you can't double spend. You can only break consensus. Once the gate moves, everything behind it is forever committed. All you can do is keep the gate from moving.

If you're the majority, what does it matter? You can control the ledger and double spend all you want. The client you're double-spending against will notice because their transaction will disappear. But for the rest of the network, your nodes are as trustworthy as before. Also, with Ripple, you must assume past good behavior implies future good behavior, which is an unreliable assumption.

@LucaMatteis You can't double spend. You can't change anything before the gate and until a transaction is behind the gate, nobody will rely on its results. I'm not sure what you mean by "client you're double-spending against". (And in any event, every known monetary system requires that assumption. How do you know a Democracy won't change the laws in a way that destroys any value you hold?)

Who owns this gate? You're saying that all the transactions need to be approved by this central gate to achieve consensus?

@LucaMatteis Every server has its own gate. Read the second paragraph of my answer.

But my point is: what if the majority of the servers are dishonest? Then they could do bad things right?

@LucaMatteis To themselves, sure. But who cares if dishonest people do bad things to themselves? For anyone else, the bad guys can't make their gate go backwards, so there's no double spend. They can, however, keep the gate from advancing. So there's a DoS attack possible.

But couldn't the dishonest behave honestly and so others would think they are just like other regular honest servers. But behind the scenes they would do bad things specifically to some individuals (like invalidating some transactions or something else). Would this be possible?

@LucaMatteis No. Proposals and validations are always signed and flooded. You couldn't get away with sending two different versions. Servers move their gate based on a supermajority, and you can't create two different supermajorities. (You can create none if you control enough trust but then you'll rapidly lose that trust.)


text:
How to buy a million ripples?
If someone wanted to buy up lots of ripples, say a million, how would they go about doing it?
Currently the exchanges don't seem to give good rates, and trading one-to-one with someone else would be inefficient. Is OpenCoin selling directly? At the current Bitstamp rate, it would cost $4444.44 to buy 1,000,000 XRP.

For now you can request a private sale at a good rate by emailing Bitstamp customer service or directly Nejc Kodrič  (nejc dot kodric at bitstamp.net)

Citation? Why would they offer a better rate outside the exchange?

The will offer a better rate because they want your money. Nejc Kodrič is the man to talk to. I have no idea what the rates are or whether that's a large enough amount for them to give you a discount.

@DavidSchwartz Any comments on how much the next giveaway is going to be, and how it's going to be distributed?

Not yet, sorry.

Wow, did the OP ever make this purchase which would be worth in excess of $30 million today?


text:
How are Ripple transaction fees "destroyed?"
What is the exact process by which the transaction fees are "destroyed?" Are they sent to a special account, or simply erased from the ledger?

The sender's account is debited the transaction fee, but no other account is credited the same amount.

In addition, the total_coins field in the ledger header is decremented.


text:
Why does the standard Bitcoin message signature include a "magic prefix?"
The standard Bitcoin message signature works as follows:
sign(sha256(magicPrefix . length(message) . message))

The "magic prefix" is simply the string '\x18Bitcoin Signed Message:\n', where 0x18 is the length of the prefix text.
In other words, it's this:
sign(sha256(length(prefix) . prefix . length(message) . message))

My question is:

Why does it use a magic prefix?
Why does it include the lengths of the two components?

I'm asking mainly from a security point of view. Does adding a prefix or including the length(s) have any security benefits? If not, I'd like to drop it from my signatures.

Is this from the C++ code? Because I saw similar code in pybitcointools' electrum_sig_hash function

It's also in BitcoinJS: https://github.com/bitcoinjs/bitcoinjs-lib/blob/1079bf95c1095f7fb018f6e4757277d83b7b9d07/src/message.js#L13

The duplicate doesn't address the inclusion of the lengths. The answer is that it's to definitively protect against length extension attacks.

RFC4880 apparently standardises the way signatures work, so it could be referring to:

0x18: Subkey Binding Signature
This signature is a statement by the top-level signing key that
indicates that it owns the subkey.  This signature is calculated
directly on the primary key and subkey, and not on any User ID or
other packets.  A signature that binds a signing subkey MUST have
an Embedded Signature subpacket in this binding signature that
contains a 0x19 signature made by the signing subkey on the
primary key and subkey.

But it seems much more likely BIP70 extension proposal is the reason for standardising signatures, as outlined by their BitID wallet implementation requirements:

To be compatible with the BitID protocol, a wallet must implement the following:

register the bitid scheme
throw a bitid intent when scanning a BitID QR code (if applicable)
decode the URI and verify its format
display a request for authentication showing the domain name callback and > - ask for validation
ask the user to pick up or create a Bitcoin address for the authentication (show the last Bitcoin address used if this is a known callback address)
sign the BitID URI with the private key (using the \x18Bitcoin Signed Message:\n#{message.size.chr}#{message} convention)
POST the signature and the public key to the callback URL
completion dialog : success/retry/cancel

It would have been much better if you actually explained and not citing the documents.

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


text:
How to connect to litecoin testnet3?
Running litecoin-0.13.2 with testnet=1 I get "No block source available."
Do I need to add some nodes to litecoin.conf ? I tried adding some that I found from http://litecointools.com/ . Is there a more official list?

testnet3 is deprecated.  The development version is now on testnet4 and it appears this will be in the v0.14 release.
https://github.com/litecoin-project/litecoin/pull/285


text:
What will happen to bitcoins stored at segwit outputs pre-BCH-fork?
If I understand correctly, P2SH-P2WPKH outputs are simply anyone can spend outputs in BCH.
What would have happened to BTC stored in such SegWit outputs BEFORE the fork, assuming that those addresses had sent several transactions also BEFORE the fork.
In this case, anyone can scan the blockchain and "steal" the bitcoins, despite there being no fault of the person who had those bitcoins.

According to BIP 141, talking about the Bitcoin chain, it'd still trigger "Witness program" and the funds would be stored safely in the SegWit address -after the fork.
Talking about the Bitcoin Cash chain, the miners can redeem SegWit outputs, (both Bitcoin Cash sent to SegWit addresses and Bitcoins in SegWit addresses pre-hardfork.) However those addresses need to have exposed their Witness program, or the outputs can't be redeemed.

Following the Bitcoin Cash forks, any segwit outputs (either existing before the fork or created after the fork), can be spent by anyone (but usually a miner because such transactions are non-standard).
However, since Segwit had not activated prior to the Bitcoin Cash fork, any Segwit outputs at that time on Bitcoin could also be spent by anyone.
Following Segwit activation, Segwit outputs from before the activation can still be spent from but have to follow the segwit rules.


text:
What is the best way to restart bitcoind after a bitcoin.conf change (Ubuntu 23.10)
I'm curious about the recommended way to restart a systemd service after a configuration change or if there is any particular issue with running sudo service bitcoin restart to have the config change take effect?

https://github.com/bitcoin/bitcoin/issues/11586#issuecomment-341737656

Bitcoin Core reads the bitcoin.conf file on every startup, so if you have it (properly) configured as a systemd service, restarting it that way will indeed make the configuration change take effect.

Thank you for your response! I do understand this, was also inquiring to see if there are better ways to go about things i.e. be offline for the least amount of time or avoid restarting at a pivotal time unknowingly due to some event occurring simultaneously... If you have any thoughts there it would be much appreciated.

There is no pivotal time such that Bitcoin Core would be unwilling to shut down when requested. Recall from the Bitcoin white paper that "nodes can leave and rejoin the network at will".

Thank you very much. Appreciate your time.

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


text:
Lightning Wallet bulk creation
I want to giveaway small amounts of BTC on lightning. The ideal method is a wallet paper equivalent, this means no coupons, websites or redemption procedures. I still have some doubts about the process.

Can I do this without running my own node?
Any special safety precautions?<
Can you give me high level overview of the how the generation may look?

Thanks in advance for your time.

Well, I'm not sure I can answer your exact questions, but I can offer an alternative. I had the same idea of creating a bunch of wallets to send small amounts to. But for my specific case  the important things was actually get small amounts to people. So, for me, I used cash app since you can freely SATs to other people using cashapp(5000 SATs min). Once, they had a decent amount, I would show them what options they had to get their own wallet or they could just keep using cashapp. Don't know if this helps, but if I understand The Lightning Network right, it seems like you would need a node. I could totally be wrong though. CashApp uses lightning network.


text:
Redeem script for input #0 doesn't match the scriptPubKey in the prevout
I'm trying to create a new bitcoin transaction using bitcoinjs-lib. Here is my transaction.
{
  "weight" : 661,
  "txid" : "4621e1e4e8ace541902aac5ad6cff164da6e55c1bb8af793fb65e76d5a98c841",
  "status" : {
    "block_height" : 800029,
    "block_hash" : "000000000000000000045fd943ecff32113fbc9610570e8ef071deb3b92db312",
    "confirmed" : true,
    "block_time" : 1690187566
  },
  "vin" : [
    {
      "inner_redeemscript_asm" : "OP_0 OP_PUSHBYTES_20 3d6f823b6cfc0e422f14d011c9401c3bed6dfde0",
      "txid" : "edbcb7cdd428c4c251377a49ffc91b8eabef092200f10f88aea8452cea80293f",
      "prevout" : {
        "scriptpubkey_type" : "p2sh",
        "scriptpubkey_address" : "3QQBsz2wPqNeWyEY6vnRKoCuHcyBgx2ZpQ",
        "value" : 100000,
        "scriptpubkey_asm" : "OP_HASH160 OP_PUSHBYTES_20 f91c21e619f4d51b2e58c3cfc0463057fc5e13a7 OP_EQUAL",
        "scriptpubkey" : "a914f91c21e619f4d51b2e58c3cfc0463057fc5e13a787"
      },
      "scriptsig_asm" : "OP_PUSHBYTES_22 00143d6f823b6cfc0e422f14d011c9401c3bed6dfde0",
      "is_coinbase" : false,
      "vout" : 0,
      "sequence" : 4294967295,
      "witness" : [
        "304402204d0ea4bc5a2ba018178daecdd55253fa6623e104aab5fd6e3198d9100f7f54c90220021255a9e25150da369cee1d279a3ed5e24a008c08c4c46c5338b397dd66bb8501",
        "0243027fe517049903f9c8ad1302b3c11146acf6dbcb3f355f8b3c4f2b7182e1bc"
      ],
      "scriptsig" : "1600143d6f823b6cfc0e422f14d011c9401c3bed6dfde0"
    }
  ],
  "vout" : [
    {
      "scriptpubkey_type" : "p2sh",
      "scriptpubkey_address" : "3PA2J9aN9N82q4YZyhBYHBcHpVvpGewvX2",
      "value" : 10000,
      "scriptpubkey_asm" : "OP_HASH160 OP_PUSHBYTES_20 eb762ef1946c2d462764d30112ce27c531fdd603 OP_EQUAL",
      "scriptpubkey" : "a914eb762ef1946c2d462764d30112ce27c531fdd60387"
    },
    {
      "scriptpubkey_type" : "p2sh",
      "scriptpubkey_address" : "3QQBsz2wPqNeWyEY6vnRKoCuHcyBgx2ZpQ",
      "value" : 88008,
      "scriptpubkey_asm" : "OP_HASH160 OP_PUSHBYTES_20 f91c21e619f4d51b2e58c3cfc0463057fc5e13a7 OP_EQUAL",
      "scriptpubkey" : "a914f91c21e619f4d51b2e58c3cfc0463057fc5e13a787"
    }
  ],
  "size" : 247,
  "locktime" : 0,
  "version" : 2,
  "fee" : 1992
}

I'm trying to send another transaction, but I'm getting this error.
Error: Redeem script for input #0 doesn't match the scriptPubKey in the prevout

This is my code in Javascript using bitcoinjs-lib to create the input. I'm hardcoding the values for this example.
const psbt = new bitcoin.Psbt({ network });

psbt.addInput({
    hash: "4621e1e4e8ace541902aac5ad6cff164da6e55c1bb8af793fb65e76d5a98c841",
    index: 0,
    witnessUtxo: {
        value: 10000,
        script: Buffer.from("a914eb762ef1946c2d462764d30112ce27c531fdd60387", 'hex'),
    },
    redeemScript: Buffer.from("00143d6f823b6cfc0e422f14d011c9401c3bed6dfde0", 'hex'),
});

I am facing same issue in bitcoinjs-lib Error: Redeem script for input #0 doesn't match the scriptPubKey in the prevout
psbt.addInput({
hash: "155009fe07a45086066843faf90dcb5d541bf7d77d7e3dd0db7707e13947d314",
index: 1,
witnessUtxo: {
script: Buffer.from("a91473b7786d0ada73c9f0d90c42605c03ba3a76a88687", 'hex'), // this buffer is correct??
value: 86141,
},
redeemScript: Buffer.from("001473b7786d0ada73c9f0d90c42605c03ba3a76a886", 'hex'), // redeemscript is correct or not?, how to get redeemscript here?
});
please suggest how to correct it?


text:
Which branch of bitcoinj should I sync to?
I am experimenting with Bitcoinj to design a stable node that is synced.
Older versions of bitcoinj seem to drop connections and stop syncing.
I currently see the following branches (see screenshots).

I would assume to use the "release" branch but the latest one is "Unverified"

On the other hand, I am also inclined to use one of the active branches.
The Segwit has not been updated for 11 months. I recall reading on the mailing list that the segwit code is still not complete.

Instead of having to dig into the code myself, I would like to get opinions on which branch to use and save some time.

https://github.com/bitcoinj/bitcoinj/issues/1336

Just ran into this issue and spent a while debugging it (on latest release, 0.14.5). I added rpcserialversion=0 and that fixed the issue, so it's easy enough to work around. If bitcoinj isn't planning to add support for the new format, it might be nice for bitcoinj to realize it is parsing the new format, and throw a more relevant error message, something like "New rpc serial format not supported, see #1336".


text:
Is there any way to listen to all transactions using bitcoind api?
I understand that using json-rpc to listen for all transactions is a bad idea due to performance, but bitcoinj is able to do it. In reality bitcoind is parsing all transactions under the hood when it forwards them. Is there any way for bitcoind to notify me when it sees a new transaction (not paying to an address in the wallet)?
Surely its is able to notify other peers, so why not me?
One solution I am thinking of is running connecting a bitcoinj node to my bitcoind and then using that to listen to transactions.
Another solution is to just listen for blocks and lose the ability to see zero conf payments.

Yes by default newer versions of bitcoin core should have zeromq enabled by default. Check here -> https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md
If you're using java you can use the code snippet there (using https://github.com/zeromq/jeromq ) -> How do i parse the zeroMQ messages in java?

Yes, You could use walletnotify in your bitcoin.conf file.
This option will execute command when you receive a transaction.
for example in your bitcoin.conf
walletnotify= curl http://127.0.0.1/callback.php?transaction=%s

Please make sure that you've curl installed.

Address is not paying to my wallet. I can add the address  but there must be a limit to how many i can add

Listening to mempool unconfirmed transaction won't harm your server performance if you are using this server for other purposes you can get another server for these jobs.


text:
Who mined the infamous block 364422?
Block 364422 contains a transaction that takes a long time to verify. This transaction design demonstrates a way a denial of service attack could be executed. This prompted Gavin Andresen to propose additional limits to the protocol.
Gavin talks about this issue in this video.
Is it known who mined this particular block? What was their intention? Did they collude with the person who generated the transaction?

Excellent answer by Pieter Wuille. Pieter just forgot to answer the question of the post title, "Who mined the infamous block 364423?"
Unfortunately, the question is  was "wrong": the first two links in the OP's text point at block 364422, not 364423. (edit: meanwhile the OP removed the discrepancy)
Either way, both
Bitcoin blocks 364422 and 364423 had been mined by F2Pool (also called "DiscusFish"). The outputs went to the Bitcoin address 1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY which belongs to F2Pool, see https://github.com/blockchain/Blockchain-Known-Pools/blob/master/pools.json
Both blocks were merged-mined with Namecoin blocks 238371 and 238372 respectively. The coinbase string of Bitcoin block 364422 as well as the auxPoW data in Namecoin block 238371 contain "新視野號距冥王星6951602公里" (Chinese for: "New Horizons' distance to Pluto: 6951602 km"). The coinbase string of Bitcoin block 364423 as well as the auxPoW data in Namecoin block 238372 contain "New Horizons is 6948752 km to Pluto" (this time in English). One of the pool operators at F2Pool wrote a script that inserted the current distance of NASA's New Horizons probe from Pluto into the coinbase string. After the arrival of the NASA probe he removed that script, and the F2Pool coinbase string contains the usual F2Pool info as before. Amongst other data this includes "七彩神仙鱼", "Discus Fish" in Chinese language.

Yes, because they are the same person.

I guess Pieter is refering to Wang Chun. There is a little message in the tx output script: "七彩神仙鱼  Bitcoin to Pluto!"

I fixed the block number to match Gavins slides. Thanks for pointing that out.

Upvoted. This answers the original question better :)

Disclaimer: I proposed a partial solution myself to this problem (BIP 143, see below).

Did the miner collude with the creator of the transaction?

Yes, because they are the same person.
It's a transaction that consumes a ton of dust outputs, and converts them to fees, which the miner claimed.
I doubt that the intention was to cause problems; it may just have been an attempt to clean up a lot of dust at once.
However, it did make it more obvious that the theoretical problem of quadratic hashing time for verification of blocks was real. The cause is that every signature requires computing a different hash, and that that hash is computed using the entirety of the transaction as input. Thus, if the number of signature checks in a transaction grows, both the number of hashes to compute as the amount of data each of them needs to hash increases.
Several solutions have been proposed:

Limiting the maximum size of transactions.
Limiting the total amount of data hashed by a transaction.
Changing the way hashes are computed.

1 (and to a lesser extent 2) would harm potentially useful large transactions in the future, depending on what the limits are. In particular, scaling solutions that rely on collapsing multiple payments into a single transaction may get hurt.
Deploying 3 for existing transaction outputs would require a hard fork, and a change to every piece of wallet software. Additionally, it would invalidate any pre-signed but unbroadcast transaction.
However, 3 can be deployed for a new type of transaction output. BIP 143 describes a new signature hashing mechanism that is at worst linear in the size of blocks, but only applies to transaction inputs that spend segregated witness outputs (see BIP 141).


text:
Bitcoin-QT issues with non standard filesystem
I'm having issues with blockchain catchup that I believe to be related to the underlying file system.
Symptoms: Significantly behind the network, start client and begin catchup. Catchup proceeds for 1-2GB then halts. CPU usage is 0 for the process, but it holds 500MB-1GB RAM allocated. 0 connections. Console commands receive no response, so crashed process? If I restart the client it will proceed again for a similar length of time, then repeat the behaviour.
Last run:
BOOT AT: ~353355
STUCK AT: 359430

Logs show many of these errors:
2015-11-21 03:39:26 ERROR: AcceptToMemoryPool : nonstandard transaction: non-final

End of log:
2015-11-21 04:03:10 UpdateTip: new best=0000000000000000041ca40bdec7946dc4105fea0cefb26ea7fb8914880fe089  height=359623  log2_work=82.893042  tx=71115044  date=2015-06-06 04:15:15 progress=0.806010
2015-11-21 04:03:14 UpdateTip: new best=0000000000000000028104e61aabd1b31bd0a136c33daecdd92165126aeb7ce1  height=359624  log2_work=82.893074  tx=71115578  date=2015-06-06 04:29:37 progress=0.806021
2015-11-21 04:03:15 UpdateTip: new best=00000000000000000b0c4437cd594ae56bb6dc532c497af9b595b653311345f5  height=359625  log2_work=82.893107  tx=71115639  date=2015-06-06 04:26:21 progress=0.806019
2015-11-21 04:03:26 Pre-allocating up to position 0xd00000 in rev00278.dat
2015-11-21 04:11:27 UPnP Port Mapping successful.
2015-11-21 04:31:27 UPnP Port Mapping successful.
2015-11-21 04:51:27 UPnP Port Mapping successful.
2015-11-21 05:07:26 socket inactivity timeout
2015-11-21 05:09:30 socket inactivity timeout
2015-11-21 05:11:27 UPnP Port Mapping successful.
2015-11-21 05:31:27 UPnP Port Mapping successful.
2015-11-21 05:51:27 UPnP Port Mapping successful.
2015-11-21 06:11:27 UPnP Port Mapping successful.
2015-11-21 06:31:27 UPnP Port Mapping successful.
2015-11-21 06:51:27 UPnP Port Mapping successful.
2015-11-21 07:11:27 UPnP Port Mapping successful.
2015-11-21 07:31:27 UPnP Port Mapping successful.
2015-11-21 07:51:27 UPnP Port Mapping successful.
2015-11-21 08:11:27 UPnP Port Mapping successful.
2015-11-21 08:31:27 UPnP Port Mapping successful.
2015-11-21 08:51:28 UPnP Port Mapping successful.
2015-11-21 09:11:28 UPnP Port Mapping successful.
2015-11-21 09:31:28 UPnP Port Mapping successful.

This seems to happen on my Flexraid disk array(Snapshot RAID) that appears to the OS (2008R2) as a regular NTFS 8TB volume but not on a regular 160GB backup drive. I've seen issues once before when an application attempted to create many files at once, this was resolve by tweaking that applications write caching.
Any suggestions for tweaks to allow stable disk IO?
EDIT: Forgot client info
"version" : 90300, v0.9.3.0-g40d2041-beta
"protocolversion" : 70002,
"walletversion" : 60000,
"balance" : 2.27391276,
"blocks" : 353567,
"timeoffset" : 9,
"connections" : 8,

NB: Client is out of date BUT I've tested with the latest LTC-QT and have the same RAID no single yes behaviour so its unlikely the cause.

What version are you running? That's almost certainly not the latest. The AcceptToMempool error isn't an error that's anything to do with anything, you can ignore that.

@Bitcoin Sorry, forgot to paste that bit, edited in now

Woo that's super old, you're 2 major versions behind, almost 3! Update your version of Bitcoin Core to 0.11.2, there's been massive changes in the sync process since 0.9.3. If nothing else it will be significantly faster, and there's been some changes to the way things are written to disk which might fix your problem.

@Bitcoin is the codebase not shared with "Litecoin Core version v0.10.2.2 (64-bit)"

There's big changes from 0.10 to 0.11 though, and Litecoins network is significantly less intensive to process (there's almost no transaction volume). There's security fixes you need to catch up on as well, there's no reason for anybody to use 0.9 era Bitcoin today.

While I was waiting for something else to finish I decided to drop in a newer BMC firmware. Killed the machine. I'll return to the question later, thanks.

Update: Upgrading QT didn't solve it

Ok so its finally up and working.
With v0.9.3.0-g40d2041-beta the core process definitely crashes on that volume. Now with version : 110200 it appears as if its crashed, but doesn't. Setting the write catch to 512MB may have had an impact here.
14:44:48  getinfo

15:36:10
{
"version" : 110200,
"protocolversion" : 70002,
"walletversion" : 60000,
"balance" : xyz,
"blocks" : 388767,
"timeoffset" : -7,
"connections" : 1,
"proxy" : "",
"difficulty" : 79102380900.22598300,
"testnet" : false,
"keypoololdest" : 1385606583,
"keypoolsize" : 101,
"unlocked_until" : 0,
"paytxfee" : 0.00000000,
"relayfee" : 0.00005000,
"errors" : ""
}

Note the delay of 52 minutes for a console command to return a response. This probably indicates bad threading that an IO process can block the interactive terminal. Eventually though block processing does resume and it caught up 16GB worth of data.
I might look into it further so I can log a bug report.


text:
What does the US government do with seized coins?
It was reported today that the US government shut down the web site Silk Road, where people bought and sold things (allegedly including illegal drugs) using Bitcoins.  The operator was arrested, and BTC 26000 was seized.  (Source: New York Times).
A few months ago, it was also reported  that the US Drug Enforcement Agency seized BTC 11.02 from a person suspected of buying or selling illegal drugs.
Is anything known about what the US government (or any other government) does with seized coins?
Some possibilities:

Sell them on an exchange for USD, and turn the proceeds over to the Treasury
Sell them at public auction, as is commonly done with other seized property
Use them in future sting operations
Do not return them to circulation, but hold them indefinitely
Destroy them by transferring them to an address with no private key

In order to auction/sell them, US govt. will first have to acknowledge that it is worth some money i.e it is a valid currency. Do they do that?

@user13107: See the answer by Tim S and links therein. They are planning to auction them, so they certainly acknowledge that the coins have value. I'm not sure that's the same thing as "being a valid currency".

The bitcoins will be sold, but they haven't said precisely how that will happen. Since there is no bitcoin exchange that is properly legally licensed in the US, they will likely auction them off directly, like seized property.
The bitcoins, if you're interested, are sitting in two very large wallets: one with ~144K bitcoins (~US$117.6M right now) and another with ~30K bitcoins (~US$24M), all siezed from Silk Road.
The above is based on the news sources Fox News, Forbes, and Wired. What follows is my own opinion.
This approach makes sense, since bitcoins aren't inherently illegal (thus only useful in sting operations or to be destroyed, like seized drugs), and aren't US cash (and thus sensible to directly deposit in the Treasury). Like all other valuable property, the best way for the government to liquidate them is at auction.
When this sale happens, the price of bitcoin will likely go down, but will probably be lost in the noise of trading. (Edited. At first I said that it'd be driven down fairly drastically.)
Update (2014-06-13): The smaller chunk of bitcoins, nearly 30K bitcoins (now ~US$18M) seized from Silk Road (including all of the little transactions people have given to it since then) now have an auction page set up on the U.S. Marshals Service website: they'll be sold in blocks of 3,000 bitcoins (less for the final block). The actual bidding will occur on June 27th, the fiat money will be wired by July 1st, and I'd expect the coins to be transferred via Bitcoin transactions shortly after. See Forbes for a news source talking about this.

Whether this has any influence at all on the price depends largely on whether the buyer turns around and dumps them on exchanges. If he just holds on to them it wouldn't affect the price at all.

Likewise if buyer sells them a few at a time at the exchanges, giving the markets a "rest" of some hours between offers. Only in the case they were sold altogether all of a sudden, the whole ~170K BTC, then the market price would descend a big notch, certainly.

Hm..you're probably right. I've edited my opinion.

Property seized is held until a conviction, then sold at auction.   If there is no conviction, property may or may not be returned to the rightful owner.

I understand this is the usual procedure for tangible property, but does it also apply to intangible property, financial instruments, etc?  Certainly the government wouldn't sell seized currency at auction (that would be silly).  How do they handle stocks and bonds?  Do they really auction them on the courthouse steps?

The interesting part will be, if in the end such bitcoins are sold in an auction, how far/below above the exchange's price are the buyers willing to go. The final price for the 2 lots will signal a lot of things about how the buyer sees Bitcoin and its future.


text:
Are old rev*.dat file safely deletable?
based on this answer rev files contains information for dealing with reorgs.
If I think reorg longer than let's say a month are highly unlikely, could I safely delete rev*.dat files older than a month?

Why not to test deleting rev*.dat files in testnet environment and check? :)

No. You need the rev*.dat files as much as you need the blk*.dat files. If Bitcoin Core cannot find the rev*.dat, it will need to regenerate them by reindexing the databases. Removing them effectively corrupts the databases.
If you want to save disk space, you can use pruning instead. This will have Bitcoin Core properly remove blk*.dat and rev*.dat files to save disk space.

I don't want to prune. I need a full node. Did you actually test what you are saying? In which occasion the node will recognize some rev files are missing? I am asking because I stopped the node, moved some old rev files and restarted the node. There is no error message in the log neither the regenerated files

A pruned node is still a full node. I have done this in the past and it resulted in a reindex. It looks like Bitcoin Core doesn't verify the undo data as much as it does for the block data, but it still does some verification. If you delete the wrong files, it will have problems.

yeah sorry for the wrong terminology, anyway I want all the blockchain data. I still suppose the wrong files causing problems are only the recent rev* files. I would like to see other answer

I can now confirm after testing my node started to recreate rev files in a very long process after I deleted it. So somehow are needed also the old ones


text:
Is there a way to create a BTC wallet with an unusually nice Bech-32 address?
For example, let's say I want a wallet address that contains only numerical digits, or that contains only letters from the first half of the alphabet. How can I ensure I get such an address?

The concept you are referring to is called "vanity address". Check out the topics labeled [tag:vanity-address].


text:
What is the maximum size transaction that will be relayed by bitcoin nodes using the default configuration?
I understand that the actual size limit of a transaction is determined by the block size, as we can see from this absolute unit. But transactions this large must be submitted directly to a mining pool because they will not propagate through the bitcoin network.
What limits prevent this transaction from being relayed? Is it configurable? What units are used (absolute size or weight units)? Is there an associated fee rate limit that also applies?

Bitcoin Core's standardness rules limit transactions to 100000 vbytes (or 400000 WU). Larger transactions are not relayed or added to mempools. Since they are consensus-valid, they are obviously acceptable if included in a block however.
The purpose of this rule is DoS protection against a few known (such as quadratic hashing) and possibly unknown ways to trigger excessive computation at validation/relay time. They also help block template building for mining, as it's easier to fill up a block with many small transactions as opposed to a few big ones (binpacking problem).

What limits prevent this transaction from being relayed?

Transactions size standardness limit.

Is it configurable?

Not in Bitcoin Core, no. Standardness limits are just a policy rule however; anyone can run any software, including software that doesn't have such a limit, or has it patched.

What units are used (absolute size or weight units)?

Weight units.

Is there an associated fee rate limit that also applies?

Independently, transactions whose feerate is below 1 satoshi per vbyte are not relayed either.


text:
BTC synchronization in Bitcore
I had kept some BTC for for synchronization in BITCORE but now I need money, so want to SELL my BTC but the process of synchronization is still going on.....
In that case can I stop the process of synchronization in between and get all my BTC back safely into my wallet? So that I can then sell these BTC
If your answer is yes... you can stop the process and get my BTC safely then HOW CAN I DO THAT?

You have tagged this "bitcoin core" but your question is about "bitcore" which is different. Did you mean https://bitcore.cc which is a different currency (BTX), or https://bitcore.io which is a different wallet? also I am unsure why you associate storing money in a wallet with synchronisation - please explain.

No, I meant Bitcoin Core https://bitcoin.org/en/bitcoin-core/    I referred to this as I wanted to do transactions of Bitcoins but as they are in synchronisation I can't.....

Yes I know that but the problem is I can't transact that BTC as the synchronisation is going on ...... right? as the transaction would not be confirmed.... please give me a solution so that I can sell my BTC as of now as I need money as this process is not allowing me to do so


text:
Time needed for Bitcoin core synchronization
I had put on the process of synchronization on BITCOIN CORE and it has been around 2years since I had started the process and still its not completed, therefore now I would like to put some questions in front of you related to this

Can I speed up this process of synchronization?

Its done around 85%, how long it can take (it took 2 month to increase 5%)

Can I cancel the synchronizing in between without affecting my bitcoins

Can I send some bitcoins to another wallet while the process is on?

Do the process of synchronizing time, depend on how much bitcoins are in wallet

Showing me last block time "FEBRUARY 2021" and today is OCTOBER isn't it taking too long? or its normal?

Currently I am facing very bad financial condition as by mistake I have put up synchronizing all the bitcoins at one time due to which all bitcoins are not blocked in the process and now I don't have money, your every answer would give peace to my heart, please help!

You keep mentioning "Bitcore" as well next to Bitcoin Core. Is it possible that you downloaded malware that pretends to be Bitcoin Core?


text:
Building from source static bitcoind on Ubuntu
I'm trying to build bitcoind from source on Ubuntu 13.04:
$ apt-get install libboost-all-dev ccache pkg-config # deps
$ git clone https://github.com/bitcoin/bitcoin.git
$ cd bitcoin
$ ./configure --without-qt --with-incompatible-bdb
$ make

It works !
I'm looking for way to build static binary.
However, I can not find --enable-static option in configure. How should I build static bitcoind properly?

You might ind useful these quote from configure docs
Enabling static libraries for a package which consists of only dynamic modules makes no sense, and the package author would probably have decided to ignore such requests
... `AC_DISABLE_STATIC'
These macros tell libtool to not try and build either shared or static libraries respectively. libtool will always try to build something however, so even if you turn off static library building in 'configure.in', building your package for a target host without shared library support will fallback to building static archives.
In other words, check your code for presence of particular macro in configure.in files across subtree. it may have been decided to prevent making it static.

authors: Менгли Холматов


text:
Are transit fees supposed to be common in Ripple?
In addition to transaction fees, Ripple also has transit fees when exchanging IOUs. Is it supposed to be common to pay transit fees, or is it for rare cases only? How much would the transit fees typically be?

For now, gateways are using transit fees as their primary revenue source. Bitstamp currently charges 0.2% and that's pretty typical.
We hope that those fees will go down over time for two reasons. First, competition and increased volume should bring the fees down. Second, when interest rates start to rise to more historically normal levels, gateways can use the interest on money they hold as a revenue source.
We've been asked to have a "transit fee cap" so a single transaction can't have a transit fee above a limit regardless of transaction size. And we've been asked to have a "fee exempt" flag so gateways can exempt particular accounts from paying transaction fees (perhaps in exchange for a monthly fee). These changes are under active consideration. For technical reasons, they're not as easy to implement as they might seem.

Would the transit fee cap be part of the protocol, so that no single gateway could violate the rule? If I understand correctly, a gateway could hold your account hostage by raising their transit fee to a very high amount. What would be the defense against this in the absence of a protocol-level cap? Perhaps to spread out your funds into multiple gateways (just like the banks).

The fee cap would be something each gateway could set for each currency. So if you had a USD gateway, you could specify a .2% transfer fee, capped at $0.10 per transaction. If a gateway sets their transfer fee high, they hold everyone's balance hostage, which they can do anyway by refusing to redeem. Of course, raising the transfer fee or cap (if they set one) would be very public.


text:
How is segwit backward compatible (soft fork) when the transaction serialization structure is changed?
I understand that SegWit is backward compatible (soft-fork) from this perspective.
So, for old nodes the following output script (scriptPubKey)
OP_n (where n from 0 to 16) <2-40 bytes>
... is considered as anyone-can-spend and in "concatenation" with the empty input script (scriptSig) it will be always valid.
For new (updated) nodes it will be considered as SegWit, so the special SegWit validation process, as Pieter Wuille described, will start.
Observing only this, everything is clear to me.
What is not clear to me is how all this will work when the structure of the transaction has been changed from SegWit.
Namely, according to bip144, the structure of the transaction has been changed by "expanding" the transaction with two bytes (marker (0x00) and flag (0x01)) after version field, and also adding witness data after tx_outs and before locktime.
For new (updated) nodes this is considered as a sign that there is witness data, however, for old nodes this is a transaction with 0 inputs and 1 output which is considered invalid so they will always discard this transaction (especially since there is also witness data that is not clear to them at all).
Even if we would consider that the old nodes would not relay these transactions to other peers, they would not even accept them in the blocks they receive from the miners, because for them these are completely invalid transactions (valid from the first perspective of inputs and outpus since they are anyone-can-spend, but invalid from this second, structure perspective).
Can someone explain to me how this works? I misunderstood something.

Does this answer your question? How is SegWit a soft fork?

Yes, I read it, but I still don't understand 100%. I have additional questions. I've posted the questions below in a reply, but may as well post them here so RedGrittyBrick doesn't get too many notices.

Old nodes never see the new serialisation format
When an old node asks a new node for data, the new node edits the data into the old serialisation format before sending it

Okay, but when a node just want to relay the transaction it got to all its peers, how will he know if the peer is old or new (updated) node?

Part of the communications handshake distinguishes segwit nodes

Okay, I understand they can do that when we're talking about relaying. But what about the block transaction received by the miner? How will the old nodes confirm this since they don't understand the new structure? I mean, it can't be the old serialization format without witnesses and markers/flags because then the old and new nodes would have a different blockchain and this block would have a different hash?

@RedGrittyBrick While that's true, the handshake just lets the other side know that the peer can offer witness. To actually get witness data, a node has to ask for a witness_tx or a witness_block, rather than tx or block (if you ask for those, even from a segwit node, you get the stripped version).

@joke The txid of a transaction is independent of whether the witnesses are included or not, and the hash of a block is the hash of its header - which also doesn't include the witnesses. Witnesses data is committed to in blocks, but just by including the hash of all the witnesses in the coinbase transaction somewhere. So no, you can just drop all the witness data from a witness block, give it to a pre-segwit peer, and it will be valid to them.

@PieterWuille So the stripped version (of both the block and the transaction) is always sent, with the fact that during handshaking, the segWit node somehow announces itself (it will set some flag or something) as segWit node and that can also send witness data?

Right. NODE_WITNESS announces that witnesses are available, and if so, the getdata command can be used to ask for transactions, blocks, or for transactions+witness, or for block+witness. Without that flag, only transactions or blocks can be asked for.

@PieterWuille Couple of question. 1) I assume that NODE_WITNESS flag is introduced with segWit, so it won't "confuse" old nodes? I mean, they will just ignore it and ask for tx/block (not tx+witness/block+witness)? 2) If we ask for tx+witness, we will get from node new serialization format (with marker+flag+witness), and if we ask for tx we get old serialization format? (of course all this in case that tx is segWit) 3) What does it mean block+witness and block? Is first that we get block consist of all tx with new ser format, while the second one is all tx with old ser format?

@joke To go in this much depth, I suggest you just read BIP144 which specifies the protocol/serialization changes. BIP141 specifies the segwit consensus rules, which go along with it.

@PieterWuille I did, but I still do not understand it. It's still too technical for me, I'm trying to understand conceptually. That's why I'm trying this way by asking questions here. After I understand things conceptually I think I will then be able to understand the details.

Yes, unknown service flags are ignored by nodes that don't know them. 2) Yes, the marker/flag format is used for any transaction that has at least one non-empty witness (old format is still used for transactions without witnesses) 3) Yes, the witness block format is identical to telhe normal block format, but instead of normal transactions, witness transactions are included.

@PieterWuille If old nodes operate with stripped block and new nodes with the, let's call it, "full" blocks, does it mean that old nodes and new nodes will have different blockchain, since their blocks will be different? They will have same blocks in context of  ids (hashes) and transactions, but blocks by their structure will be different?

@joke: It is probably clearer to think of it not as different blockchains but as the same blockchain with Segwit data stripped out. Just as we would say a pruning node and a non-pruning node have the same blockchain even though one node has more data than the other.

Clearly they don't have the exact same data, as the pre-segwit nodes lack the witnesses. But apart from that, whether that's "structurally" different will depend on how you define that.

@PieterWuille "structurally" in context that old nodes will have blockchain made of blocks composed of transaction with old serialization format while new nodes will have blockchain made of block composed of transactions with new serialization format (that is, if tansaction has witness input, it will have additionaly marker, flag and witness data, otherwise old serialization format is used too). So blockchains in new and old nodes will differ in this "structurally" way?

@joke This is becoming a semantics discussion, I don't think this will serve anything.

@PieterWuille Well its just important for me to know if old nodes have in their blockchain blocks with old serialization tx format, while new nodes have in their blockchain blocks with new serialization format, so thats how their blockchains differ? The other parts of their blockchains are the same.

@joke Yes, exactly. New nodes use the flag/marker serialization (which includes witness data) for transactions that have non-empty witnesses, while old nodes always use the old serialization format. To me however, serialization is just an implementation detail - the question is which data they have, as it can always be converted to another format. And in terms of data, they have exactly the same data, just without witness data.

@PieterWuille Yes I understand that. Just I want to understand how will their blockchain differ? Is it as RedGrittyBrick said that in old nodes blockchain will be composed of stripped blocks (old tx serialization format) while new nodes has blockchain composed of blocks with witness data (new tx serialization format)? I am asking because if its like that, then I understand the way that segwit is backward compatible from this perspective.

@Joke I thought I had already confirmed that! Yes, old nodes only use the old serialization, which does not support witnesses, so yes, what they receive are by definition the blocks without the witnesses. They likely also store those blocks in that format, but they don't have to.

@PieterWuille Oh, sorry, did not understand it like that. What do you mean by saying 'but they dont have to'? Does it mean that they can store it in some arbitrary way that suit them, I mean how do Bitcoin core nodes do that?

Yes, that's my point, nodes can use whatever format they want to store the data, the only thing that matters is what data they have available and which protocol they speak. Bitcoin Core stores blocks in the same format on disk as it'd sent on the network, packed together with multiple blocks in a files with some metadata before each block, and a separate database that contains an index of all those blocks.

@PieterWuille Cool, and only different between old and new nodes in the context of block storage, if I understand correctly (and I hope I finally do), is that old nodes will only store blocks with the old ser format, and new nodes will also include a block with the new ser format (if there is a segwit transaction in it). I am talking about bitcoin core. True?

@joke Bitcoin Core will only store blocks once, using for each transaction the appropriate format (witness format if it has a witness, old format otherwise). If a pre-segwit peer asks for a non-witness block or transaction, the data is re-serialized in the old format (which discards witness data) before sending.

@PieterWuille Yes, but that one time when the Bitcoin core node stores the block, if thats 1) old node: it stores block that consists only of all old serialization format transactions (no matter whether tx is segwit or not; it ifs segwit it will be without witness data/flag/marker and will be considered as anyone-can-spend) 2) new node: it stores block with old ser tx format and new ser tx format. If and old peer ask a new node for some block or tx, the new node will re-serialized in the old format before sending. Right?

If by "with old ser tx format and new ser tx format" you mean that the blocks it stored will use a mix of both formats, yes. It doesn't store everything twice. Otherwise, indeed!

@PieterWuille Oh, I didn't express myself well.  I just wanna say the following. If we have, for example, block with 10 tx where 3 are segwit and 7 are legacy (P2PKH for example), then the old nodes will store the block as 10 tx all serialized with old format (no witness data, no marker, no flag, 3 segwit tx are considered as anyone-can-spend). On the other hand, the new nodes will store the same block as 3 segwit tx with new ser format (yes witness, yes marker, yes flag, these tx are not anyone-can-spend) and for other 7 tx use old tx ser format. Right? This is only difference in storage?

@joke All correct.

@PieterWuille Cool, thanks, everything clear.


text:
Anyone knew about bitnuxt.com?
I have balance in bitnuxt.com site
0.67 btc, and when I want to withdraw the site says I have to deposit 0.002 btc so that the withdrawal can be done
Anyone know about this site is scam or not ?enter image description here

The answer,very suspicious. can anyone help?

https://bitnuxt.com/fee-schedule says:

Currency
Depositfee
Withdrawal fee
Min. Deposit
Min. Withdrawal

BTC
0.0005
0.0005
0.01
0.0003

Personally, I wouldn't use such a service, but the obnoxious fees are there in plain sight for all prospective customers to read.
Also, importantly, they would deduct that fee from your balance, not ask you to pay it in. This aspect makes it clear that someone is scamming you.
If someone helped you set up this account, you are definitely the victim of a scam

Websites with same claimed founder name

bitnuxt com
bitwire ltd
issuu com
bitkindly com
cryptonexer com
fastocoin com

and many many others. I think it certain they are all scam sites -- or, at best, all but one.

Related:

Is this exchange legitimate? (about another "Justin Hance" website)
How to tell if a cryptocurrency exchange or trading platform is trustworthy? (see 4th point in my answer there)
Is it normal to be asked for an advance fee on a withdrawal?
How do I recover from a cryptocurrency scam?


text:
Simple math in Script
I want to create a script that takes 3 numbers and verifies that:

Each of the numbers is less than 8.
The sum of the numbers is 15.

How can I do that?

This is the smallest script I could come up with, at 13 opcodes:
OP_3DUP
OP_ADD
OP_ADD
OP_15 OP_NUMEQUALVERIFY
OP_8 OP_LESSTHAN OP_VERIFY
OP_8 OP_LESSTHAN OP_VERIFY
OP_8 OP_LESSTHAN

It saves some bytes by using OP_3DUP to duplicate all three input numbers, and one byte by checking the addition first using OP_NUMEQUALVERIFY instead of OP_NUMEQUAL, which saves one OP_VERIFY opcode.

Nice, that's a lot simpler indeed.

Thanks, I think this is the shortest approach for this question.

OP_DUP OP_8 OP_LESSTHAN OP_VERIFY
OP_SWAP OP_DUP OP_8 OP_LESSTHAN OP_VERIFY
OP_ROT OP_DUP OP_8 OP_LESSTHAN OP_VERIFY
OP_ADD OP_ADD OP_15 OP_NUMEQUAL

Tracing the execution (for a successful input):

Initial: a b c
OP_DUP: a b c c
OP_8: a b c c 8
OP_LESSTHAN: a b c 1
OP_VERIFY: a b c
OP_SWAP: a c b
OP_DUP: a c b b
OP_8: a c b b 8
OP_LESSTHAN: a c b 1
OP_VERIFY: a c b
OP_ROT: c b a
OP_DUP: c b a a
OP_8: c b a a 8
OP_LESSTHAN: c b a 1
OP_VERIFY: c b a
OP_ADD: c (a+b)
OP_ADD: (a+b+c)
OP_15: (a+b+c) 15
OP_NUMEQUAL: 1

Wouldn't OP_PICK be simpler than duplicating and swapping/rotating?

I think it'd require the same number of opcodes and bytes, but feel free to suggest as an alternative.

No need, just making sure I haven't missed something obvious. I'm not particularly versed in Script.


text:
How Can I find sat/vb of a given Txid using bitcoin-cli
I want to find the sat/vb of a tx in a mempool. I am using bitcoin-cli to do this.
cmd = ['bitcoin-cli', 'getrawtransaction', txid, "true"]
This is the command that I extrect the info of the given tx but it only returns the size not the fee. Thus I cannot calculate the sat/vb how can I find how much fee is paid?

Since Bitcoin Core v25.0 (implemented in #23319) you can get the transaction fee (and prevouts) in getrawtransaction by setting the last parameter to 2.


text:
What is the purpose of P2WPKH-P2SH?
When I ask the google what is the purpose of P2WPKH nested in P2SH, it says the following:

This allows the user to send funds to a SegWit (Segregated Witness)
address using a non-SegWit transaction, which can be useful in cases
where the user's wallet or software does not support SegWit
transactions.

But I do not get it, if a wallet does not support segwit, how will a wallet then create a transaction with witness data to spends it.
So my question: What is the purpose of P2WPKH-P2SH? What do we get with sending SegWit type to non-segwit address (starting with 3 base58check for P2SH)?

P2SH-P2WPKH addresses can only be created by segwit-compatible wallet software. However, sending to a P2SH-P2WPKH works with any P2SH-compatible wallet, as the address is indistinguishable from (and effectively is) a P2SH address.
It was useful in a time before most wallets supported segwit, as even those that did not usually supported P2SH.

So there is no need (real purpose) anymore for P2SH-P2WPKH? Btw is it correct to say P2SH-P2WPKH or P2WPKH-P2SH for P2WPKH nested in P2SH?

You can say what you want, but I think P2SH-P2WPKH is a lot more common. Most (but still not all) wallets support BIP173 (native segwit v0 addresses) now, so it is certainly less useful than a few years ago.

Okay, but what do you mean by saying "P2SH-P2WPKH addresses can only be created by segwit-compatible wallet software."? I do not get this. If that is a P2SH then it will follow classic P2SH scheme and address will start with 3, it won't even know if the hash is from some random redeem script or from witness program (0 for version then 20 byte for hash of public key)? How does wallet wont be able to create address when its literally classic P2SH?

By "creating" an address I mean generating a private key, computing the corresponding script, and converting it to an address, so it can be given out to senders, while being able to spend the coins sent to that address. While it's true that software can compute a P2SH address for any P2SH script, that's not the same as a receiving wallet creating such an address to actually use it.

Okay, but if P2SH-P2WPKH can only be created by segwit compatible wallet, how will that help, that is how will that change anything? I do not get it. If you send P2SH-P2WPKH to non-segwit wallet then that wallet can't spend it because it does not know to work with segwit? Is the point that the user will know in this way that funds have been sent to him because it is P2SH (P2WPKH nested), but he will not be able to spend them because his wallet is not segwit compatible? Otherwise, if it is only P2WPKH he wouldn't even be able to see that the funds arrived? In this way he can at least see that.

I think you're confusing sender and receiver. The receiver creates the address, and they only create addresses they know how to spend from. So P2SH-P2WPKH can be used by receivers who support segwit, but with senders that only support P2SH (but do not know about segwit, as they don't care). When the funds arrive at the receiver, and they want to send those funds onward, they need a segwit spend, but they know how to construct that, as they are a segwit wallet.

"If you send P2SH-P2WPKH to non-segwit wallet then that wallet can't spend it because it does not know to work with segwit?" - This cannot happen, because the non-segwit wallet will not give out a P2WPKH address; it'll give a P2PKH address for example, which it does know how to spend.

So, if I (my wallet) know how to work with SegWit (as a result of wanting to work with unconfirmed transactions, to avoid malleability, lower fee, etc.) I can actually generate P2SH address that will contain hash of P2WPKH (0 20byte-hash) instead of some random redeem script as in "traditional" P2SH, and give it to some sender that does not need to understand the P2WPKH. In this way, he will "pay" to classic P2SH (cause he does not know how to create P2WPKH locking script, just P2SH locking script) and I can get all the benefit from working with P2WPKH (which is actually "packed" in P2SH)?

@maximus Exactly. You get the benefits of segwit (with a small penalty, the P2SH wrapping has a cost), but you get to receive coins from senders who do not support native segwit addresses.

What kind of cost?

The P2SH wrapper increases the size of transaction inputs that spend outputs sending to P2SH-P2WPKH, compared to spending P2WPKH outputs. As transaction fees generally scale with the size (weight) of the transaction, the wrapper increases the fees for the receiver.

So with P2SH-P2WPKH you have to pay bigger fee than for classic P2WPKH but at least you will get the other benefits that P2WPKH provides (for example resistance to malleability) comparing to "traditional" P2PKH?

Yes, but P2SH-P2WPKH is also cheaper (=smaller input) than P2PKH, just not quite as cheap as native P2WPKH. P2TR key path spends are even cheaper.

So in context of fee (from the biggest to lowest fee): P2SH/P2PKH -> P2SH-P2WPKH/P2SH-P2WSH -> P2WPKH/P2WSH -> P2TR. Additionally, SegWit (v0 - P2WSH/P2WPKH, v1 - P2TR) has other benefits, with the fact that v1 (P2TR) has provides even greater benefits compared to v0 (P2WSH/P2WPKH)?

In general yes. It's more complicated for the script variants (P2SH, P2WSH, P2TR script path), as the cost of spending is also a function of the complexity of the script/spending policy involved. There are several answers on this site with comparisons of script type costs, though.

Can you give me a link to some such posts that compare it in detail? Maybe some that you wrote? It would be help a lot.

@maximus https://bitcoin.stackexchange.com/a/84006/140802


text:
How to create more ripples?
What is the exact procedure for creating more Ripple currency units (XRP) in excess of the default 100 billion that already exist?

There is no such procedure. While OpenCoin could accomplish it today by changing the code to create such a thing, in the future, the procedure would be as follows:

Propose some kind of change that would create more XRP.
Assign it a 256-bit ID. (It can be arbitrary.)
Release patches that support this change, and announce their support for this ID.
Get 80% of validators to run your patches.
Wait out the two week waiting period for new feature enablement (to give a chance for review and vetoing).
If 80% of validators (weighted by trust) still run your patch, the feature will enable itself and then you can create more XRP. Alternatively, you could try to convince about 50% of validators (weighted by trust) that your patch is so urgently needed that the normal supermajority delay process can be bypassed.

"Propose some kind of change that would create more XRP." This is a kind of transaction, right? A special kind of transaction.

No, step 1 would to be to suggest it to the community to build a human consensus. Otherwise, step 4 will never happen.

Bringing out the tin foil hat now, my favorite part. So a government that controls 50% of the validators could start expanding the money supply. Would this be easy to detect by the other nodes? Could they do anything to stop it? For example, in Bitcoin terms, if there's a new "coinbase," maybe they could reject transactions originating from that coinbase, considering them as fake coins. I don't know ... this is my main concern with the cryptocurrencies.

It would be trivial to detect. If they announced it as a proper change, everyone would know when it was properly enabled. If they did it secretly, the other 49% of the network would be unable to ever agree with them because the XRP levels would disagree. Plus, there's the total amount of XRP field in the ledger. You can trivially count the XRP in the ledger and compare (I do that regularly). And if any XRP "moved" there'd be a signed ledger with the before, a signed ledger with the after, and no transaction to justify it.

So essentially in the worst-case scenario if the so-called government tried to do this covertly then it would just bring the network to a halt.

Right, just like a 51% attack on Bitcoin. Except people could just stop using the compromised validators. So the manual recovery process would be simple. (It may even be possible to automate this process when it's clear which side is objectively wrong. The more insidious threat, if the aim is to disrupt the network, is to try to disrupt consensus without being so blatant.)

This theoretically is true. But the change wouldn't be in secret, it would create 2 XRP networks, keeping totals for the original in tact, while the new network wouldn't be able to sell coins on, say, cryptsy, because that network doesn't own XRP, they own their own new currency, with a likely value of nothing unless they get plenty of support, causing people to invest in it..


text:
How to cheaply melt many micro UTXOs?
I know this was probably brought up before but I cannot find any good resources on some potential, at least theoretical way of achieving this.
So basically I have a lot of UTXOs whose value is between lets say 1k sats and 5k sats and I want to transfer them all into a single UTXO.
With current fee rates of 15sats/byte I would barely break even in the best case scenario.
Is there any strategy or algorithm that could help with this kind of issue?

There's no free lunch.  You can spend all the UTXOs in one transaction to spread the output bytes across many inputs, but each input still needs a certain number of bytes.  To my knowledge, there isn't any more efficient way of spending them than the standard transaction types.  (If there were, it would be the standard.)
You can of course attach a fee below the current prevailing rate, and hope that the transaction gets picked up during some period of low transaction demand (when fees drop), or wait until such a time to broadcast your transaction.  Certain times of day or days of the week may be somewhat better; you could look back at historical transaction fees to get a sense.  But there's no guarantee that such a low-fee transaction will get confirmed.

Depending on your time-restraints, you either have to pay the market's current fee rate, or wait until the block space demand is low enough to include your transaction at a much lower fee rate. Nate did a good job at describing that.
I wanted to add that there is an on-going discussion to generally lower the minFeeRate, so if you can be very patient, your transaction may eventually relay and get mined even paying a fee rate below 1 satoshi per byte. See: https://github.com/bitcoin/bitcoin/pull/13922, https://github.com/bitcoin/bitcoin/pull/13990


text:
How is OP_CHECKTEMPLATEVERIFY a scaling solution
I was wondering about OP_CHECKTEMPLATEVERIFY or OP_SECURETHEBAG as it was previously called. As far as I understand it you can commit on how to spend the coins later this way. But it doesn't enable covenants in the sense of https://fc16.ifca.ai/bitcoin/papers/MES16.pdf, right?
Tainting later transactions is probably quite controversial (and impacts fungibility). Will it be somehow possible to extend OP_CHECKTEMPLATEVERIFY to enable this in the future?
I believe there are probably some use-cases for CTV, but I don't seem to quite understand how this is a scalability solution (as it was "advertised"). After all if you do something in two-phases (first commit and then actual transactions) there is more blockchain data. The trick is just that you do the commitment when fees are high and can do the second part later (with lower fees) or am I missing some important piece? Couldn't you solve the same thing with P2(W)SH?

A bit of a meandering answer to the question, and to answer a side question: fundamentally what is a scaling solution?
OP_CTV does not increase the block space. Transactions using generally will use more block space actually (although it need not be a large amount), and relay can be optimized to equivalent.
But scaling is more than just a block size increase. The lightning network shows this -- not just because of eliding intermediate states from the chain, and routing, but also because of latency. It matters for lightning that confirmations can come faster than 1 block. This is not a minor point; if there were another way that you could get sub-block confirmations but use more total chainspace, people would probably still want it. Important to note that redeeming a channel still takes a long time potentially -- you're trading less latency now for more latency later (HTLC timeouts are longer than a single transaction confirm).
So, that said, what does OP_CTV do?
OP_CTV lets you more efficiently use block space over time. Imagine if you have a block that is almost full, and there's space for just a few inputs and outputs (let's say 2 outputs). Previously, this would mean that space would go to confirming a payment to one person -- one change address, one payment.
This isn't very efficient because we're only paying one person!
With OP_CTV, a single marginal output can confirm payment to an unlimited number of recipients. So that means the efficiency for confirming a payment on-chain is now much better.
However, at some time in the future those still must be claimed on-chain, which means that overall average demand isn't reduced (maybe, in fact, increased).
But if you look at trends, not all blocks are full. Sometimes they are, sometimes they aren't. A not full block represents "wasted" bandwidth for confirming transactions. All blocks should be full.
By splitting the market, we create two different "fee bands", the fee band for confirming a spend and the fee band for redeeming a CTV output. This creates a much healthier backlog for Bitcoin.
This is indeed similar to P2SH -- before p2sh, you pay for data on spend, when you should only need to pay for it on redeem. p2sh is bytes-wise less efficient than non-p2sh. And p2sh can't emulate it because p2sh operates at the script level, not the transaction level.
So what are the core benefits?

Improved confirmation throughput
Lower Fees paid
Lower fee-rate for top of mempool
Business operators abstracted away from "chain weather"

CTV also jives well with protocols like LN by increasing the number of HTLCs a channel can hold, which has been shown in some research (citation needed) that the number of HTLCs increasing is critical to LN working well. CTV also makes it easier to bulk-open channels, which decreases costs for opening channels & can increase LN routing viability.
CTV also enables new kinds of non-interactive protocols, which can eliminate a transaction between "withdraw from coinbase" and "open lightning channel". This meets the "classical" decreased block space usage criteria. This includes a case where, With Schnorr signatures/taproot, it's also possible to have the sub-tree be elided in favor of a new transaction.
See https://utxos.org/analysis/bip_simulation/
Oh, and it does enable similar covenants to the MES Covenants, see https://utxos.org/uses/ for more on vaults, non-interactive protocols, etc.
To close, a different definition of a scaling solution:
A blockchain scaling solution is a technology which decreases how aware users are of the fundamental limitations of the underlying blockchain, assuming they have proper wallet software (e.g., lightning support, ctv, etc).
CTV eliminates a large class of cases where a user bumps up against chain limitations, and is therefore a scaling solution.

Thanks for the great explanation. I was probably a bit myopic in what scaling actually means.


text:
Buy Bitcoin in the UK
Where can I buy Bitcoin in the UK? Preferably at Gox prices? I have tried at bitcoin.info and on Gox. I'd prefer not to go through a local sale.
Thanks

This question has been asked a lot before.

The other GBP market which is available is based on www.bitcoin-central.net
They are based in France, the liquidity is not of that of MtGox but for casual buy orders this should not be much of a problem.
Most other options involve individual trades and no exchange as such exists within this country anymore.


text:
Transactions with multiple origins?
See this transaction.
How can a transaction have multiple origins? Surely one transaction comes from one address?

Transactions can 'claim' from multiple addresses. In fact, the default client will do it if your balance is spread out amongst multiple addresses when you want to make a transaction.

Ah ok, so it's the wallet software choosing where. Got you.


text:
Are there any opensource PHP cryptocurrency exchange/marketplace
As the title suggest, are there any opensource PHP cryptocurrency exchange/marketplace.
Most of the ones I found does not seem to work or are abandoned.

There is bitwasp: https://github.com/Bit-Wasp/BitWasp . It's actively developed but not yet production ready. This same group also produces a php library which is also found on github: https://github.com/Bit-Wasp/bitcoin-php

I'm not aware of any and I believe it's something hard to find, Because exposing PHP codes may lead to some critical exploits and vulnerabilities.

Well its not really a exchange platform but it supports apis of more than such exchange platforms,big name include Binance, Bittrex etc . Also try it if you are looking for trading purpose
Check this out

https://github.com/ccxt/ccxt

Checkout this one https://github.com/GMX9/Crypto-Exchange-PHP
Is based from shapeshift, instant exchange that you can use freely