Though it might be possible for nodes to be subject to attack, the attacker must redo all the works that have been done on the node and the works done on the later blocks that have been attached or chained to the previous.
This is where the impossibility comes in given the fact that, it’s a system that largely depends on the majority and the number of users running nodes have ran into thousands if not millions and priority is always given to the longest chains which is impossible for any of such attacker to have therefore, the chances of taking control over the computation isn’t possible.
That has nothing to do with nodes, but it concerns the miners and the cumulative proof-of-work and that ensures that it is computationally difficult to rebuild the blockchain for a 51% attack for example. Longest chain is always one that has the longest cumulative proof-of-work and thereby expensive to attack. It is not impossible, just very expensive and possibly infeasible without tons of resources. There are several node specific attacks, Sybil attacks and Eclipse attacks are examples but Bitcoin Core has certain safeguards for it. |
|
|
|
Why not -addnode instead of -connect, if I may ask? You will most likely want to add other nodes to connect to, like Tor onion nodes and such, in the event that your server node becomes inaccessible or goes down for some reason. But you will at least be able to control which nodes you will get inbound and outbound connections to, instead of showing your IP address to the entire network.
Using connect makes sure Bitcoin Core only uses the nodes that you've specified while addnode would preferably try those nodes but will connect to others if they fail. If I'm not mistaken, both would propagate your IP address to others through addr messages. However, addnode would likely not enhance your privacy at all, as compared to not running addnode at all. |
|
|
|
|
It is not possible, you can possibly associate addresses to distinct users or a group of people but under normal circumstances you would not be able to link them to individual wallets. Addresses cannot be linked as the public keys and the addresses are not linked by any pattern, and thereby indistinguishable. The linkage you are talking about has to do with chain analysis of transactions.
For example, imagine that I have 3 addresses in a wallet and I have funds in all of them. If I were to spend all of them in one transaction, you can possibly deduce that the three addresses are linked to a single entity. Of course, there are scenarios where this may not hold true, but it can be accurate to a good degree.
|
|
|
|
No, I don't check serial numbers. The difference here is, the systems at play with crypto are not the same as you giving some cash to a cashier or whatever. There is not some realtime global database on every payment. Also, cash in general, is used by regular people, grandmas etc. It doesn't have a bad rep (increasingly lately.. but in general, it is seen as normal). If you are a "Bitcoin person" you are standing out from the rest already. And governments hate crypto by default, banks do so too. This is why they block transactions all the time, even with KYC exchanges. So it's not the same thing at all. They will find any excuse to extract as much money as possible from you and scare you from using it. I am not looking forward to be used as an example of that. And as far as Monero, we can see what happened. It was kicked from most exchanges, you cannot cash out Monero to buy anything of relevance.
Genuine question: then why would Bitcoin be in the discussion at all? If you are so worried, then using traditional fiat and ditching Bitcoin would be the way to go. If your government is not fond of their citizens using Bitcoin, then they would find and make up reasons to find fault with you. Even if there is zero taint, I'm sure there is a good reason why you should get investigated. If you are afraid that there is a possibility that this would happen to you, stick to fiat. Else, if you are aware of your rights and understand how the law operates, I don't see how this would be an issue at all. Otherwise, if you are afraid that exchanges would find fault with you, or whoever you're transacting with, then you should stick to fiat and PayPal. Zero taint doesn't exist, unless you are willing to pay a premium in exchange for freshly minted coins. You would probably have to declare your income source as well, I don't think it is worth the hassle and the paranoia for you. |
|
|
|
If you know the first letter of the 12 words,you will have fifty-fifty possibilities to recover the wallet.Because some wallet will provide the base word,if you know the first two letter of the words means.The possibility of recovering the wallet is huge.For example,the word is hat,hen.The first letter of this two words are the same one,but the second letter of the word made the word was different one.I had not get in to the meaning of the words,when the word of the wallet doesn’t require a meaning.Most of the people use to Copy paste their wallet recovery words seed in the saved messages of their telegram or other social media accounts.
So I request you to find the 12 words from the saved place.Before I had faced the same issue,but my problem not solved by the first letter prediction.The way I had chosen was to find the place where I had saved my wallet private key.If you have a private key,it was another way to recover the wallet access.
It is not fifty-fifty, the probability isn't just (able to recover/unable to recover)  . Anyways, even if you have the first two characters, it might not be as easy as it seems. If you're really lucky, then your search space can get narrowed significantly, or else it would still be time consuming. {'ab': 10, 'ac': 14, 'ad': 9, 'ae': 1, 'af': 3, 'ag': 4, 'ah': 1, 'ai': 4, 'al': 15, 'am': 5, 'an': 16, 'ap': 6, 'ar': 18, 'as': 7, 'at': 6, 'au': 7, 'av': 3, 'aw': 6, 'ax': 1, 'ba': 19, 'be': 20, 'bi': 8, 'bl': 14, 'bo': 17, 'br': 20, 'bu': 19, 'ca': 42, 'ce': 7, 'ch': 25, 'ci': 6, 'cl': 24, 'co': 41, 'cr': 29, 'cu': 11, 'cy': 1, 'da': 10, 'de': 38, 'di': 27, 'do': 13, 'dr': 15, 'du': 7, 'dw': 1, 'dy': 1, 'ea': 8, 'ec': 3, 'ed': 3, 'ef': 1, 'eg': 1, 'ei': 2, 'el': 9, 'em': 8, 'en': 21, 'ep': 1, 'eq': 2, 'er': 6, 'es': 4, 'et': 2, 'ev': 4, 'ex': 23, 'ey': 2, 'fa': 22, 'fe': 12, 'fi': 20, 'fl': 15, 'fo': 19, 'fr': 12, 'fu': 6, 'ga': 17, 'ge': 6, 'gh': 1, 'gi': 7, 'gl': 12, 'go': 10, 'gr': 16, 'gu': 6, 'gy': 1, 'ha': 15, 'he': 11, 'hi': 7, 'ho': 18, 'hu': 12, 'hy': 1, 'ic': 2, 'id': 3, 'ig': 1, 'il': 3, 'im': 8, 'in': 32, 'ir': 1, 'is': 3, 'it': 1, 'iv': 1, 'ja': 4, 'je': 4, 'jo': 5, 'ju': 7, 'ka': 1, 'ke': 4, 'ki': 11, 'kn': 4, 'la': 20, 'le': 18, 'li': 17, 'lo': 14, 'lu': 6, 'ly': 1, 'ma': 33, 'me': 21, 'mi': 17, 'mo': 21, 'mu': 10, 'my': 3, 'na': 7, 'ne': 15, 'ni': 2, 'no': 13, 'nu': 4, 'oa': 1, 'ob': 7, 'oc': 3, 'od': 1, 'of': 4, 'oi': 1, 'ok': 1, 'ol': 3, 'om': 1, 'on': 5, 'op': 5, 'or': 9, 'os': 1, 'ot': 1, 'ou': 4, 'ov': 3, 'ow': 2, 'ox': 1, 'oy': 1, 'oz': 1, 'pa': 25, 'pe': 14, 'ph': 4, 'pi': 14, 'pl': 10, 'po': 19, 'pr': 29, 'pu': 16, 'py': 1, 'qu': 8, 'ra': 21, 're': 48, 'rh': 1, 'ri': 16, 'ro': 15, 'ru': 7, 'sa': 19, 'sc': 15, 'se': 23, 'sh': 23, 'si': 19, 'sk': 7, 'sl': 12, 'sm': 5, 'sn': 5, 'so': 21, 'sp': 25, 'sq': 3, 'st': 33, 'su': 25, 'sw': 11, 'sy': 4, 'ta': 13, 'te': 10, 'th': 15, 'ti': 11, 'to': 28, 'tr': 28, 'tu': 8, 'tw': 6, 'ty': 2, 'ug': 1, 'um': 1, 'un': 18, 'up': 6, 'ur': 2, 'us': 6, 'ut': 1, 'va': 12, 've': 11, 'vi': 16, 'vo': 7, 'wa': 16, 'we': 12, 'wh': 8, 'wi': 17, 'wo': 10, 'wr': 6, 'ya': 1, 'ye': 2, 'yo': 3, 'ze': 2, 'zo': 2}
|
|
|
|
The MB limit (AKA, the max size of block files) has nothing to do with the need for re-scan or the "balance detection", unless you meant something else. When you import a new private key in a Bitcoin client that does not index transactions (with txindex=1), then you need to re-scan the blocks. If, however, you're running pruned node, then re-scanning requires re-syncing, because you don't have all the blocks to perform transaction indexing. So you need to re-download them.
You can import the private key and specify false for rescan such that you don't have to rescan and reindex for a pruned node (ie. importprivkey "privkey" "" false). Thereafter, if all of your transactions are within your pruned limit, you can do a rescanblockchain start_block end_block to scan for transactions within the pruned range. If not, then you can just do a importprunedfunds to import your UTXOs into the wallet if it is not within the pruned range. Whilst not perfect, you can still initiate a rescan so long as the blocks are on disk. |
|
|
|
1) Do they need to generate a new Bitcoin address for this purpose, or can they use their existing addresses?
No, but it doesn't hurt to separate them. Usually, we generate and use new addresses specific for MultiSig for the sake of simplicity and avoiding the confusion by having dedicated addresses for them. Note that you don't generate multisig with addresses, but with public keys. 2) Could someone provide a step-by-step guide on how to achieve this using Bitcoin Core or Electrum, preferably with an example?
For Bitcoin Core: https://developer.bitcoin.org/reference/rpc/createmultisig.htmlFor Electrum: https://electrum.readthedocs.io/en/latest/multisig.html3) Is it necessary to fund the newly created Bitcoin address during this process, or can they generate the multisig Bitcoin address without funding it?
No, similar to how you don't have to transfer funds to Bitcoin addresses when you generate them. If Alice and Bob want to transfer all their coins to this newly created multisig 2-of-2 address, do they both need to approve the transaction along 2-of-2, or can Alice and Bob independently execute the transaction as usual from their private addresses, with the multisig address as the destination?
Restriction only comes in when you are spending the wallet; you would need the unlocking script (generated with your two public keys) and valid signatures when spending funds from that address. In case Alice and Bob want to fund the new multisig address they can use any bitcoin source address, right?
Yes. There are no restrictions when sending funds to any address types. However, I've still an unanswered question that was born out off this: is the Bitcoin address of Alice and Bob somehow related to the new-created multi-sig address or can Alice and Bob continue using their private address as they were used to before the multi-sig address creation ?
They are independent, it is just that signatures from those two addresses are required to spend. Alice and Bob can both use their own addresses as well. Though I do not recommend this; just create a new address.
There appears to be some confusion about HD wallets and Multisig setup. Multisig is created by having only public keys of the signatories, and creating a Multisig address which the appropriate script. The master public key IS NOT involved in the creation of the multisig address. When you create a Multisig wallet with a HD seed, the wallet does the above automatically for you, with the different public keys generated from your HD wallet. As such, you have a "HD Multisig Wallet", which is generated by the combination of the public keys from the different seeds. Ie. Index 1 of HD Seed A with Index 1 of HD seed B to generate Multisig Address 1, Index 2 of HD Seed A with Index 2 of HD seed B to generate Multisig Address 2. |
|
|
|
Looks good, but you should still connect to your node through TOR. If you want to prevent your IPs from being leaked or your activities from being tracked by ISPs or any adversary, you should use Bitcoin Core with Tor on watch-only computer. Using VPNs, proxies or SSH tunneling may not provide sufficient privacy or safeguards against traffic analysis assuming that you want complete privacy. Using it over clearnet also guarantees that your ISP will be able to monitor your every move; connections are not encrypted between Bitcoin nodes. When using TOR and running on onion network, there is virtually no privacy benefit on connecting to the node on your server besides complicating the whole process. The setup guide for running your node over TOR is here: https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md. |
|
|
|
|
Satoshi isn't Bitcoin and he should not dictate what Bitcoin is and what direction should development go. He doesn't have the benefit of hindsight and cannot possibly predict whatever would've happened in the years to come and expect Bitcoin to continue the direction that he wanted. Development of Bitcoin should be fluid and evolving as time goes by.
Whether Bitcoin is decentralized, I would say that it still is. There isn't anything that we have done to break the balance between decentralization and utility.
|
|
|
|
Actually you didn't pay attention to the prerequisite accompanied OP's scenarios. He clearly said "lets say the fee rate is the same in both scenarios." Besides. no one right minded would not consolidate to "into an exchange " . Thus, I'm sorry, but you speculations have no sense. Answers which highlights the second scenario as the cheapest one are accurate.
I did. No need to apologise, you might've misunderstood me. I didn't make the assumption between making transactions of different periods, and thereby differentfee markets. We usually consolidate UTXOs periodically when fees are low, and hence you gain an advantage in the future; you avoid paying a higher fee in the future when fees are high. Sure, that'll make sense if and only if you expect the benefits for adding another transaction to be lower than that just being able to spend an entire UTXO in its entirety and thereby making it a 1 input to 2 output transactions in the future. As much as we should provide general advice, I'm thinking of a different scenario where it can be applicable to some. Let's say I have 20 x 0.01 BTC UTXOs, periodic payments, service payments, etc. Then I want to pay another person 0.01BTC, or 0.05BTC periodically, let's say per month. Would it make sense for me to do a consolidation with: 20 inputs -> 1 UTXO, and then 1 input -> 2 UTXOs over another 4 transactions. (1402+(141*4)) = 1966 Or 5 inputs -> 1 or 2 UTXOs 4 times (412*4) = 1648 Note that I'm not invalidating the advice given, I even suggested that the second transaction could be better in general. It'll be important to understand someone's spending habits as well. I don't see any harm trying to understand if OP can possibly predict and estimate their spending behaviors over the long run. |
|
|
|
Anyway, back to the seed phrase where 24 words is much safer but still it is possible to lose money if ever a person is able to know the words then he/she will be able to take it out of the wallet. Losing money is not all about brute force but scammer find a way to steal your wallet seed phrase. It is all up to the owner to keep the wallet safe.
12 words and 24 words have marginal difference in security increment. I wouldn't call it much safer by any regard. 12 words seed phrases are easier to keep than a 24 words seed phrase and hence a better option. |
|
|
|
|
If you find a wallet on the floor, is it legal for you to keep the money inside and leave the wallet on the floor? The answer is probably no in your jurisdiction. Same applies for Bitcoin as well, not legal advise but I'm fairly sure that it would be illegal in your jurisdiction. Regardless, it would be impossible for you to just come across a funded wallet. You would get yourself in trouble with something else in that case.
|
|
|
|
I actually thought the answer to this would be ‘not possible’ but instead, what I see is means and criteria for this to occur by altering some part of the hash in a supposedly interconnected blockchain network.
Wouldn’t this likely possibility create room for double spending and therefore, allowing counterfeiting which is a problem of currency with this being the exploited option for digital currency?
It isn't exactly the problem, because Bitcoin solves both double spending and the byzantine general problem. The existence of 51% attack doesn't invalidate both of them. It is true that you are able to exploit the network and in a sense "reverse" a transaction that was previously included in a longest chain on the network. However, it is also true that in any of the longest chain of the network, you can only spend a single UTXO, or unspent transaction output exactly once. Hence, by the exact technicalities of double spending, it isn't considered double spending. To the point about double spending, the issue would be whether it is worth it for any attacker to execute such an attack on Bitcoin. The amount of hashpower required to execute the attack is rather high, and for a potentially low reward. Most exchange or big services requires a number of confirmations before they would credit the deposit. Hence, it is likely that an attacker would require 51% of the hashpower to execute a worthwhile attack successfully. For a sustained attack, you would likely have to invest in tens, or even hundred of millions of resources for an extended period of time. This is very costly and there is no chance that zero precautions would be taken against the attacker, by the merchant for a transaction of this size. In addition, consider that the Bitcoins that are double spent would essentially be worthless after the attack with the community's response. Even if the attacker is a government entity that wants Bitcoin's demise, I doubt the impact would be significant enough such that Crypto would be killed off forever. |
|
|
|
Here is the distribution of the number of words in the Electrum Wordlist: {'a': 136, 'b': 117, 'c': 186, 'd': 112, 'e': 100, 'f': 106, 'g': 76, 'h': 64, 'i': 55, 'j': 20, 'k': 20, 'l': 76, 'm': 105, 'n': 41, 'o': 55, 'p': 132, 'q': 8, 'r': 108, 's': 250, 't': 121, 'u': 35, 'v': 46, 'w': 69, 'y': 6, 'z': 4}
In the best case scenario, you have 4^12 combinations with all z, and the worst case would be 186^12 with all c. While it isn't impossible, you would have to be quite lucky to be able to find the seeds with that limited amount of information. If you have any other clues other than the first words, you might stand a slightly better chance though I wouldn't exactly count on it. Small correction: the worse case is 250^12 with all s.
Thanks... I should've sorted it. |
|
|
|
|
Actually, there is insufficient information so none of the answers can possibly be accurate. If you are talking about the scenario that you've posted without any further transactions, then your second transaction would consume less fees because it has a smaller size in total.
Think of it this way: If you are consolidating transactions, you are making use of periods of lower fee rates to reduce the fees that you have to pay if you were to spend multiple inputs at once in the future, where fee rates are higher. Hence, you can pay less fees by having a smaller TX size; 1 inputs to 2 outputs instead of many to 2.
If you know that some of UTXO can possibly cover the entirety of another transaction, ie. depositing it into an exchange in the future, then you can simply deposit with 1 input to 1 output transaction when required, instead of having to consolidate to yourself, thereby incurring additional fees. However, if you are unsure and you want to take advantage of being able to use lower fees to get your transaction confirmed, then a consolidation would be your ideal way forward. Instead of having to spend multiple UTXOs together in the future, you just need to spend one of the UTXOs.
If you have any transactions that you would need to make immediately, it would be a good idea to use all your UTXOs or more UTXOs than needed, and consolidate them into a change output.
|
|
|
|
Why is it critical for the request to expire and not the address? Who I am requesting it from? I don't see it's utility.
Address doesn't expire and cannot expire. It is irresponsible for any wallet to discard the private key of an address because of an arbitrary expiry time. The reason for having requests with a fixed expiry is for record keeping. In certain cases, it would be important for people to keep track of the time when funds are being transferred and hence it would be good for users to know when they should receive the funds by and if it has been transferred within that timeframe. For example, if I'm a merchant trying to sell an item, I would want the buyer to transfer the funds within 24 hours, and after which the transaction becomes voided (because my rates are only valid for 24 for example). Having an interface which tells you if the funds has been transferred within a certain time helps me to track my payments from my buyers. |
|
|
|
So if I summarize your answers, it is possible for someone with knowledge of the private key to replace and change a transfer of a UTXO at any time and indefinitely (including inputs and outputs and the amounts to be transferred), provided that the UTXO is unconfirmed in the current one Blockchain.
Yes, provided that it is not included in the block. These transactions are not considered as final until they are included in a block. RBF is purely implemented by the node's mempool policy and it comes with the reference client. As such, it would be dependent on the node's mempool policy to either "replace" or drop the transaction entirely. For the reference client which implements BIP125, the behavior of the client is outlined as per the proposal provided that no further modifications are done to it. |
|
|
|
The general limit for the maximum descendants of 25 for transactions would limit your ability to do so as well. Because of the double counting as stated, you probably can have less than 100 unique descendants for the limit to be reached as well.
But the 100 transactions don't have to be in a single chain. I can make a transaction with 99 outputs and then spend those 99 outputs in separate transactions. If I replace the transaction including 99 outputs with RBF, nodes would remove 100 transactions from their mempool. Correct, the example that you've given is correct with exception in certain cases. Reference client's mempool has a maximum descendant limit of 25, and from what I understand (and previously experimented), the mempool limit also applies when the any of the ancestors transactions has reached the 25 descendant limit. Other than that, because of the way the descendants are counted, it may be possible for transactions to be double counted as well. This would be the case with my example in the first post. |
|
|
|
I don’t quite get this question but if you’re asking weather if a transaction before confirmation can be changed I will say in a way yes it can be done and an example is an RBF done on a transaction to another transaction, this is a change since it is transferred to another other address other than the first intended one by increasing the transaction fee.
I will say alterations doesn’t happen due to decentralization of the bitcoin network, if a particular node wants to carry out something not proper on the network other nodes will simply reject and since bitcoin works on consensus you can alter any thing like that maybe till you control more than or 52% of the total network hash power
RBF doesn't actually result in the transactions being changed. RBF is used as a method for a transaction to be replaced in the mempool, neither the original transaction or the new transactions are modified. In fact, you don't even have to use RBF if a miner is directly able to mine another transaction for you. You cannot change the consensus rules of Bitcoin even if you control all of the miners on the network. However, if you were to build blocks faster than the rest of the network, you can execute a 51% attack with a 100% certainty. That doesn't mean that you cannot do so with hashrates below 51%, it would just mean that the success rates would be lower. |
|
|
|
|
Show Posts
