|
1601
|
Economy / Exchanges / Re: Is my wallet safe? S.O.S
|
on: April 10, 2021, 05:28:48 AM
|
|
The reason isn't exactly compelling. Instead of asking you to do a KYC for verification, they're asking you to make a deposit to reduce 'anonymity'. Red flags either ways, sending funds to the exchange won't be enough to reveal sufficient personal information and that governments will want documents submitted from the user instead of just asking them to make a deposit.
|
|
|
|
|
1602
|
Bitcoin / Bitcoin Technical Support / Re: Get addresses from wallet.dat
|
on: April 10, 2021, 05:26:07 AM
|
If you realy don't want to synchronize and want to be absolutely sure that it is empty, you can get a wallet dump. Window>Console and Replace the directory to file to whichever you want, must have write permission. You'll get a dump file which you can open with any text editor and it will show you the addresses from your keypool as well. Can be quite a tedious task to check every address. |
|
|
|
|
1603
|
Bitcoin / Electrum / Re: Electrum 4.0.9 address notify and change address problem
|
on: April 10, 2021, 04:40:55 AM
|
The only limit I could think of is the history depth of the addresses which used to exist (not sure if it still does). For example some nodes only stored 10000 transactions for each address not all and if the address had more the user had to use a different server that stores more.
The maximum request size for the address was capped at 1MB and is still enforced, but it is now user configurable. If your use case requires having an address with a very long history, you'll have to modify your own configuration and also find a server that would allow the user to synchronize such an address. It'll probably be a bit easier to hit the cap for the total number of subscribed address though. I thought servers used to have it listed in their console message but I can't find any of them still doing so. |
|
|
|
|
1604
|
Bitcoin / Electrum / Re: CPFP
|
on: April 09, 2021, 04:03:51 PM
|
|
Not directly. A CPFP transaction spends from the output of the unconfirmed transaction; this means that the extra fees can come from the UTXO that was created from the unconfirmed transaction. Alternatively, you can spend another UTXO in the CPFP transaction to supplement the fees as well.
|
|
|
|
|
1605
|
Bitcoin / Electrum / Re: Electrum 4.0.9 address notify and change address problem
|
on: April 09, 2021, 01:39:54 PM
|
1. Is there any limit in Electrum 4.0.9 for a large number of addesses subscripting to the same notifying url?
The number of addresses that you will subscribe to will be limited by the server that you're connected to. Repeated request is fine but it would probably result in the server being unhappy and throttling your connection after a certain threshold or just outright disconnecting you. It'll be fine for the subscriptions to be pointed to the same URL. 2. Is there any way to identifying the address is a receiving address or change address in a wallet? In addition, can I make any limit to the number of change address in Electrum Wallet?
Receiving address and change address have different derivation path. You can try to use the xpub to generate either and match them. You can avoid sending to change addresses/reuse them but would be pretty bad for privacy. |
|
|
|
|
1606
|
Bitcoin / Development & Technical Discussion / Re: Why is it necessary to mine the genesis block?
|
on: April 09, 2021, 10:43:58 AM
|
Yes, but if you can overwrite the Genesis Block, then you can start the whole chain earlier. So, for example, instead of starting from 2009-01-03, you could start from 1970-01-01. And then, you could pretend that the whole chain existed earlier. So, this block was hardcoded to prevent pretending that Bitcoin was invented before by someone else than Satoshi.
The inclusion of the scriptsig's message was a reference to the article so yes, that is what Satoshi intended; proving that he started the chain no earlier than the date but it has nothing to do with who invented what, and when was it invented. The genesis block is not important, you can just attack by reorganizing everything after the genesis block and it would achieve the same thing. It is definitely better to have a pre-defined starting point for a blockchain though. Genesis block was hardcoded for the start, if I'm not wrong. Here's the snippet of the code. //
// Init with genesis block
//
if (mapBlockIndex.empty())
{
if (!fAllowNew)
return false;
// Genesis Block:
// GetHash() = 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
// hashMerkleRoot = 0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
// txNew.vin[0].scriptSig = 486604799 4 0x736B6E616220726F662074756F6C69616220646E6F63657320666F206B6E697262206E6F20726F6C6C65636E61684320393030322F6E614A2F33302073656D695420656854
// txNew.vout[0].nValue = 5000000000
// txNew.vout[0].scriptPubKey = 0x5F1DF16B2B704C8A578D0BBAF74D385CDE12C11EE50455F3C438EF4C3FBCF649B6DE611FEAE06279A60939E028A8D65C10B73071A6F16719274855FEB0FD8A6704 OP_CHECKSIG
// block.nVersion = 1
// block.nTime = 1231006505
// block.nBits = 0x1d00ffff
// block.nNonce = 2083236893
// CBlock(hash=000000000019d6, ver=1, hashPrevBlock=00000000000000, hashMerkleRoot=4a5e1e, nTime=1231006505, nBits=1d00ffff, nNonce=2083236893, vtx=1)
// CTransaction(hash=4a5e1e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
// CTxIn(COutPoint(000000, -1), coinbase 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73)
// CTxOut(nValue=50.00000000, scriptPubKey=0x5F1DF16B2B704C8A578D0B)
// vMerkleTree: 4a5e1e
// Genesis block
char* pszTimestamp = "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks";
CTransaction txNew;
txNew.vin.resize(1);
txNew.vout.resize(1);
txNew.vin[0].scriptSig = CScript() << 486604799 << CBigNum(4) << vector<unsigned char>((unsigned char*)pszTimestamp, (unsigned char*)pszTimestamp + strlen(pszTimestamp));
txNew.vout[0].nValue = 50 * COIN;
txNew.vout[0].scriptPubKey = CScript() << CBigNum("0x5F1DF16B2B704C8A578D0BBAF74D385CDE12C11EE50455F3C438EF4C3FBCF649B6DE611FEAE06279A60939E028A8D65C10B73071A6F16719274855FEB0FD8A6704") << OP_CHECKSIG;
CBlock block;
block.vtx.push_back(txNew);
block.hashPrevBlock = 0;
block.hashMerkleRoot = block.BuildMerkleTree();
block.nVersion = 1;
block.nTime = 1231006505;
block.nBits = 0x1d00ffff;
block.nNonce = 2083236893;
|
|
|
|
|
1608
|
Bitcoin / Development & Technical Discussion / Re: Why is it necessary to mine the genesis block?
|
on: April 08, 2021, 06:00:35 PM
|
And I'm asking again: What do you mean by saying "valid"? A proof of work is proof only if it's necessary. For example finding hash that doesn't exceed a certain target. Is your proof of work valid if you don't find such hash? You may have worked, but not enough to "prove" something. Satoshi worked, but there wasn't any purpose to do so. There wasn't something to be proved and thus, it's wrong to say that he mined the genesis block.
I think I have touched on the validity of a block above? Proof of work is a concept that proves that someone has expended resources in exchange for finding a hash that meets a target. Satoshi's genesis block proves exactly this and I'm sure he didn't get it by chance. You really don't have to make the genesis block valid, it is after all just something for your subsequent blocks to reference. You can test it out and construct it without meeting the target but I'm not sure whether it would fail with any validation or not. There is really no issues as long as you can exclude it from any (if any) PoW checks. |
|
|
|
|
1609
|
Bitcoin / Electrum / Re: Electrum 4.0.9 wallet sync problem
|
on: April 08, 2021, 09:16:17 AM
|
Actually I understand that Electrum may not be a good choice to handle a huge number of addresses. But in this situation if someone having rights is going to make transaction from Wallet A, the gap limit of wallet A is required to be changed as the same as Wallet B first in order to take the correct balance?
Balance in Wallet A will never be updated. The sole purpose of Wallet A is to sign the transaction and nothing else. Wallet B has to have the correct information and you will be able to have it since that is the wallet that is able to craft the transaction to be signed in Wallet A. It really wouldn't matter if the addresses doesn't appear in both wallets, if the corresponding master private key is in Wallet A, the addresses generated will never deviate. The wallet will also be able to tell which private keys to generate and sign as the PSBT generated by Electrum shows the full derivation path so the gap limit is not an issue at all. {
-snip-
"value": -snip-,
"n": 1,
"scriptPubKey": {
"asm": "-snip-",
"hex": "-snip-",
"reqSigs": 1,
"type": "witness_v0_keyhash",
"addresses": [
"-snip-"
]
}
}
]
},
"bip32_derivs": [
{
"pubkey": "-snip-",
"master_fingerprint": "-snip-",
"path": "m/0'/1/0"
}
-snip-
|
|
|
|
|
1610
|
Bitcoin / Electrum / Re: Electrum 4.0.9 wallet sync problem
|
on: April 08, 2021, 07:27:00 AM
|
I have changed the gap limit of Wallet B only. But this change does not reflect on Wallet A too. Do I need to also manually change the gap limit of Wallet A?
Yes. If you don't change the gap limit, it won't be shown in wallet A. Rule of the thumb is that as long as the addresses in Wallet B are also in Wallet A, any subsequent addresses generated will not deviate as well. I'm not sure how the gap limit of the offline wallet would work since it technically won't know which addresses aren't used? |
|
|
|
|
1613
|
Bitcoin / Development & Technical Discussion / Re: Crazy pow power reduction idea
|
on: April 08, 2021, 04:59:11 AM
|
|
I do think that the idea *could* be possible but the problem is with reaching the consensus for the variables that you've added. The network's time can deviate between node to node by quite a bit and it is difficult to synchronize all of them without a reference to a central server. Transactions aren't relayed instantaneously and there can be a delay between the nodes seeing it.
As for the benefits, I fail to see how this would increase the security at all. Given that you don't have to mine for 8 minutes, this makes it such that all of the work is done within the 2 minutes which would be much lower than the 10 minutes of continuous hashing that we have right now. It wouldn't bring older ASICs back into the game as the profitability would remain roughly constant; think of it as Bitcoin having to decrease the difficulty retarget to make 2 minute blocks. Standby power could still be fairly massive and would be much more inefficient than continuous hashing.
|
|
|
|
|
1614
|
Economy / Speculation / Re: Someone just bought 12000 Bitcoin on coinbase wonder why?
|
on: April 07, 2021, 05:45:04 PM
|
|
Coinbase outflows are not indicative of any trading activities as they're totally independent of that. If you're talking about trading Bitcoins, you should look at the trading volume
Outflows can only tell you the amount of Bitcoins that were transferred out of the exchange. Sounds like some people can't really read the text on the graph.
|
|
|
|
|
1615
|
Bitcoin / Bitcoin Discussion / Re: 652 Ukrainian officials declare holding a total of 46,351 BTC
|
on: April 07, 2021, 04:30:31 PM
|
North Korea and other nations with financial sanctions can run their bitcoin mining rigs. They will do it in secret but they don't lose anything when mining bitcoin. No data or article is available about this tactic but I think some are applying it.
I doubt it would really be worth it for them. Financial sanctions can be unforgiving for certain countries but Bitcoin mining would hardly contribute anything to their GDP. It would be tough to mine Bitcoins when your country doesn't even have a stable supply of electricity and your focus is on developing nuclear weapons. Training people for cybercrime is far more lucrative like what some of their APTs are doing. If these figures are true, then Ukrainians may be one of the largest holders of cryptocurrency in the world. Imagine this. If the few hundreds of officials are holding such a massive amount (0.3% of the circulating supply), then the remainder of the population should be holding at least 10x or 20x of that number. So we can confidentially say that Ukrainians own 3% to 6% of the circulating supply of BTC. This is a massive number and may be higher than the same from other countries such as India and Taiwan.
Probably not. You're ignoring the fact that most of the expendable wealth are concentrated in those with power and the normal citizen probably wouldn't even use Bitcoin. It is not an accurate way to estimate Bitcoin's usage in a specific country. |
|
|
|
|
1617
|
Bitcoin / Bitcoin Technical Support / Re: A basic question about how a Node finds a block
|
on: April 07, 2021, 03:22:07 PM
|
|
A node doesn't find a block, miners do but miners can be using a node as a source for the information and to propagate their blocks.
Generally, mining involves double hashing the block headers to find a hash the satisfies the target. The block header contains a few elements (block version, previous block hash, merkle root hash, nonce, timestamp, target, etc) and they are concatenated together to form a string which is then hashed twice, SHA256(SHA256(Blockheader)). The miners will determine the coinbase transaction as well as the transactions that they wish to include and create the merkle root. Afterwards, they'll hash it to form the hash of the block header and check if it satisfies the target. If it doesn't they will increment the nonce/extranonce and try again until they're able to generate a block header hash that meets the target.
Transactions that are included in a block are determined prior to the hashing, they cannot be added after the block is found.
The nonce is an arbitrary variable that is changed in order to be able to generate a different hash every time. It doesn't have to be determined as the user.
The miners are always mining, when a new block is found and propagated, they will reassemble a set of transactions (as some of the transactions may have already been included in the block) and change the previous block hash as well. Bitcoin mining is not a puzzle, despite what people make it out to be.
|
|
|
|
|
1618
|
Bitcoin / Electrum / Re: Offline seed and wallet-backup
|
on: April 07, 2021, 02:47:07 PM
|
|
1) It'll defeat the purpose. If you're looking for an airgapped setup, then you should never connect it to the internet or expose yourself to unnecessary attack vectors. Just use PSBT feature on Electrum to transfer the transactions back and forth using either a QR code or USB drive.
2) Your seeds are already backed up by writing it on a physical medium. The backup version doesn't matter, unless you're modifying details (labels, transaction description, etc) in between the backups and you're looking to still access them in the future.
|
|
|
|
|
1619
|
Bitcoin / Development & Technical Discussion / Re: Why is it necessary to mine the genesis block?
|
on: April 07, 2021, 02:10:03 PM
|
What do you mean by saying "valid"? How is a valid block defined? Every other block requires PoW to ensure that the majority of the computational power goes to the current chain and to prevent double-spending.
A valid block has to have at least a target above the minimum value as stated or a difficulty of 1. If it has zero difficulty, it is invalid. What exactly do you prove once you mine a genesis block? That you can achieve it with difficulty=1? As I said, you'd do that after to maintain the longest chain. What difference would it make if Satoshi had picked the first hash with nonce=1? There's nothing to be proved in the genesis block.
Probably nothing. I'm not sure whether Core skips the checks for a valid block when it comes to the genesis block. I'm not too familiar with the codes for Bitcoin Core but I'm pretty sure I've read somewhere that the genesis block still has to have sufficient PoW and was validated as per normal for at least in the first few release. Perhaps someone can add on to this. |
|
|
|
|
Show Posts
