text:
How to find if two transactions in mempool are conflicting?
There are lots of transactions over the mempool of the bitoin. However, there might be double spends. How can we verify whether two transactions are conflicting, i.e. they are double spends of a bitcoin?
P.S. Given two transactions are conflicting, then they both have at least one common input transactions. So, what else should be checked to verify that two transactions are conflicting (double spend).
Thanks

Firstly, there is no "the mempool". There is no global mempool. Rather each node maintains its own mempool and accepts and rejects transaction to that mempool using their own internal policies. Most nodes have the same policies, but due to different start times, relay delays, and other factors, not every node has the same mempool, although they may be very similar.
When it comes to doublespends, the typical node policy is that if a transaction conflicts with another transaction, it will not be accepted by that node, thus the conflicting transaction doesn't enter that node's mempool. So unless you modify your node to accept conflicts, your node's mempool will never contain conflicting transactions.

Thanks for the answer. My question is exactly here that how to detect that two transactions are double spends and delete them. I mean the algorithm behind that. What I am curious to know is identifying double spends and the algorithmics behind it. Given two transactions as conflicting transactions, they both have at least one common input transaction. However, what else should we check to find if two transactions are conflicting and double spend?

That's all that you have to check. Two different transactions (different txids) that have at least one identical input (same txid and vout in one input).


text:
How secure is blockchain.info?
How secure is using a wallet on blockchain.info?
How do you evaluate the different sites that provide wallets?

I think I'd like to see your second question broken out into a separate SE question.

source: Stack Exchange

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

sort: votes


text:
Is it possible to buy or sell Bitcoin options?
Like put and call options for a stock, but for the future price of Bitcoin?

Additional methods are being developed or available currently with an invitation.  When they are available to the public, they will be added here: http://en.bitcoin.it/wiki/Trade#Options

https://en.bitcoin.it/wiki/History#2010 ctrl-f 'option'

It is possible, there various sites that provide option (or option like) trading. Each have their pros and cons. Of the ones I know of theses seemed the best. However YMMV and caveat emptor.
At time of writing here are some simple ones:

btc oracle <-- Looks like a very elegant (bitcoin) solution. Just send some bitcoins to the addresses and if (in 15min, 3hr, 1day, 1week respectively later) you are in the money you are sent back X a Multiplier.
btc Levels <-- Similar to btc oracle in concept. Except you have to login to place your (high low positions) bets. Plus you can only place positions for up to the next 24 hr.

However neither of those let you buy/sell an option that is in the money(or out of), you have to wait until the option expires. And neither of them let you write options.
Some others:

icbit.se <-- Futures contract
mpex.co <--  Has a large buy in.
coinbr.com <-- They act as a broker to mpex.co (So has a much lower buy in)
1broker.com <-- CFD  for btc/USD
campbx.com <-- Options coming soon. (so is xmas though :P )

It's possible in theory, but right now there are no good markets to actually do it. The only one I know is MPEX which has multiple problems and should be avoided.

I found MPEX too, but thought it was not really usable...

Why should it be avoided ?

@David: 1. It costs 30 BTC just to get an account. 2. Even if you paid the 30 BTC your account can be arbitrarily deleted at the owner's whim, effectively stealing your fees (https://bitcointalk.org/index.php?topic=131061.0). 3. The current spreads for options make them impractical, and the automated offerings don't seem to have adapted to current rates. 4. The owner is an obnoxious troll. 5. The owner is an alleged scammer (https://bitcointalk.org/index.php?topic=129544.0.)

Something not being free does not make it bad. 2) Inactive accounts get pruned with a two months notice, and to keep your account active you just need to leave a Satoshi in there, not a big deal I'd say. 3) It still addresses OPs need even if the spread isn't that good. 4) I don't usually judge the solidity of a financial service on the "niceness" of its operators, Pirate and all the scammers were all nice people apparently, did it make them honest ? No 5) The important part of your statement is "alleged", read the thread, there's nothing. Your answer is predjudiced and not backed by facts.

Continued in chat - http://chat.stackexchange.com/rooms/7358/re-is-it-possible-to-buy-or-sell-bitcoin-options

CoinBr is a MPEx broker that supports buying/selling/exercising of options, with much better interface and reasonable fees.

OP, here you go:
Haven't used the service myself.
https://atlasats.com/

I have never traded options, so you should make sure that you look into any details before trading. Just keep yourself safe!
But here are some sites I found:
http://options.bbinary.com/GetUnlimited100Bonus/v2/en/?campaign=4189&p=about%20options%20trading
https://campbx.com/
http://www.btclevels.com/

MPEx is fine, it offers options.
Accounts there are expensive (30 BTC IIRC) but there are third-party brokers that will let you avoid these fees by offering a different fee structure.
If you want to deal with MPEx directly you should have some knowledge about PGP as its security architecture is based on it and requires to be able to clearsign orders.
It doesn't have any specific issues that I know of (except for the opinionated PR perhaps).

Meni Rosenfeld's opinion is quite irrelevant here, MPEx allows the purchase and sale of options, which is precisely the question that is being asked.

If the suggested site has a questionable reputation, it is totally relevant!

Look at the facts, not the opinions and hearsay, why do you think SatoshiDice chose it for its IPO?

There's plenty of facts in the posted links.

i don't see anything that justifies that "it should be avoided". granted the PR is controversial, but AFAIK they've always been honest, they have a solid business model, they're chosen by the most successful bitcoin company ever for their IPO, they're transparent and have a rock-solid security model. And these are facts. Anyway, the OP will make his own opinion.

There are now quite a few ways to hedge the price of BTC. One way is with IG Markets binary options. There are also CFDs (contracts for difference) at several providers.
As for "dark pools" this concept is impossible on BTC since every 10 minutes all transactions are broadcast.

You are welcome to stick around and provide better answers than those that you saw. However, your answer here could use a more specific reference than "quite a few" and "several providers". :)

Just as a quick pointer: dark pools are indeed possible as trades on exchanges are not in fact broadcast to the network. What happens inside an exchange is not public as long as no one pays out, which would then again be a transaction on the network, or the exchange operator decides to make it public.

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


text:
What is the reputation of bitfloor?
It seems that bitfloor is a well designed trading platform, and a competitor to MtGox. However, the trading volume is low.
How long has bitfloor been in business?
Have there been any negative accusations such as fraud?
How safe is my money/bitcoins at bitfloor?

I am still unable to withdraw my bitcoins that were deposited before their September 2012 security breach.  Therefore BitFloor is technically insolvent.
They are registered with FinCEN as a money-service business in the U.S.  Thus I assume they are not immune to U.S. courts and U.S. bankruptcy laws.
They are one judgement away from having their bank funds frozen by a creditor, likely forcing BitFloor to declare bankruptcy.  If that happens, your funds might be used for paying out to legal costs, paying for the receiver, and then whatever is left for payment to all remaining unsecured creditors such as yourself, proportionate to the amount owed (i.e., "pennies on the dollar").

http://bitcointalk.org/index.php?topic=112069.msg1218947#msg1218947

I like BitFloor and I'ld like to see them succeed, but continuing to operate an exchange while insolvent is a move that is irresponsible and shows disrespect to its customers, current and prior.

Is this really true?  Bankruptcy laws are designed to give debtors a structured way to default on debts.  Bitfloor is free to handle the situation as they see fit (including not repaying any of the stolen funds).  If any of their customers have an issue with their handling of the situation, then they are free to complain to Bitfloor, and if that doesn't resolve the matter to their satisfaction, they can file a lawsuit.  If enough people file lawsuits, it is Bitfloor that has the option to seek bankruptcy protection.  I don't think anyone can force them to file bankruptcy.

Come on, you can't possibly be defending BitFloor's actions.  BitFloor's current customers might not be aware of the precarious situation of BitFloor's current insolvency and that their deposits are at risk.  Just to clarify though, IANAL. There is over a quarter million USD worth of coins owed to customers. When the first creditor gets a judgement it is then too late for BitFloor to stop that creditor from getting access to the USD funds of current customers.  BitFloor is effectively gambling (that no creditors will try to get a judgement) with its customer's money without their knowledge.


text:
Why did GLBSE close?
I went to https://glbse.com/ and see it is closed. It was a stock exchange for shares of companies denominated in Bitcoins.
Does anyone know why it closed?

Related bitcointalk thread

See http://bitcoinmagazine.net/interview-with-glbses-nefario/.

It appears that Nefario, the person operating GLBSE, decided to go against all bylaws and terms of service and just close GLBSE. That part of the story was explained by theymos. It it still unclear, however, why he did it.

Not sure the protection is warranted ... it seems rushed to me.

@ripper234 I think that the GLBSE closing down could be an event that would encourage a lot of people to rant and speculate. For not we have 3 answers with reputation 1 - one is just a random comment, one is making claims without giving sources, and one is balanced, but a bit uninformative. I'd rather avoid the mess of the first two types of answers. I guess I'll start a conversation about this topic on meta.

@ripper234 http://meta.bitcoin.stackexchange.com/q/308/323

At this point in time only one person, Nefario, knows for sure why GLBSE closed.  He was the one who had the power to close it, and he did so, without giving any public explanation.
Everything else is either hearsay or speculation.

Nefario's official reason for closing GLBSE was 1) AML  2) Tax 3) Regulation and he made it clear other shareholder's had no say in the site closing down.

Citation needed. Where did Nefario state that?

There is a very long IRC conversation with him chatting to his shareholders about this. I dont have a link but it is out there.


text:
Ideal prompt to show to the customer
I am selling SASS solution on my website.
How do I ideally educate customer to use bitcoin, which convince them
to use bitcoin instead of paypal or other methods.

Do you offer both Bitcoin and PayPal/other on your website? If so, offer them some discount, say 10% off, if they use Bitcoin. Tell them that it is due to lower processing fees. With some monetary incentive, you will convert some of your customers over.
If you offer only Bitcoin, put some link in a visible page stating something like "why only Bitcoin?", then bring them to a page in your FAQ where you explain your reasoning to use Bitcoin - lower development cost, lower processing cost, no charge-backs, freedom from third party companies, etc. etc.
Be sure to link to some accessable material for newcomers - for example, We Use Coins, or some materials from Bitcoin Wiki on Introduction.

A discount is a great incentive. Be sure to add to the FAQ "how do I buy bitcoin?"

Presumably you want your customers to use Bitcoin because it benefits you in some way.  Perhaps you get hit with forced chargebacks when using PayPal that you wouldn't have with Bitcoin (i.e., any refunds given would be initiated by you as the service provider).  Or perhaps the lack of fees versus PayPal (which cost 2.9% + $0.30 per transaction) are a reason why.  Or perhaps the proceeds are used to pay vendors, and the sooner the funds clear the sooner they can be put to work (bitcoin transactions are available for spending in about an hour).
So sharing with the customer some of the gains the come from the switch to Bitcoin  are one approach.  If the customer is presented with the invoice -- $100 when paid with PayPal / Credit Card, or $98 worth of bitcoins, then the choice is up to the customer but they are probably going to look into these.
If the customer has to pay 3% or more to get bitcoins (which is common using "instant" methods), then this financial incentive is a wash or less appealing.  But there are bank transfer methods which reduce the cost significantly (e.g., Using Dwolla with ACH bank transfer in the U.S., the bank transfer is free and teh cost paid to Dwolla is $0.25 per transaction.  Then the exchange fee is likely just half of a percent.  That's it then!)
Now if your business offers to accept bitcoin and your competitors don't, that alone gives it a competitive advantage as those of us who already hold bitcoins are likely to spend with a Bitcoin-friendly merchant versus one that isn't.  For instance, even though Amazon doesn't accept Bitcoin yet, their gift codes are easily obtained with bitcoins (i.e. several sources).  And thus of all the places computer hardware and consumer electronics is offered, more bitcoins are effectively traded for purchases at Amazon than anywhere else.  Amazon gains market share by simply offering a method in which ultimately bitcoins are used for purchases and its competitors don't.
Though there is no guarantee, there is the chance that bitcoins bought now and held will be worth more in the future.  Consumers generally don't understand speculation and tend to feel cheated when ending up losing from it, so encouraging consumers to speculate probably isn't in a merchant's best interest.  However a merchant might be willing to absorb the risk instead.  For example, an annual subscription could be offered at a discount where payment is made in bitcoin and the merchant essentially escrows the bitcoins.  If the value of bitcoin drops, the merchant still offers the service but absorbs the difference in the price paid.  If the value of bitcoin rises, the merchant takes the profit.  The consumer is happy in either instance -- service was obtained at a discount, yet the merchant may benefit greatly if the future exchange rates end up favoring the merchant.  Now if the service doesn't have high margins, then this approach may not be good, as the merchant might not be able to continue providing the service at a loss if the bitcoin exchange rate drops significantly -- so this approach may not work in many instances.
Essentially, it comes down to this -- most consumers don't know nor care if you accept bitcoin, they are going to use the method they already know.  Inertia.  Now if it is important to you that they switch to Bitcoin, you need to give them a reason and incentive to change the inertia.  Changing customer behavior is the aim of marketing and business strategy.  There likely will be more and more organizations discovering that Bitcoin brings advantages that it starts becoming important enough to allocate resources and getting the ball rolling.


text:
Does the public key associated with an address become part of the public record after it has been used to spend?
Since bitcoin addresses are hashes of public keys and not public keys as such, if one wanted to craft a message that could be decrypted by the generator of an address, that can't be done just with an address. But after the generator of an address has spent something that was received there, which requires presenting the public key (or does it?) publicly, is that public key part of the public record so it can be used for direct message encryption?
And is there a standard way to perform such message encryption, analogous to opaque PGP blocks, and supported by UI panels in bitcoin-qt where one can paste blocks of plain (with intended recipient) or ciphertext (directed to one of one's own addresses) and see plaintext or a copyable opaque block?

You're right that public keys are generally unknown until coins are spent from their address, and that until coins are spent only a hash of the public key is published.
While it's technically possible to use bitcoin public keys for the kind of encryption you're imagining, you're the first person I've seen talking about doing so.  The satoshi client has an interface to allow users to sign messages using their private key which others can verify using the associated bitcoin address, but using public keys to encrypt messages which only the holder of the private key can decrypt is something I've never seen.
Notice that signing a message with your private key in the satoshi client includes the corresponding public key in the output signature.  This allows the recipient to verify the message.  It's possible that otherwise they wouldn't know the public key, having only the corresponding bitcoin address.

Unless encryption is needed for making payments, that will not likely be something added to Bitcoin.  Here's an example of the resistance even to making clear text signing using a Bitcoin address and making it easier to be used for wider / general use: http://bitcointalk.org/index.php?topic=102761.msg1129361#msg1129361

The publicly shared Bitcoin address is a hash of the public key and nothing more.
The only thing a Bitcoin address shares with public-key infrastructure (PKI) is that it is a type of cryptography and it is shared publicly.  It does not provide the ability to encrypt a message so that only the owner of the private key can decrypt it.
What can be done though, is to combine two technologies to give you what you are looking for.
With the Bitcoin-Qt client, Alice can sign a message that can be verified to have been signed using the private key for a specific address.
So Alice can then use Bitcoin-Qt to sign a message that says "my public key is: 73B7B2F3".  Bob can then use his Bitcoin-Qt client to verify that the message was truly signed by the owner of a certain Bitcoin address.
Bob can then use GPG to encrypt a message to Alice, using Alice's public key that she claimed was hers and thus only Alice can decrypt and read Bob's message.


text:
Bitcoin arbitrage
Suppose I have BTC at HitBtc and Poloniex. The prices and fees are:

HitBtc: price is 8460, fees are ~0.1%.
Poloniex: price is 8385, fees are ~0.2%.

The price difference is 0.9%. I can sell BTC at HitBtc by 8460 and then use this money to buy BTC at Poloniex by 8385 to make money after fees.
Is there an arbitrage opportunity here?

Sounds right, why not?

Then why such opportunities exist?

Arbitrage Example

Buy 100 XCOIN for 100 EUR (1EUR/XCOIN) on Exchange A
Send 100 XCOIN to exchange B minus transaction fee of 1 XCOIN
Wait for X confirmations before Exchange B will let you trade to your 99 XCOIN
Sell 99 XCOIN at 1.1 EUR/XCOIN for 108.9 EUR
Repeat

Risks and Fees

There are sometimes fees for purchasing coins
Transaction fees exist on many blockchains.
Confirmation times can take several minutes to several hours.  During this time the price can drop below the price you bought it at, causing a loss.
There are fees for selling and converting coins to Fiat.

These opportunities exist because price is set by the market.  Each exchange is its own market with different people selling different amounts of coins for different prices.

Thank you. I would think my previous examples take care of 1, 2, and 4. So I would think 3 is the reason.

arbitrage is possible but have not a very good profit margin in this case (caused by tradingfees, networkfees, etc). furthermore you must consider the fast price fluctuation of btc cryptocurrency-markets.

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


text:
I sent a Bitcoin transaction to myself using Bitcoin Core and it is not broadcast?
I am not asking why the transaction is not confirmed, I am asking why it does not show as being broadcast even though it is in the log.
I sent a Bitcoin transaction to myself some time ago using Bitcoin Core, and it just says it is in the mempool after 55 days - I just noticed. Usually, it says broadcast through x nodes. The balance is, of course, showing in my wallet.
Status: 0/unconfirmed, in memory pool
Date: 1/12/17 20:48
Total debit: -0.00004551 BTC
Total credit: 0.00004551 BTC
Transaction fee: -0.00001001 BTC
Net amount: -0.00001001 BTC
Transaction ID: 766dd7ea920a7f40579ee805e649a2fc886e89e9b514f653837b8ab219825af9
Transaction total size: 225 bytes
Output index: 0

I know that the fee might seem a bit low but I did use the fee recommendations, and another transaction with the same fee sent elsewhere at the same time confirmed some time ago.
In my debug.log this time after restarting the node I see:
AddToWallet 766dd7ea920a7f40579ee805e649a2fc886e89e9b514f653837b8ab219825af9
Previously I used to see a debug.log message for rebroadcasting transaction after node restart, which I assume now was this one even though there is no broadcast count, but I cannot see that message yet this node restart. EDIT: log message took a while and looks like this:
2018-01-24 10:51:10 Relaying wtx 766dd7ea920a7f40579ee805e649a2fc886e89e9b514f653837b8ab219825af9
2018-01-24 10:51:10 ResendWalletTransactions: rebroadcast 1 unconfirmed transactions

What needs to be done to resolve this?

@Alpha I have seen that canonical question and understand the confirmation process, fees, transaction bandwith limit, etc. but that I know of it does not answer my question - unless an explanation of how it does is necessary?

It seem's that your ultimate question is "What needs to be done to resolve this?" In response, @Alpha's linked article states "Nothing. The next best thing is to cancel and resend the transaction."


text:
I have a physical Bitcoin, how can I exchange it for dollars
I aquired a Bitcoin back in 2013,can I exchange it for dollars at a bank.

What do you mean physical bitcoin? do you mean casascius coin? you cant exchange that for dollars at a bank, you have to redeem the bitcoin first by downloading a bitcoin wallet importing the key and then selling the coins on exchanges or local peer 2 peer trading sites for dollars.

See answers to Finding the Address of a Physical Bitcoin for help in identifying your coin and whether it is worth anything and how to spend it.

If you have a physical Casascius coin, you will be much better off selling it for dollars on eBay or similar site, or perhaps at a coin (numismatic) shop. The value of Casascius coins usually exceeds the nominal bitcoin value. They are collector's items.

There are a handful of people/companies who manufactured physical bitcoins, most notably Casascius.
If you have one of these, a little tamper proof seal should cover a private key. You can then import that private key into a wallet such as electrum, and send the bitcoin to an exchange where you can trade it for fiat, which will vary by your location.
If you do not have a bitcoin which contains a private key, then your physical bitcoin has no bitcoin value.

NOTE: if you do have a Casascius coin in good condition, then it is probably worth more if you do not unseal the private key. Casacius coins are considered collectibles, and if they are still sealed they can sell for much more than the face value of the coin. You may get more money selling the coin to someone, than you would unsealing it and transferring/selling the BTC on it.

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


text:
What's with this address 1111111111111111111114oLvT2?
It was the burn address with the most BTC received in 2017 according to
http://bitcoinwhoswho.com/blog/2017/12/30/8-97-bitcoins-burned-in-2017/. It's Hash160 is 0000000000000000000000000000000000000000. In Sept 2015 it served as a 40 BTC proof-of-burn address for Blockstore.
So, why did it receive 14,270 inputs of BTC dust in 2017 totaling 8.70069482? Why does "unable to decode output address" accompany this address on every transaction on Blockchain.info? https://blockchain.info/address/1111111111111111111114oLvT2
In this transaction it appears similar to a change address:
https://blockchain.info/address/16HBq938GwQkpWKWFkAomt4KpQeWUqXsZR

The "unable to decode" is an OP_RETURN output which simply contains some arbitrary data to be inserted into the blockchain as part of the transaction.  See [tag:op-return].

what is 111...1114oLvT2?

See also here, it explains in detail on the logic behind „proof of burn“, including op_return.

why 14,270 BTC?

We cannot know. Pure speculation would be, that people write scripts, to do a proof of burn. Or also, they could provide a P2SH tx, where the hash of a text is provided. Think of it as „I can proof, that I had a data, that I published as a ahah into the bitcoin blockchain“ (proof of existence). Also one could think of a recurring payout from a faucet or mining contract. We don‘t know.

why unable to decode?

answered by Nate

1111111111111111111114olvt2 appears to be used as the Proof of Burn address of Blockstacks Core. I had never heard of that project before, but they describe themselves as:

Blockstack is a new internet for decentralized apps where users own their data.
Blockstack applications follow a can't-be-evil design philosophy. They cannot alter, transfer, or revoke the user's identity, and they cannot read or write the user's data without permission. Blockstack provides the platform, network, and SDKs for building can't-be-evil applications using existing Web tools. If you are Web developer, all of your skills are immediately transferrable to Blockstack.

I found their project via a note on the oxt.me explorer for the address in question.


text:
Where are the specifications for making "known protocol" OP_RETURN scripts?
I have created a transaction with high miner's fee that is now in mempool that won't confirm:
https://live.blockcypher.com/btc-testnet/tx/abcc4ce473f490896e87102fe3ffb857ff735a0fc97525dadf9c5b0ed5410f9f/
From a previous question, I've been informed that the likely reason for this is that there is data embedded with a non-standard (or "unknown" protocol). I have input "hello_world" as an OP_RETURN script. How do I make it a known protocol so that the transaction can be confirmed? Is there a list of known protocols somewhere?

The technical term is in fact "standard" or "non-standard" transaction.   You can read the definition here or here.  But testnet isn't supposed to impose those restrictions, so I don't think this is what's affecting your transaction.

Not exactly a duplicate but the other question's answers are helpful in understanding the situation which is that my transaction is apparently fully "standard". So it's just blockcyper's code that doesn't like it. Still a mystery why the transaction isn't confirming though. Maybe testnet really is that slow.

Actually, I think it isn't standard.  Not because of the OP_RETURN output, but because of the 546-satoshi output which is dust.  But again, I'm not sure how that's treated on testnet.

@NateEldredge That amount was determined by bitcoinj's params.getMinNonDustOutput(). I am doing another test with a larger amount (and no OP_RETURN): 3500f82046a690638220af9fc857eb3a777ed599a368fcc9776ac6e896619a2d


text:
How does the bitcoin transaction fee be calculated? And who guide this?
https://en.bitcoin.it/wiki/Transaction_fees
I learned that the transaction fees is given by sender to bitcoin miners to ensure that this transaction be confirmed.
But I notice that, in most exchange websites or clients, the default transaction fee is 0.0005BTC, so Could It be possible that the transaction fee will be guide by the exchange websites or popular client software providers?
Because if a person don't accept the transaction fee in main stream, his transaction will probably not be accepted and appended to the block.

When creating a transaction the Bitcoin-Qt client will determine the properties of a transaction and if the transaction is likely to need feeds the client will insist that a fee be added.   The rate is 0.0005 BTC per 1K of data consumed by the transaction.  If the transaction size is below 10K though and meets other criteria no fee is required:

http://en.bitcoin.it/wiki/Transaction_fees

Other clients may not have any requirement when sending.  For instance, the Blockchain.info/wallet allows "Custom" send in which the fee is entered by the sender.  Zero is a valid fee amount.
It really doesn't matter what the client or the user chooses, what matters are the level of fees the miner's require.   If few miners will accept a transaction because the fee is too low, the transaction will simply just take longer to confirm, eventually.
So there is a competitive market for transactions.  A miner can try to boycott transactions in which the fee is too low however the next miner might be willing to include the transaction and in that instance the boycotting miner is simply passing up the opportunity to earn the fees from that transaction.
So the market consisting of miners looking for revenues from transaction fees guide the rate that is required for a transaction to get mined in a timely manner.
It is likely the amount for the recommended fee in the Bitcoin-Qt client will be decreased at some point if 0.0005 BTC ends up becoming expensive (currently less than three U.S. cents).

"The rate is 0.0005 BTC per 10K of data" - isn't this wrong? isn't this 0.0005 BTC per 1000 bytes of data? Anyway isn't it planned to be decreased to 0.0001 BTC per 1000 bytes of data soon?

Thank you Miernik, you are correct, 0.0005 per 1K with the exception of a data size under 10K and other criteria met.


text:
How many confirmations do I need to ensure a transaction is successful?
As a regular user of Bitcoin, I often send bitcoins to other, or receive BTC from others, sometimes this might be a trade or deposit. Some traders require at least 6 confirmation, some require at least 3.
I want to how many confirmation is enough to ensure the transaction is successful?

Please refer Why is 6 the number of confirms that is considered secure? .

It depends on your risk model.
If you can trust the person paying you, you can accept payment on 0/unconfirmed if you want.
As a merchant or trader, you want to use the configuration that is more secure (no incoming connections permitted, explicity connect to well-connected nodes).
With zero confirmations you are vulnerable to the race attack and the Finney attack, as well as the 51% attack.
With one confirmation you are vulnerable to the 51% attack.  There could also be a miner with a lot of hashing power who could get a couple blocks in a row, so three confirmations removes most of them.
With six confirmations it is essentially mathematically impossible for an attacker with less than 51% of all mining capacity to get six blocks in a row. and still surpass the longest block chain.  With 51% or a lot more than 51% the attacker can get six confirmations by creating a parallel blockchain in which only transactions approved by the attacker get included in blocks.
A merchant like a retailer can likely accept even on 0/unconfirmed in most instances (e.g., purchases up to $100 worth).     A merchant that ships e-commerce might hold off until the transaction has three confirmations.
A cash, face-to-face cash trade will probably be best if three confirmations for a large amount, maybe one confirmation for small amounts.
Any recommendation would need to come only after determining which risks are deemed acceptible.

50% hashrate isn't required to double-spend 6 confirmations. 20% hashrate is enough to have 1% chance, 40% hashrate is enough to have 50% chance.

I choose this as correct, but I found that there is already a question discussed this a lot. Please refer Why is 6 the number of confirms that is considered secure? .

@MeniRosenfeld can you provide some reference for these calculations?

The lesson of the recent v0.7/v0.8 fork issue is that simply waiting for 6 or more confirmations is insufficient.  You also need to satisfy yourself that there are no competing blockchain forks
e.g. this thread discusses a double spend proof-of-concept that was executed during the chain fork: https://bitcointalk.org/index.php?topic=152348.0

With 6 confirmations you are safe from double spends and the like.
For low-value transactions, 1 or 2 are likely enough.


text:
Why is getdescriptorinfo returning an error "Invalid descriptor (code -5)"
I am using Bitcoin Core bitcoin-cli with getdescriptorinfo like so:
curl --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getdescriptorinfo", "params":["sh(multi(2,[3c60330a/1]03061b79f20d49790c15bdaf15ec8db6d75275f62f04a56eaac31f5c2db48736fc,[d54e4481/1]0396bd8d30f0128dcc67e143cf46efd686bf9e4dc8587facc07f81bb248d1b0209,[1e132a06/1]03c77aa842edc8af76b76f5c29a1133b45b78c8c26a170090184e500232abd15a4))#3qpdv9la"] }' -H 'content-type: text/plain;' http://bitcoin:password@127.0.0.1:18332/

But it returns Invalid descriptor (code -5)
What am I doing wrong?

If you are willing to compile Bitcoin Core from source, there is a change in the current master branch that will return more specific errors about descriptors (https://github.com/bitcoin/bitcoin/pull/16542). This change will be available in 0.19.

Descriptors in Bitcoin Core can have a suffixed checksum.
sh(multi(2,
[3c60330a/1]03061b79f20d49790c15bdaf15ec8db6d75275f62f04a56eaac31f5c2db48736fc,
[d54e4481/1]0396bd8d30f0128dcc67e143cf46efd686bf9e4dc8587facc07f81bb248d1b0209,
[1e132a06/1]03c77aa842edc8af76b76f5c29a1133b45b78c8c26a170090184e500232abd15a4))
#3qpdv9la

You pass the checksum 3qpdv9la. However if I call getdescriptorinfo without the checksum (see below) a checksum of 539k404m is calculated for that descriptor.
bitcoin-cli getdescriptorinfo "sh(multi(2,[3c60330a/1]03061b79f20d49790c15bdaf15ec8db6d75275f62f04a56eaac31f5c2db48736fc,[d54e4481/1]0396bd8d30f0128dcc67e143cf46efd686bf9e4dc8587facc07f81bb248d1b0209,[1e132a06/1]03c77aa842edc8af76b76f5c29a1133b45b78c8c26a170090184e500232abd15a4))"
{
  "descriptor": "sh(multi(2,[3c60330a/1]03061b79f20d49790c15bdaf15ec8db6d75275f62f04a56eaac31f5c2db48736fc,[d54e4481/1]0396bd8d30f0128dcc67e143cf46efd686bf9e4dc8587facc07f81bb248d1b0209,[1e132a06/1]03c77aa842edc8af76b76f5c29a1133b45b78c8c26a170090184e500232abd15a4))#539k404m",
  "isrange": false,
  "issolvable": true,
  "hasprivatekeys": false
}

Invalid descriptor (code -5) is returned, because your descriptor doesn't match the checksum you provide.
Did you enter the descriptor by hand (i.e. not copy pasting)? Where did you get the descriptor from?

The descriptor came from the json result Bitcoin Core returned when calling bitcoin-cli getaddressinfo, I will try and replicate the whole process and edit the OP.

would a descriptor in regtest create a different checksum then a descriptor in testnet or mainnet? Maybe that is it.

The xpub/xprv and address format used inside descriptors is network dependent.


text:
How to manually compute a descriptors checksum?
In the docs it says: The checksum for a descriptor without one can be computed using the getdescriptorinfo RPC.
I would like to build a recovery tool where many descriptors are imported, calling getdescriptorinfo for each is cumbersome. Manually calculating the checksum would save a lot of time and network calls.
Do I just double sha256 the entire descriptor and convert the first 4 bytes to hex?
Thanks :)
EDIT: I found this, seems quite a bit more complex than a double hash... https://github.com/bitcoin/bitcoin/blob/master/src/script/descriptor.cpp#L95

You can take a look at the file bitcoin/test/functional/test_framework/descriptors.py, there  is a function to create the checksum:
def descsum_create(s):
    """Add a checksum to a descriptor without"""
    symbols = descsum_expand(s) + [0, 0, 0, 0, 0, 0, 0, 0]
    checksum = descsum_polymod(symbols) ^ 1
    return s + '#' + ''.join(CHECKSUM_CHARSET[(checksum >> (5 * (7 - i))) & 31] for i in range(8))

It has dependencies to  descsum_expand and descsum_polymod but both are included in the same file.
Here is the Python code you will need:
from test_framework.descriptors import descsum_create

descriptor = 'addr(mkmZxiEcEd8ZqjQWVZuC6so5dFMKEFpN2j)'

descriptor_with_checksum = descsum_create(descriptor)
print(descriptor_with_checksum)

result:
addr(mkmZxiEcEd8ZqjQWVZuC6so5dFMKEFpN2j)#02wpgw69


text:
Altering Consensus Rules
How nodes agree to consensus rules? Is it possible for someone to change the consensus rules for his own software and then remain in the previous network? If not, then why?

If you alter the consensus rules in the software running your node, there are two options:

You apply rules less restrict than before, accepting some transactions that were previously invalid: every block you mine will be displaced by blocks from longer chains mined by the miners that didn't change anything and have more hashpower than you. Because they'll never accept your blocks but you're still accepting theirs.
You apply rules more restrict than before, rejecting some transactions that were previously valid: you are on your own, and will have to mine every single block. Depending on your current hashpower, it could take weeks until the next one. Unless you also change the rules concerning minimum difficulty. But the blocks you mine still will be accepted only by your node.

Is it possible for someone to change the consensus rules for his own software and then remain in the previous network?

It is theoretically possible to do this and still remain on the previous network especially if you are imposing an additional restriction (an effective soft fork) rather than a relaxation (an effective hard fork). However I would strongly recommend against doing so on mainnet if any funds with real world monetary value are at stake. The reason for this is even with soft forks you can be forked off the network following a different blockchain if you reject a block due to a transaction in this block not meeting your additional restriction. An example of this was demonstrated prior to the Taproot soft fork when there was one user running a full node who claimed to have been forked off the network for applying the Taproot rules too early when 0xB10C spent an anyone-can-spend Pay-to-Taproot output prior to activation.
When it comes to consensus rules the punishment for diverging from the rules being enforced by the rest of the network is significant. You risk being forked off the network, following a different blockchain and verifying transactions and blocks that aren't representing the actual Bitcoin blockchain (effectively a different currency or asset). So by all means experiment on testnet, signet with different consensus rules but when verifying mainnet transactions and blocks do not do this.


text:
How to set up Lightning Network conf file. RPC user / password? and zmqpubraw?
In my lnd.conf file I have the following settings:
debuglevel=info
listen=192.168.100.134
externalip=186.4.235.84
alias=MyNodeAlias
color=#000000
maxpendingchannels=5
bitcoin.mainnet=1
bitcoin.active=1
bitcoin.node=bitcoind
bitcoind.rpcuser=bitcoind_rpc_user_string
bitcoind.rpcpass=bitcoind_rpc_password_string
bitcoind.zmqpubrawblock=tcp://127.0.0.1:18501
bitcoind.zmqpubrawtx=tcp://127.0.0.1:18502

What is rpcuser and rpcpass? which values should I use? Also, what is zmqpubrawblock and zmqpubrawtx?

So in Bitcoind you can define authentication via an rpc interface (remote procedure call). In the config file of Bitcoind which is usually located in ~/.bitcoin/bitcoin.conf you can set the values for
rpcuser=bitcoind_rpc_user_string
rpcpass=bitcoind_rpc_password_string

Obviously you should select other values than the ones in this answer / question. You could also pass those values as command line arguments to Bitcoind.
As for the other two values. Bitcoind uses zero message queue (zmq) to share raw block data and raw transactionsdata. I guess raw means binary (but I am not sure). These two values are the zmq sockets for both interfaces I guess they are pub / sub sockets to which your lnd node will subscribe.

Note that the newer rpcauth lines are preferred over rpcuser/rpcpass.

The bitcoin conf should be in ~/.bitcoin/bitcoin.conf. Also, I think it should be noted that you don't usually need any of this configuration if lnd is run as the same user as bitcoind, since lnd just reads the secrets from bitcoin.conf, while bitcoind should autogenerate auth credentials.

Is that needed in case on lnd running on same machine of bitcoind?


text:
How to create a p2sh transaction with a scriptsig of OP_true?
How can I create a p2sh transaction with a scriptsig containing OP_TRUE only, removing the need for a digital signature, which will be broadcasted and mined?
Also could some one provide an example of such a transaction?

@Michael Folkson I see the tag bitcoin-core-development was added by you, but I don't understand how it's related to the question, can you explain?

@VojtěchStrnad: Not sure, it was a while back! Think I thought it was functional test related but removed now :)

Here you have an example of a transaction spending from a P2PKH output and creating a P2SH output with an OP_1.
And here you have the counterpart, a transaction spending from the first one (with an input script '0151') and generating a P2PKH output.
I've created both using a Python library i'm coauthor of. You can check it out here.

I've added new transactions including fees to ensure that they end up in a block.

Does the output script you use to fund the p2sh transaction always have to be OP_HAS160 (hash) OP_EQUAL ?

Yes, that's the structure of any P2SH output script.

Could a transaction like that be created on the mainnet?

Sure. However you should be careful, anyone will be able to redeem it.

Would the transaction with scriptsig 0151 be considered standard or non standard?

Standard AFAIK, it's just a push of data.

So once the output script you are using as your input is OP_HASH160 (hash) OP_EQUAL , you can create a p2sh transaction with scriptsig OP_TRUE that doesn't require a digital signature?

You're messing around the concepts a little bit. If you are spending an UTXO of type P2SH that encapsulates the hash of an OP_True, you can create a P2SH transaction that spends it just by pushing a 1 to the stack.

So how can you know if it encapsulates the hash of OP_TRUE and what does a hash of OP_TRUE  look like?

has160(A) = hash_A no matter how many times you compute it. So the hash of OP_True will always be da1745e9b549bd0bfa1a569971c77eba30cd5a4b

So if the utxo doesn't encapsulate OP_TRUE, is there any other op code or combination of op codes that can be used to create a transaction that can be broadcasted and mined?

Yes, it doesn't matter the op_code combination. You can create for examples a P2SH encapsulating an OP_2 OP_EQUAL, and then redeem it with a push of 2. There are many combinations that do not imply a signature.

So is there any op code or combination of opcodes that will make a  transaction valid regardless of what the output script encapsulates and if not, how can you determine what the output script encapsultes in order to create a scriptsig with the necessary op codes?

Updated links to blockstream.info as prior block explorer links have been taken down


text:
Unilateral closing transaction for channel stuck in mempool
I've now had an unilateral closing of a channel stuck in the mempool for over two months. I want to transfer the unconfirmed sum to another wallet, so I want to create a new transaction which also is a CPFP transaction to the first transaction thus making it confirm faster. But I haven't been able to find a way to do it and would appreciate any guidance in how to do it, if it's even possible.
My lightning node is running Core Lightning v23.08.
And I don't see anything in "outputs":[] when running lightning-cli listfunds

Not an issue anymore for me transaction now confirmed after been 2 months in the mempool. It's the longest time I've had a transaction there. To me it shows the robustness of Bitcoin! This is still a problem tough if you want to escalate the transaction or just send the funds. But maybe there is an explanation I'm missing.

This was discussed on the Core Lightning community chat in August 2023. grubles stated:

You can do it manually if you use hsmtool to dump your CLN onchain descriptor, import that into bitcoind, create a PSBT with a higher fee, and sign it with CLN. Let me know if you want to give that a try.

At the time of writing (September 2023) there doesn't seem to be an easier way to do this.


text:
Is weighed multi-sig wallet possible?
In a multi-sig wallet, each of the public keys is unique. Is it possible to create weighted multi-sig wallet, such that one private key has more power than the others?
Case 1: typical Example (need 2 of 3 to spend):
2 PubKeyAlice PubKeyBob PubKeyChris 3 CHECKMULTISIG

Case 2: Duplicate public key for weighted signing (need 2 of 4 to spend):
2 PubKeyAlice PubKeyAlice PubKeyBob PubKeyChris 4 CHECKMULTISIG

In this case, Alice could sign on her own (she has 2 of 4), or Bob and Chris can come together to sign.
Case 3: No duplicate public keys, but multiple public keys controlled by one person.
In this case Alice would control two private keys, and then the wallet would look like:
2 PubKeyAliceA PubKeyAliceB PubKeyBob PubKeyChris 4 CHECKMULTISIG

Certainly Case 3 works today. And Case 1 is the basic unweighted implementation.
Does Case 2 work? Or is there some alternative to make Case 2 work? (i.e. a single Private Key holder has more power / shares then others).

There is no restriction on what the public keys of the multisig are (assuming they are valid public keys as defined by a particular SegWit version). If you want two of the four public keys in a 2-of-4 to be the same there is nothing to stop you with OP_CHECKMULTISIG and the new Taproot multisig opcode OP_CHECKSIGADD.
You can achieve something similar with a script that effectively says "Alice signs OR 2-of-3 signs" without repeating Alice's key in a 2-of-4.
You can also repeat the same public key in threshold key aggregation schemes like FROST assuming you treat the two public keys that are the same as independent public keys for the purposes of nonce generation (Thanks to nickler for confirming).

Thank you. Is there a good source for getting started with FROST? I found a paper but seemed rather dense, would be good to see something where its applied or examples of use cases.

@miketery: Still a work in progress PR at this point. Links to various FROST resources are here: https://btctranscripts.com/sydney-bitcoin-meetup/2022-03-29-socratic-seminar/ The use case is saving block space (only one signature goes onchain when spending from it) and updating the threshold sig arrangement without needing an onchain transaction.


text:
Can you do P2WSH / P2SH on Lightning Network (LN)?
I understand that a channel is a 2 of 2 multisig:
1 && 1

Is it possible that one side of this channel is a multisig wallet?
So in essence one of the 2 main, is actually a 2 of 3 multisig. This would be:
( 2 of 3 ) && 1

If the other side was also multisig (say 4 of 5), then the channel would be:
( 2 of 3 ) && ( 4 of 5 )

I know the point of LN is speed, and low fees. So speed is hurt by coordinating multiple signatures. And also multisig is typically meant for high value, so fees might not be an issue if not on LN.
Separately, I presume if you use Schnorr signatures, there is no way to know how many are needed for the threshold. Is this true? So it would be:
1 schnorr threshold && 1 schnorr threshold

Are these live on LN?

I understand that a channel is a 2 of 2 multisig.

Right, a channel according to the current Lightning protocol must be a 2-of-2 multisig. As far as the blockchain is concerned any funds moved from this address require two signatures from the two specified public keys.
However, as you rightly say Schnorr multisig (e.g. MuSig2) and Schnorr threshold key aggregation schemes (e.g. FROST) allow you to simulate multisignature and threshold signatures arrangements with only one signature and one (aggregated) public key going onchain. So you can take one (or both) of those 2 keys in the 2-of-2 and do as you suggest.
In addition the Lightning protocol could change in future to take advantage of MuSig2 and turn that 2-of-2 into a single pubkey spend. However, that most likely won't happen anytime soon, requires a Lightning protocol change, channels to upgrade etc. The nested schemes you suggest can happen today and as far as the blockchain and the Lightning gossip is concerned it is a valid 2-of-2 with no knowledge of the simulated arrangement behind it.

Separately, I presume if you use Schnorr signatures, there is no way to know how many are needed for the threshold. Is this true? So it would be:

Right, unless you are part of the multisig or threshold arrangement all you see is the signatures on the blockchain. So you don't know whether a threshold was used at all and if it was what exact threshold it used.

Are these live on LN?

As Rene says we expect this isn't happening today as we haven't seen open source implementations of it yet but it is possible it is.

As you realized the point of Lightning is to reduce latency. At the same time coordinating signatures from various parties in order to move forward the state seems rather impractical. Thus as far as I know there is no open source implementation by anyone to do that.
However this is certainly possible and probably also useful to some.
As a starting point I would look at https://gitlab.com/lightning-signer/docs where they create a remote signer. This remote signer could probably have a more involved signature scheme like you proposed.


text:
How many BIPs were adopted in the standard client in 2021?
With taproot, a number of longstanding BIPs were merged into the Bitcoin standard client/consensus protocol - BIP341, BIP340, and BIP342. However, the Bitcoin repository BIPS index is unclear on when a BIP has actually been 'adopted' and merged into the standard client.
Does anyone have suggestions on identifying which BIPs were implemented in bitcoin-core, and when?

BIPs are just proposals. Whether any particular piece of software supports/adopts it is up to the developers of that software.
To find out which BIPs are supported by Bitcoin Core specifically, look at its  doc/bips.md file.

Thanks for your answer Pieter - however, per my question the doc/bips.md file is unclear on when the BIP was adopted/merged by Bitcoin Core.

Ah, you can look at the version numbers. 0.21.0, 0.21.1, and 22.0 were released in 2021. Note that the descriptor BIPs (380 and up) were mostly implemented in earlier versions, but only later turned into BIPs.

With taproot, a number of longstanding BIPs were merged into the Bitcoin standard client/consensus protocol - BIP341, BIP340, and BIP342.

Bitcoin Core is an implementation of the Bitcoin protocol. It is considered by many as the reference implementation and is certainly the dominant implementation on the network at the time of writing.
According to BIP 2 a BIP can be in a FINAL/ACTIVE state. But this does not necessarily mean that a BIP is adopted in Bitcoin Core. Some BIPs (e.g. BIP 39) are proposed standards documents that have been implemented in the wider ecosystem but have not been implemented in Bitcoin Core.
There are three types of BIPs (Process, Informational, Standard) and even within say Standard BIPs they can vary from Consensus (soft fork) to Applications that may not be applicable to Bitcoin Core. BIP 340-342 were examples of Consensus (soft fork). Obviously Bitcoin Core needed to implement these features for these consensus changes to be activated on the network.
However, the state of each BIP isn't always up to date. For example Signet has been implemented in Bitcoin Core but is still in a Proposed state. So any count of BIPs in a FINAL/ACTIVE state wouldn't be an accurate representation of what has been "adopted" or "merged into the standard client".

Thank you for the context around the state of the BIPs and their relation to the implementation.


text:
My node is not showing on Bitnodes
I have a 0.16.3 Bitcoin Core wallet running. I have incoming transactions allowed and I have lots of incoming connections. However, I fail to see my node on the map of Bitnodes; it says it's unreachable, also I have tried to appoint it as a trusted node to my Samourai wallet, and Samourai also fails to connect to my node.

i dont understand, how is it reachable to you and how does it produce spam ?

@scaaahu How do you know if OP's node is reachable, as he hasn't given an IP address?

To the OP and @PieterWuille : My bad and my misunderstanding. I apologize. My spam flag was declined and I just upvoted this question to make it up. Sorry again.

The reason a running node shows as 'unreachable' on bitnodes.io is that (y)our "maxconnections" limit has been reached. Sometimes connections drop off and we can get lucky by repeat clicking on the "CHECK NODE" button. Restarting bitcoind increases the chances of getting a green banner as connections slowly build up to the maximum configured in 'bitcoin.conf'. I wish there was a whitelist that accepted incoming IP connections regardless of "maxconnections".

From my experience, sometimes the router doesn't actually respond to the UPnP setting for mapping the listening port. What always seems to be working for me is

Shutdown your node (cli stop && shutdown)
Restart your router (usually unplug, wait a minute, replug and wait a few minutes)
Restart node

Regarding the hookup to Samourai, what exactly are your bitcoin.conf settings?

so shuting down the node and restarting the router i've done many times already, however im on my way to change my router with a new one as this one is old anyway. Samourai requires IP of the node, RPC pass/user and port. as information in order to appoint your node as a trusted one to your samourai wallet.


text:
Lightning: Keys confusions
I am currently trying to understand the Lightning network using their whitepaper and BOLT#3.
However, I have some trouble to understand each public/private keys roles in the processus.
From what I understand here is the process (I call P public keys and K private keys):

Alice and Bob create a Funding transaction but before broadcasting it --> 2 P_a P_b OP_CheckMultisig

They create a commitment (C1a/b) in order to be able to retrieve their fund in case of problems.  They both sign it and give it to the counterparty (so Alice sign the C1b with K_a and give it to Bob and vice versa)

(I skip the part of RSMC,HTLC...)
HOWEVER, in BOLT#3 in find this:

Each commitment transaction uses a unique localpubkey, and a
remotepubkey

So I don't really understand, do Alice and Bob continue to sign using their private key ? (K_a and K_b) in order to be able to unlock the funding transaction? Are these new publics keys only used for signing new multisig Adress in HTLC and RSMC ?
I think that I am confused about:

which key to use and when
how can we still unlock the funding transaction using various keys

Thank you for your time, I am a newbie here and I hope I will find some help!
Best

The BOLT#3 quote you mention refers to the output(s) of each commitment transaction. Keys used in the to_local and to_remote outputs are rotated for each commitment transaction pair.
The commitment transactions are still signed using the funding output's keys.
Aside, note that while the Lightning paper at lightning.network does describe key ideas behind the payment channels in use today on the network it is very outdated. It for instance still makes use of NOINPUT-signed transactions which can be confusing if you start learning about the Lightning Network.
Deployable Lightning from Rusty Russell describes the fundamental changes, and the BOLTs describe what is actually in use today (which is also different). However, they intend to be detailed and prescriptive, not explanatory. If you are looking for an introduction to the Lightning Network, then the Lightning Network Book is probably a better resource.

Thank you so much for your response (And thank you Antoine as well).
You are totally right, the lightning white paper seems ... outdated? For exemple, the white paper talks about 'Breach Remedy Transaction' or 'Revocable Transaction' but in bolt#3, it seems that this "Breach Remedy Transaction" and the Revocable Transaction are directly in the output script now (only need a revocation key instead of the whole breach transaction for exemple)

To complement Antoine's answer, Chris Stewart presented on Lightning private key management at the Lightning conference 2019.
There are actually 6 different secret keys that you need to manage as part of the Lightning protocol, some of which need to be hot and some of which can be kept in cold storage.
I think you are getting confused between the funding private key and the first per commitment secret. Chris explains the per commitment secret here:

It is the per commitment secret and this is changed every time a
Lightning transaction happens. You rotate this secret so it is
constantly changing every time something happens in the Lightning
channel. It is used to generate the two outputs on your commitment
transaction so you need it in a very real sense to be able to access
these outputs in case a commitment transaction goes to the chain.
Again with this key it must be hot. Every time a Lightning transaction
happens you need to be changing this thing and then revoking it after
a state transition happens.


text:
Bitcoin wallet on smart phone drains battery a lot?
I downloaded Android Bitcoin Wallet (version 6.17) on my android phone, and realized that the app drains battery a lot. The system showed 40% of battery was used to the wallet.

Does anyone have same issue?
Or is this happen to other different Bitcoin wallets?
Or should I kill the process after I open the app?

If Bitcoin Wallet drains battery a lot compared to other apps like Whatsapp, Facebook that run background, the wallet is not suitable to smart phone...

if its downloading the blockchain so I think its a usual behavior

@Adam After synced blockchain, it happens.

@NateEldredge Yeah you are right, so I edited the wallet name, not core wallet.

I never tried the android version but from my experience from the desktop version, when you run the core, the bitcoin core will attempt to connect to another peer, when it received it, it will verify the transaction using your CPU which causes more power draw

Thanks, but I rather want to know the wallet for smart phone.

SPV clients work very differently from full nodes like Bitcoin Core, so I don't think this answer is really relevant.

@YuyaOgawa if you need a wallet, try to use blockchain or coinbase

@NateEldredge I mean I never tried the mobile version of it so I just give my best answer but it still bitcoin core so it might need to do a transaction verification

I think OP is talking about some other wallet app, because there is no version of Bitcoin Core for Android.

@NateEldredge oh ok I see


text:
Is it safe to rent server to run a full node?
I want to rent dedicated server to run a full node to receive bitcoin for my website. Is this safe if I encrypt my wallets or should I own physical server?

If you need only to receive bitcoins, or better only to check the balance of your wallet, you can setup a read only address that leave no way to send money through this server.
To setup read only addresses there are several command:
importaddress
importmulti
importpubkey
Instead if you need a full node that receives and sends bitcoins automatically, (despite the fact that the encryption is secure) the wallet cannot be encrypted and it can be risky (at least more than having physical possession of the server) and you have to evaluate if the savings of buying a VPS instead of a physical server compensate for the greater risk of theft.

How i can setup read only address and how i can send money from read only address? why wallet cannot be encrypted in case receives and sends automatically?

you can import a readonly address on the target server with bitcoin-cli importaddress , the address should be generated on another server which has the privatekey to spend btc, if you want to send btc automatically the node must read the privatekey to send btc so it cannot be encrypted

bitcoin core can generate wallet offline?

yes, however the wallet does not need to be created with bitcoin-core, you can use the wallet you prefer, a bitcoin address is always a bitcoin address, however you generate it, you can always import it with bitcoin-core as read only.

Even better, you could import an extended public key in your web setup which would allow you to generate separate receive addresses for each invoice. The private key should remain on a separate system as leevancleef describes.


text:
What is the real size of the non-pruned Bitcoin blockchain?
My node (via Bitcoin Explorer) tells me as of now: 340.98 GB

Most website online: 280-300 GB
Why is there such a large delta?

In what way does your node tell you this?

@PieterWuille I use a RaspiBlitz and can get Blockchain stats with help of the web app "Bitcoin Explorer". See newly added sccreenshot. (Wow - what an honour to get reply from a Bitcoin VIP...)

It says data size. Your node stores a lot more data than just the blockchain (also undo data, utxo set database, indexes, and a few smaller things like mempool, wallet(s), ...).

Understood. Thanks so much!


text:
What is the "value" in a Segwit sig hash?
The BIP143 docs state that the value is: "value of the output spent by this input (8-byte little endian)"
If I have a single UTXO of value 10,000 sats and I'm using this as an input for a Segwit tx, then when I'm ready to sign the transaction / create the witness section, I use 10,000 as the value? Or is the value the sum of the outputs that I'm sending?
Another example would be this in the BIP example.
Where does the 0046c32300000000 amount (600,000,000 in Decimal) come from?
This would suggest the "value" is the full available amount of that particular input? Or is it the amount of all the inputs combined?

If I have a single UTXO of value 10,000 sats and I'm using this as an input for a Segwit tx, then when I'm ready to sign the transaction / create the witness section, I use 10,000 as the value? Or is the value the sum of the outputs that I'm sending?

You use 10000 as the amount and don't care about what other inputs are or how much their value is.

Where does the 0046c32300000000 amount (600,000,000 in Decimal) come from?

The "amount" that is being used during signing (and pretty much everywhere else) is always in satoshi as a 64-bit integer. Since the second input being signed had a value of 6 BTC that is equal to 600000000 satoshi. Which is the full value of the input (UTXO) that is being spent.


text:
What disadvantages do 2nd layer solution/side chain smart contracts on the bitcoin network have against those on the ethereum network?
I have seen that side chains/2nd layer solutions that utilize smart contracts on the bitcoin network are feasible and in use. If the 'programmability' feature of smart contracts is available on the bitcoin network, why is all of DeFi currently on the ethereum network instead? Does the former have inherently worse features for the usage of smart contracts? If so, what are they?

If you ignore scalability and privacy, it is easier for developers to write smart contracts onchain and within Ethereum's VM. Not only can you use a Javascript like language (Solidity) but your contract can update automatically based on changes in state. Bitcoin deliberately restricts state changes to unlocking UTXOs and immediately locking them again.
You can replicate many smart contracts on Bitcoin but because Bitcoin is focused on long term scalability and privacy as much as possible is pushed offchain (you have to deal with payment channel capacity and routing etc) and requires cryptographic tricks like adaptor signatures before a transaction is broadcast onchain. This makes life harder for a developer and creates more work but at least in my view there is no alternative. You could ignore privacy but long term scalability is critical. What's the point of making something easy to use if any wide scale usage pushes transaction fees up pricing out that and other use cases? There is very little progress and activity on 2nd layer solutions for Ethereum I think partly because of the complexity of new tokens introduced and partly because then you have to struggle with the same challenges of doing smart contracts offchain as Bitcoin.

Question is Bitcoin vs Ethereum. It doesn't ask for a comparison between Ethereum and Rootstock or Ethereum and Solana. I don't know anything about Solana, presumably it uses accounts rather than UTXOs and an EVM equivalent too? I'm not particularly interested in Ethereum let alone Ethereum clones ;)

There is a lot more tooling and ecosystem around Ethereum than Rootstock. If you don't care about scalability and privacy and you're doing an academic project I'd probably recommend Ethereum over Rootstock.

OK maybe I should add that sidechains have different trust models and less tooling, ecosystems built around them (other than perhaps Liquid). At least in theory access to the Ethereum chain is open in a way that multisig sidechain pegs aren't. The plan for DLCs is to use payment channels, Lightning rather than sidechains.

I don't know why the above is relevant. I thought we were talking about 2nd layer/sidechains not other chains.

@MichaelFolkson could you elaborate on how/why the bitcoin network/side chains/2nd layers are more scalable? Does this have to with size of the blockchain? Or something else?

@Runeaway3: It is just the concept of doing as much stuff offchain as possible. For example Lightning only touches the chain on channel opens and channel closes. In the meantime you could have hundreds, thousands of transactions that the chain never sees. Similarly with sidechains. If you assume the premise that blockchains are a limited resource and can't support the global economy using them for every transaction, every smart contract etc you want to use them as sparingly as possible.

@MichaelFolkson and the bitcoin network is better at this because all smart contracts on ethereum touch the blockchain each time?

Right. Not only the smart contracts but the state transitions of those smart contracts. You lose the benefits of the Ethereum VM (e.g. the rich statefulness) if you are operating outside of it most of the time.


text:
Which hardware wallets require importation of PSBT for knowledge of multisig set up?
My understanding of a multi-vendor multisig is that certain wallets require importation of the resultant multisig wallet's PSBT information in order to sign multisig transactions. Coldcard's documentation indicates that it requires this import of the info, but do other wallets? Specifically:

Trezor
BlockStream Jade
Seedsigner

Additionally, why do some require this and others not?
To be clear, I already understand that the output script descriptor of the x of n keys are needed to recover funds, but here I am asking about the specific need to import the PSBT into the x wallets so that they 'know' about the multisig.
Edit:
Jade's documentation suggest that it does require notification. Only seedsigner does not?
This documentation (walking through a Coldcard, CoboVault, and Seedsigner multisig set up) has steps for 'notifying coldcard' and 'notifying Cobo' but none for 'notifying seedsigner'. Does this mean seedsigner does not need to notified about the multisig?

One of the tasks of a signer is to determine whether it should sign something. There are a few different schools of thought on what should be done for this determination, however many hardware signers follow the pattern of parsing the transaction to be signed, showing it to the user, and asking the user for confirmation to sign it.
Even with many wallets doing this basic pattern, they still do some things differently, such as what information should be shown to the user, and what can be assumed about the user. Generally, the assumption is that the user is not technical and so as much technical information needs to be elided or otherwise separately verified by the signer to be safe.
For example, a technical detail that is often hidden is that transactions have change outputs. One of the most basic things for a hardware signer to do is to show the user all of the addresses that will receive Bitcoin in the transaction and the amounts that they will receive. But most users don't know about change outputs, or they don't know what change address is theirs. Showing the user the change output may confuse them, so the hardware signers will determine which outputs are change so that they do not need to show them.
But how can a hardware signer determine which outputs are change? For single sig scripts, this is easy as the hardware signer can generate the key for the script, and by assuming that anything that it can sign for is change, it can find the change outputs.
However for multisigs there will be keys that it does not know nor can generate. For multisig inputs, it needs to be told the script (and therefore the other keys). It needs the same for any outputs that are change. But even if it can produce the change output, how does it know that it actually is the change output? How can it be sure that there wasn't malware that swapped out some of the keys for an attackers?
Some hardware signers deal with these questions by requiring the user to have registered the multisig on the device before they sign any transactions involving it. The user provides the multisig threshold as well as xpubs of the involved keys, and the order they should appear. The wallet may store this or they may provide a signature of sorts that would later prove to the device that it had been pre-registered. Then during signing, it can look at that multisig information in order to determine which output is change.
Other wallets do not necessarily need this information and instead try to figure out the change from the transaction itself. A PSBT can contain enough information to figure it out. The signer can look at the inputs, determine the threshold and the xpubs of the multisig from the inputs, then check if any of the outputs match that. Thus they can determine the change output.
Change output detection is not the only problem. Some wallets want to do further verification to ensure that users are not accidentally losing funds. Suppose the user is participating in multiple multisigs. Some hardware signers want the user to make sure that the user knows which multisig they are spending from. This requires such devices to store the multisig or have be able to verify a commitment to it, and so require registering the multisig before signing.
There are also other wallets that simply don't care to verify and show this information to the user, and may just blindly sign anything that they can. It all depends on the security model that the hardware vendor is trying to go for.
Here are is a non-exhaustive list of hardware signers that require registering the multisig:

Ledger (Bitcoin App 2.0+)
Coldcard and clones
Jade
BitBox02

Some hardware signers that do not require registration:

Ledger (Bitcoin App 1.x)
Trezor and clones
BitBox01

I don't know about the seed signer, but from the documentation I can find, I think it does not require registration.
It's important to know that this is all just implemented in software on the devices that can be updated. As you can see in the list, Ledger has changed from previously signing anything, to requiring registration in order to sign. Other signers may choose to implement registration as well.

If you use a hardware wallet that does not require it, and then they change to requiring it, would you need to bring all x of n keys together to regenerate the registration info to import into that wallet?

Yes. If they introduce requiring registration, you would need to register any existing multisigs that you use.

But to do so would you need to bring the x of n wallets together? If they are geographically distributed this would be somewhat difficult.

No. Registering requires you to know the xpubs and the threshold, which you already have to know in order to receive any coins. So you should already have this information readily available in order to perform the registration. This does not require the co-signers to produce any signatures, or to even be aware that you are registering, so there is no need to bring all of the wallets together.

Ok great. Last additional question... to reconstitute the wallet you need to have x of n wallets and n OSDs. Do you need to somehow label which x wallet belongs to which n OSD? Like will reconstitution require lining those up? Or simply x wallets and n OSDs be sufficient, with no need to explicitly link between the [for lack of better term] data sets?

SeedSigner doesn't require that the multisig wallet descriptor be pre-loaded into the device. In fact, because there's no onboard persistent storage, anything loaded would be forgotten once it was powered down anyway.
But it is strongly recommended that you scan in a "known-good" copy of your descriptor when reviewing a psbt.

If the descriptor can't generate the same change address, you get a show-stopping warning that prevents you from proceeding. This would only happen if your software coordinator had crafted an "evil" psbt that was attempting to steal your change.

Note: this also applies for any receive addresses for your wallet if you're doing an internal cycle/consolidation back to yourself.
What is a "known-good" descriptor?
This whole optional step of scanning in your descriptor is a safety measure to help protect you from a compromised, "evil" software coordinator constructing a malicious psbt for you to sign.
The basic scenario you have to have in mind is:

I created as secure an environment as possible when installing my software coordinator (e.g. Sparrow, Specter Desktop, Nunchuk, etc) and then used it to create my multisig.
At some point later, my software coordinator was compromised and is now controlled by an attacker.
I use the compromised software to construct a transaction that will steal some of my funds.

In this scenario, when SeedSigner offers to verify the change (or self-spend receive) address, if you scan the wallet descriptor straight from this theoretically now-compromised coordinator (e.g. in Sparrow, going to the wallet Settings and clicking the QR icon next to your Descriptor), it's just going to lie to you some more and provide a matching "evil" descriptor that will verify just fine in SeedSigner.
You're essentially being duped into confirming: Yes, the "evil" change address really does belong to this "evil" wallet that I don't actually control.
Instead, when creating the multisig in your initially secure environment, you need to backup the resulting wallet descriptor right then and there. If your initial environment really was sound, then you can be assured that this backup really describes the wallet you just created. Sparrow and Specter Desktop even provide printable pdfs of the backup/descriptor that include the descriptor as a QR code that SeedSigner knows how to read.
This backup saved at this stage is your "known-good" copy of the descriptor (again, all hinges on your initial environment being clean).
I print this pdf backup and keep a paper copy with each geographically distributed key. I also keep digital copies of it in various local and cloud vaults (note: the descriptor is a potential privacy leak--anyone who has it can see all your past and future transactions--but it doesn't contain any private key info and so it isn't a security risk; the descriptor alone can't be used to steal any funds).
No matter how compromised my system becomes after this, it doesn't matter since the attackers cannot alter what's on my "known-good" descriptor print out (ignoring real-world ninja/spycraft infiltration!).
If they try to get me to sign an "evil" psbt, my "known-good" descriptor will raise the alarm that the proposed change/receive address is not actually owned by my wallet.


text:
Blockchain.info unconfirmed transaction
I'm a newbie and was wondering what to do when there is an unconfirmed transaction on Blockchain.info. Can I reverse the transaction? Will my BTC reach the other side? Or are they lost?

Do you mean that you made the transaction using blockchain.info's wallet, or that you look at the transaction using blockchain.info?

If your transaction doesn't confirm, and the sender (blockchain.info/wallet, in this instance) doesn't re-broadcast the transaction then the transaction should disappear from your wallet, as if it had never been made.
This may take a day or so.
If the transaction is being re-broadcast by the sender then it can stay there as long as the re-broadcasts are occurring.

If you click on unconfirmed it will show the progress of the transaction. I notice I am a little late replying (you posted 3 hours ago) it should have completed by now if you check again.


text:
Hash of backed up wallet file not the same as hash of wallet currently in use
A couple of months ago I had backed up the wallet.dat (I use bitcoin-qt) file and saved it some place else.
Lately I've opened the data folder for the current running node (also bitcoin-qt) and I compared the md5 hashes of both files and they are different.
What caused this? Surely my private keys have not changed so why is the wallet.dat file not exactly the same as the backed up version?
Thank you

The wallet file contains the hash (and more) information about the tip of the chain it has been synchronized to. This means that generally when loading a wallet into a running node, it will be modified every time a new block comes in.
Furthermore the wallet file also contains all transactions affecting the wallet balance. If you sent or received any transactions, that too will inevitably modify the wallet file.

So whenever my wallet.dat file gets "updated", I can archive the previous files and replace with the new one without incurring any loss of information?


text:
Do I really have to place my wallet file in the data directory?
I run bitcoin-core QT and I downloaded the full ledger data to an external HD so I can move between machines. My wallet.dat file is secured someplace else.
I start-up the QT client giving the external hard disk as the data root.
So after I put my real wallet.dat file in the data directory (and restart the client with -rescan):
Do I really have to keep it in the directory where the ledger data is saved? Is that safe?

You can use the -wallet=<path> startup option to specify a custom path to your wallet.

@darosior Is this the recommended approach when one wants to have the ledger data in a separate place? please add an answer so I can mark it as the correct answer.

It seems to me to be the most straightforward one. Added an answer.

If you want your wallet database (file) to be in a different directory than your data directory, you can use the -wallet=<path> startup option to specify a custom path to your wallet.
Quoting the manpage:

-wallet=< path >
Specify wallet database path. Can be specified multiple times to
load multiple wallets. Path is interpreted relative to  <wallet‐
dir>  if  it is not absolute, and will be created if it does not
exist (as a directory  containing  a  wallet.dat  file  and  log
files).  For backwards compatibility this will also accept names
of existing data files in .)


text:
How to add a fixed transaction fee to each transaction?
Each time I send some bitcoins from Blockchain.info, it allows me to set a specific fee. I've installed bitcoind and I can't figure out how to add a 0.00013674 fee for each fee.
I have read a few articles and I see the set fees is always relative to transaction size. So, I'm using paytxfee=0.00027348 in my config file.
Issue is this setting is producing:
sent amount=0.00106326 fes=0.0000618
sent amount=0.00086326 fes=0.00006153
sent amount=0.00106326 fes=0.00014166
I'm willing to have my transactions included in the blockchain faster. Any idea to tweak my settings to have this improved ?

If you want total control over the fee then you will need to build the transaction yourself using createrawtransaction - more info here: https://en.bitcoin.it/wiki/Raw_Transactions
However, it's important to note there was a relatively unnoticed change in the way paytxfee handles the fee calculation earlier in 2016 - see here: https://github.com/bitcoin/bitcoin/issues/7633


text:
Unlock a Bitcoin-qt wallet
How do I unlock a bitcoin-qt wallet? I know my passphrase and all.
It says that my wallet is encrypted and locked for now so how do i unlock it?

To unlock your wallet:
Option 1: Introduce password in prompt that opens when you send coins
Option 2: Console (Help > Debug window > Console)
Type the following:
walletpassphrase "passphrase" timeout

Where passphrase is your password and timeout is the number of seconds you want the wallet unlocked (i.e. 120 = 2 min). This is option is the only one when you want to do something that requires unlocking but you don't want to send coins (like dumping a private key) or when you plan to leave the wallet open and fear forgetting to lock it again.

It unlocks when you need to spend.  If you try to send money to an address, it'll ask you for a password.  You don't need a password to receive bitcoins.


text:
Is there a light (SPV) version of bitcoin core (bitcoind)?
I'm trying to develop an SPV Bitcoin client which makes use of a library requiring bitcoin core (a running bitcoind service).
However, from what I understand, Bitcoin Core is full node, meaning that it stores the whole blockchain.
My question is: there exists a service which is similar to bitcoind (that is it provides a JSON-RPC server), without needing the whole blockchain?

"full node" doesn't mean it stores the full blockchain. It means it's a fully validating and has downloaded the while thing, but it not necessarily keeps everything. You may want to look into pruning for more info on that.

@Jannes: Thanks for the clarification.
However, as you say, it still needs to download the whole chain (thus requiring a certain amount of disk space).
So my question still applies: I need something lighter than a full node, that is an SPV working with headers only, which provides an RPC service, similar to that offered by bitcoind.

It needs to download the whole blockchain, but it doesn't need to store it. You don't need more than a few GB of disk space. An SPV client does not provide you with the same security guarantees and trustlessness as a full node.

Yes, bitcoind with pruning is similar to bitcoind, though some RPCs are disabled (naturally, because of pruning).
bitcoind in pruning mode does not store the whole blockchain, and can reduce your space usage to 2GB instead of 85GB.
See the release notes here and here.
Update: There is also a Full Block SPV wallet PR by Jonas Schnelli. Which is even lighter than pruning mode, since it only downloads blocks from the creation of the wallet.

Thanks. I didn't know that bitcoind had a pruned version.
This could actually be very useful.
In the meanwhile I found a good compromise by adopting the bitcored wallet service, which provides with a full node server that can serve a number of light wallet clients.

What is the good compromise that you found? Can you share it? @FedFranz

It is already in my previous comment. I used Bitcore (which is a different client)

As Alin explained today the lightest version is pruned mode. However there are pull requests for an even lighter version, called full block downloading SPV mode, or full-SPV mode.
Keep an eye on these two pull requests. You are also free to contribute:
Complete hybrid full block SPV mode
Add simple light-client mode (RPC only)


text:
Why does the Bitcoin pool reject my Antminer D3 shares?
I hope somebody can help, since I have received my antminer D3 and connected it to the antpool, all my shares are getting rejected.
I am mining bitcoins but all of them are getting rejected.
I have uploaded a screenshot below.
Somebody knows what is the solution to fix this problem.

You cannot mine Bitcoin with D3.
You can only mine Dash with a D3.

The Antminer D3 spec states that it is a miner for the X11 hashing algorithm.
Bitcoin uses SHA-256d as its hashing algorithm. The Antminer D3 cannot mine Bitcoin, but only X11 based currencies such as Dash.


text:
Why does Ripple use Blockchain technology in the first place?
This is what I understand Ripple's use-case with banks.
You and I announce to a trusted third party that $10 million of my money should now be considered yours. This third party isn't a middleman who holds debt,  - it simply keeps track of IOUs and regularly announces to all parties who owes who how much. The ACH system in the US (a.k.a. "Direct Deposit") works this way.
So, for the most part, bank's don't actually send money to each other at all - they just keep track of who owes who how much. Actually settling those debts, if it happens at all, has to happen outside of the systems above.
Ripple, as I understand it, basically a distributed public ledger of IOUs. (And those IOU's can themselves be traded as currency, when they're written by a trusted party.)
But why ripple uses Blockchain technology. Here doesn't Ripple acts as a middle-man? Why not to use central DB's? What is the difference of Ripple from a company that creates network of banks but rely it's technology on Oracle DB and related API's for example? Also who are the miners and nodes of the Ripple's use case with banks?
Thanks.
Firat

This is a very good question. The simple answer is marketing. Technically, a standard database would have been much more efficient in achieving the same. However, there would have been even less reason to invent a token (XRP), you couldn't have found them on coinmarketcap, and they couldn't call it blockchain. So no billions for the founders.

Ripple did not set out to revolutionize the banking sector and replace existing banks. Ripple is just a protocol which enables real time payment transfer between individuals without any third party as a middleman.
As you said, Ripple keeps track of the state of IOUs on a distributed public ledger. And to get to consensus about the current state of ledger, it uses permissioned miners. People like you and me can not set out and start mining Ripple, but major banks can come together and contribute as miners. Ripple enables banks to work with each other in trustless and transparent environment. And that's how it uses blockchain.

Ok I got the point somehow but now another question pops up. I'd like to send you 10 USD and it makes 5 Ripples at the time I try to make transaction. (1XRP=2USD) But then something happened and XRP currency lost value as %50 and you got 5 XRP and its value is 5USD right now. What is going to happen?

You can think this way with any two currencies. Suppose I want to exchange INR to USD and the momemnt I exchange my 60 INR  for 1 USD, exchange rate changes to 30 INR=1 USD.  Cryptocurrencies are also currencies and their prices are derived from the supply and demand, same as of other currencies.

Yes but we have to admit that no fiat currency on the world is as volatile as any of the cryptocurrencies.

Why do you not consider the permissioned miners a third party? Are they not responsible for completing the payment?

Permissioned miners are not third party because once a node gets permission to join network, all nodes are equal. Task of permission can also be done in distributed way by taking vote from all the nodes.

from https://www.whydoesthisneedblockchain.com/discuss/banking-finance/why-does-ripple-need-blockchain:
"to be clear there is ripplenet the protocol, ripple (xrp) the cryptocurrency, and ripplelabs the company. ripplelabs uses ripple as the base currency in its protocol. it's a way for banks to easily exchange these IOUs in a currency that isn't tied to any one bank. so any bank could theoretically come up with their own currency and say that's what they would send other banks, but there kind of needs to be a 3rd party in order for every bank to hop on board because of privacy. also it's much, much faster than any other current solution for banks to transact with each other. the ripplelabs use case for xrp is really more as a digital currency and less so for the decentralization piece."

It is true that due to the central banking system, transferring between banks within the same country is easy. However, when you look at international transactions, the process becomes more complex and involves the payer’s bank, that bank’s correspondent, the recipient bank’s correspondent, and finally the recipient's bank.
Ripple is really aimed toward international currency exchange, although may be used in countries that do not have an effective central banking system.
But if nothing else... at least you can imagine the ripples on a serene mountain lake as you skip rocks by the water's edge.


text:
Where did Bitmain get the "Antminer" name from for all their ASIC miners?
Does anyone by chance know? Can't seem to find this anywhere and this question popped into my head.

Antminers were released before Antshares existed.

Presumably (I'm not sure, this is an educated guess) they called it an antminer because they have very many of them, all set to do a single thing and doing it well. One could compare their mining pool to an ant hive, where each mining ASIC is an individual ant, foraging for food.
This is a very common metaphor, because ants are fascinating creatures, whose actions are completely governed by very simple rules, which cause truly incredible emergent behavior. See: Ant Colony Optimization for a good example of this.


text:
How private shilded transactions to payee address works in ZeroCash from the information point of view?
In ZeroCash they perform transactions like this. I want to unravel and understand how z-addresses work in ZCash. It shall be described simply in here and in-depth, revised here and here (older, a bit simpler). Simply put it shall be described here:

or even simpler here:

Blue is what gets into the ledger including stuff like cm, a_{pk}, hash(sn).
In simple terms here is how I understand the algorithm and please correct me if I am wrong: A payer (slide #5) passes a value onto the chain as if it is passed by the payee. And this where I stop getting it:

How payer proves that he indeed can spend that value if he makes it look like operation is done from payee's perspective?
If value, rho, r' and r'' are passed in the form of payee's public key how does it not make such transaction capable to happen only once\or how is it checked and proved?
If a transaction can happen only one and payer needs to prove that he has funds for it how he can not be linked to that transaction?

Dear moderators, please do care to explains why the hall on bloody earth question on the fundamentals of one of the top five blockchain systems (zcash) is offtopic on a website about blockchain?!?

See: https://bitcoin.stackexchange.com/help/on-topic


text:
Bitcoind Node crashes after using -dbcache option
I've been trying to speed up my node sync by increasing the dbcache. However my node tends to crash overnight. My system is running ubuntu 18.04, 4GM of ram bitcoin core v0.18.
I've tried bitcoind -dbcache=4000, also tried setting it to 3000 and 2500. All have crashed overnight.
Any thoughts on improving sync time using this or other methods?

You are allocating far too much dbcache. If you allocate 4000 MB to the dbcache, you will use up all of your RAM and it will crash. Your operating system needs RAM, Bitcoin Core itself needs RAM outside of the dbcache. I would highly recommend that you do not set a dbcache at all as 4 GB is really not enough RAM to handle a larger dbcache, Bitcoin Core's other RAM usage, operating system RAM usage, and whatever else may be running on your machine.
I suggest that you start Bitcoin Core without dbcache and check what your RAM usage is (using top or Ubuntu's system monitor). See how much RAM is being used and how much is free. Then you can set a higher dbcache if you have enough free.
Bitcoin Core has a few other suggestions for reducing memory usage. You can set maxmempool=<n> to a number less than the default 300. You can reduce the maximum number of connections by setting maxconnections=<n> to a number smaller than 125. Note that that only is helpful if you happen to have a lot of incoming connections. Lastly you can reduce the number of threads being used for signature validiation by using par=<n> and setting it to a number smaller than the number of cores your CPU has.

Thanks for the advice, I have been watching my ram usage using top and started bitcoind without any additional options bitcoind.

However, as I watch my top and log file, my load average increases steadily going to 4.17, 2.97, 1.36 and my cache goes well above 300mb, it seems to hit about 380mb at which point it uses up all my system ram and my server crashes.
I'm now starting with bitcoind dbcache=100 to see if this prevents the cache from growing out of control.
Do you know if there is a config option to set the cache size in a file?

The command line function is not limiting the cache size. There must be a database configuration file that has been set to too high a cache limit. Any ideas how I could find that file?

I've tried specifying a cache size by creating a DB_CONFIG file in the .bitcoin directory.

My cache continues to increase in size regardless of what I set it to, this time I tried 25 megabites, here is my log file from after the crash, it just shows a cache update: 2019-07-16T22:39:10Z UpdateTip: new best=0000000000000000000ef9baad2eda04785ee40c55788def6de7e76bc90ad5b0 height=548707 version=0x20000000 log2_work=89.96435 tx=353876079 date='2018-11-04T07:37:51Z' progress=0.870169 cache=110.8MiB(850392txo)

I'm reindexing my local blockchain copy as a debug to see if that solves the issue. It would be great if there was a node debug thread.

Create a bitcoin.conf file in ~/.bitcoin and add the line dbcache=<n> where <n> is the size of the dbcache that you want to set. A DB_CONFIG file won't do anything because Bitcoin Core is not expecting a file of that name so it won't read it. Bitcoin Core's configuration file is bitcoin.conf. If you set it as a command line option (i.e. -dbcache=<n>), it should work. Don't forget the dash (-). Note the conf file needs the option without the dash.

I added the dbcache=50 argument, but my cache usage still increased out of control when my reindex reached around 82% completion. See the last log entry before my node crashed again:
2019-07-19T13:57:25Z Pre-allocating up to position 0x400000 in rev01329.dat 2019-07-19T13:57:25Z UpdateTip: new best=0000000000000000002e63058c023a9a1de233554f28c7b21380b6c9003f36a8 height=534292 version=0x20000000 log2_work=89.340154 tx=331282217 date='2018-07-29T17:14:04Z' progress=0.818250 cache=280.3MiB(2059661txo)

So I checked my bitcoin.conf file and found that txindex=1, this should be set to zero by default, right? I have set it to 0 and will see what happens.

Near the beginning of each run in the debug.log file you should see a few lines that say something about how much cache is being allocated to each of the various things that need caching in Bitcoin Core. Also, don't forget to restart Core every time you modify the conf file.

It just crashed again and I noticed that my top function showed that bitcoind was using 532% of CPU resources.

Here is the beginning of my last session in the log file: 2019-07-19T14:27:24Z Using wallet wallet.dat 2019-07-19T14:27:24Z BerkeleyEnvironment::Open: LogDir=/home/satoshi/.bitcoin/database ErrorFile=/home/satoshi/.bitcoin/db.log 2019-07-19T14:27:24Z Cache configuration: 2019-07-19T14:27:24Z * Using 2.0MiB for block index database 2019-07-19T14:27:24Z * Using 8.0MiB for chain state database 2019-07-19T14:27:24Z * Using 110.0MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space)

Is something like this the solution? https://stackoverflow.com/questions/20259235/bitcoind-0-8-4-is-having-huge-memory-leak-causing-daemon-to-crash#22738428

That is certainly an option, however it should be possible to reduce memory and cpu usage enough to avoid crashes. I updated my answer with some additional information that you might want to check out. If CPU usage is really high, then the part about threads (and reducing the number of threads) should be useful.