text:
Question on getaccountaddress, getnewaddress, getAddressesByAccount
I would like to get some feedback. I am new to the bitcoin development and I don't want to misunderstand something important before I start designing the application. I am working on bitcoin online-store integration. We are planning to show btc payment instructions to customers after order acknowledgment page so that they can send the payment from their private wallets.
We want to create one address per transaction. (take Transaction No = "abc"). My plan:

First call getaddressesbyaccount("abc"). If it returns blank address
list, then call getnewaddress("abc") to create new address for this
order. (Then create QR code and show to customer with expected
amount).
Otherwise, if the getaddressesbyaccount("abc") returns an address,
use that returning address.

This page says "getaccountaddress will return the same address until coins are received on that address; once coins have been received, it will generate and return a new address.".
I am planning not to use this function because if we expect 1 btc from the customer and he sends 0.5 btc, I don't want to create a new address. This is just to keep things simplified (1 address per 1 account). getaddressesbyaccount function returns a list of addressess associated with the account "abc".
I find getaccountaddress redundant for my needs. Is there any benefit to "getaccountaddress" creating new address if the current address has balance on it? Do you see any pitfall with my logic. Your feedback is appreciated.
Thank you,

I recommend that you do not use Bitcoin Core's internal accounting system because it is deprecated and will be removed in the future. Once it is removed, whatever code you have written that depends on it will be broken. Furthermore, the accounts system is not all that good.
I suggest that you instead maintain a separate database where you keep your own accounting system. That database would record each user's address and how much has been paid to that address. To figure out how much has been paid to each address, you would have a script that is called by -walletnotify which then looks up what address is being paid and how much for each transaction that you receive.

There are software that handle this sort of payment processing for you already that can be used with Bitcoin Core. One such software is BTCPay.

For some business reasons, we need to develop this internally. So BTCPay isn't an option.
Our plan is to use an external database and a controller to send commands to Bitcoin Core service for address creation and querying.
A service similar to -walletnotify is also within the scope.

@SerdarUlutas one additional comment i have for -walletnotify is that it sends out two notifications on incoming tx. one when it's added to mempool (confirmation=0) and one when it's first added to a block (confirmation=1). you'd probably need additional steps to make sure it reach certain number of confirmations before calling it final

My suggestion is to fire it up on -testnet and see what it does. You can get some testnet BTC from a faucet for testing.
Also, you probably realise you can get information on the various commands from help:
>bitcoin-cli help getaccountaddress
getaccountaddress "account"

DEPRECATED. Returns the current Bitcoin address for receiving payments to this account.

Arguments:
1. "account"       (string, required) The account name for the address. It can also be set to the empty string "" to represent the default account. The account does not need to exist, it will be created and a new address created  if there is no account by the given name.

Result:
"address"          (string) The account bitcoin address

Examples:
> bitcoin-cli getaccountaddress
> bitcoin-cli getaccountaddress ""
> bitcoin-cli getaccountaddress "myaccount"
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getaccountaddress", "params": ["myaccount"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

There is no mention of a new address being created once BTC is received on a particular address.
Also, many of the commands that you are discussing are depreciated - there are probably new methods available. >bitcoin-cli help will list all available commands.


text:
Understanding the iquidus API settings
I am trying to understand what values I am being asked for in the settings.json to install the block explorer for Iquidus. I know how to get the genesis block as I have hard coded it when I did a fork to create a new altcoin, however, I am unsure how to get the genesis_tx. I know you can convert it from the genesis block but I am unsure how?
"genesis": {
"genesis_tx": " ",
"genesis_block": " "}
In terms of the API settings, they are asking for an address, blockindex, blockhash, and txhash. The blockindex can be any value within your block height... so do I pick just any one value for the index with the corresponding address in the transaction list? Also, how do I get the txhash and the blockhash? These values to my understanding are subject to change and I know they are stored in the blockchain... does anyone know how I can retrieve this information?
"api": {
"blockindex": " ",
"blockhash": " ",
"txhash": " ",
"address": " "
},
I appreciate your time and consideration.

Figure out your blockhash with index=0
(normally in your coind debug window,s you can: do a
getblockhash 0
(0 = genesis block number)
With the return value from that, you do a
getblock xxxx
eg:
￼
getblockhash 0
 ￼
5597f25c062a3038c7fd815fe46c67dedfcb3c839fbc8e01ed4044540d08fe48

￼
getblock 5597f25c062a3038c7fd815fe46c67dedfcb3c839fbc8e01ed4044540d08fe48

{
"hash" : "5597f25c062a3038c7fd815fe46c67dedfcb3c839fbc8e01ed4044540d08fe48",
"confirmations" : 4142183,
"size" : 240,
"height" : 0,
"version" : 1,
"merkleroot" : "2bad42ac6e0ccc4808d8df0fd50ac8634eea335b1412b1ef52864b430a87b262",
"tx" : [
"2bad42ac6e0ccc4808d8df0fd50ac8634eea335b1412b1ef52864b430a87b262"
],
"time" : 1394102925,
"nonce" : 2482334,
"bits" : "1e0ffff0",
"difficulty" : 0.00024414,
"nextblockhash" : "df34593a55b7ed0ff076766805023c8262fe26c84ba8624b77abae446c402dea"
}

source: Stack Exchange

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

sort: votes


text:
How to create a simple lightweight wallet (without mining) for an Altcoin
I am trying to create a wallet using electrum for an altcoin that uses the Scrypt algorithm. I am looking around for tutorials that can show a step by step process on how to create a simple wallet for this altcoin that simply sends, receives and stores your coin for windows, linux and android. Does anyone have any recommendations on how to do this or where I can look to build this myself?
I prefer using electrum because there are multiple clone repos for electrum and its pretty simple to use but I am open to other easier options.
Thank you again!

If your altcoin is based on Scrypt then you can go for Qt wallet.
There are tutorial in bitcointalk on how to create QT wallet for X-platform. Its simple and easy process and does must of what is needed
Check this link . Might be useful for you

you can probably modify https://github.com/OutCast3k/coinbin/ to your needs

Thank you for the response, but I am looking for something that is more app based... something that can be installed on linux, windows, android and mac. Do you know any tutorials that shows you how to make modifications to a wallet like electrum for a scrypt based altcoin?

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

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


text:
Iquidus JSON settings for Blockchain Explorer
I did a fork from litecoin into my own altcoin and I am trying to get it on a blockchain explorer to run realtime on a website. I chose an open source blockchain explorer called Iquidus which was recommended by one of the members in this community:
https://github.com/iquidus/explorer
I have followed the guide up to the point where I must adjust the settings.json file to customize it to by particular altcoin.
https://gist.github.com/zeronug/5c66207c426a1d4d5c73cc872255c572
The problem is that I am not too sure which information that needs to be adjusted in the file as it is not explicit in the instructions on what needs to be adjusted; for example, how do you know the blockhash, txhash, address, supply, which passwords and users that must be used, the instance, etc. Some values are subject to change so I am unsure where to set these values.
I am new to cryptocurrencies and I am trying to learn. My question is if there is a guide to help with modifying the settings.json file for my altcoin? Is there any recommended literature that can help me with this endeavor? If any, is there an easier option for a blockexplorer that you'd recommend?
Thank you for your time.

Mandatory settings.json changes
if not set correctly explorer will not work
have to dig in the code of your forked litecoind (daemon) to get them
genesis_tx
genesis_block

same settings as your litecoind daemon taken from litecoin.conf file
wallet
  host
  port
  user
  pass

mongo database, change if different than your settings
dbsettings
  user
  password
  database
  address
  port

make sure you set difficulty which for litecoin is POW
index
  difficulty

Secondary changes
meaning that the explorer can start working without them but should be changed to reflect your coin
title
address
coin
symbol
port

for the api page look here for details https://github.com/iquidus/explorer/issues/130
api
  blockindex
  address
  txhash
  blockhash

if you want to get coin value from markets set correct values for
markets

For reference settings.json.template


text:
Determining total blocks solved
How do you determine the total blocks solved among all clients in the source code of an Altcoin? Is there a file in the code that can be viewed to see how many blocks have been solved in the meta data? How can this be determined or where can one look in the source code?

To determine the current blockheight of any coin, you will need to pull data from the network itself. The source code that runs a node for any coin will not include this information.
A full node will download the blockchain history, so your node could then report the current blockheight back to you. The source code basically contains instructions telling your computer how to do this, but the explicit block height is not contained within the source code.

Thank you so much for the response... I forked a coin and have the main server node a VPS where other nodes connect. Is this information on the .mycoin directory on the VPS? Thank you so much again.

You'll want to query your node for the current blockheight. You'll need to check the docs for the software you forked to find exactly how this is done.


text:
Is Hashgraph a serious competitor for the blockchain?
What is going to be the effect of the recently publicized Hashgraph technology developed by Leemon Baird going to be on the Bitcoin and other blockchains? It is obviously not open source since a company called Swirld Inc holds a patent on it, but it does look like it could make the blockchain obsolete. Is this a serious worry for those invested in the latter?

This is a good question that is also on my investigation radar. Naively speaking, it probably boils down to is the hashgraph consensus mechanism better than a blockchain consensus mechanism, and how easy can such a consensus mechanism can be swapped with legacy cryptocurrencies.

The Hashgraph consensus mechanism achieves Byzantine Fault Tolerance (BFT) using voting on a braided tree of hashed events (the "hashgraph") that is faster and more lightweight than Nakamoto consensus on blockchain using Proof of Work (PoW). However, it is being positioned for different use cases than cryptocurrency.  Whether its consensus mechanism is better PoW really depends on the use case. Hashgraph actually layers nicely on top of blockchain, e.g., by using Bitcoin for Proof of Stake or Proof of Burn. That said, it will certainly be more suitable than blockchain for many commercial applications that need distributed shared memory and high transactions per second on consumer grade nodes.
In addition to the consensus algorithm, when comparing the two it also makes sense to consider the full range of features that would be supported by a bonafide cryptocurrency platform, which for Bitcoin would mean duplicating the features in its proposed payment platform, Lightning. Is it Hashgraph's express goal to replace Bitcoin+Lightning?  Clearly not at this time. Can it? That is not yet clear, and whether it can will be determined as much by additional factors including licensing and developer community support as by the consensus algorithm. Lightning will support blockchain contracts, bidirectional payment transactions and payment routing. Hashgraph could conceivably be used to implement the off-chain transaction ledgers, though that could require dozens and possibly up to thousands of such Hashgraph ledgers to satisfy the millions to billions of transactions per second that Lightning is targeting.
I hope that helps, best of luck to you.


text:
No sign of my private keys in Electrum wallet ... where do I find them?
I recently downloaded an Electrum wallet (version 1.7.3) and made two Bitcoin purchases. The wallet shows the public receiving addresses (including those receiving addresses which I used to receive the coins) and the amount of coins received in these transactions. My problem is that I can't see the private addresses anywhere and don't feel confident that the coins are still in my possession (of if they ever were).
I am guessing that when (in the Classic Gui) I click on the 'Send' tab, enter the address for the intended recipient in the 'Pay to' slot, the 'Amount', 'Description' of the transaction for my own benefit, the 'Fee', and subsequently click on 'Send', the client might then perhaps disclose a private address along with an address for any change to go to. Is this correct? If not, can someone be good enough tell me how it does work?
I feel uneasy that I cannot see the private addresses anywhere. And, of course, I can't spend the coins until I have the private addresses. (I would like to commit my private keys to paper.)
In the 'Settings', there is a tab labeled 'Import/Export' and one of the options there is to 'Export' / 'Import' Private Keys. Does this mean to 'Export' the private addresses from the wallet to somewhere else (another file which one might create, perhaps), or to 'Export' them from somewhere else into the wallet? Does 'Import' the Private Keys mean to bring them into display somewhere in the wallet? I just don't understand and am afraid to try out either of these commands just in case I somehow lose my Bitcoins.
As you can see, I'm not exactly tech savvy and would really be grateful for help here from any Electrum wallet users on this forum.
Terrylei

You ask a lot of things, so I'll explain how Electrum works for you and hope it is what you need.
Electrum uses a seed (twelve words length password). Your private keys are derived from this seed every time you make a transaction.
The only thing you need to spend the coins received in your Electrum addresses is that seed. You can export the private key for one of the addresses in your wallet, but you should not do it. Keep your Electrum private keys PRIVATE.
You can also import a private key from another wallet, e.g Blockchain.info to be able to spend the coins in that address. It will be added to your wallet as a imported address, imported addresses behave kinda different to Electrum seed addresses. So keep a copy of the imported private key, just in case.
You will always be able to restore all your Electrum addresses using your seed, but not the imported keys, as they are not on your seed.

I understood that I could use the seed to restore my wallet, but I had not grasped the connection between the seed and the derivation of the private keys. I see now that, in having exported my private keys, I have, in fact, weakened my security. It seems it would have been better to leave their exportation until I actually wanted to spend them.
Nor had I realised that I could import a private key from another wallet, or that, in that case, that private key could not be restored via my seed.  Thanks rdymac very much for this important explanation. - terrylei

An alarming thought: in exporting my private keys to a CSV file, have I, in effect, 'spent' the bitcoins? Or are they recoverable still from the seed to sign a real transaction? - terrylei

I recommend you to create a new Electrum seed and spend all your previous coins to one of your newly created Electrum addresses. After that, you should never export a privkey of your seed. If you want to learn a bit more, look for deterministic wallets and how your addresses are created deterministically derived from your seed.

I haven't used this wallet but from what you're saying, it seems there is no problem. Here is how it works:

Wallets will not display your private keys for your addresses on the the display. That's normal. Private keys are important so they should not be left dangling around.(What if someone is looking at your screen?) That's why the program does not show it to you. But private keys are there. The private key for each address is saved on your computer by the wallet program.
Import does not mean taking these saved private keys and showing them on the display. If you created a bitcoin address somewhere and if you know the private key, then you can make the program send the bitcoins on that address. to do this, you need to tell the program, this is my address and this is my private key. Then it will automatically start holding/owning that address.
How do you get the private keys? That's the export function. It will create a file for you that contains your addresses and your private keys. You can take this file, load it to another wallet program on another computer or the web and that new wallet will own/hold and be able to send the bitcoins on your addresses.

I hope it helps.
I suggest you get an online wallet. You can create a paper wallet from those as well. Google how to...

Thanks very much for your clear explanations for my questions, Anton. Guided by what you said, I have found my private keys and exported them to a couple of destinations where I believe they'll be pretty secure. I ‘m relieved to have found those private addresses.
You suggested that I "get an online wallet", did you mean something other than (or additional to) the Electrum wallet that I already have?
I will do as you suggested and go to Google to see if and how I can create a paper wallet from my Electrum wallet.  Once again, thank you. You have helped me a lot.

No problem :) I meant getting an account on a site like blockchain.info you can create a paper wallet from an online wallet service too.

I'll check out blockchain.info. Thanks again, Anton - terrylei

@terrylei How did you find those private addresses?


text:
Can private keys be exported more than once in Electrum client so long as the've not been spent?
Assuming one exported the private keys from one's offline Electrum wallet to a CSV file (also offline), they obviously have not been 'spent'. The whole thing was done offline. My question is this: if I were now to go online and try to spend the bitcoins covered by those private keys, are the bitcoins still there? Or does the exportation of the private keys to the CSV file equal the spending of those coins so far as the Electrum client is concerned? To put it another way, can the private keys be exported more than once so long as they have not been spent? I'm hope I'm explaining myself clearly.
[I recently made my first Bitcoin purchase and I did so into an Electrum wallet, which I am currently keeping on an offline computer. I could not see my private keys anywhere and was unsure that I'd received them and so I exported them to the CSV file purely to ascertain that I had, in fact, received them. (I would not do so on any future purchases, now that I'm confident that the private keys would be there to be generated from the seed since they are plainly more secure unexported from an encrypted wallet than on a CSV file, but, hey, my first time and no evidence or explanation that I indeed had received them ...] - Terrylei

It seems like you don't understand how Bitcoins, private keys and bitcoin addresses work, so I'll make it simple:
As I explained to you here https://bitcoin.stackexchange.com/a/11479/2467 , you should not (more like MUST NOT) export your private keys from an Electrum seed. This can compromise all your private keys.
Your private keys are derived from your seed every time you make a payment to sign the transaction. So there's no need to see them, the client calculate them for you, use them, and hide them again. all you need is to keep your seed safe.
If you want to know the balance in your offline Electrum wallet's addresses you can use a seedless wallet on an online computer. To do that look for your Master Public Key in the offline Electrum, and restore from your MPK on an online computer.
You don't need your private keys to know the balance on their public addresses anyway. Public addresses are public and if you have already received on them, you can check their balance on Blockchain.info

Thanks for your patience, Rdymac. I heard your message that I should NOT have exported the pr. Keys, but had already done so at that point. Now that I HAVE exported (but not spent) them, can I still spend them from the same wallet? Sorry if I seem obtuse. My guess is that I can still spend them from the wallet and no harm done, except that I’ve unnecessarily compromised their security. Is this correct? Or does the wallet spit them out once only? If so, how can I use them in their current form (CSV file)? Yes, blockchain.info confirms the balance of my coins.

@terrylei when you export you privkeys from Electrum (and almost any other client) it is just a copy. That means that two copies of you privkeys exist, so it is easier to find them.
On Electrum it is particularly dangerous because your privkeys are generated deterministically, so if someone have a few of your privkeys, he can presumably calculate all your subsequent privkeys you'll ever use.
Spend the coins you have to a new Electrum seed and use that one.

This eplanation addresses what was really concerning me ... that what was exported was only copies. However, I really appreciate your advice about the need to spend the coins to  a new Electrum seed and why this is necessary. I will do as you suggest. Thanks again. I need to check out and understand what a deterministic wallet is and how it works. I'm not at all tech savvy, so it's quite a learning curve. Many thanks for your attention to my problem. -Terrylei

I'm not sure this was made clear but also you do not "Receive" public keys. when you generate a new wallet your client generates public and private keys. Using math you can get your public keys from your private keys but not the other way around (eg. you can not determin your private key from your public keys). With your private key you can now sign transactions to be broadcast the Bitcoin network and anyone can use your public keys to verify that YOU authorized the transactions.
What people are saying here about the need to NOT export your keys is because normally Electrum encrypts that data. making it hard for someone else to use should they gain access to your computer (ether physically or remotely). By exporting your private keys to a csv file you've just done the difficult work for any would be attacker.


text:
How to create multi-user bitcoin wallet using UTXO?
We are developing bitcoin wallet for multi-user. We are using Bitcoin core as Bitcoin wallet. Bitcoin core is generating random address. we cannot show balance because After one transaction rest of user's balance goes to a new address. so we can not show the real balance of any user? But we can not use old accounting system. How to create multi-user bitcoin wallet using UTXO and show user address balance.

I'm assuming that you're using a fully custodial setup. You need to implement logic to keep track of their balances in a database. Hereby, you give each new user a new deposit address and keep track whom you have shown which addresses. When you receive funds, you credit the corresponding user in your database. When they withdraw, you deduct from their balance. Hereby, you need to consider the confirmation status and transaction fees of the corresponding transactions.
To be honest, if you're having trouble mapping individual user balances to your customers, it worries me that you are aiming to manage funds for others.
You should perhaps consider relying on a third party service to manage the funds of your business for you. However, even then you'll need to implement the basic business logic yourself.


text:
Does an incorrect preimage cause intermediary nodes to discard a Lightning payment?
Consider a multi-hop Lightning payment from Alice via Bob to Charlie. Charlie creates an invoice, Alice finds a route and forwards the payment, now Charlie is expected to redeem the payment by revealing the preimage to Bob. If Charlie tries to redeem the payment using an incorrect preimage, does Bob cancel the payment altogether, or does Charlie get "a second chance" to redeem it?

You will find the answer to your question in BOLT 02 in the section about the update_fulfill_htlc message
from there I quote:

If the payment_preimage value in update_fulfill_htlc doesn't SHA256 hash to the corresponding HTLC payment_hash [the receiving node] MUST fail the channel.

This goes for every local HTLC so if Charlie sends the wrong payment_preimage Bob will fail the channel with Chralie. If Bob alters the preimage Alice will fail the channel.
Whoever fails the channel should fail the onion as the path does not exist anymore. Reading BOLT 04 I guess it returns

type: PERM|8 (permanent_channel_failure)

But I did not double check in the implementations

interestingly enough I just realized that the person trying to release a wrong preimage might get a second chance. Failing the channel should be collaboratively in which case the HTLCs will timeout first before publishing a closing transaction. However if the channel is closed with a force close the HTLC is now onchain and there it could be claimed with the correct preimage (which obviously comes with additional onchain fees for the transaction redeeming the HTLC)

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


text:
If I import/restore a deterministic wallet into Bitcoin Armory, how far into the dynamic addresses does it look for transactions?
I see that in Armory, I can click on "receive bitcoins" any number of times, and it generates a new as-yet unused address every time. So I could potentially send coins to address 1000, and have 999 unused addresses before it.
I'm wondering, when you import a deterministic wallet,  how many of the addresses does it check to see if they have activity?

I tested and it at least checks the first 31. Not gonna test to 1000 tho ; )

Wow that would suck if you use it your whole life then have to restore from wallet words when you are 76!

By default, Armory will check 100 addresses, but this can be changed with --keypool command-line option.

Can you link a source to verify that info?

--keypool option is mentioned in documentation, but I couldn't find default value there, so look at source code.


text:
Is it possible to force a person to honor a conditional promise-to-pay?
I'm thinking of the situation where you have an auction where bids are placed. There are two conditions that should be held:

Placing a bid shouldn't expose you to paying the seller unless you win the auction
Placing a bid should require that you pay the selling in the case you win the auction

Is it possible to satisfy these two conditions using bitcoins?

The following protocol is based on Providing a deposit example contract and the previous answer.
When placing a bid, the bidder and the auctioneer do the following:

Both generate new public keys.
The bidder generates a transaction (deposit) which sends his bid to a multisignature script requiring signatures from both newly generated keys to spend. Then he sends its ID to the auctioneer.
The auctioneer generates a transaction (return) which spends deposit and sends the money back to the bidder. He sets its lock time (nLockTime) to some time after the auction ends. He also generates a transaction (payment) that spends deposit and sends the money to himself.
The auctioneer signs return, but not payment. Both transactions are not valid without the bidder's signature. He sends both transactions to the bidder.
The bidder checks that the transactions are as expected, and that the auctioneer's signature on return is valid. He broadcasts deposit. He also signs payment and sends it to the auctioneer.
The auctioneer checks the bidder's signature on payment. As soon as deposit is confirmed, the bidder's money is locked and can't be spent by the bidder until the auction is complete.
After the auction, the auctioneer signs and broadcasts payment transaction corresponding to the winning bid. Other bidders can have their bids returned by broadcasting return transaction when it becomes valid, or they can cooperate with the auctioneer to have their bids returned immediately.

Now, there is a little problem: the auctioneer can claim multiple bids. To solve this, have the auctioneer provide a small anchor output and make all payment transaction spend this output. Now at most one of the payment transactions can be accepted by the network. Of course, bidders need to check that payment spends that output before signing it, as well as to make sure that the same anchor is used for all bidders.

This is exactly the kind of detailed answer I was looking for! Very clever. Can you explain the anchor output in a little more detail? How can every payment spend the anchor output (when I would think every payment is from a different address)? I think it would be most clear if that part was included in the steps, instead of being an after-note.

Also, I think you should mention nLockTime, which it seems is critical to this protocol.

@BT I have already mentioned lock time. A transaction can spend from any (unspent) outputs, as long as appropriate signatures (or whatever else is required by output scripts) are provided. It doesn't matter whether these outputs are to the same address or not (or even to some custom script). I think the protocol is complicated enough without the anchor output, so it makes sense for the reader to comprehend the simplified version before the complete one.

Ah I think I see. So you're saying a bidder can create a transaction with two inputs: the bid coming from an address the bidder owns, and the anchor coming from an address the auctioneer owns. For that transaction to succeed, both bidder and auctioneer have to sign it. And as long as the transaction hasn't been given to the network, the same anchor can be used for all the bids, ensuring that only one will successfully be spent. Is that right?

@BT The payment transaction would have two inputs: one spending deposit, which requires signatures both from the bidder and from the auctioneer, and one spending the anchor output, which requires a signature from the auctioneer only. So, two inputs and three signatures in total. The auctioneer would sign only one of the transactions, and the network won't accept more than one because they spend the same output.

It is possible to create a small transaction output as an anchor for each auction: Interested parties would then be able to place their bids by signing a transaction that uses both their bid and the anchor as inputs.
When the time-frame of the auction ends, the auctioneer can countersign the transaction with the highest bid, and since the anchor can only be spent once, all other bids are automatically invalidated.
The transactions would have to be posted through the auction's portal, as they wouldn't be relayed by the network without being signed completely. After they were posted though, everybody could verify that they are valid and the bidder actually has the funds.
One problem is though, that bidders could retract their bid, by doublespending the output used for the bid. This wouldn't be so much a problem if only people bid that actually want to win the auction, but would be a very easy way for the seller to push the price up.
In the end, the auctioneer could just sign the next highest bid then though.
The retracting of bids could be monitored by the auction platform, requiring registration.

Hm, very interesting. But that last problem is critical. The scheme I've come up also allows payments that depend on the bids of other bidders, but has the same problem that people can basically retract bids. My scheme was recording encrypted bids in the blockchain, and after the bidding window is closed, bidders would release the key they used to encrypt their bid. At that point the winner would be chosen and expected to pay. But it still wouldn't be able to force someone to pay..

If you had a 3rd party like the auctioneer, they could keep bids and then return the remaining value.. but that adds a centralized facet to something I was hoping could be distributed.

The "tracking" feature would need some extra infrastructure.  The submitted bids would not be valid transactions without the countersignature, so they wouldn't be relayed on the peer-to-peer network.  However, if they were posted on the auction house's website or something, other people could verify that they were otherwise valid (and in particular, that the bidders actually had the funds they were bidding with).  Incidentally, in some ways this is like using a colored coin as a token for the property being auctioned.

@BT If the bid is encrypted before going in the blockchain, how do you know it's valid? Also, how do you know that bidders will release the key for their bid?

@NickODell its only valid if its in the blockchain before a particular date (defined by the bidding window) and if the bidder releases their key. So if they don't release their key, it isn't counted as a bid. And if they do and it successfully decrypts their encrypted bid, wala its valid.

authors: коля пылыпив


text:
Lightning Network Unidirectional Transaction
In Lightning Network is it possible to setup a channel to make payment in on direction only.  For example Bob is buying Donut from Alice every day.  So Bob put in 0.001 BTC into the channel and pay Alice 0.0001 every day for the next 6 days.  My Question is does Alice need to place 0.001 BTC into the channel?.  Thanks.

All channels on the lightning network are bidirectional, even if they are only used in one direction.  However, this does not mean that both parties contribute to the funding transaction.  In fact, in the current spec only a single party contributes to the funding transaction.
That said, your scenario is not a good use case for its own channel.  The overhead of a channel for the purpose of paying for a weeks worth of coffee if probably not worth it.  Most likely you'd simply route the payments over an existing channel and through other hubs and channels.


text:
No addresses returned by getnodeaddresses RPC call
The issue
I am attempting to use the getnodeaddresses RPC call to return all addresses known by a node in a docker network. I'm using the regtest environment. The RPC call returns an empty array although nodes have been added on the referent node using the add RPC call.
Expected behavior
The getnodeaddresses RPC call should return nodes added via the add RPC call.
Actual behavior
No addresses are returned, i.e., an empty array is returned:
bitcoin-cli -regtest --datadir=/root/.bitcoin/ getnodeaddresses 5
[
]

Reproduction
Setup a regtest network of 11 nodes. No mining has been done, and the ~/.bitcoin folder contains only bitcoin.conf with the following content:
[regtest]
regtest=1
server=1
rpcport=8332
port=8333

Connect to the referent node and run the command:
bitcoin-cli -regtest --datadir=/root/.bitcoin/ addnode "$p:8333" add where p is the other node address  for every node the referent node wants to add.
Run the commands on the referent node:
bibitcoin-cli -regtest --datadir=/root/.bitcoin/ getconnectioncount
10

bibitcoin-cli -regtest --datadir=/root/.bitcoin/ getpeerinfo

[
  {
    "id": 2,
    "addr": "10.0.0.3:53378",
     # Cut out part of response
{
    "id": 11,
    "addr": "10.0.0.4:36236",
    "addrbind": "10.0.0.2:8333",
    "services": "000000000000040d",
    "relaytxes": true,
    "lastsend": 1569835448,
    "lastrecv": 1569835448,
    "bytessent": 464,
    "bytesrecv": 488,
    "conntime": 1569835207,
    "timeoffset": 0,
    "pingtime": 0.001063,
    "minping": 0.000456,
    "version": 70015,
    "subver": "/Satoshi:0.18.0/",
    "inbound": true,
    "addnode": false,
    "startingheight": 303,
    "banscore": 0,
    "synced_headers": -1,
    "synced_blocks": -1,
    "inflight": [
    ],
    "whitelisted": false,
    "minfeefilter": 0.00001000,
    "bytessent_per_msg": {
      "feefilter": 32,
      "ping": 96,
      "pong": 96,
      "sendcmpct": 66,
      "sendheaders": 24,
      "verack": 24,
      "version": 126
    },
    "bytesrecv_per_msg": {
      "feefilter": 32,
      "getaddr": 24,
      "ping": 96,
      "pong": 96,
      "sendcmpct": 66,
      "sendheaders": 24,
      "verack": 24,
      "version": 126
    }
  }
]

bitcoin-cli -regtest --datadir=/root/.bitcoin getnodeaddresses 5
[
]

Bitcoin core version
bitcoin-cli -version
Bitcoin Core RPC client version v0.18.0.0-g2472733a24a9364e4c6233ccd04166a26a68cc65
bitcoind -version
Bitcoin Core Daemon version v0.18.0.0-g2472733a24a9364e4c6233ccd04166a26a68cc65

Installed via the repository ppa:bitcoin/bitcoin
OS
Docker container info:
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.3 LTS
Release:    18.04
Codename:   bionic

Host info:
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.3 LTS
Release:    18.04
Codename:   bionic

cat /proc/cpuinfo  | grep 'name'| uniq
model name  : Intel(R) Core(TM) i7-4600M CPU @ 2.90GHz

1 TB SSD disk

There’s no getnodeaddress RPC call so it shouldn’t be surprising this fails. You probably mean getnewaddress.

I believe you are wrong, https://github.com/bitcoin/bitcoin/commit/a2eb6f540538d32725aecf678301a96247db6fd9 is the pull request adding the command to the codebase, and it is contained in release v0.18.0

You’re right, I was thinking of a similar altcoins RPC. It’s probably not returning any results because it’s not able to discover it’s public IP address? Not sure how that’s meant to function clearly.

Might be, I have opened an issue and will follow up here when it gets resolved

Sorry for my mistake there.

No worries, we are here to discuss :D


text:
How many paths are tried on average before a payment succeeds in Lightning?
In Lightning, the sender can never be sure that a multi-hop payment will go through, as intermediary nodes don't announce the distribution of funds in their channels (only the total capacity). Is there any publicly available data on how many attempts it takes on average in practice to route payments of different sizes? Something like this (the numbers are my wild guess):
Amount - Average paths tried
100 sat - 1.8
1000 sat - 3.3
10000 sat - 5.9
1000000 sat - 13.2
There is a similar question Lightning network routing failure rate and a 2018 article linked from there, but it addresses the success probabilities based on capacities only (this can be calculated from a network snapshot). I'm interested on the data from real-world transactions.

It seems to me that a ‘generalized network average’ will not be extremely useful, as I’d expect the standard deviation to be very large. That said, I do think this is a measure that could be meaningful, but it would need to be standardized against the liquidity of your channels and of your neighbouring peers, or something along those lines. Is there a term for the quantification of a LN node’s liquidity within the network graph? Affluence? Ha. Good question, anyways.

I suggest to create histograms or a box plot. While not a single measure like a (generalized) average it will still be easy to read and probably as expressive as it gets

I don't think there is a Public dataset online with an answer to your question. This would also be extremely hard to create as the results could change a lot depending on which node is doing the experiment.
I know people are probing payment channels you could do the same. Just do payments to random payment hashes and collect the data for your node. You will get the routing failures and attempted tries in that way you can easily collect those statistics yourself.


text:
What is the difference between PSBT support in Coldcard and Trezor?
The 10x Security Bitcoin Guide says that the only two hardware wallets support BIP174 (partially signed Bitcoin transactions, or PSBT). However, this Reddit thread says that "You can use PSBT with Trezor via HWI". This Github issue elaborates.
What is the difference between the level of support of PSBT between Coldcard / Cobo and Trezor? Should a user care?

The Coldcard handles PSBT directly and natively. A PSBT can given to the device by writing it to a microSD card and inserting the card into the device. It will be able to load the PSBT and process it as a transaction. Additionally when communicating with the device over USB, PSBTs can be given directly instead of being packed into another data structure.
However other hardware wallets like the Trezor do not have this capability yet. Instead these must be given transactions over USB and those transactions must be packed into device specific data structures. The HWI software does this translation for users - it takes PSBTs and converts them into the format that each hardware wallet uses.


text:
Where, or how, can I get a complete history of difficulty?
I would like to have a complete list of the historical mining difficulty of bitcoin. Preferably it would be a text list or csv, but a webpage that displays the data in any text format will do.
I've been searching for several hours over the last couple of days with no progress. I'm quite surprised that this is so hard to find...

You can get it for example on blockchain.info. Call up the Difficulty chart, switch the time-frame to "All Time", then use the link labelled "CSV", to download it.
Note that the difficulty only changes every 2016 blocks, which is re-targeted to be about 14 days, in case you wonder why there are so few data points.

After having a look at the data, there may be a mistake in the first few data points. As far as I know the difficulty can’t drop below one, so the values given with zero irritate me. I would assume that they were one as well.

Thank you! This is exactly what I was looking for. Also, I'll adjust the 0 values, as you describe, before using the data.

I don't see any negative data points, but I do see a few 0 points. Bitcoin's difficulty can't go below 1 by consensus rule, I believe, so blockchain.info has some bad data here.

I needed a trustworthy history of mining difficulty changes and also landed on the blockchain.info chart that clearly has incorrect (averaged) data. So I wrote this script that uses the Esplora API to search for difficulty changes. The logic could be easily ported to run against your own Esplora instance or your own Bitcoin node's RPC API.
Script is here: https://github.com/jlopp/bitcoin-utils/blob/master/generateDifficultyHistoryCSV.php
<?php

// This script uses the blockstream explorer API
// It iterates through every block that was minted after a difficulty retarget height
// and if the difficulty changed compared to the previous epoch, will print it in CSV format

$ch = curl_init();
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);

$currentBlockHeight = 38304; // one epoch before the first difficulty change (speed up the script by reducing API calls)
$currentBlockHash = NULL;
$currentDifficulty = 1;

// determine where to stop looking for new difficulty epochs
curl_setopt($ch, CURLOPT_URL, "https://blockstream.info/api/blocks/tip/height");
$chainTipHeight = curl_exec($ch);
$maxBlockHeight = $chainTipHeight - ($chainTipHeight % 2016) - 2016;

echo "\nBlock Height,Date,Difficulty\n";
echo "0,2009-01-03,1\n";

while ($currentBlockHeight < $maxBlockHeight) {  // there are more difficulty retargets
    $currentBlockHeight += 2016;
    curl_setopt($ch, CURLOPT_URL, "https://blockstream.info/api/block-height/$currentBlockHeight");
    $currentBlockHash = curl_exec($ch);

    curl_setopt($ch, CURLOPT_URL, "https://blockstream.info/api/block/$currentBlockHash");
    $block = json_decode(curl_exec($ch));
    if ($block->difficulty != $currentDifficulty) {
        echo $block->height . "," . date("Y-m-d", $block->timestamp) . "," . $block->difficulty . "\n";
    }

}

As it's only 34 lines, you could inline it here (with a note of where the latest version can be found) to avoid future issues with link-rot/404

The data is also stored on the block chain.  Query every 2016 blocks to see the difficulty at that time.  Here are some samples, can see block 131040 was a re-target.
# bitcoin-cli getblockhash 4032 | xargs bitcoin-cli getblock
{
    "hash" : "00000000ca4b69045a03d7b20624def97a5366418648d5005e82fd3b345d20d0",
    "time" : 1294031411,
    "difficulty" : 1.00000000,
}

# bitcoin-cli getblockhash 131039 | xargs bitcoin-cli getblock
{
    "hash" : "0000000000000e6e98694ccb8247aad63aaa1e2bec5a7be14329407e4cea6223",
    "time" : 1308145551,
    "difficulty" : 567269.53016242,
}

# bitcoin-cli getblockhash 131040 | xargs bitcoin-cli getblock
{
    "hash" : "000000000000097aa651b8e19c448924586a8010721c8e7ea282a0272d425987",
    "time" : 1308145774,
    "difficulty" : 876954.49351354,
}


text:
Fee negotiations in Lightning
How are fees negotiated in multi-hop payments in Lightning?
Imagine a four-hop payment: Alice -- Bob -- Charlie -- Dave. Bob and Charlie advertise fees of 100 sat each, Alice thinks it's reasonable and starts routing the payment through this route. Does Bob know which part of the expected payment is intended to be a fee? What is Bob forwards the payment to Charlie taking 120, 150, or 200 sat instead of 100 -- what does Charlie do?
Is there anything that prevents intermediary nodes from lying about their fees?

Nodes advertise the fees for forwarding over a channel as part of a channel_update message. The update should be sent as soon as a channel_announcement is sent. Each party can decide its own fees for the channel.
For private channels, nodes advertise the fees inside the r tagged field of the BOLT#11 invoice.
When forwarding a payment, your node must calculate the required fee for each hop and add it to the payment requested in the invoice. When each intermediate hop receives an update_add_htlc message, they will unwrap one level of the onion packet, which contains an amt_to_forward. This is subtracted from the amount_msat in the update_add_htlc message, and the difference is the fee paid for this hop.
If the hop determines that the fee is insufficient, they respond to the sender with fee_insufficient error as part of an update_fail_htlc message. This message also includes the most recent channel_update for this channel so that the payer can re-attempt the payment with new fees.
There is always the possibility of a race condition where fees may have changed between the most recently received channel_update and the payment attempt. This is minimized by including the channel_update as part of the failure as above.
If the payment at the last hop is too small, they will respond with a failure containing the incorrect_or_unknown_payment_details failure code.

We need to coordinate in future (: I was typing on my mobile where putting all these links and syntax highlighting is annoying. Anyway plus 1 for nice onside explainations instead of referring to a tutorial video like I did.

The situation you describe cannot happen / would lead to a routing failure. I have created an 11 minute video explaining how htlcs are used in onion routing. Parts of the video (rather at the end) explain how fees are encoded within the sent onion. I think watching that video is the quickest way to understand the fee model of the lightning network.
A tl;dw (too long didn't watch) answer looks like that:
If a node decides to maliciously collect a larger fee and forward the onion. The next hop will not be able to collect the fee as it advertised and will fail the routing process. In your setting this means charlie decrypts his onion and sees which amount to forward and sees from the incoming htlc that it would only receive a fee of 80 / 50 or 0 Satoshi instead of the advertised 100. As said charlie would fail the onion but not be able to blame Bob. Actually obs behavior would confuse Alice as she chose the correct fees. Alice could assume Bob was a bad routing node and elect a different part. However this mechanism is as far as I know not implemented yet.

By "this mechanism" in the last sentence do you mean Alice marking Bob as a bad node? (BTW, the tiny envelopes you use in the video are amazing, where did you even get those things :)

What if we extended this argument by one more party? Alice sending BTC to Eric via bob, charlie and dave. Assume charlie is the bad apple in the lot and consumes all the remaining fee in the hop. How would Alice know whether it is Bob or Charlie?

Since the fees are part of the onion noone in the chain knows what the payment amount is and how much fees are in the onion in total... On the other hand I hope to remember correctly that the node that can't forward the onion because the prev took too much fees and back an failure message of type 12 fee _insufficient cf: https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#failure-messages

@RenePickhardt That was helpful. One more scenario comes to mind. Assume Alice forwarded with 150 sats fee assuming bob, charlie and dave would take 50 stas each. Now let us assume Bob is the bad guy. Bob consumed 90 sats, and charlie consumed 50 sats. Dave will send a fee_insufficient message, but it would be hard for Alice to figure out who was the bad guy

What I see here is a violation of the "don't explain to the attacker why the error happened" security principle, screaming for probing attacks similar to this one... ;)

I think it would be interesting because if there are say 10 hops and I just take 1 more Satoshi than I advertised, then only the last guys will send an error and the originator of the transaction will not who the bad guy is

Yeah the probing attack is well known. I don't see a direct relation. The proving attack usually would use a circular onion and you yourself would fail the htlc / onion

@RenePickhardt I guess I have some reading left to do ;)


text:
Can I use blockfilterindex in pruned mode?
I run a node in pruned mode. I want to enable blockfilterindex. What I expected the node to do was:

start downloading blocks from the very beginning;
create the block filter as it goes through the blocks;
only keep the last N MB of blocks stored.

What really happened was:
$ bitcoind -blockfilterindex -prune=550
Error: Prune mode is incompatible with -txindex.

I understand that it is not possible to enable block filtering without downloading all blocks, but why does it require storing all the blocks?

That error isn't for -blockfilterindex, it's for -txindex. Do you have txindex=1 in your bitcoin.conf file?

True! However, when I disabled txindex, I got Error: Prune mode is incompatible with -blockfilterindex.

The block filter index is build asynchronously from block downloading and validation. It is possible that the thread handing block storage and pruning could be enough ahead of the thread building the block filter index that it starts to delete blocks before the index thread processes them. This would be bad. So for the initial block filter index implementation, it was decided to simply disallow pruning when the block filter index is enabled. You can read some of the reasoning and discussion in the PR.
In theory it is possible to allow pruning with the block filter index. However it is more work to do this and at least for the initial implementation, the extra code wasn't worth it. PR authors often do this to keep the PR small enough to be reviewed. This functionality could be added in the future as it is part of the more general problem of how we should handle pruning with the wallet and with the txindex.


text:
Why can't an intermediary Lightning node take (nearly) all fees?
Consider a Lightning payment: Alice wants to pay 100 sat to Dave via two intermediary hops: Alice - Bob - Charlie - Dave. Both Bob and Charlie advertise a fee of 2 sat. Alice sends 104 sat to Bob, expecting him to forward 102 sat to Charlie. But Bob only forwards 101 sat. Then Charlie has a choice: either to fail the payment and get nothing, or forward it for just 1 sat. It seems that the economically rational choice is to forward anyway. If this is true, why first hops not always take nearly all fees for themselves?
Of course, due to onion routing, Bob doesn't know whether Charlie is the last hop. If Charlie is the ultimate recipient and he won't get the sum he expected, he won't reveal the preimage, and Bob will get nothing. But can such strategies be profitable on average, over many attempts?

Summarizing what I've read in other answers and elsewhere: yes, a node can technically do so, but this would probably not be economically viable, as current implementations fail a payment is the difference between "incoming" and "outgoing" amounts is less than their announced fee. So assuming that the majority of the network runs non-malicious software, the payment with modified fees with likely fail. The precise economic analysis of this attack (and the related DoS attack) has not been done though (AFAIK).

Sure there might be some game theory involved but two things speak against it:

Bob does not know what the fee or the final payment amount  is. Of course he could make an educated guess. But maybe the final payment was 101.5 sats and Charlie was supposed to forward for 500msat. Charlie would now even have to add 500msat to fulfill her 101.5 amt to forward.
It is currently differently implemented. Nodes will just not forward if the amount they reicieve minus the amount they are supposed to forward is below their fees. So if Bob would mess with the onions later nodes would currently automatically fail with insufficient fee error message. This of course could be abused for denial of service attacks.

Can't Bob just query Charlie about what fee he offers? 2. "nodes would currently automatically fail" - current implementations do that, but this can't be enforced, right?

Bob could query Charlie but since Bob does not know how long the route is the information given is low but it might be used). So there are possibilities. And yes I don't see any way to enforce this behavior

no bob would not change the amount_to_forword for the next hop but just forward a different amount than was specified in his part of the onion. This would not have any impact to HMACs but obviously meddeling / breaching the protocol is a poor idea since charlie would / should probably fail the onion as charlies routing fees are not sufficient

@RenePickhardt I just figured that out and deleted my earlier comment. What impeccable timing :). Sorry about that

Each hop along the route is sent the full amount including fees with a new HTLC, and inside the onion packet, they are told how much of it to forward to the next hop. They can therefore determine if enough is provided for the fees they have advertised for their own node, and if the fee is insufficient, they can simply remove the HTLC without forwarding it by returning an fee_insufficient failure code to the previous node in the route.
There is a possible race condition where fees have changed, so the most recent channel_update is forwarded along with the fee_insufficient failure so that the payer can reattempt the route with update fees.
Each HTLC is conditional on receiving the payment_preimage or timing out. Currently, the same preimage is used for every hop along the route, which makes the payment from Alice to Bob conditional on Dave releasing the preimage to Charlie, who can then forward it to Bob, who then forwards it to Alice.
If the penultimate node attempts to forward less than the intended amount to the payment destination, then the payment destination will respond with the failure code incorrect_or_unknown_payment_details, which will also remove the HTLC. Each node along the route will then forward the same failure and cancel each HTLC, and no money will change hands.

"if the fee is insufficient, they can simply remove the HTLC" - but do they have to?  Sure, if the last node gets less than expected, the whole thing fails. The question was, if I announce my fee as X and get offered a routed payment with fees <X, why would I want to drop it instead of earning at least something?

The node is not required to drop it, but if they do not forward at least the requested amount to the next node it is very likely the payment will fail and they will earn nothing anyway. A node is unlikely send payments with insufficient fees to begin with because it is highly likely to fail.


text:
Routing for Lightning network: was Flare implemented?
There is a 2016 paper from Bitfury on a proposed routing algorithm for LN:
Flare: An Approach to Routing
in Lightning Network
What is the relation between it and was was actually implemented (the primary reference being the BOLT specs)?

It was implemented by Bitfury and Acinq, but only for testing purposes, it never went to the production implementation.

As far as I know flare was never implemented for lightning nodes and is not being used. I think current implementations use sind pathfinding algorithms like BfS or  Dijkstra. The pathfinding itself is not part of the BOLTs anyway. A node could do whatever it wants with the information provided from the gossip store / gossip protocol. (BOLT 07). People could in particular decide to go for the approach given by flare.


text:
Multisig without P2WSH in Lightning
The current Lightning implementations use P2WSH script format for multisig in the funding transaction. But it is also possible to use the CHECKMULTISIG opcode "natively", i.e., without P2WSH (see Mastering Bitcoin, Chapter 7). Can it be used for channel establishment? What would be the pros and cons? Was multisig used in Lightning at some point, or did Lightning go straight to P2WSH?

Possible duplicate of Why SHOULD the funding tx consume BIP 141 inputs?

Potential duplicate question to https://bitcoin.stackexchange.com/questions/84967/why-should-the-funding-tx-consume-bip-141-inputs could you please comment if the other question / answers help?

That question is interesting by itself but not exactly what I'm asking. I'm wondering whether one can or did use in the "plaintext" scripts (without P2WSH) with OP_CHECKMULTISIG in Lightning (very early versions perhaps?).

I think that didn't happen because of the malleability issues connected to non segwit transactions. If that does not answer your question I will dig a little deeper or wait for other lightning devs to help out. I am no segwit expert but I think that should be the reason (:

So the tx is non-malleable only if it creates P2WSH outputs? From the question linked above I understand why it must consume only Segwit inputs (SHOULD, strictly speaking, assuming there are other ways to ensure non-malleability), but why does it also have to create only Segwit outputs?

If the output was not segwit another node could catch the published funding TX and malleate it and broadcast the mandated one with a higher fee. Now the txid of the funding TX would change and the commitment tx would be worthless as it points to nirvana. The channel partner could now blackmail the initiator. To prevent this we use P2WSH as discussed in the other thread (or I have misunderstood the answers to my thread g which I don't want to rule out)

@RenePickhardt I think what Sergei is trying to point out is that why the commitment transactions NEEDS to have SegWit output? Those pay the individual addresses of the channel partners and the txid is not referenced.

That would make sense to me but the question talks specifically about the funding TX. Now I am confused ;(

@RenePickhardt to prevent the "points to nirvana" scenario the funding tx must not commit to signatures (hence segwit) - that's what I understand. Does it imply that the funding tx must consume only segwit inputs, create only segwit outputs, or both?

In my understanding it must produce segwit outputs. What it consumes should not matter

The main issue about using a non-segwit inputs in the funding transaction or a p2sh output as the channel anchor is the transaction malleability.
The recovery guarantee before a channel is funded relies on the commitment transaction building on top of the funding transaction. If the funding transactions txid were to be malleated, the commitment transaction becomes invalid and the funder becomes beholden to their channel partner for recovery.
In the case of using a p2sh output as the channel anchor, malleation of a unilateral force-close could be used to prohibit the counterparty from punishing the publication of an outdated channel state.
Therefore the funding transaction must be non-malleable and the channel anchor must be held in a script that is not malleable upon spending.


text:
How do bech32 addresses compare to P2SH addresses in transaction size?
Bech32 (starts with bc1) and P2SH (starts with 3) can both be used for segwit transactions. I know bech32 is supposed to create smaller transactions, but I'd like to know how much smaller (than P2SH). How do transactions coming from a normal single-key address compare?

Related: What is the size of different Bitcoin transaction types?

bech32 produces smaller transactions than P2SH segwit transactions.

one extra byte per output to create P2SH outputs than to create bech32 utxos (P2SH uses OP_HASH160 and OP_EQUAL in addition to a 20 byte hash in its script, whereas bech32 just uses a fixed 00 byte in addition to a 20 byte hash), and
23 extra bytes per input to spend from P2SH utxos than from bech32 utxos (P2SH has to produce the script that was hashed when spending in the sigscript, which takes 23 bytes to encode - bech32 has no non-witness sigscript at all).

Basically P2SH requires a script hash, native SegWit doesn't, and everything else is much the same. Native SegWit provides the script when the output is created, and P2SH provides it when the output is spent.

If you want to know how much you saved (or can save) in each transaction, Blockstream explorer provides nice feature, where you can see the savings. For example for this transaction, can save extra 16% on fees

See discussion here: https://www.reddit.com/r/Bitcoin/comments/80a4zl/bitcoin_utxo_has_been_reduced_by_10_in_one_month/duu91c9/

https://bitcoincore.org/en/segwit_wallet_dev/#why-and-how-to-use-native-p2wpkh-and-p2wsh says "Comparing with the P2SH versions, the transaction vsize of native versions is smaller in most cases".

Here is an example: SegWit => 30% savings. Native SegWit => extra 16% saving

They are both just an encoding. The resulting tx could be exactly identical. In real life however people use bech32 just fur native segwit transactions, while p2sh is used as a wrapper around segwit. the tx is actually a tiny bit smaller when using p2sh.

Oh really? P2SH is actually smaller? What's the advantage of bech32 then?  I don't quite understand what "native" means in the context of "native segwit". By the way, do you have sources where we could read more about this / verify your answer?

The best source is always the actual source. bech32 have been proposed in bip173 which you can find here: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki It also has a section on how bech32 is better than different encodings. For the size there is no definite source without specifying what exactly you want to compare. bech32 is an encoding, p2sh is a type of transaction. For my comparison I assumed that bech32 is equivalent to native segwit.

This answer is false in multiple ways: 1. It's not just a different encoding, wrapped segwit and native segwit outputs are different output types. When funds are sent to a wrapped segwit address, they can only be spent in a wrapped segwit input, and vice versa for native segwit. 2. Wrapped segwit and native segwit transactions cannot be identical, even though they can have equivalent effect (at different fee costs). 3. Wrapped segwit transactions use more blockspace, than native segwit transactions.


text:
Will Lightning be implemented on Bitcoin network?
Lightning cannot currently operate with pruned nodes. I presume without limitation the same applies to SPV nodes. Will Lightning be implemented on the Bitcoin network?

Lightning nodes can function in a light client mode by connecting to full nodes who support the new BIP157&158 light client mode. This is supported by LND (the lightning network daemon), and is known as neutrino. On testnet, the lightning faucet operates a neutrino-compatible full node but support will spread and it will eventually become as easy as using SPV currently, with many added benefits over SPV.

Okay, that's better. I should probably have noted in the question that I was reading the c-lightning implementation readme, not the Lightning specification. Phew! - https://github.com/ElementsProject/lightning/blob/master/README.md


text:
Reduce bitcoin blockchain size
I have a freebsd server with a bitcoind server. But the blockchain is getting to large for me. So I just bought some new sas drives so I can keep it up. I now have 218GB of total space. 40GB is for the OS, programs and all files. The rest is for the blockchain(178GB). I do not want to buy more SAS drives than I have now.
I am afraid that the blockchain will get to big again in 1 or 2 years.
Is there a way to reduce the blockchain size or is there a cryptocurrency where this problem is solved?

Interesting, I run a full node too, and at the present time, it uses little over 90GB.

@FábioAntunes mine to but I didn't want to install bitcoind if I cant use it anymore in 1 year. But now pruning exists so I can continue.

Yes this problem has been solved. Have a look at the pruning option. You can specify whatever maximum size you want to allow the blockchain to take up.


text:
EasyBitcoin-PHP very slow
I am trying to use bitcoins on my website. For this I use EasyBitcoin-PHP. It works good except that it is very slow. It takes about 5 seconds to load a simple script like this:
<?php
require_once 'easybitcoin.php';
$bitcoin = new Bitcoin('...', '...');
echo $bitcoin->getinfo();
?>

Is there a faster alternative than EasyBitcoin-PHP or is there a way to make it faster?

This is likely implementation specific. Bitcoind is an intensive application to run on a basic server, especially if the webapp lives on the same machine.
You should never directly connect a page's code with Bitcoin Core, for static information you should run a cronjob to update a cache every n seconds. If all you're showing is the last 10 blocks, maybe you shouldn't have every user at that moment triggering calls for the same data.
Update: It's worth mentioning that RPC responses suffer a delay whenever Bitcoin Core is syncing, whether syncing for the first time, or being switched on after a day. This is because the block verification functions block for a while.

The problem was that bitcoind wasn't yet synchronized but your also of course will also help me.

Ah, I was going to mention that but thought against it :) I'll mention it in my answer, since it'll happen every time you start the node.


text:
Freebsd Bitcoind doesn't read config correctly
When I try to connect to my bitcoind server with the username and password in my bitcoin.conf I get a 401 error.
When I set an username and password in the bitcoind parameters(bitcoind -rpcuser=... -rpcpassword=... -daemon) it does work.
I also have prune in my config file. For some reason this does work.
Also the rpcallow works fine.
So it does read my config file?
When I add the -conf parameter with my config file I get this error:
Error reading configuration file: the options configuration file contains an invalid line '��
(I also can't read those last 2 characters)
I even get this error when the file is empty
Does someone know how I can fix this?

Which version of Bitcoin Core do you use? Does the password/username contain non-ascii characters?

I'm also interested in what version you're using. Did you build it yourself or does it come from ports? I didn't have this problem with 0.13.1 at least. Also can you do bitcoind -conf someconffile.conf | & hd to see what those characters are in hex?

One guess would be that it is something to do with locale, which isn't set by default on FreeBSD (and the boost function used for conf file parsing may croak on that). e.g. try export LC_ALL=en_US.UTF-8.

@user2084795 I am using the version from the repository. It is 120100. My username and password only contain letters and number.

@wumpus your command is not correct, I get a syntax error.

That syntax is based on bash. Your shell may have a different syntax for exporting environment variables

Could you do an hexdump on bitcoin.conf and check for >0x80 characters, or upload the entire file (w/ censored user and pass) somewhere? I'm quite interested what unicode it contains. Some editors leave UTF-8 BOM markers at the beginning, for example.

I don't know exacly how, but I got it working.
I do know that I used export LC_ALL=en_US.UTF-8 but I am not sure that is the reason it works.
I still have the same error with the -conf paramter. Even when permissions are 777.
I know this isn't a perfect answer. But my bitcoind server works now.


text:
Creating an account system
I am using the bitcoind account system for my web app, but it doesn't work the way I want it to work. So I want to make my own account system in Laravel(probably opensource).
The main reason for the account system is that I can't know the fee when I send a transaction. With my own account system I can check if the fee is correct and then send the transaction.
But how can I setup a safe account system?
I was thinking about a table with all the bitcoin accounts(I am not using the users table so I can create accounts for an order for example).
Then an address table with all the addresses linked to an account.
But how do I handle incomming transactions? And outgoing transactions?
If I for some reason change something outside my account system, it will probably will break pretty easy.
Do I have to import all the transactions to calculate the right account balances?
And I want to make the system in a way that I can make transactions between accounts, without making a "real" transaction, just like it works now.
I think it isn't that hard without the account-to-account transactions and moving bitcoin addresses to other accounts features, just import all the transactions in the database and calculate the balance for every address. And than sum the address balance for every account, but I need it.
Does this kind of system already exists.
If not can someone help me with thinking this out.

Is there any particular reason why addresses must be associated with specific accounts? From what you write it seems to me that you're in full control of the funds on every account anyway, so just tracking the balances of your users separately from the addresses would be much easier.— Note that the "account system" in Bitcoin Core has been deprecated for years and wasn't meant to be used for accounting, it's not surprising that it doesn't do what you want it to. ;)

@Murch I just want to make a good project that is very scalable. So other people can use it also. If I use it for other projects it can be implemented very easy.
If I keep track of the user balance separately from the addresses and I make a mistake(It happends a lot ;)) it wouldn't be good.

Keeping all the users' funds in separate addresses means that you have no benefit of scale for issues like fees and coin selection. You'd grind the UTXOs to tiny pieces as your users manage their funds, you'd be unable to aggregate payments via Lightning channels without updating on-chain (or payment channels)… It's anything but scalable.— I'm also not sure that keeping the balances separate makes it much harder to make a mistake.

@Murch think I that have found the way. I have a table with all the transactions. These have an user id. The user id is the id of the owner of the address at the time of receivement. So if the address goes to another account, the transactions still belongs the the user who received them. This way I can just get all the transactions of an user and  calculate the balance.

Yeah, that seems much better way to do it. :) Just be sure to account for transactions only after confirmation, and perhaps even after a a few blocks or your table will be very confused by blockchain reorganizations or stale blocks. ;)

I have the account system working! Only I didn't really test it, so it isn't stable.
https://github.com/jwz104/bitcoin-accounts
It works with an user, address and transaction table.
There is running a cronjob that registers all received transactions. If the adddress is found in the address table, it will add the transaction with the user id of the address. If the address has no user_id the transaction will not be added because it is a return transaction(Change).
When a transaction is created the package will send the amount of bitcoins to the address, and the bitcoin that are left are send to a return address(Address without user_id) so the user won't pay to much.


text:
When is the estimated date that segregated witness gets fully implemented worldwide?
I read the news recently that reviews had already been done and that the segregated witness program will be on deployment soon, so when is it expected to be fully adapted worldwide?  Or is there a target percent of implementation which can be considered completion of adaption?  Because I don't think all bitcoin stakeholders would rush to do such an upgrade considering potential risks in its implementation.

Hmmm, seems anyone does not have the idea of the target implementation date..  But this information is very important for VC investors.  Hope, somebody answers it, any smart estimate would be OK.


text:
Bitfinex get credits and convert timestamp to JS Date
I'm fetching my active credits in BFX and trying to discover when I'll have my funding back. This is a response example:
/v1/credits
[{
    amount: "294.4316181",
    currency: "USD",
    id: 15778083,
    period: 2,
    rate: "16.816",
    status: "ACTIVE",
    timestamp: "1454846632.0"
}, ...
]

But new Date(1454846632.0) returns a very old date, what makes me think this timestamp isn't there to be converted into a real date at all.
I am doing something wrong? How can I discover the remaining time of a credit I provided?

This is kind of off-topic, as converting timestamps is more of a regular programming question than a cryptocurrency specific issue. However, the question is well-written, got an answer quickly, and might be of use to others, so I'll not vote to close.

The problem is not with the timestamp, it's with your method of converting the timestamp to local time.
As this SO question describes, convert it this way:
var dt = new Date(0);
dt.setUTCSeconds(1454846632);
console.log(dt.toString());

Which prints Sun Feb 07 2016 07:03:52 GMT-0500 (EST).


text:
Install 2 Electrum wallets in a same computer
I have an Electrum Wallet in my computer, and I'd like to transfer my BTC to another Electrum Wallet, with a new seed and new adresses.
Is it possible to have 2 Electrum Wallets in a same computer? If so, how can I install it?

Is it possible to have 2 Electrum Wallets in a same computer? If so,
  how can I install it?

You able to have as many wallets as you want. You dont need install electrum twice, all you need it is create new wallet.
I assume you already have a wallet with password.
Run electrum and choose your wallet from the dialog:

Save that wallet somewhere in other place, and create another one with a new seed and new adresses. Then send from one to other.


text:
Sending funds from a Segwit address to a non segwit
I just generated a Electrum wallet with the Segwit option on. I wonder what happens if I try to transfer SegWit -> Non-SegWit or Non-SegWit -> SegWit: Will the funds be confirmed and get transfered or will it be lost forever?

what happens if I try to transfer SegWit -> Non-SegWit or Non-SegWit -> SegWit

As long as you are using software that supports doing so, this is perfectly possible and fine to do.

Will the funds be confirmed and get transfered or will it be lost forever?

Bitcoin can never be lost forever because of an unconfirmed transaction. For an unconfirmed transaction, the bitcoin do not move from their starting address until they are confirmed in a block. Eventually a transaction may be confirmed, or the network's nodes will remove the old unconfirmed transaction from their mempool's, and you will be able to spend the coins again. There are a few of ways to push unconfirmed transactions through, like replace-by-fee (RBF) or child-pays-for-parent (CPFP).

Thanks for the answer.  I'm asking this because I'm afraid to start using these Segwit wallets and not being able to transfer money from, for example, the Exchange wallet to my personal wallet. Being that said, how can I be sure that the Exchange wallet supports Segwit?

'The exchange supporting segwit' would generally refer to the exchange allowing customers to deposit funds into a segwit address controlled by the exchange. The exchange does not need to explicitly support segwit in order to send an outgoing tx to a segwit address. You do not need to worry in that regard.


text:
Bitcoin Cash: difference between addresses
My BCH wallet prefixes the addresses with a "bitcoincash:" string and the hash itself (without the prefix) is 42 chars. Let's say I need to send some BCH to an old address (34 chars, unprefixed), will this work? If not, what do I need to do to make it work?

I'm voting to close this question as off-topic because it is not about Bitcoin, i.e. BTC.  (See https://bitcoin.stackexchange.com/help/on-topic) -  "The Bitcoin stack exchange ... is not about ... any cryptocurrency or technology that is not applicable to the Bitcoin network and users of the Bitcoin currency"    I believe these rules were altered recently and made more restrictive.

In this case, I think the bitcoin-cash tag should be remove ASAP, as it is misleading as it is.

@darksoulsong see https://bitcoin.meta.stackexchange.com/questions/1017/progress-tracker-of-implementing-the-scope-change

Yes.
If your wallet does not support this, you can use https://cashaddr.bitcoincash.org to convert the old addresses to new addresses, and send to new addresses.

Thank you, but In my case, I can't convert the old address because I have no control over it. So, do I need to convert my address to an old one in order to transfer the funds?

@darksoulsong You can take any Bitcoin Cash addres in old format, convert it, then the funds will go there safely. Both types of address are compatible with each other.

I see. But my case is the exact opposite, that is, my wallet is in the new format and I need to send funds to an address that is in the old format. In this case, I should convert my wallet address to the old format, am I right?
Sorry for sounding repetitive, but I really need to be sure on this.

The address format does not actually make any difference other than not being able to put a Bitcoin Cash new CashAddr into a Bitcoin Core textbox. Other than that, you can send/receive to/from both types of addresses. If some website/wallet doesn't accept your new address, then you can convert it to old address. Feel free to ask questions @darksoulsong .


text:
Bitcoin Core extremely high syncing time
I'm running Bitcoin Core wallet on a gaming PC with a GTX 750ti, and 3.7ghz quadcore processor, and 16gb of ram. My internet download speed is 15 116mbps via hardwire.
But for some reason the syncing is stuck on 2 years and 33 weeks. I just ordered 100$ worth of bitcoin (which should come in 7 days) and I'm worried that it won't go through if it's still syncing.
Does anyone know what I could do to fix this? It's making me anxious.

What does the debug.log say? Have you tried starting with -rescan? Possible duplicate of What can I do when the blockchain synchronization is stuck at a specific block?

The transaction will go through whether Bitcoin Core is done syncing or not, so don't worry about that.  You just won't see the transaction appear in the application until syncing is finished.
The Bitcoin Core GUI doesn't always give the most accurate updates on its progress.  But one way to check the progress is to open Help:Debug Window, click the Console tab, and type getinfo.  Look at the blocks number.  Then try getinfo again a minute or two later and see if the blocks number has increased.  If so, you are in fact syncing and just have to be patient.  Note that you are downloading about 60 GB of data and performing fairly intensive computations on all of it.
If you get tired of waiting, you might prefer a "thin" client that doesn't try to download and verify the entire block chain.  See Cannot access my bitcoins because my wallet is still synchronising. What can I do to spend them immediately? to learn about your options for switching.

I thought I was stuck on 2 years 33 weeks as well, but it just reduced by a week :)

I know it's an old post but I just want to announce that I've been able to reduce the sync time from 12 days to 7 hours by disabling Windows Defender.
If you do not use Windows Defender then you can use the Task Manager for debugging. Use it to see if another application start using a large part of your CPU resources when starting the Bitcoin Core application.
You must enable antivirus when sync is complete.
But Nate Eldredge's answer is still a good answer if you do not want to ride with the antivirus program.

modern core can fully synchronize in about 24 hours. it displays funds only when the synchronization catches up to the time when you recieved the funds

I'd add, that after you have a full sync, it's not a bad idea to throw your entire Core folder; including all the blockchain data, in exact form, onto an external HDD.
I've had a number of instances where a bad shutdown causes Bitcoin Core to throw errors on startup after reboot, thus having to re-sync the entire blockchain.
Having a large portion local, you can restore from there, without having to redownload the entire chain.


text:
Manually crafted multisig Tx: non-mandatory-script-verify-flag
I'm trying to broadcast a manually crafted and signed transaction. As far as I can tell, the scripts are correct and the signatures pass BIP 66 validation.
However, I keep getting:
{'message': '64: non-mandatory-script-verify-flag (No error)', u'code': -26}

Suspecting the DER encoding, I tried different libs (plus my own ad-hoc code) to no avail. This is the raw transaction in question:
010000000185a08567ea46e4643bcace616519227876b89a364afe9410390196ba0185a7d900000000fd44010047304402202e119d14a6fd920d4444c6d73800609b8a8dfe48bc4c1fe0d2840fef40a26027022041d8f3ec7517b9773879eb5255ef30a457740fa2669f2b33d1c93c6e7894163a014730440220686531e7c640e62a860f499f9582ee72c8581b4827c0f05d9196d6b73722d56402200fa3b7132414092de23b1c7cf31874c21b7b5dea775ae677b8bd3ce5d0dca3830147304402205628c813b01bb0355309400c363c37aaa6d36d5ee6592a0793c77cfd32fd0f3d022017c68684a5748423129a60449344982b7e101aaf7882bf74958ef145631c682e014c695221023abd0b238c5e93e4d1d9f06e9d743941e5d3f23d0b5371a0f87ac56106373829210231e33da7f49dd067b556c04b07fc339b571f144bb8c51b3410e66b143b3e75202102b49c7c0f9d3026fdc3311c61bdb7b92d81ee1d4adf806e0fbfdfac5f5c9b9e7853aeffffffff01204e0000000000001976a9144c477bec69fa6f89d6effdc3b17ab53101c6fa1a88ac00000000

What's wrong with the transaction? I'll provide any additional information necessary.

I was sending an extra signature.
The transaction required 2-of-3, and I sent the 3 signatures. The extra signature was not popped off the stack by OP_CHECKMULTISIG, and the remaining stack looked like this:
EXTRA_SIGNATURE
OP_0 # null-dummy for Bitcoin Core's old bug

The extra signature took the place of the dummy, and bitcoind detected this when verifying the dummy was an OP_0.

RPC_VERIFY_REJECTED = -26, //! Transaction or block was rejected by network rules

Rule "prev_out" failed to validate:
Prev out d9a78501ba9601391094fe4a369ab8767822196561ceca3b64e446ea6785a085:0 not found.

Does that mean the output doesn't exist? I can see it here in test-insight: https://test-insight.bitpay.com/tx/d9a78501ba9601391094fe4a369ab8767822196561ceca3b64e446ea6785a085


text:
Bitcoin regtest mode block versions
I'm running a bitcoind instance in regtest mode, for automated testing purposes.
I'm having trouble with the fact that the blocks I mine are version 1 blocks, which lack the block height in the coinbase transaction (my code relied on that).
How do block versions work in regtest mode? Can I configure them? Do I need to mine a specific number of blocks?

BIP 34 (the BIP that specifies block version 2 and block heights in coinbases) is not activated on regtest and is never activated.

How do block versions work in regtest mode?

Block versions are actually version 0x20000000, not version 1. This version allows for other soft forks like BIPs 65 and 66 be activated. Some other forks (BIP16, CSV, and Segwit) are activated by default, and BIP 34 is disabled.

Can I configure them?

Yes, use the -blockversion command line option when starting bitcoind

Do I need to mine a specific number of blocks?

For BIP 34, no, you can't activate it without changing the software.


text:
Unconfirmed bitcoin transaction for more than 3 days
i sent bitcoins on 14.3.2016. the amount has been debited from my wallet but remains unconfirmed. i am waiting for the transaction to go through but maybe because i checked try and sent with 0 transaction fees the transaction is not being confirmed. i want to know how to get the bitcoins back and whether there is some way that a beginner like me can stop the unconfirmed transaction so that the coins are returned to my wallet.

You can't retract a transaction. If it fails, the Bitcoins will be credited back to your wallet since Bitcoins can't be lost.
Chances are high the the transaction will pass. Even with a fee of zero. I suppose you'll have to wait another 2-3 days.
I advise using Bitcoin-XT instead of Bitcoin-QT so we won't get insane transaction fee amounts and limited transaction volume per block in the future.

the transaction got confirmed today even though it had a 0 fee.

There is no chance you can stop transaction which already sent. You can only wait and yes.. your bitcoin will return into your wallet if transaction failed.
Failed can cause many things, one of that things is take too long to confirm and you can't send or asking people to help you without cost nothing :)


text:
Displaying the bitcoin wallet on the internet
I was wondering, is it a security risk if you display your bitcoin wallet on the internet? Let's say my bitcoin address is 123abc. This is linked to my wallet which stores several bitcoins. It is adviced to place the address 123abc openly on the internet? Or is it a security risk?

First, do not mix up the words "wallet" and "address".  A wallet is a file or computer program which stores the private keys corresponding to one or more Bitcoin addresses.  Sharing the address is very different from sharing the private keys.
Sharing the address is not a security risk, in the sense that knowing the address does not give anyone the ability to spend your bitcoins.  They would have to know the private key.  Indeed, since Bitcoin uses a public transaction register, you can assume everyone in the world already knows the address 123abc exists, and knows how many bitcoins are credited to that address.
However, sharing the address can be a privacy risk.  Everybody knows that the address 123abc exists; what they don't know is who it belongs to.  If you post the address on your personal website, or from an account that can be connected to you, now they do know that.
For instance, suppose you made a transaction from that address to an address that's known to belong to EmbarrassingSexToys.com.  The transaction is public, so everyone can see that it was made.  If you hadn't posted your address on the Internet, then everybody knows that somebody bought an embarrassing sex toy, but nobody knows who it was.  If you did post your address, then everyone knows that Adnan bought an embarrassing sex toy.

nice answer, also you can have a look at walletexplorer.com. It will show you addresses probably linked to your current address


text:
Altcoin WIF checksum check
In bitcoins, it is possible to check if a private key is valid using the WIF checksum.
Is this also the case for altcoins which use SHA256. And how about the ones that use another hashing algorithm?

How altcoin wallets import private keys is up to the specific altcoin, so I cannot provide a blanket answer for all of them.
However, I can tell you that this functionality is not determined by the hashing algorithm used for the altcoin's proof-of-work.  That is independent of the Wallet Import Format, which just so happens to use SHA256, and does not use SHA256 because that is what Bitcoin uses for proof-of-work.
My guess is that most altcoin's (but not all) support their own version of WIF, but with a couple of likely differences.
First, the altcoin may not use the same asymmetric cryptography for creating addresses, which means that private keys might not be the same length as they are in Bitcoin.  Since the private key is the input of WIF, this can have a consequence on the end result.
Second most altcoins will probably use a different network identifier that gets pre-pended to the private key in step 2.  Bitcoin's mainnet uses 0x80, but an altcoin could use whatever value the creator felt like.  Perhaps it was changed...perhaps is wasn't.
Other than that, I would guess that most Bitcoin-clone altcoins use the same process for importing private keys.  It is also possible that the checksum is created using a different hashing algorithm than SHA256, but that algorithm in no way has to correspond with the proof-of-work hashing algorithm of the altcoin.
Check the docs on the altcoin in question to find out for sure.


text:
Can I use Bitcoin to recieve funds from Egypt
I am owed about £7000 from a friend in Egypt but we are having a very difficult time transferring the money to my UK bank account, as the money is in UKP (sterling) WU and moneygram only accept USD, the banks want a government signed contract between us, and paypal is new in Egypt and will not accept debit cards or his new visa card so he cannot sign up to these services, so my question is, is bitcoin a way that we could transfer the funds directly to me and will I be able to convert the bitcoins to Sterling, and how much will this cost? many thanks to all that reply
Tony

I am from Egypt and banks in Egypt does not  require a signed contract.  I highly doubt that and sounds strange to me. Check the bank yourself or tell me its name to check for you. Also Paypal will not refuse debit or credit card. I was using an online visa card issued in Egypt with no problem at all with Paypal.
You can create a bitcoin address and sure your friend can convert the money in bitcoins and send to your address, latter you can change that to any currency you want.

Yes it is possible.
Steps.
1) Find a bitcoin seller in Egypt.
2) Buy Bitcoins in Egypt. Your Friend must provide a bitcoin address to receive the bitcoins.
3) You provide a bitcoin address to your friend where he sends the bitcoins.
4) You find someone willing to buy bitcoins with sterling in your location.
5) Sell your bitcoins and receive Sterling.
You both will need a bitcoin wallet. And a way to contact with a bitcoin seller/exchange.
You can do the exchange in person (ie, LocalBitcoins) or directly to your UK bank account using a service like Coinbase.


text:
How to copy wallet.dat from v0.10.2.0 to v0.11.0.
I am trying to import the balance from the older version to the newer one. I deleted the wallet.dat from the newer one and copied the older one into its place. However, the wallet will not start with the old wallet.dat. I get a small "error" msg box. When I click "ok" qt closes down.
Are the two wallets incompatible? If so, is there another way to import my balance to the new wallet?
Thanks

What does the error message box say?

Its a very small box that says "Bitcoin" in the title bar, then it has a red circle with a white x in the box with an "ok button underneath. When I click the "ok" button, qt shuts down. If I do nothing, qt freezes (behind the box) with "verifying wallet..." printed at the bottom.

Now I tried to importwallet from the console but got the following error: Cannot open wallet dump file (code -8)

The strange thing is that this wallet.dat that I can not open in another instance of qt, works just fine in the original qt client it came from.

As there was no response for this, and in case someone else has the same problem, I dumped the private keys, and then imported them to the other client.


text:
Pros & Cons of Using the "Satoshi" Method to Track User Deposits
In this question user @lungj suggests using "satoshi" as a marker for user deposits.

Another method I’ve seen used on bitcoin is using satoshis as a
marker. For example, when paying for a one bitcoin item, an additional
7 satoshi could be added to the amount due to distinguish from another
user asked to add 6 satoshi. Payments must be in exact amounts for
this to work (but you can always refund an incorrect payment, less
fees, to a sender). This does not scale all that well if your IDs must
be permanent. This avoids the need for users to interact with a
contract to include metadata.

This method basically allows all users of a service to deposit funds to the same Bitcoin address while allowing us to keep track of who deposited which funds.
Off hand I can think of two potential issues with this method:

If we reserve 1 Bitcoin address to 100 users, we are adding a minuscule amount of $$$ to each payment (between 1 - 10 cents if Bitcoin exchange rate = $100,000)
It only works when we know in advance how much the user intends to deposit (otherwise there's no way of calculating how much extra "satoshi" was added to a payment (so it won't work for general deposits)

What are some of the other pros and cons of using this protocol to keep track of user deposits? Are the issues above solvable?
Thanks

That's a question about Ethereum, a system that's notoriously difficult to accept payments with due to some incredibly bad design decisions. Ethereum has operational costs for making new addresses which make this sort of poor engineering attractive.
We have no need to do anything ridiculous like that to try to distinguish payments, we can just make a new address per payment and have people pay to it. There's no need to try to re-use addresses as there's no resource being consumed by you creating new ones. All this would serve to do is cause mass confusion, difficulty when people made two transactions to pay an invoice, and unmitigated confusion about who owns what payment if anything goes awry.
There is no pros at all to what you're describing.
One new address, per invoice, per user. There's no reason to over think it.

Thanks for your reply. I thought the reason to force everyone to send payment to one address is to save us from needing to consolidate (forward) all funds to a single "master" address (to make it easier to manage). On the other hand, since Bitcoin uses UTXO model, perhaps receiving all payments to the same address would be of no benefit as each transaction received (even to the same address) would still have a different UTXO. Thus, if I wanted to send one large payment from funds in the single Bitcoin address, it would still be necessary to consolidate everything again during off peak hours..

Why would you want to "consolidate" UTXOs, that's just adding extra cost and time for absolutely no purpose. Nobody does this because there's absolutely no reason to. Doing so would even make spending your money more difficult because you would even up making chains of transactions.

because the deposits are made by buyers and payments are made to vendors. Average deposit = 0.001 BTC (1/1,000 BTC) and average withdrawal by vendor = 0.1 (1/10th BTC). It means that when a vendor withdraws his funds we are forwarding on average 100 buyer deposits to the vendor which means 100 transaction fees.. If we don't consolidate during "off peak" hours the fees to send funds to vendor are going to be astronomical..

There’s no difference. You have to consolidate them at some point, doing it before sending it to its destination doesn’t really solve any problem. The sizes of the transactions will even be larger if you do it ahead of time.

https://bitcoinops.org/en/xapo-utxo-consolidation/

@S.O.S paying repeatedly to one address is no different than paying to new addresses each time in terms of UTXO consolidation costs. Using a single address is a bad idea.

@S.O.S It sounds like your confusion stems from thinking that consolidation has something to do with addresses - it does not. If you have N incoming payments, you have N UTXOs, regardless of whether they're sent to distinct addresses or the same address. Consolidation combines them into a single UTXO, again regardless of whether what was consolidated was sent to distinct addresses or not. Addresses and how funds are sent/assigned to them is completely independent of transaction costs.

Answer up-voted and accepted! Thanks to @PieterWuille and @_Pseudonymous for clarifying the subject. It's a bit counterintuitive but I think it all makes sense now..


text:
Zero Hashes Per Second with Diablo-D3 Miner
I'm trying to setup Diablo-D3 Miner on my computer (I'm aware that there are other solutions available, but I need something written in Java for a personal project) and I see in console I'm getting zero hashes:
mh: 0.0/0.0 | a/r/hwe: 0/0/0 | gh: 0.0 0.0 | fps: Infinity

Why is my hash rate zero when I have NVIDIA CUDA OpenCL 1.2 CUDA 9.1.75 and   GeForce GTX 960M installed on my system and it's being detected by Diablo?
Thanks in advance.