text:
Bitcoin Core RPC server not working
I have downloaded and installed and got up and running a bitcoin core node, and it is running fine as far as people are connecting to it on port 8333 just fine.  However I can't seem to connect to it myself on the same machine using python bitcoinrpc library...
My .conf files looks like...
port=8333
timeout=10000
printtoconsole=1
chain=main
rpcuser=one
rpcport=8334
#rpcauth=one:xxxxxx
server=1
coinstatsindex=1
daemon=1
txindex=1

and my python app..
from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException

# rpc_user and rpc_password are set in the bitcoin.conf file
rpc_user = "one"
rpc_password = "two"
rpc_connection = AuthServiceProxy("http://%s:%s@127.0.0.1:8334"%("one","two"))

best_block_hash = rpc_connection.getbestblockhash()

And when it runs it fails on line
best_block_hash = rpc_connection.getbestblockhash()

with the following error...
Traceback (most recent call last):
  File ".\bitcoin104.py", line 10, in <module>
    best_block_hash = rpc_connection.getbestblockhash()
  File "D:\PROJECTS\python38_env_bitcoin\.venv\lib\site-packages\bitcoinrpc\authproxy.py", line 139, in __call__
    response = self._get_response()
  File "D:\PROJECTS\python38_env_bitcoin\.venv\lib\site-packages\bitcoinrpc\authproxy.py", line 179, in _get_response
    http_response = self.__conn.getresponse()
  File "c:\users\hanso\appdata\local\programs\python\python38\lib\http\client.py", line 1344, in getresponse
    response.begin()
  File "c:\users\hanso\appdata\local\programs\python\python38\lib\http\client.py", line 307, in begin
    version, status, reason = self._read_status()
  File "c:\users\hanso\appdata\local\programs\python\python38\lib\http\client.py", line 276, in _read_status
    raise RemoteDisconnected("Remote end closed connection without"
http.client.RemoteDisconnected: Remote end closed connection without response

I have checked all my ports, and I am certain they are working, they work through telnet, the netstat -a shows the ports are listening when i open the bitcoin core node, and when i try a different port I get a different error complaining about host connection was refused. So I am 99% certain the port forwarding and firewall is open to the desired ports.  Port 8333 for outside connections shows a log of people connecting to the server. So I am almost certain it is not the machine, firewall, or router not allowing connections through the port.
That leaves either something I am setting up wrong with the password.  I changed the setup to use a simple one, two useid and password for testing, and so I can post here to show exactly what I am doing word for word in the conf and the python script.
I am really pounding my head against the wall.. Is it possible something to do with rpcauth... i tried running that and creating a hash and then tried to use that as a replacement in my http://pass:key@127.0.0,1:8334 connection. But it doesnt' seem to work either.  But funny enough when I type the clearly wrong password in i get the same error I am getting now.  But if I change say the ip address then it fails up on the AuthServiceProxy creation line instead. And the issue says that the machine host refused connection. So all this points to the node node liking my userid and/or password but I can't find any examples to know for sure I am setting these up correctly for the node in the .conf file before launching node, or if i am doing something wrong in the python script?

Is the rpcauth line actually commented out in your bitcoin.conf?

yea, I wasn't quite sure if I needed it. I tried using it, but i am not sure exactly then what i use in the python call ie what goes in the AuthServiceProxy() initialization function?
I ran the app include in bitcoin core to get that number, but I wasn't sure how I am suppose to use it.  So I commented it out after using it and it didn't work.  And went back to what i have seen in the very few case examples I could find, which didn't seem to include it..

In your bitcoin.conf file, there should be, uncommented an rpcuser= and rpcpassword= pair of lines. Alternatively, you can have an rpcauth= line which specifies username and password together, salted (for more info see https://github.com/jlopp/bitcoin-core-rpc-auth-generator). But if you don't have either one or the other, then you haven't really specified a username and password pair, so you can't authenticate.

@alexg I definitely had both the rpcpassword and rpcuser, as well as tried the rcpauth method as well, Neither worked... but it seems to at least be partially working as when I change it, it get a different error, indicating it seems to be picking it up?
Could it be the issue is sending the message back?

@TheJourney Without knowing what the new error is, it's hard to tell... In any case, if you are using rpcuser= and rpcpassword= instead of rpcauth= then your password cannot contain the equals sign (=). If you are using rpcauth then the password can contain any character because it's encoded.


text:
AML laws seem to be very erratically enforced
It seems that only MtGox actually enforces them.  Are they now a PSP or bank?
MtGox says the reason they prohibit wallet-to-wallet bitcoin transfers (yes, they are prohibiting for unverified accounts now - even if you put your coins in there long ago) is because of the AML laws... yet, no other wallet site (that I know of or use) has this restriction, as they all allow me to transfer bitcoins to another address without the need to verification.
So, either MtGox is making up it's own AML rules, or none of the other sites, like Blockchain, for example, are following them.
Does any know what the real deal is with these AML laws?  it is all kept very secret.  In fact, the AML laws require that the exchange NOT notify the users in advance before the exchange put in place any new restrictions or limits...but only AFTER they are in place.
The real question is... where can I read the AML laws, specifically on how they apply to bitcoins? (although I still find it hard to believe they even Do apply for wallet-to-wallet transaction... but that is what I am told by MtGox)

source: Stack Exchange

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

sort: votes


text:
How would I be able to show 24 open, high & low on my site made with php
I'm a self thought designer/developer that knows basic photoshp/css3/html5 and a little python/php. I have never used an API to fetch  stats, so can you please point me in the right direction?
I would love to show the 24 hr open, high & low price of BTC on my php site, here is the api reference: https://docs.gdax.com/?php#get-historic-rates
Could any of you make a .php file with the necessary code for me? It would be such a great help.
I got this code to get started:
<?php

// get the HTTP method, path and body of the request
$method = $_SERVER['REQUEST_METHOD'];
$request = explode('/', trim($_SERVER['PATH_INFO'],'/'));
$input = json_decode(file_get_contents('php://input'),true);

// connect to the mysql database
$link = mysqli_connect('localhost', 'user', 'pass', 'dbname');
mysqli_set_charset($link,'utf8');

// retrieve the table and key from the path
$table = preg_replace('/[^a-z0-9_]+/i','',array_shift($request));
$key = array_shift($request)+0;

// escape the columns and values from the input object
$columns = preg_replace('/[^a-z0-9_]+/i','',array_keys($input));
$values = array_map(function ($value) use ($link) {
  if ($value===null) return null;
  return mysqli_real_escape_string($link,(string)$value);
},array_values($input));

// build the SET part of the SQL command
$set = '';
for ($i=0;$i<count($columns);$i++) {
  $set.=($i>0?',':'').'`'.$columns[$i].'`=';
  $set.=($values[$i]===null?'NULL':'"'.$values[$i].'"');
}

// create SQL based on HTTP method
switch ($method) {
  case 'GET':
    $sql = "select * from `$table`".($key?" WHERE id=$key":''); break;
  case 'PUT':
    $sql = "update `$table` set $set where id=$key"; break;
  case 'POST':
    $sql = "insert into `$table` set $set"; break;
  case 'DELETE':
    $sql = "delete `$table` where id=$key"; break;
}

// excecute SQL statement
$result = mysqli_query($link,$sql);

// die if SQL statement failed
if (!$result) {
  http_response_code(404);
  die(mysqli_error());
}

// print results, insert id or affected row count
if ($method == 'GET') {
  if (!$key) echo '[';
  for ($i=0;$i<mysqli_num_rows($result);$i++) {
    echo ($i>0?',':'').json_encode(mysqli_fetch_object($result));
  }
  if (!$key) echo ']';
} elseif ($method == 'POST') {
  echo mysqli_insert_id($link);
} else {
  echo mysqli_affected_rows($link);
}

// close mysql connection
mysqli_close($link);

Thanks!

A lot of the code you are sharing is unnecessary and unrelated to working with APIs in PHP.
It's 3 basic steps. Define the URL of the API endpoint you want, fetch that URL in PHP, return the values to your page.
Here's a simple example:
<?php
//define API endpoint
$url = "https://api.gdax.com/products/BTC-USD/stats";

//fetch the url and convert the JSON into an associative array
$fgc = json_decode(file_get_contents($url), true);

//assign values to variables
$open = $fgc["open"];
$high = $fgc["high"];
$low = $fgc["low"];
$close = $fgc["close"];
?>

My Website

Bitcoin 24 HR stats

Open: $<?php echo $open; ?>

High: $<?php echo $high; ?>

Low: $<?php echo $low; ?>

Close: $<?php echo $close; ?>

You're amazing, thank you so much! It looks so hard when you don't know where to start, but once you get a little help, it can get you moving greatly

But what if the link shows you data like this? https://api.coinmarketcap.com/v2/ticker/1/
Something should be added to the code for me to use 'rank' etc. right? @m1xolyd1an

If something is nested you have to call it's parent first. For rank you would use $fgc["data"]["rank"] or if you wanted price you would use $fgc["data"]["quotes"]["USD"]["price"]

Makes sense! Thanks so much dude, you're amazing <3

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:
Blockchain Recent Scaling Proposals : (Sharding, blocksize , SegWit, GHOST, Lightning, multichains, sidechains, DAGs)
What are some recent scaling proposals worth note? (Continually Updated)

SIDECHAIN

Peg communicates between sidechain & BC and is the mechanism for exchange rate between assets. It is possible for assets can be imported from and to other chains. Allowed to use in side chain and transfer back and forth between chains
They require mining, reward could be TX fee or coins, many possible implementations, Raiden/Lighting are just payment channels, not sidechains
After successful transaction, the coin signifying transfer between chains will be destroyed. The actual coin is not actually transferred, but locked on mainchain while equiv coins created on sidechain. To go back to original coin, must place back into secondary wallet to get primary unlocked.
A 2 way peg exchanges the same coin, removing the need for altcoins. Side Chains can replace altcoin necessity, also possible to remove/create at will
A downside is it creates centralized access, trusted 3rd party : NOT GOOD
Benefit of sidechains are they enable developers to safely develop new applications without a risk.

Major usage of the:
SPV proof : A mathematical proof providing a way where you can determine that a particular transaction was in a block in the block chain without requiring the entire block chain to be downloaded.
Keywords:

Confirmation period - lock duration in parent chain before transfer allowed
Contest period- time after send to wait before coin can be used

Notes I have from a Berkeley Deep Dive:
Lightning Network

Only have net payments on chain and all incremental payments are kept in channels. Relationships are critical to LN, overhead expensive to keep setting up TX ntwrks. Trust is the only thing needed to fund transactions. Need a liquid network: Both sides offer deposit, which limits how other people can use it.
Possible because not all transactions are random transactions, recurrence paying friends ie the same person. It is not feasible to connect all nodes, must have some reused payments.
Incentive to send transaction is to get their own transaction processed. Transaction fees are arbitrary, not determined how much yet.
Low cost path be reused to make large transaction if same chain is used in both directions
Paiwise Channels - Between 2 players
Funding Transaction: Initializes channel w certain amount of bitcoin from each party
Hashed Timelock Contract
Provide preimage of contract hash to redeem payment else receiver can withdraw funds. Timelock created through changing sequence numbers.

Example:
Open fund, close fund are only blocks to add on chain, anchors the transaction into the chain
To redeem deposit, network must be closed. Also there is a temporary key swap for each transaction, not private key. Unique key for each transaction, created just for commitment transaction.
Error Handling:
Payment Malfunction
If payment not redeemed, sender gets their money back after time expires
TX’s exist on BC layer, no actual contracts made
Cost is transaction fees and time spent. If LN fails, Blockchain does not fails as well but deposits may be lost


text:
mSigna: Signed, send, but 0 confs despite high fee (0.001 BTC)
Tried to send my first tx from mSigna today. Receiving was painless, but the send does not get included into a block since half a day, and dozens of blocks passed.
I unlocked the account, created the tx, signed and sent it. The confirmation count for my receiving tx still rises (as more blocks arrive), but the one for the sending tx stays 0. Sounds like enough support to me...
I feel I am missing important information, like I need to do some step in addition?
The only calculation for the fees I found is at bitcoinfees, but it's based on average tx size. It currently recommends 0.0002712 BTC, which is well below the fee I payed.
blockchain.info says "Transaction not found". Looking at the adress at blockchain.info, it says "0 transactions".
I'm running mSigna 0.10.6 with Bitcoin Core QT 0.14.2 (64bit) locally.
EDIT: As I read somewhere that transactions based on unconfirmed payments take longer than usual, I wanted to add that my receiving transaction is shown with over 6000 confirmations (again up from yesterday).

You can use another wallet to test your network. Don't worry about the fee, it's enough. Mostly one tx will be confirm in 2 hours.

Thanks, jinsong. I am wondering what you mean be "test my network". Surely, the continuous arrival of confirmations for the receiveing tx (both at Bitcoin core and at mSigna) shows that my connection to the bitcoin nodes is good? Why would blocks come in, but no tx go out?

Maybe we can change the network setting to another Host and Port for a test? You can find a node here, let's find out the problem together.

change the network setting of mSigna to another Host and Port, if you use Mac client, the setting options is in the Preferences Menu.

mSigna cannot connect to a few items on the list (I tried 10 items now). Error messages differ (German, so I'll translate): The target refused the connection; the target did not react properly; Network timed out; connection was terminated by local system. What I find suspicious is that the list stops with "last connected" 2017-08-24 17:44:34, which is roughly one month ago...

try 116.62.112.81 in Beijing of China and this 109.206.177.21 in EU, I've done a test with them on my own mSigna client and the state is connecting. My location is China, so you can try more different IPs.

If you use mSigna as well, maybe you know the meaning of the different patterns in the row background? The receiving transaction has a slightly dotted background, the sending transaction has a slightly darker background.

Also, I asked with the mSigna company about community or other forms of support, and they asked back whether I would be willing to organize a community...

Just tried the EU IP you sent. mSigna sync'ed the newest 50 blocks with this IP; the old receiving tx got a few more confirmations, but the new sending tx still is at 0 confirmations. Clicking "Transaction Signatures" (which is as far as I can get to a display of details, I think) shows a hash, the statement "Transaction is signed", and one row listing my keychain (with a closed lock symbol).

A few blocks have now arrived over the Bejing IP you sent. Same results as before, still 0 confirmations. I tried the "Resend Transaction" function, which only shows a dialog "Transaction has already been sent".

When the transaction has already been sent, just wait the miners to include your tx in a block for one confirmation. At the same time, you can check your tx on blockchain.info to check whether this tx has been broadcasted to the bitcoin network successfully.Now you can do another test, change your host and port to localhost, and send some bitcoin, then close the client and resent again to get the alert information. And then compare the new alert information to the one which is 'Transaction has already been sent' to see that whether there have some different and let me know.

Maybe the problem is that the local chain data has not sync completely. When the full node has not sync data completely, it will not broadcast any tx before that because it can't check whether the tx meets all the tx rules. Check it, good luck.

Jinsong, nothing has changed regarding the state of my tx: It is still not listed at blockchain.info ("Transaction not found"). My local Bitcoin Qt has received the latest block as listed on blockchain.info, and mSigna also shows this block number twice in the status bar. Still, no confirmations. The dialog I get when I click "Resend transaction" is the same regardless of the node I connect to - "Error: Transaction already sent".

By the tests we have done, we knew that the problem is caused by broadcast step and sometimes the tx could be broadcasted successful and whether tx has been send or not that is not beyond on tx had been broadcasted to the bitcoin network or no when using mSigna. So I suggest three other kinds of test:1.Change your wallet to another. 2.  Change your Internet connection, maybe use mobile Hotspot for a little while to test. 3. When using mSigna, after create a tx, change the ip and port to see if it will be broadcasted successfully like the one you have done about EU IP.

The purpose of doing so is to check why the tx can't be broadcasted to the network, maybe the Internet nor the mSigna client. I knew you use Bitcoin QT, so you can create a tx test by this client too.


text:
How can a hacker steal the funds received in the future when there is only an xpub on the server?
In book titled "Mastering bitcoin" 3th edition, on page 114, there is a sentence as below.
Gabriel’s website does not contain any private keys and therefore any hack of it can only steal the funds Gabriel would have received in the future, not any funds he received in the past.
I think hacker can not steal the funds received in the past and the future.
thanks！

For websites selling goods for bitcoin it is a common practice to use xPub to derive a new address for each customer. This has two benefits 1) using a fresh address protects the merchants privacy as tracking the funds is harder and 2) handling orders becomes much easier as each individual order has the bitcoin address as a unique identifier.
It is true that even if the xPub gets leaked, the hacker wont be able to use any of the funds. But he will be able to see past and future generated addresses and can monitor any and all traffic in the wallet.
If the website gets hacked there are ways for the hacker to steal bitcoin intended for the merchant. For example the hacker might change the website's xPub to his own, so all of the future transactions end up in the hackers wallet instead of the merchants. What the book is pointing out is that in a case of a hack, using the xPub it is impossible to steal any bitcoins that were sent before the hack.

I also think your last paragraph is a possible interpretation of the quote. Just a note though, an exposed xpub plus any single private key can be used to obtain all private keys of that xpub

From a technical perspective, that statement is wrong. Obtaining the xpub alone is merely exposing all public keys, both past and future. However, as stated here, if an attacker could also obtain any single private key derived from that non-hardened path, they can obtain all other private keys associated with that xpub!
My guess however is that the quote actually means the possibility of a hacker swapping Gabriel's xpub with their own without anyone noticing for a while, thus getting paid in Gabriel's stead (as Juha also noted in their answer)

Thanks all! From a technical perspective, i also think this statement is wrong.

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


text:
Call function for block n on blockchain
I've been going through main.cpp in order to roughly find out which function calls the best block and I found out depending on situation there are several similar-sounding function names and code extracts that I suspect of calling the best block.
Here's my list:

CBlockIndex *pindexBestKnownBlock
uint256 CCoinsView::GetBestBlock () const
CBlockIndex* pindexBestHeader
CBlockIndex* pindexBestForkTip
pindexBestInvalid
// move best block pointer to prevout block
view.SetBestBlock(pindex->pprev->GetBlockHash());
chainActive.Tip()->GetBlockHash().ToString()

Now my question: Which one of the list items above can I use and modify in a way that calls a block that is n blocks deeper than the best block on the same blockchain?

The chainActive variable stores the best known block chain. But this is essentially just the chain of block headers, not the actual blocks themselves. To load the actual block from disk, use the ReadBlockFromDisk() function. But, be aware that this is an expensive function to use, it does not return immediately.
chainActive[0] or chainActive.Genesis() [1]
Gives the genesis block header.
chainActive[chainActive.Height()] or chainActive.Tip() [2]
Gives the header for the most recent block in the active chain.
chainActive[chainActive.Height()-10]

Gives the block header for the block with 10 blocks built on top of it.
Use any of these CBlockIndex pointers as below to get the block.
CBlock block;
if (ReadBlockFromDisk(block, pindex)) {
    // do something
}

Thanks! Does ReadBlockFromDisc() access blk?????.dat? Is there any software or app for opening and reading blk?????.dat?

I believe it does access the blk___.dat files. Those files just contain raw concatenated block bytes, so you would probably need a blockchain parser to access those. What exactly are you trying to do? I might be able to point you at a good tool for the job.

I'm going to simulate and analyse outcome of a "block mining race". I want to make a rebuild of bitcoin-0.10.0 with modified code that prescribes selfish mining algorithm. For this part I got the hint that bitcoin code must work with a pointer (speaking on processor level) that is shifted back and forth according to the state of a node. And here I want to implement the selfish behaviour: modified code shall "point to blocks" according to the algorithm of the attack. With the idea of a pointer I hope to be able to "hide" blocks - this would mean a backshifted pointer to a publicly known block.

For the simulation, for example I'm planning to run 1 selfish node (modified node) alongside with 4 other honest nodes (original code), fork the blockchain and start mining on both branches.

In that case, what you probably need to do is make a new set of parameters in one of the chainparams files, and program your node to selfish mine when it is started with some flag. This doesn't require digging into the blk___.dat files at all, mainly some modification of what/when things are shared in main.cpp. Then start up the various nodes, connect them to each other, and have them all mine. If the selfish one gains more coins in the long run, then the strategy is working.

Thanks a lot! Can you maybe give me a good source where I can read about what each chainparams file does or do you recommend to go through the files and just try to understand? Unfortunately, I'm very new to C++ but I'm eager to learn new stuff. Is there a good approach for getting a rough idea what those chainparams files do? (I hope I'm speaking of same files as you: chainparams.cpp, chainparamsbase.cpp,  chainparamsseeds.h etc.)

I think the code is pretty much the best documentation at this point. Just read main.cpp, chainparams.cpp, and chainparamsbase.cpp. Look up code elements that you're not sure about to see their documentation (e.g. std::vector or std::map, or anything related to boost). Best of luck!

Thanks for the review! Could you please explain why chainActive[] works with genesis block but not with any other block? Is it because a block can have multiple valid "twins"?

@AliakbarAhmadi The operator chainActive[] may be confusing to people without intimate C++ knowledege, so I left that part out of the suggested edits. But in general, 'twins', as you say, are not an issue because the chainActive only has the headers of the main chain in it.


text:
Bitcoin Core stalled peer logic during initial block download
I'm trying to track down the cause of unexpected (20% to 85%) IBD slowdowns between my 2020 and 2021 annual performance tests.
I experienced this slowdown with multiple implementations, so I don't think the issue is Bitcoin Core specific, though I do want to understand one potential cause with regard to how Bitcoin Core handles stalled peers.
Several developers have told me that if a peer doesn't respond to a request for a block, a Bitcoin Core node will disconnect from it after 15 minutes. I see here that @pieter-wuille said something similar on a related question.
However, when I look at the "stalled block download" logic in Bitcoin Core it seems to be using a timeout of only 2 seconds.
I have several full debug logs from different syncs I ran and from looking at the logs, these stalled peers appear to get disconnected after 2 seconds; even the ones that are serving headers rather than blocks. Example log:
2021-10-28T13:00:43Z New outbound peer connected: version: 70016, blocks=707043, peer=9 (outbound-full-relay)
2021-10-28T13:00:45Z Ignoring getheaders from peer=9 because node is in initial block download
2021-10-28T13:00:48Z more getheaders (338000) to end to peer=9 (startheight:707043)
2021-10-28T13:00:48Z Protecting outbound peer=9 from eviction
2021-10-28T13:00:50Z more getheaders (340000) to end to peer=9 (startheight:707043)
2021-10-28T13:00:52Z more getheaders (368000) to end to peer=9 (startheight:707043)
2021-10-28T13:00:53Z more getheaders (342000) to end to peer=9 (startheight:707043)
2021-10-28T13:00:54Z more getheaders (370000) to end to peer=9 (startheight:707043)
2021-10-28T13:00:56Z more getheaders (344000) to end to peer=9 (startheight:707043)
2021-10-28T13:00:59Z more getheaders (372000) to end to peer=9 (startheight:707043)
2021-10-28T13:01:00Z more getheaders (346000) to end to peer=9 (startheight:707043)
2021-10-28T13:01:02Z more getheaders (374000) to end to peer=9 (startheight:707043)
2021-10-28T13:01:03Z more getheaders (348000) to end to peer=9 (startheight:707043)
2021-10-28T13:01:04Z more getheaders (437999) to end to peer=9 (startheight:707043)
2021-10-28T13:01:07Z more getheaders (376000) to end to peer=9 (startheight:707043)
2021-10-28T13:01:09Z more getheaders (350000) to end to peer=9 (startheight:707043)
2021-10-28T13:01:11Z more getheaders (439999) to end to peer=9 (startheight:707043)
2021-10-28T13:01:14Z more getheaders (378000) to end to peer=9 (startheight:707043)
2021-10-28T13:01:16Z more getheaders (352000) to end to peer=9 (startheight:707043)
2021-10-28T13:01:18Z more getheaders (489999) to end to peer=9 (startheight:707043)
2021-10-28T13:01:19Z more getheaders (441999) to end to peer=9 (startheight:707043)
2021-10-28T13:01:20Z more getheaders (380000) to end to peer=9 (startheight:707043)
2021-10-28T13:01:22Z more getheaders (354000) to end to peer=9 (startheight:707043)
2021-10-28T13:01:23Z initial getheaders (707100) to peer=9 (startheight:707043)
2021-10-28T13:01:24Z more getheaders (491999) to end to peer=9 (startheight:707043)
2021-10-28T13:01:25Z more getheaders (443999) to end to peer=9 (startheight:707043)
2021-10-28T13:01:26Z Peer=9 is stalling block download, disconnecting

In short, I'm trying to better understand what the worst case scenario of slow / malicious peers could be with regard to impacting IBD performance and how I might diagnose which peers are causing the sync slowdown.

During IBD, there is a "moving window" of 1024 blocks ahead from the current height, from which blocks can be requested from peers for parallel download. When a peer has an open slot for a block request (there is a maximum of 16 blocks assigned to a peer at a time), it is requested to provide a block from this window.
A stalling situation occurs, when there is no such block available to assign to a peer, because all blocks from the current moving window have either been already downloaded or are "in flight", i.e. have been requested but not received. This can happen if some peer sends blocks too slowly or not at all.
In this case the "stalling" peer is determined - the peer that was asked to provide the block that would help us extend our current tip / move the window forward, but hasn't delivered. This peer gets an additional period of 2 seconds (BLOCK_STALLING_TIMEOUT), and if it fails to provide a block, it will get disconnected for stalling and the "bottleneck" block that prevents the window from moving will be requested from another peer.
[Edit]: The requested blocks of the 1024 block window are usually distributed over 10 outbound peers (among them 2 block-relay-only peers) as per the current default. (Blocks aren't requested from inbound peer while in IBD as long as outbound peers exist, although there is currently a proposal to soften this rule: Bitcoin#24171.) This means that a given peer must be considerable slower compared to other peers for a stalling situation to occur.


text:
bitcoin-cli remove an account
How i can remove an account created on my server?
coincoin@localhost:~# bitcoin-cli listaccounts
{
  "": 0.00000000,
  "first": 0.00000000,
  "perso": 0.00000000
}

I juste want to delete "first" account

I don't think there's currently a way. I looked at all of the account-related rpc calls, and setaccount can change the account of an address. However, that doesn't delete the account once all of them are gone.

@NickODell ah! At least, the things are clear! Thank you for the information

Also the accounts feature is deprecated https://github.com/bitcoin-dot-org/bitcoin.org/issues/1287


text:
Do Bech32 transactions map to 1-prefixed-addresses?
I recently installed Bitcoin Core and let it synchronize just to play around with different buttons in the latest version and see if I still understand it.
One thing I noticed are the Bech32 addresses, which seem to be the main (only?) way of receiving money in latest Bitcoin Core. I think I understood the implications of transactions happening over 1-prefixed-addresses, but the new system got me wondering:

if someone sent me some money to my bech32 address, would it end up in one of the 1-prefixed-addresses as well, or should I think of them as of completely separate systems?
if not, does a wallet backed up before the transaction took place contain that transaction in it (I think it would if it was a 1-prefixed address).

No. Since these addresses refer to different output types, they are not interchangeable.
Addresses are shorthand to describe output scripts. Addresses starting with 1… describe Pay to Public Key Hash (P2PKH) outputs, while bech32(m) addresses starting with bc1… describe native segwit outputs (Pay to Witness Public Key Hash (P2WPKH), Pay to Witness Script Hash (P2WSH), and Pay to Taproot (P2TR)). While they all use private keys from the secp256k1 elliptic curve as the underlying secret, they use the keys differently in their locking mechanisms.
Wallets backed up before a transaction took place will never know about that transaction, but they will be able to discover any relevant transactions when they get reconnected to the network and hear about new blocks. Generally, wallets store private keys, and it is possible to derive all output scripts corresponding to the different types from these keys.
Generally, you should not need to worry about how a native segwit address and legacy address are related. Today, almost everyone should be able to send to native segwit addresses. If the sender that's trying to pay you cannot send to bech32 addresses, you should be able to generate a legacy addresses from Bitcoin Core either via the command line or the GUI.

Bech32 addresses cover a completely distinct set of outputs, compared to 1... addresses, or 3... addresses

Base58 v0 (1...) addresses: pay-to-pubkey-hash (P2PKH) outputs (included in Bitcoin's first release).
Base58 v5 (3...) addresses: pay-to-script-hash (P2SH) outputs (defined in BIP13 and BIP16).
Bech32 v0 (bc1q...) addresses: pay-to-witness-pubkey-hash (P2WPKH) and pay-to-witness-script-hash (P2WSH) outputs (defined in BIP173 and BIP141).
Bech32m v1-... (bc1...) addresses: all other pay-to-witness outputs (only pay-to-taproot - P2TR - for now) (defined in BIP350 and BIP341).

Each of these cover non-overlapping sets of outputs, by design, so there is never more than one address for a particular output. Your wallet decides what type of address to construct (possibly depending in configuration settings, wallet type, ...), you give that address to the payer, and they have to send to the single output corresponding to that address. Sending to anything else will not be considered a valid payment by you, the receiver.
I don't understand your question about the backup. Clearly a backup cannot contain anything that's only created/received after the backup was made.


text:
How much would you need to remember to store bitcoins in your head?
Suppose I had a gigantic sum of bitcoins and wanted to store them in my brain's memory instead of any physical form. How much data would I need to be able to remember? I understand I'd have to transfer it all to one address - would I need to remember both its private and public key, or can the public one be calculated based on the private key?

This is called a brain wallet. You need to remember only the generator for the private key, which can be anything you choose. You just have to remember something (anything) that is complicated enough that other people could not guess it, even if given trillions of guesses.
This is actually surprisingly complicated. If you write the passphrase down, it's not really a brain wallet anymore. If you don't, and you forget any bit of it and cannot precisely remember it, your funds are lost. If you make it simple enough to ensure you can remember it, the risk that someone else will find it is high. Lastly, the tools you use to convert the passphrase to a Bitcoin address can be flawed or sabotaged.

I'd like to stress the importance of the risk that someone else can find it. As opposed to normal password-guesses, where you are rate-limited or shut out after some failed tries, here you are exposing yourself to an unlimited attack by the whole world, forever. If you didn't generate the passphrase by a computer or dice, it's probably not random enough (even though it is long, and looks non-random).

What if I decide to just remember a random key? Wouldn't that theoretically be as secure as storing the key on the HDD?

@d33tah So long as the key had at least 70 bits of equivalent entropy, you should be okay. But it's pretty hard to remember 13 random characters. Give it a try -- yXi2ano5SXJ8D.

I think that if you store a million dollars there, you have quite a good incentive.


text:
Buying Bitcoins without identity checks?
Are there any exchanges that offer Bitcoins without identity checks? I would like to remain anonymous while buying the currency.

I'd prefer an exchange that would accept international bank transfers without identity checks.

Might exist, but most of these offers will likely be scams. Also keep in mind that this doesn't provide full anonymity, they will still keep the data that shows where the money came from.

LocalBitcoins provides

In-person cash trades - can be done complete anonymous. Check "Buy bitcoins with cash" on the site.
Cash deposits - depending on the bank and the country you may be do cash deposit anonymously


text:
Could Bitcoin be implemented without saving the block chain on the HDD?
Is the Bitcoin's copy of the block chain completely necessary? Couldn't we just store the current balances of all addresses, without keeping logs of their transactions as well?

Yes this is called an SPV client.  See this question here for detailed explanation of how SPV works.  There are several of these today, most mobile wallets and the multibit wallet use SPV technology.

No, you can't. When a transaction refers to an unspent output, it refers to it by transaction ID and output number, not by address. So knowing that a particular address has a particular balance is not what you need to validate transactions. If you can't validate transactions, you can't validate blocks. If you can't validate blocks, you can't really do much of anything except trust some other server to do the real work for you.
Ripple implements accounts with balances instead of unspent outputs precisely to avoid this.

It's entirely possible for a node to store only the balances (Actually the UTXO, but it's conceptually similar). This is called blockchain pruning, and IIRC has been on the wishlist for a while.
The biggest problem is that to bootstrap a full node, it can't just take your word for what the set of balances should be, it needs proof. That proof is the full blockchain.
So even if 99% of nodes switch over to keeping pruned versions of the blockchain, we'll need a few that archive everything, so new full nodes can convince themselves of the correctness of the balances.

To answer your question completely:

It is possible to implement a Bitcoin client without the whole blockchain. In fact, many exist, including Electrum, MultiBit, Mycelium, etc.
However, it is not possible to implement the entire Bitcoin network without a full blockchain, unless you want to create a fundamentally new technology. Bitcoin thrives on the blockchain; it is what allows it to maintain a decentralized ledger. If no one kept track of transactions before block 200,000, you'd have to trust that whoever is maintaining the balances at that block 200,000 isn't making up numbers.


text:
How are Namecoins managed by the system?
First of all, sorry for a potentially silly question, but I flicked through seven pages of questions here and I couldn't find a specific answer for that:
How does Namecoin basically work? I understand the basic principles of Bitcoin and heard these are the same in Namecoin - you mine coins, get a reward, which gradually decreases. But in Namecoin, the coins are also deleted, aren't they? Doesn't it mean that we will eventually run out of the supply of Namecoins?

First, I'd like to note that Namecoin and Bitcoin are separate - they share a lot of code, but they have different blockchains and networks.
Let me talk about the problem that Bitcoin solves: double spending. It solves this by having nodes vote with their hashpower on what they think the most accurate picture of the network is. This creates an ordered list of transactions.

How does Namecoin basically work?

It turns out that having an ordered list of transactions is exactly the sort of thing you need to create a naming system that provides all three elements of Zooko's triangle

Secure
Memorable
Decentralized

Registering a domain looks like this:

You publish a transaction that says, "You can find mysite.bit at 23.12.34.67"
Other nodes include that into a block.

It's about as difficult to steal your domain name when it has X confirmations as it is to double spend a transaction which has X confirmations.

Doesn't it mean that we will eventually run out of the supply of Namecoins?

That's true, but the supply of nice sounding memorable domain names is so small that it makes sense for there to be a cost to registering domain names en masse.


text:
Unconfirmed Bitcoin Transaction for more than 7 Days
I initiated a Bitcoin transaction from Bitcoin Core to another wallet, and it has remained unconfirmed for more than 7 days. I suspect this is due to the very low transaction fee I set. During the transfer, I selected the option for a 7-day target confirmation time (1008 blocks) with the wallet’s suggested minimum fee. Previously, payments with this setting processed without issues.
How can I cancel the transaction and return the bitcoins to my wallet? To clarify, the transaction is still unconfirmed, with no blocks verified under the hash identifier.
P.S. I am aware of functions to increase the transaction fee to make it more noticeable to miners, but this is no longer relevant for me. I simply want the transaction to be canceled and the coins returned to my wallet.
Thank you.


text:
Can Bitcoin incorporate the scripting protocols of Ethereum without a fork?
I am curious if the Bitcoin protocol can incorporate Turing complete scripting capabilities without forking the block chain. I ask this because I understand the ability to create contracts digitally is as significant an development as bitcoin.
I am trying to judge the efficacy of new altcoins like Ethereum to assess the future viability of Bitcoin.
Thanks for your comments!  Also if you are curious as to why I think contracts are so important here is my blog about why contracts are important.
Peer to Peer Government: Guarding the Guardians
http://statisticaleconomics.org/2014/01/10/peer-to-peer-government-guarding-the-guardians/

Ethereum is not an altcoin, but it supports altcoins on top of it.

Ethereum has a coin that it uses for its own transactions called ether. It also within its structure allows unlimited other coins.

@JohnT the term "altcoin" is not strictly defined. For many it simply means any cryptocurrency other than Bitcoin. For others it means other things. The Bitcoin StachExchange describes tag "altcoin" with "Questions about alternative cryptocurrencies are off topic unless they are applicable to Bitcoin.", for example.

Bitcoin has a scripting engine already. At this time only a limited number of features in it are used, such as those for standard transactions. Other features are unused but can be developed upon and some, disabled (though could be reintegrated later).
Solutions are already present which build on top of Bitcoin or other such coins to provide smart contracts, m of n transactions, programmable features and more for those who want to use more advanced scripting features which bitcoin would be unable to support.
The currently most fully featured example of this is Open Transactions (http://opentransactions.org/). It is also token-less in the sense there are no "coins" being minted in the use of the application keeping it pure.

I downvoted. Bitcoin's script engine is not turned off, only some of its at the time unused features. Every Bitcoin transaction uses scripts. M-of-n multisig requires less standard scripts.

I will make this more clear hopefully get that down-vote removed :).

The scripting engine in Bitcoin is not turing complete on purpose. The reason this was done is that it enables a static analysis of the scripts in transactions and facilitates discarding transactions with scripts that would for example run indefinitely, consuming resources at all nodes that see it (see the halting problem for example).
That being said it is certainly possible to increase the expressiveness of the scripting language by incrementally adding new opcodes. In order to avoid a hard-fork where transactions valid in one partition are not valid in another just because of the scripts used there would be a transition period after which the individual adjustments become effective. Notice however that changes to the scripting language are often very controversial and will be extensively vetted by the core developers.
In short: yes, you can increase the expressiveness of the scripting language, but no, you will most likely never see it becoming turing complete.

Thank you for the insight on the impact of Turing completeness. It is a concept that I am not familiar with, I understand it as a set of programing logic? Not sure how one can construct an incomplete set of logic.

By your description, it seems Ethereum may run into some computational and bandwidth problems, by doing too much at once.

You can easily see it this way: a hardfork can occur in two ways:

an update allows things that clients running older clients do not allow
an update accidentally makes blocks or transactions that were already in the blockchain invalid

In principle, the first problem is the easiest to solve, a hardfork will only occur when someone uses the new feature before the majority of the network has updated to the new version. So basically, it would not be smart to start using new functionality immediately, because a hardfork between new and older clients can occur. However, in a certain amount of time, the majority of the clients will be updated and the new protocol can be used in it's entirety.
The second problem, however, is of a different kind. Practically, it can be solved just as easy, but it required all clients to keep track of this change so that they can explicitly only enforce the rule to new blocks. This can be done fairly easily by adding a hard-coded reference to the point at which this new feature has to be accepted to all clients. However, it's clear that this is not the kind of solution you want. If you need to hard-code these kind of things, the protocol will get cluttered.
So basically: removing functionality clutters the protocol and will be avoided, while adding functionality can be adopted fairly easily as soon as the majority of the clients has been updated.


text:
How did Silk Road work when it came to delivering product anonymously?
A lot of times, people say Bitcoin is anonymous, but I know most transactions can be easily traced using IPs that used ewallets and by making connection with other bitcoin addresses. So with that in mind, I'm curious if someone had bought something on Silk Road (or any other place) - wouldn't they need to have that product delivered eventually to some address where they could pick it up? How did that affect anonymity? Or were drop off locations used or something? I'm just curious how that worked.  Any ideas?

Currently silkroad is not operating anymore.

I'm not sure this question is really about Bitcoin.

Regarding bitcoins, all the funds were mixed using various techniques to prevent coin tracking. It is propably better to not use a web wallet in this case. Using the Tor network allowed to prevent being tracked by IP. Although you might think bitcoin is not 100% anonymous, it is anonymous enough so that no scammer/hacker/thief has ever been caught using only the blockchain.
To my knowledge products were compressed and sent to the customers' home address in letters. Apparently that's not a problem for small orders.

It was all done behind TOR, where also Bitcoin core was running and therefore was unable to be traced, and the website itself was an .onion domain which also is hidden behind TOR.
Sellers on the market then received Bitcoins for the sold items, which always was sent through the mail, both big and small (there was some journalists in France or Spain, who tried ordering a handgun to see how easy it would get through customs, and it was hidden quite well inside a stereo which just looked as if it was ordered from abroad).
Other sellers on the market then specialized in turning Bitcoins into cash for a fee, and this was one way of getting the earned Bitcoins into cash anonymously.
But the owner made many mistakes, while always thinking he was safe an anonymous. But he ended up getting arrested because FBI were able to find his real name with the use of Google. They were even on to him already 1-1½ year before they made the arrest.
(There has been enormously many exciting articles and documentaries about this whole thing :)


text:
Which version of Bitcoin Core do I need for a Dell laptop with Ubuntu?
I am not technically proficient but I want to download Bitcoin Core on my Dell laptop with Ubuntu. I have a new external drive and want to download a (pruned) BTC node for use in conjunction with Sparrow.
Dell Linux: Intel@Core 17-75OoU cpu @2.7GH
OS name: Ubuntu 20.04
The download page https://bitcoin.org/en/download has 5 Linux choices. Which one of them do I need?

Hi Sam Sam, I've edited your question and replaced "partial" with "pruned" as I'm assuming that's what you meant. If that's incorrect feel free to change it back.

3. bitcoin.org
bitcoin.org/en/download lists

Platform
Package

Windows
exe - zip

macOS (x86_64)
zip - tar.gz

macOS (arm64)
zip - tar.gz

Linux 64 bit
(tgz)

ARM Linux 64 bit - 32 bit
-

RISC-V Linux 64 bit
-

PPC64 Linux 64 bit - 64 bit LE
-

Linux (Snap Store)
snap

For your contemporary hardware based on Intel x86 / AMD x64 compatible architecture, the appropriate choice from that list would be
Linux 64 bit (tgz)

2. bitcoincore.org
However, in my opinion, bitcoin.org is the wrong website to use. I would always prefer to use https://bitcoincore.org/en/download/
See Is bitcoin.org or bitcoincore.org the one to trust?
1. Native package manager
But first of all I would check the native package manager for the installed Linux distribution (e.g. apt for Ubuntu and many distributions based on Debian, yum for many distributions based on RedHat) and see if that native package manager has the most recent version of Bitcoin core
This is especially true if you believe you are "not technically proficient" - Use the package manager icon on the graphical desktop.

Postscript

OS name: Ubuntu 20.04

20.04 dates from around 2019 is out of desktop and server support though it still has security updates. Current version of Ubuntu with long term support (LTS) is 24.04 - I would upgrade to that.


text:
What is this strange microtransaction in my wallet?
I did not initiate this transaction: c64df53cdab52b1ff53425a3d819bc897982912bf36e0c97e8fe6dcee8501edc
Is there any reason that it could be legit, not a sign of a compromised wallet?
Thank you!

Hi John, can you clarify whether the transaction is sending money in or out of your wallet?

This seems to be what's known as an address poisoning attack. It works like this:
The attacker picks an address that has been used multiple times and holds a considerable amount of money (over 5 BTC in this case). They then craft an address using a brute-force search that they control but that begins and ends with the same characters as the victim's address, and from this special address send the victim a small amount of money. The hope is that the next time the victim wants to use their address they copy it from their transaction history and accidentally copy the attacker's address, who then receives funds intended for the victim.
Some ways you can protect yourself from this attack:

Don't reuse addresses.
Don't copy addresses from your transaction history.
Always check every character of your address, not just the start and end.

thank you so much. It really looks the case. I made a mistake, that it looked like mine address


text:
call to consteval function 'util::ConstevalHexDigit' is not a constant expression
i have bitcoin repo from tag v28.0, everytime i run cmake --build build -j$(sysctl -n hw.ncpu), i keep getting the following error
bitcoin/src/uint256.h:133:19: error: call to consteval function 'util::ConstevalHexDigit' is not a constant expression

am trying to setup bitcoin as part of assessment for chaincode lab BOSS program.

What compiler are you using? You need at least GCC 11.1 or Clang 16.0 to build Bitcoin Core 28.0 (see list of dependencies: https://github.com/bitcoin/bitcoin/blob/v28.0/doc/dependencies.md)

The issue is the with the clang compiler. Use gcc as the compiler to build the code.
Install gcc from homebrew and then build the code with the following command specifying the path of the compiler to be used.
cmake -B build -DCMAKE_C_COMPILER=/opt/homebrew/bin/gcc-14 -DCMAKE_CXX_COMPILER=/opt/homebrew/bin/g++-14 \
    -DBUILD_GUI=OFF -DWITH_BDB=OFF -DBUILD_BENCH=OFF -DBUILD_FOR_FUZZING=OFF -DBUILD_KERNEL_LIB=OFF \
    -DBUILD_SHARED_LIBS=OFF -DBUILD_TESTS=OFF -DBUILD_TX=OFF -DBUILD_UTIL=OFF -DBUILD_WALLET_TOOL=OFF


text:
What would happen if we provide witness program different than 32 bytes for SegWit 1?
If the witness program (at the time of writing this question) is greater than 1, it is considered as anyone-can-spend output. Also, if the witness version is 1 and the witness program is 32 bytes, then the output is encumbered with the taproot validation rules. In BIP341 it says that if the witness program is not exactly 32 bytes, the output remains unencumbered.
My question is, if it's not 32 bytes witness program and the witness version is 1, is it then anyone-can-spend output, so the soft fork can be done like in tapscript (when the public key is not 32 bytes, the signature opcode just passes without verification), or it is unspendable output?
Thank you!

SegWit version 1 outputs with lengths other than 32 bytes remain unencumbered, which means their validation is unchanged and they remain anyone-can-spend. From BIP341:

A Taproot output is a native SegWit output (see BIP141) with version
number 1, and a 32-byte witness program. The following rules only
apply when such an output is being spent. Any other outputs, including
version 1 outputs with lengths other than 32 bytes, or P2SH-wrapped
version 1 outputs, remain unencumbered.

Just like with Taproot, new validation rules for these outputs can later be added in a soft fork.
Note that this is different from SegWit version 0 outputs, which are unspendable if they aren't exactly 20 or 32 bytes.
In Bitcoin the consensus rules are basically a series of checks, and if all checks pass the transaction/block is valid.  A soft fork adds new checks, and "unencumbered" in this context means "there are no new checks for this output type". If the output was previously anyone-can-spend, it will remain so.


text:
What types of RBF exist and which one does Bitcoin Core support and use by default?
As far as I know Bitcoin Core knows two types of RBF. These are Full RBF and Opt-in Full RBF. In both cases, the transaction will be replaced if a new one arrives that consumes at least one of the same inputs, is valid and has a higher fee. The only difference is that with Full RBF this applies to every transaction, while with Opt-in Full RBF transactions must signal it (some nSequence smaller than 0xffffffff-1).

What other types of replacement exist, either "replace by fee" or some other? (I just need the list, I'll research what they are myself)

Here they mention Child-Pays-For-Parent (CPFP), Replace-By-Fee (RBF; I assume this means both Full RBF/Opt-in RBF; correct me if I'm wrong) and First-Seen-Safe Replace-By-Fee (FSS RBF). It doesn't mention Opt-in Full RBF but I assume that's what's considered under RBF since it's actually Full RBF where the transaction has to signal replacement, correct me if I'm wrong. By the way, the answer is from 2015, so I'm interested in whether there are more types of replacement in Bitcoin.

Does Bitcoin Core support CPFP and FSS RBF, as well as all the types you listed in the answer to question 1?

What type of replacement does Bitcoin Core use by default? I know that it was an Opt-in Full RBF and that there were some indications to switch on Full RBF.

Thanks to all!

The original software release included a mechanism that allowed transactions with a higher sequence on inputs to supersede transactions with a lower sequence. This mechanism was not incentive-compatible and got removed.
First-Seen-Safe RBF was a proposal that would only permit a replacement when the replacement transaction replicated all outputs from the original transaction. This would have meant that almost every new replacement transactions would add another change output (whereas only one of the original inputs had to remain, so one or more of the others could have just been swapped out for UTXOs with larger amounts). The protection FSS RBF offered to unconfirmed transactions was also generally considered unreliable. For these reasons and others, the proposal was not popular and the network instead adopted Opt-in Full RBF.
The "opt-in" requires the original transaction to signal replaceability, by having at least one input with a sequence field lower than MAX-1.
"Full RBF" in this context meant that a replacement was permitted to completely supersede the original transaction without preserving any of the payments that the original transaction had announced. The replacement transaction would still need to pay a higher absolute fee as well as a higher feerate.
Full nodes operating under these mempool policies would not permit replacement of transactions that had signaled finality, much like for every transaction before Opt-in Full RBF got adopted.
More recently, Bitcoin Core got a configuration option that allows node operators to permit "Full RBF" replacements per the same rules, without requiring the original transaction to have signaled replaceability.
CPFP is another mechanism to reprioritize a pending payment, but CPFP is not a replacement mechanism. CPFP works by adding a higher feerate transaction as a dependent to an existing transaction. Miners are incentivized to include both the parent and the child in order to collect the attractive fee on the child transaction.

Thanks for this comprehensive answer. I have one question related to what you wrote for FSS-RBF. By writing this: "This would have meant that replacement transactions would have often ended up with two change outputs." you meant that since we can't change outputs (we can't just decrease change output value - output that return sats back to us - in order to increase fee) we need to add one additional input and change output, and by that way to increase fee. The result is that we have at least 2 change outputs (and maybe more if we do FSS-RBF again) Did I understand you correctly?

Yes, you would generally need to add another change output with each replacement, unless your input set for the replacement happens to not need change, but you could keep just one input stable across all replacements and swap out other ones with larger UTXO amounts.

Hmm. So you meant the following. Original transaction: inputs(10 bc, 5bc) - outputs(13bc, 1bc). Second output is change and fee is 1bc. If 1bc is not enough (2bc is), we can make the replacement transaction as follow (11bc, 5bc) - outputs(13bc, 1bc). In this case, we just changed one input and outputs stayed as they were (no additional change outputs). However, it is much more realistic for the replacement transaction to look like this: inputs(14bc, 5bc) - outputs(13bc, 1bc, 3bc) or inputs(12bc, 3, 5bc) - outputs(13bc, 1bc, 4bc).

Therefore, the real scenario is actually that the number of inputs stays the same or increases, and we have one additional change output.

No, only a single input is necessary to create a conflict with the preceding transactions, therefore the number of inputs can vary freely, but generally would be greater than one after the original, although their total amount must go up with each replacement. So, you might have an input that is present on the original and all subsequent versions of the transaction, but the remainder could for example be two inputs summing to 1 BTC (and two change outputs), then five inputs summing to 2 BTC (and three change outputs), finally a single input worth 3 BTC (and four change outputs).

Yes, thank you. That's exactly what I meant. I just can't agree with this: ...although their total amount must go up with each replacement.. We can leave all the inputs as they are and just decrease the value of the change output. In this case the total amount in transaction remains the same, but we still increased the fee and the replacement is valid. I hope you agree?

No, since you have to replicate all outputs of the previous version of the transaction, the sum of the amounts of the inputs has to strictly go up in order for you to be able to pay more fees.

Yes, you are absolutely right. My fault.

Here you can find a list of all transaction replacement types (no mention of CPFP).

Bitcoin Core today only supports Full RBF and Opt-in RBF. Bitcoin Core also supports CPFP (but that is not a transaction replacement policy).

By default, Bitcoin Core uses Opt-in RBF.

CPFP is not a transaction replacement policy (no replacement is involved). It's a quality the mining algorithm has to prioritize parent transactions when the child pays a higher fee. It can be used as an alternative to replacement in dealing with transactions whose fee is too low, but through a completely different mechanism.

In your table, what is "Satoshi RBF"?

@PieterWuille I took the image/table from here.

@PieterWuille Are there any additional replacement techniques other than those in the table?

None that I know of, no.

@PieterWuille Just a question related to CPFP and what you wrote, does bitcoin full node (core) have anything to do with CPFP or that's miner "policy" since he is the one who chooses the transactions for the block, so he will choose the parent transactions whose child transactions pay huge fee?

Miners need to get their block template from somewhere, and typically that comes from Bitcoin Core directly or indirectly. The block building feature in Bitcoin Core supports CPFP since version 0.13.0.


text:
Is the Schnorr digital signature scheme a multisignature interactive scheme, and also not an aggregated non-interactive scheme?
In his answer Pieter Wuille defined a concepts of multisignature scheme and aggregated signature scheme as follows:

A multisignature scheme is a scheme where multiple parties jointly produce a signature on a single message, which can be verified against the set of all participating public keys.
A aggregated signature scheme is a scheme where multiple parties jointly produce a signature, each on their own message, which can be verified against the set of all (pubkey,message) pairs.

Also, in another answer he defined a concepts of non-interactive aggregation and interactive aggregation as follows:

(1) non-interactive aggregation is the ability for a third party (who does not hold any private keys) to combine multiple signatures, each with their own message and public key, into a single signature that can be verified by someone who knows all messages and public keys.
(2) interactive aggregation is the same, but when the signers need to be aware of the aggregation, and communicate with each other to jointly produce a single signature.

Since the Schnorr scheme provides the possibility for multiple parties to combine (merge) their public keys and also combine (merge) their signatures made over the SAME message, it is a multisignature scheme. Also, it is an interactive scheme, since the interaction between the participants is necessary in order to realize the given mergers (although this could also be done by a third party to which they would provide their individual public keys and individual signatures). On the other hand, the Schnorr scheme does not support the possibility of merging signatures created over DIFFERENT messages, so it is NOT an aggregation and non-interactive scheme (honestly, the description of these two concepts seems exactly the same to me, that is, they mean the same thing).

Are these the correct properties of the Schnorr scheme?

In the second linked answer Pieter Wuille said that we cannot have one Schnorr signature on the block level since the Schnorr is interactive (we will ignore the fact that such a signature is certainly not possible because the signatures are over different content, but the focus is not on that). However, I would say that there does not need to be any interaction between the transaction creators in this case. The miner (third-party) can only collect all the signatures and merge them into one, while all the public keys are found in the referenced outputs, which can then also be taken and merged into one.

Since this is done by a third party, could we say that Schnorr is still in some way a non-interactive aggregation scheme if we look at the concept of interaction only through whether there is interaction between the signatories and not whether all the signatures are over the same message?

Thanks in advance to all!

I want to start by addressing a few misconceptions in your question:

"Schnorr signatures" aren't really a well-defined signature scheme. They're a class of digital signature schemes (with many possible instantiations, e.g. BIP340 and Ed25519), and in a wider sense even an abstract idea for building many types of signature schemes (including e.g. MuSig2, FROST, CoSi, BN06, ...). Historically, and in several answers on this site, I have not always made a clear distinction between them. In what follows, I'll call the latter "Schnorr-based". While there are properties that apply to many Schnorr-based schemes in general, the details vary a lot.

"Adding signatures gives signature for sum of public keys" is a simplification. It is an abstract mathematical property that applies to the verification equation of many Schnorr-based schemes (the fact that the equation is linear). This particular way of formulating it helps convey what it's useful for in an approximate way, but using it in practice in concrete schemes is not as simple. It's not just applying an addition function, and the co-signers need to be aware of each other, or the resulting sum won't be a valid signature. This is why the resulting signature aggregation schemes are said to be interactive, and don't lend themselves to block-wide aggregation for example. If it were possible to just hand the keys and signatures to a third party who could aggregate them, the result would be called non-interactive, but that's not the case here. There do exist other classes of signature schemes for which non-interactive aggregation is possible (notably, BLS), but for Schnorr-based schemes only interactive constructions are known.

"Adding signatures gives signature for sum of public keys" is not on itself a scheme. It's only a principle upon which multisignature and other more advanced schemes can be built. Even taking point (2) above into account, applying this principle naively as a multisignature scheme is woefully insecure. Secure schemes are non-trivial to get right (several published ones, including the first version of MuSig, were later shown to be broken), and appear to involve at least 2 or 3 interaction rounds between the signers. So we can't just talk about this being sort-of an implicit possibility that's part of the "Schnorr signature scheme"; you need to specify exactly which scheme is being considered.

Before continuing I also want to point out a few points of terminology:

The difference between signature aggregation and multisignatures. In a multisignature scheme, there are multiple participants which jointly sign a single message, resulting in a single signature. In a signature aggregation scheme, there are multiple participants that jointly sign their own message, resulting in a single signature.

The difference between key aggregation and multisignatures. According to the typical academic definition, a multisignature scheme involves a verifier who receives all individual public keys (together with a message, and a multisignature). Some multisignature schemes (notably, the MuSig family ones) output a signature that can also be verified by a verifier who only knows an aggregate public key of all the co-signers (and thus being unaware what the individual public keys are, or even how many of them there are). We call those multisignature schemes, key aggregation schemes. That is what we want in Bitcoin, because (a) it doesn't require changing the consensus rules to accomodate and (b) is cheaper and more private as the individual keys do not need to be publicly revealed. So a key aggregation scheme is a special type of multisignature scheme. A key aggregation scheme is also not a signature aggregation scheme, as signature aggregation always requires the verifier to be aware of all signers, because they can all have different messages.

In Bitcoin-speak, "multisig" refers to threshold signatures, not multisignatures. A threshold signature scheme is one where any subset of k out of n given public keys can sign (where multisignatures can be seen as a special case, with k=n).

So to answer your question, we need to talk about specific schemes. And schemes, as pointed out before, are a combination of key generation, signing, and verification algorithms.

BIP340 defines key generation, signing, and verification, so it can be said to be a complete scheme. The verification side defines the consensus rules that apply to the spending of Taproot outputs in Bitcoin (see BIP341 and BIP342 for how). The signing algorithm is strictly for one signer though, so it is not a multisignature scheme or signature aggregation scheme at all.

Naive (concatenation) multisignatures If we don't care that the multisignature is small, it's always possible to construct a multisignature scheme by just using a normal (non-multi) signature scheme, and concatenating all the signatures. Arguably, Bitcoin Scripts with multiple public keys can be seen as an instance of this (and even as a threshold signature scheme).

Concatenation key generation: same as the underlying signature scheme.
Concatenation signing: same as the underlying signature scheme + concatenating the results.
Concatenation verification: splitting the resulting signature, and invoking the underlying signature verification for each

MuSig2 defines a multisignature scheme, using the linearity property, which supports key aggregation. It needs two signing rounds, works with ordinary public keys (no special key generation algorithm is needed for the participants), and outputs a multisignature that can be verified against the aggregated key using the ordinary Schnorr (in the narrow sense) signature equation. BIP327 defines a BIP340-compatible standard for MuSig2, which is thus usable on Bitcoin.

MuSig2 key generation: identical to Schnorr, plus MuSig2 specific key aggregation.
MuSig2 signing: MuSig2-specific 2-round interactive protocol.
MuSig2 verification: Schnorr verification with aggregated key

Bellare-Neven 2006 defines a multisignature scheme, which does not support key aggregation. So while it permits multiple signers to cooperatively construct a single signature, verifying that signature requires knowledge of all individual public keys. And thus, while certainly Schnorr-based in its construction, the result is very much not a Schnorr signature, or even compatible with it.

BN06 key generation: identical to Schnorr
BN06 signing: 3-round interactive BN06-specific protocol
BN06 verification: BN06-specific verification (using all keys).

Bellare-Neven 2006 also explains how any multisignature scheme in general can be turned into an interactive aggregated signature scheme (IAS): just use the concatenation of all keys and messages as the multisignature message. Note however that that approach is not compatible with key aggregation, as the verifier inherently needs to be aware that there are multiple signers (each with their own message).

BN06-IAS key generation: same as underlying multisignature scheme.
BN06-IAS signing: underlying multisignature on the concatenation of keys and messages as message.
BN06-IAS verification: underlying multisignature verification using the concatenation of keys and messages as message.

FROST is a threshold signature scheme that is compatible with Schnorr signature verification. It can be seen as a generalization of MuSig2 in this regard, permitting only a subset of signers to produce a single signature that can be verified against a single aggregated public key. It does however have a far more complex setup; participants need to engage in an interactive protocol with each other to generate their keys, and can't just use ordinarily-generated public keys.

FROST key generation: interactive key generation protocol
FROST signing: FROST-specific interactive signing protocol
FROST verification: Schnorr verification with aggregared key

There are many more schemes, with various levels of applicability to Bitcoin. I've listed just the above to give an idea of the level of variation that exists.

Now to answer the question in the title:

Is the Schnorr digital signature scheme a multisignature interactive scheme, and also not an aggregated non-interactive scheme?

In the narrow sense, Schnorr digital signatures are not a multisignature or aggregated signature scheme at all.
In the wider sense, Schnorr-based schemes exist which are multisignature schemes (including key aggregation schemes), or signature aggregation schemes, or threshold schemes. They are however all interactive.

Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on [meta], or in [chat]. Comments continuing discussion may be removed.


text:
How to create bitcoin coin , coinbase transaction?
I know about
createrawtransaction '[{"txid":"0000000000000000000000000000000000000000000000000000000000000000","vout":0}]' '{"39jbHRLG6Z2KgXLHR3BWgbccZde1Moo15k":6.5}'

its give
020000000100000000000000000000000000000000000000000000000000000000000000000000000000ffffffff018036be260000000017a914583daf881525ddfcb891e1ab715a2a790b62f03c8700000000
19:10:24
￼
decoderawtransaction 020000000100000000000000000000000000000000000000000000000000000000000000000000000000ffffffff018036be260000000017a914583daf881525ddfcb891e1ab715a2a790b62f03c8700000000

￼
{
  "txid": "b95321ea560dbdf48581c0ff451699e4240c86021bd10791585b3bc4078681cf",
  "hash": "b95321ea560dbdf48581c0ff451699e4240c86021bd10791585b3bc4078681cf",
  "version": 2,
  "size": 83,
  "vsize": 83,
  "weight": 332,
  "locktime": 0,
  "vin": [
    {
      "txid": "0000000000000000000000000000000000000000000000000000000000000000",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 6.50000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 583daf881525ddfcb891e1ab715a2a790b62f03c OP_EQUAL",
        "hex": "a914583daf881525ddfcb891e1ab715a2a790b62f03c87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "39jbHRLG6Z2KgXLHR3BWgbccZde1Moo15k"
        ]
      }
    }
  ]
}

but if i try decode tx from blockchain
as example tx d56e6eccf09e3b2993326b86d95bf79919ec98ff576c2cc6b550d7fd90187080
from  block 00000000000000000005c8f82be414604a30f33fa35028079d0d012079c8f3ea
￼
getrawtransaction d56e6eccf09e3b2993326b86d95bf79919ec98ff576c2cc6b550d7fd90187080

￼
01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff5b0300f60941d7e1f2e7560aff41d7e1f2e755ef2a2f45324d2026204254432e544f502ffabe6d6d1c3eb14eb586c97d05cb6333184280d0d86e081a6ccc1cbbc0367888f2368b2b8000000000000000e7000a064122000000000000ffffffff0140be4025000000001976a9140b904a4a8590d0ccff680bb8adc4ae4fe49f890a88ac00000000

￼
decoderawtransaction 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff5b0300f60941d7e1f2e7560aff41d7e1f2e755ef2a2f45324d2026204254432e544f502ffabe6d6d1c3eb14eb586c97d05cb6333184280d0d86e081a6ccc1cbbc0367888f2368b2b8000000000000000e7000a064122000000000000ffffffff0140be4025000000001976a9140b904a4a8590d0ccff680bb8adc4ae4fe49f890a88ac00000000

￼
{
  "txid": "d56e6eccf09e3b2993326b86d95bf79919ec98ff576c2cc6b550d7fd90187080",
  "hash": "d56e6eccf09e3b2993326b86d95bf79919ec98ff576c2cc6b550d7fd90187080",
  "version": 1,
  "size": 176,
  "vsize": 176,
  "weight": 704,
  "locktime": 0,
  "vin": [
    {
      "coinbase": "0300f60941d7e1f2e7560aff41d7e1f2e755ef2a2f45324d2026204254432e544f502ffabe6d6d1c3eb14eb586c97d05cb6333184280d0d86e081a6ccc1cbbc0367888f2368b2b8000000000000000e7000a064122000000000000",
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 6.25000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 0b904a4a8590d0ccff680bb8adc4ae4fe49f890a OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9140b904a4a8590d0ccff680bb8adc4ae4fe49f890a88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1249HZzzG5YSi8juRXPXYopcCYBx3CQYW7"
        ]
      }
    }
  ]
}

i see coinbase value
"coinbase": "0300f60941d7e1f2e7560aff41d7e1f2e755ef2a2f45324d2026204254432e544f502ffabe6d6d1c3eb14eb586c97d05cb6333184280d0d86e081a6ccc1cbbc0367888f2368b2b8000000000000000e7000a064122000000000000",

what is this ? How to create working coinsbase tx what can be puted to block and it will be correct for mining , all what if find there is not incorrect info and link to outdatet wiki.
tx created by any of that solution dont have this field so they are invalid .
Problem is there no info how to add that coinbase to coinbase tx .
maybe some where exist some python script what can do coinbase tx ? For look at logic how it creation that tx.

The coinbase transaction is a special transaction that has to satisfy the following:

Only has 1 input
The input is using 0x0000000000000000000000000000000000000000000000000000000000000000 as its txid and 0xFFFFFFFF as its index (vout)
The signature script of this input has to have a length between 2 and 100 (2<= length <=100)
Any block after BIP-34 activation (height>=227931) must have the block height pushed at the beginning of the signature script using strict push lengths. (The rest of the script is ignored.)
Like any other transaction it has to have at least one output
If the block contained any transaction that had witness, the coinbase tx must have* a single witness (corresponding to its single input) containing a 32 byte witness commitment and an output that contains the computed witness merkle root hash and starts with OP_Return followed by 0x24aa21a9ed and is at least 38 bytes total
The sum of output amounts must be smaller than or equal to the block reward + sum of fees

*This is optional in case there were no witnesses (so SegWit tx inside the block)


text:
How genereate pub key from priv key ? algo
How to generate pub key from prive key ?
All examples and explain skip this.
but i dont need steps to address etc .
i only need steps from priv to pub ( compressed or not )
what using at that.
if possible example or python , or simple algo what used.
example i hv priv key 981F3AF336E23EEFF4384A939065C4C623E394F1AE7E4D922C045CEDC3F258D2
i want make from them pub key , (i not need generation priv key i have them!)
compressed or uncompressed .
what steps i need to do for make valid public key for bitcoin address .
Update
sorry for my qustion , i cannot undestand this logic.
i try make pub key  as example with 04 uncompresed from priv key 0x64hex, i not need steps for make it base58.
i stuck at that step.
as example
i hv some words i make from them hex 0x64digits.
how i can do from them not public key as example
049f35c793522be1fdcfd50c3fb15f455cda37fb3fb779b9e4707c89a49cdf47242c3dc34778f7361a44c074a6a21e5972bbf5ca5265c9ea121ce4f2a5dc4964b6

Does How do you get a Bitcoin Public Key from a Private Key answer your question?

I just tried to fix the grammar, spelling and punctuation, but the question is a bit jumbled. In the first part it seems to me that you say you don't need instructions to get to an address, but then in the last sentence you say "what steps i need to do for make public key for bitcoin address"? Could you clarify the scope of your question please?

sorry for my qustion , i cannot undestand this logic.
i try make pub key  as example with 04 uncompresed from priv key 0x64hex, i not need steps for make it base58.
i stuck at that step.


text:
Does the hashrate/hash power represent the number of single or double sha256 operations that can be done per second?
When we state that someone has, for example, a hashrate of 240 H/s, does it imply the capability to perform 240 SHA256 hash operations (equivalent to 120 double-SHA256 operations) or 240 double-SHA256 operations? In other words, does the term "hashrate" or "hash power" refer to the number of single SHA256 hash operations or the number of double SHA256 operations that someone can execute in one second?

Other very very similar question: How is hash rate of mining hardware calculated and Bitcoin Performance: What does Hashes/Second Mean?


text:
What am I doing wrong in calculating point addition? Is something redundant in the formula I am using?
First of all, just to note that I am having trouble with this MOD math, so for some this question might be basic, but in my case it caused a lot of confusion.
Just for the context. In my previous question Pieter Wuille and I had a discussion in the comments (we've deleted them so you won't find them anymore) about points in a finite field and he said that it's just a convention to represent a point as a "direct" value of some field. For example, in a curve where p = 11, the direct values are [0, 1, 2, ..., 10] (I randomly denoted them as a "direct" values). He said that we can represent, for example, value of 3 also as 14, -8 and -19 etc, since using mod 11 on them they all denote the same value and it is just a convention to represent them as "direct" values. I totally agree with that.
He also said that we can do EC arithmetic (addition) with, for example, (3, 9) as well as with (3, -2) or (3, 20) (since -2 mod 11, 9 mod 11 and 20 mod 11 are all the same values) and we will end up with the same point/result after arithmetic operation. What he specifically drew my attention to is the following (I'm paraphrasing): "as long as you realize that the output points whose coordinates differ by multiple of 11 are the SAME POINTS). This seems totally logical to me and I agree with that, but...
What confuses me is that I always end up with the exactly same point regardless of the input point values. For example, in case of (3, 2) + (9, 5) = (8, 2), according to what he says, if I use 14, -8 or -19 in place of 3 it need to end up with some X coordinate that differ by a multiple of 11 to 8. However, I always end up with the (8, 2) regardless of what are the initial coordinates.
I know that the formula for adding points in EC is as follows (taken from here). I have given it as a picture.

Since we work with the EC over finite field, we must take MOD operation into account , so the modificated formulas are as the following (taken from the same site):

Using these formulas I always end up with the exact same point (in my example (8, 2)), regardless of inputs. So there are no points on output whose coordinates differ by a multiple of 11.
I assume that there is something redundant in this formula, which consistently returns values in the set, as I previously referred, of "direct" values. I assume some MOD is redundant, or do I even need any of these MOD (although when I do not use MOD I and up with totally wrong points).
What am I doing wrong? What is redundant in the formula?
Thanks to all!

My point was that regardless of whether you do a modulo operation or not, you'll end up with the same point - if you treat differences of a multiple of 11 as "identical".
If of course you do a modulo operation, then clearly you cannot end up with a difference of 11 anymore. The modulo operation is exactly what removes all multiples of 11, and maps all field elements to [0, 1, 2, ..., 10].
You have to remember that what you're really calculating is elements of the "integers modulo 11" field. Since computers (and people) can't natively deal with these, we instead represent the field elements as integers. But as pointed out in your earlier question, it does not matter what representation you use as long as the operations keep the same meaning.
In practice, for addition, subtraction, and multiplication, the modulo operation at the end is optional. If you don't, you'll just end up with another representation for the same field element. The same is not true for division and equality checking. Field division is nothing like integer division at all; it requires multiplication with the modular inverse (and again, the modulo reduction after that is optional). For equality checking you must treat a difference of a multiple of 11 as equality.

Thanks, and just one (out of context) question. Can we have 2 points on EC with the same Y coo?

@LeaBit Yes, 3 in fact. See https://bitcoin.stackexchange.com/q/120050/208 (but this results only holds for curves with a=0, and when p%3 = 1).


text:
Does mining power of different miners add up in mining pools?
I have this doubt regarding bitcoin mining, assuming I have two miners of hashpower 500 H/s .

Can I add up my hashpower and make it work like a single processor of 1000H/s
OR
Both both miners would be acting independently?

According to what I have read, option 1 is how it takes place.

So this means a mining pool has combined power of all the associated miners and working on one block?
OR
All miner are working on different block of their own ??

According to what I have learnt, option 3 is how it takes place.
Now, referring to the attached chart by blockchain.info and assuming option 1 & 3 for the questions
Only top 3-4 mining pools should be making profit. Relatively other miners have a very low probability with available hashpower to mine a block. And say for profit if all the miners decide to join big mining pools, eventually the network will become centralized.

Mining is a lottery, not a race.
The fastest miner doesn't always win. In general, if you have X% of the hashrate, you will find X% of the blocks.
This is because not just all pools, but every every, every chip, ... is attempting to solve a different block proposal. Every attempt has an independent chance of winning. There are an infinite number of potentially valid blocks, but they're still only a tiny fraction of all possible blocks. Everyone is not trying to find the next block - they're trying to find a next block.
So:

Can I add up my hashpower and make it work like a single processor of 1000H/s

Yes. You can't distinguish the different processors - more hashpower just tries more block proposals at the same time.

Both both miners would be acting independently?

Yes. Everything always acts independently.

So this means a mining pool has combined power of all the associated miners and working on one block?

Yes.

All miner are working on different block of their own ??

Yes.

Thanks @peter, I recall you answered my similar question earlier as well, but still I am not able to digest it completely. You said yes to question 3 & 4 both, so what happens out of these two? 1. A mining pool with total hashpower of y H/s makes a block, sends hash to miners for computation and computes nounce with y H/s.
2. A mining pool asks miner to provide block hash and nounce clearing the current difficulty according to their ledger, and all miner computes nounce with power of whatever fraction they hold of total y H/s.

(simplified) Each pool gives each miner a separate range of possible block variations to try. As soon as one of them finds a solution, they notify the pool. As a result, a pool with 2 hashers will go through possibilities twice as fast, and have twice as much chance to find a solution first.

Perhaps your confusion comes from the fact that there is no block until a solution is found. It's not that the pool gives out a block X to miner A and a block Y to miner B. It gives a range of a trillion blocks proposals to try to A, and another trillion to B.

thanks @peter, it has made things more clear. But still, it's hard to imagine pools with <1% hashpower to make profit. They have the same chance towards the answer I understand but winning lottery against 99% hashpower seems highly unlikely :p , anyways considering their relatively low investment kind of makes up for the possible profit value.

Exactly. With 1% of the hash rate they will find 1% of the blocks. However, they also only needed to invest in 1% of the hardware and electricity. So assuming hardware and electricity are equally priced, this just translates to a fixed BTC income per hw/elec spending.

@peter , when you say trillion blocks proposals are given to A and B, it means mining pool has created a block and included the transaction, and gives different block hashes by changing coinbase value to all the miners, right??


text:
What is the need of miners and mining?
Bitcoin is designed to have an average time duration of 10 min between block mining. This is maintained by the difficulty attribute and haskey complexity. But mining takes so much power and it is a manual process as well.
Why it just not create a block every 10 min automatically?
Now bitcoin has 10kb(not sure exactly) reserved for priority transactions of pool. Let's just decide priority by the same functionality, and fill our block with transactions.
Users need only send transaction to the pool, no power lost and it is automated. Blocks will still have it's hash codes, and all immutability would be maintained. Just miner need not find it.
Say I have coded bitcoin like this:
1. 5 min for every new block. 2. only one transaction from one public key at a time. It will stop the double spend, and no need of POW, and within 5 min, changes will be reflected in connecting nodes.
Why are such methods not used?? What are the drawbacks??

Thanks for the response alcio.
Say I have coded bitcoin like this:

5 min for every new block.
only one transaction from one public key at a time.

It will stop the double spend, and no need of POW, and within 5 min, changes will be reflected in connecting nodes. What the drawbacks here??

Problem 2 is not trivial to solve and is in fact solved by creating the blockchain.

One of the core concepts of Bitcoin is that it has a decentralized transaction ledger (the Bitcoin blockchain). This means that every (full) node in the network has a copy of this ledger (as opposed to VISA for example where only one centralized party has a copy of the transaction ledger).
When new transactions have to be added to the blockchain, this results in a problem. The nodes in the Bitcoin network need to agree (or reach consensus) about a new state of the blockchain. The problem boils down to "Which block of transactions will we all add to our blockchain next?".
Now, say all of the full nodes would have your proposed software routine that says "I will create a new block of all the transactions of the past 10 minutes".
The result will be that different nodes will have different blockchains.
Transactions can't be propagated instantly across the entire Bitcoin network.
So a given transaction could fall within the 10 minute time-span for some nodes, but arrive late to other, more distant nodes.
The nodes are now in disagreement and it's unsure which blockchain is the true blockchain of the network.
So to prevent this, a consensus algorithm is needed, which allows all the nodes in the network to agree on the next block to add, so there is only one version of the truth.
One node will have to propose the next block to be added, and the other nodes will need to be able to easily verify that the block is valid.
PoW is just one example of a consensus algorithm, and it's indeed known to consume a lot of energy.
Other consensus algorithms exist that are more energy-efficient, e.g. PoS (Proof-of-Stake), PoC (Proof-of-Capacity), ...
But without one of these algorithms, there is no way of keeping one and the same decentralized blockchain.

I don't understand in the sense that if a node propose a block, it implicitly accepts it. If other nodes refuse the block,they will have a different blokchain? Unless the node that proposes the block needs to wait for the answer of all other nodes?

Who would create the block? What if two people create different blocks and can't agree? If the whole network trusted one pool to create the block once every 10 minutes, it becomes completely centralised. Bitcoin uses the mining race to securely decentralise the decision of which block is the accepted block.

Appreciate the response MeshCollider.
now say, block is created by itself, assuming it is coded like that only. It won't be centralized, no pool is creating the block, but the code itself.

But if everyone's code makes a block based on the order it sees transactions, what if two different computers see the transactions in different orders? How can they reach agreement? The whole point is that everyone must agree

No, not everyone is making blocks. Assume block is being created by blockchain itself every 5 minutes, and only one transaction from one public key in a block. According to priority, txns are automatically added to the block. It will stop the double spending, and no need of POW, and within 5 min, changes will be reflected in connecting nodes.

I think you completely misunderstand what the blockchain actually is. There is no code in the blockchain itself, there is no way for it to make blocks itself.

Adding to Mesh's argument, how can you know your magic blockchain code hasn't been hacked? The value of having so many users on the network is its security. The whole point of a blockchain is so that the databse / ledger is decentralized. If the machine is the one running it, there is no way to know for sure that it isn't being manipulated.

The problem in a peer-to-peer gossip network is that not every peer has the same information at the same time. This means that "only one transaction from one public key at a time" is not a trivial problem to solve. In fact, this is the core invention of Bitcoin: The Bitcoin network uses the blockchain to determine which transaction is to be considered "seen first".


text:
Is it credible that a "stuck transaction" was the true cause of Binance pausing bitcoin withdrawals?
It is reported that Binance is blaming a "stuck transaction causing a backlog" as the reason it prevented people withdrawing their bitcoin for some hours on the 13th June 2022.  I do not have much of a feeling of exactly what that means, looking at questions here it seems to be something that happens and it seems to be a technical issue, usually between screen and keyboard.
Is it actually credible that this sort of technical issue could bring the worlds largest centralised exchange to a halt for hours?

In the questions you linked, the phrase "stuck transaction" is one typically used by people who are unaware of the effect of chosen transaction fee on confirmation time.
As we all know, this sort of "stuck transaction" cannot delay other people's transactions.

According to a Coindesk article

Cryptocurrency exchange Binance explained what caused the temporary withdrawal issues involving bitcoin on Monday in a series of tweets, saying they stemmed from repairs it was doing to address small hardware failures.

Binance wrote that it was “repairing several minor hardware failures on wallet consolidation nodes earlier today, which caused the earlier transactions that were pending to be broadcast to the network after the nodes were repaired.”

The company said that “these pending consolidation transactions had a low gas fee, which resulted in the later withdrawal transactions – which were pointing to the pending consolidation UTXO - getting stuck and not able to be processed successfully.” (UTXO refers to unspent transaction output.)

In order to fix these issues, Binance said it had to “change the logic to only take successful UTXO from consolidation transactions or successful withdrawal transactions. This fix will also prevent the same issue from happening again.”

So essentially, the problem was inside Binance. Some combination of hardware issue and bugs in their internal software. The transactions they constructed to carry out customer's requests were dependent on a consolidation transaction that had been affected by repairs to hardware failures.
The reference to "gas fees" seems a bit odd to me, they probably mean low transaction fees. However I believe it is clear the problem was not simply the same type of "stuck transaction" typically referred to by casual Bitcoin users. It was not simply an external issue of Bitcoin blockchain congestion or fee escalation. The fault lay wholly inside Binance.

In normal circumstances those other transactions can try and use Parent Pays For Child to essentially "unstuck" the low fee transactions. In this case it seems Binance's internal systems for how they consolidate funds between their various wallets prior to conducting customer transactions broke down. As @RedGrittyBrick pointed out it was a purely internal Binance issue not a Bitcoin issue.


text:
Technology and logics behind BTC flashing apps
How they develop BTC flashing software ? I mean, is there any technical way to send fake BTC ? If not, how BTC flashing app works.. I am just curious ..

What is 'BTC flashing software'?

I also dont know much.. There are many apps in google claim to send fake BTC to any BTC enabled wallet (eg blockchain.info wallet). the fake BTC will stay there for few hours and will eventually flushed out by the receiving wallet..

That sounds nonsensical, I would suspect that many of these apps are just malware designed to steal your bitcoin, etc.

There is no technical way to send fake BTC
I surmise the way BTC flasher apps work is not by sending fake BTC but by

tricking the app purchaser out of their money.
tricking the app purchaser into installing malware.
opening the app purchaser to extortion.