Bitcoin Forum
April 30, 2024, 12:59:02 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 [95] 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 ... 461 »
1881  Bitcoin / Development & Technical Discussion / Re: Brute-forcing Bitcoin private keys on: March 02, 2021, 12:20:50 PM
Well as i can see that many of the replies are about how hard it is, i do understand that, let me give you an example of bitaddress.org which was used by many people back in the day to buy bitcoin, what are the chances that someone made a wallet and transfered some bitcoins to it and forgot about it, i can refere you to this https://www.reddit.com/r/Bitcoin/comments/1rli5i/if_someone_cracks_bitaddressorgs_number_generator/
Then you are exploiting potentially flawed PRNG which has been done and is completely feasible. Bitaddress uses randomness from different sources which would make it harder as you'll have to replicate both the tracked mouse movement as well as the randomness that was generated when the user enters the page.

These attacks can only work if they are using predictable variables as an entropy source. If and only if you can find a pattern in that generation, then you can reduce the search space significantly. Under no circumstances should any wallet be generating using flawed PRNG. Brainwallet stealing works similar to the above as humans are generally terrible at producing anything with sufficient entropy.
1882  Bitcoin / Development & Technical Discussion / Re: Help with info running a full node please... on: March 02, 2021, 12:03:09 PM
I really can't recommend you to run a full node if you do so only because you think that it is a good idea. Unless you are going to prune your node, you'll be looking at 360GB+ of data to be stored in your SD card. SD cards are not exactly suitable for constant I/O activity for extended periods of time so you'll probably have to get an external HDD as well. Given that it's quite underpowered, initial synchronization can take quite awhile as well. If your purpose is to use Bitcoin, then using an SPV client like Electrum on your Raspberry Pi might be better.

I've had some experiences running a full node on RPi. You have to get an SD card and install RaspBian on it, while adding a blank file called SSH. You'll be able to access the SSH interface on your local network with your IPad and a SSH app. The default username:password is pi:raspberry.

To get Bitcoin Core, you'll need the ARM version: https://bitcoin.org/bin/bitcoin-core-0.21.0/bitcoin-0.21.0-aarch64-linux-gnu.tar.gz.

There's a nice guide on the page itself: https://bitcoin.org/en/full-node#linux-instructions.
1883  Bitcoin / Development & Technical Discussion / Re: Does Bitcoin become more decentralized over time? on: March 02, 2021, 04:56:44 AM
How is that? Pruned nodes "benefit the network" just like any other full node, with just one exception: they are not helpful with the stupid bootstrap process in the current (experimental) implementation of the protocol, nothing else, not a tiny bit of any sign of being inferior compared to a historian full node ... I just made it up  Cheesy Tongue
And that is why I think we have fundamentally different ideas of how Bitcoin should function, based on your past response about how verification of block data is not necessary, etc. If your view is that blockchain data is not important, then I believe that you'll probably disagree with everything that I say.
We can only argue that more Archival Full Nodes are going to benefit the network only if there is a shortage of them that makes syncing hard for new nodes that come online or puts extra pressure on the existing Archival Full Nodes.
I don't think this is the case since we have enough of them to supply the historical blockchain.
I believe that there is nothing wrong with making it more available. Having more "archival" full nodes would be far more useful for initial synchronization both in terms of it's speed and availability. I'm aware that pruned nodes can almost function like an "archival" full node but I fail to see how it would be as beneficial than the other, given that the bulk of the benefits falls on the user using the full node. If the blockchain size grows even further, people that are hosting them on RPis and servers may not want to run it anymore.
1884  Bitcoin / Bitcoin Discussion / Re: Cooperative Mining on: March 02, 2021, 04:48:26 AM
Mining is an all or nothing race. This is why miners join mining pools. Only a tiny fraction of the total hash power of the network is saved in the block that gets accepted. Maybe there's a more fair and efficient way to mine. What if miners could mine cooperatively, taking turns generating each block and helping to hash the same block.
Most miners join a mining pool to put the responsibility of maintaining the messy back end to someone else and just focus on their own hardware. That and if they are a smaller mining operation, they can choose to mine at a pool for a more regular payout. The mining profit is roughly the same before deducting the pool's fees.
When a miner joins the network the other miners respond by indicating their position in line and what position the new miner can take.

Mining happens in rounds. In each round, the next miner gets a turn to generate the next block- just the block data not the hash. They then allocate workloads to the other miners based on their speed. A workload is a range of nonce values. The miner who generates the block essentially hosts their own temporary mining pool.

As each miner completes a workload, they broadcast it to the network so that everyone can confirm it. The host credits them and supplies another.

Confirmation of work doesn't require re-checking every hash in a workload. The number of hashes checked at random can be based on the number of miners online. With every miner checking only a few random hashes, each workload gets checked a lot. If any miner finds errors in a workload, they inform the host who then scans it more thoroughly. Rewards are only allocated for actual work.

When a block is solved, it gets broadcast to the network as usual and the next round begins with the next miner in line assuming the role of host. If a miner drops from the network the round goes to the next miner.

The block reward and fees of the current block cannot be allocated among the miners in the same round so they are allocated in the block that follows it.
Unfortunately, Bitcoin network does not allocate mining this way. The block reward is claimed by whoever submits a valid block with sufficient Proof of work. There is no concept of individual miners on the Bitcoin network. You could probably do this queue system if you could allocate some central party to regulate this which could possibly idealize in an altcoin. Miners don't actually "check" hashes but it is a matter of bruteforcing and finding a block header hash that meets the current target.
1885  Bitcoin / Development & Technical Discussion / Re: Brute-forcing Bitcoin private keys on: March 02, 2021, 03:40:19 AM
by studying the algos that create those wallets and patterns that may exist i think that number will be much lower, add to that if somehow you found thousands of people who are willing to brute force using a good algo for couple of years straight, then what are the chances that you maybe find a wallet with a large balance,
The complexity of those would still be fairly high, unless a weak RNG is used which could possibly lower the keyspace due to it's non-random generation. That's what some of the bruteforcing projects are attempting to do by getting these weak keys.
and for people who may say this theory is crazy and not possible i refere you to the guy who actually done just that for couple of years and found private keys of 3 small wallets.
Possibly weak keys.
This is like digging for gold and by technology going up i believe oneday it will be possible to brute force about 20-100 wallets each year using some crazy asic machine and a whole industry will be built around just this idea.

this is just a theory of mine which made me curious, would love to hear what you think other than no it's impossible.
Current ASIC cannot be used to generate addresses but it should be fairly simple to do so as well. Other than the speed (which we have established that it would have to generate addresses extremely quickly), you'll have to compare the addresses generated to those addresses that currently have any Bitcoins which could present itself as a slight bottleneck depending on the way it gets designed.
1886  Bitcoin / Development & Technical Discussion / Re: Does Bitcoin become more decentralized over time? on: March 01, 2021, 02:26:08 PM
I don't get it.  Roll Eyes
Why People are so concerned about HDD capacity? We have pruning already, a pruned full node works just fine.
Pruning works just fine. I think we have fundamentally different concepts of what true decentralization is; which is for everyone to have a copy of their blockchain for me as we're touching on the topic of decentralization. You may correct in your own right and I can't really dispute that either. I'd prefer having more nodes with the entire blockchain rather than nodes which only stores the last few GBs of the blockchain which really wouldn't benefit the network more than the others.
1887  Bitcoin / Development & Technical Discussion / Re: Does Bitcoin become more decentralized over time? on: March 01, 2021, 01:08:34 PM
I agree, however wallet such as Wasabi (which uses Tor, BIP 158 or both of them) usually took some minutes for first time sync.
They would still have lower requirements than Bitcoin Core; less bandwidth, less time taken, more privacy, etc. Definitely would outweigh any disadvantages.
Few years ago I purchased 4TB HDD disc and that is now even cheaper, and SSD disc are now also affordable and much faster.
When I purchased my first SSD it was expensive and had limited storage, but now you can find 1TB or 2TB SSD M.2 like Samsung or Adata in reasonable prices with good five year warranty.
I think current size of Bitcoin blockchain is around 330 GB, and with current yearly growth of around 25% I think that having few TB disc will last for years without any issue.
At current capacity, Bitcoin can't stay at that rate of growth if we want to accommodate more transactions. I'm not too sure about the rate of growth for HDDs, price might have gotten cheaper but the growth of Bitcoin could be faster than the growth of HDD capacity. I have doubts that most people can have enough space for a full node ontop of their own files and would probably just to forego that completely. Coupled with a fairly long initial synchronization as well as a catchup after not opening it for a while.
1888  Bitcoin / Development & Technical Discussion / Re: Why are we crippling the initial sync? on: March 01, 2021, 03:05:44 AM
I knew I would get a comment like this.

Do we really think there are ten of thousands of nodes not accepting connecting being spun up in secret?  Or can we go with the simpler explanation of not many people are bothering to spin up a node and we shouldn't be making it harder to do so because at some point it may or may not be a problem.
Well, yes. If the service only records nodes that it can establish a connection to, then it wouldn't reflect those which aren't allowing it. There really isn't a reliable way to get every single node in the world.

There isn't anyone trying to make the synchronization any harder than it is. Loads of optimizations have been made but older computers will still suffer due to their hardware. IBD will be the longest process for most so it really isn't that big of a concern as you're only doing it once.

Samsung SN550, if a QLC drive causes it to take 4 weeks to sync something is really broken with the network.  But like I said when I manually added a bunch of nodes that had either TELUS or Google Fiber as their ISPs my sync time dropped to 40 hours.  Slowly as they disconnect and I go back to the 8-9 nodes my sync time goes back to 3 weeks.
Definitely shouldn't take 4 weeks, especially with NVMe if you're talking about WD SN550. My synchronization took a day with my HDD and 6 hours on my SATA SSD but they had 6GB of dbcache. Is your ISP throttling your connection by any chance?
1889  Bitcoin / Development & Technical Discussion / Re: Why are we crippling the initial sync? on: March 01, 2021, 02:29:39 AM
Those are the nodes which allows incoming connection. It's methodology gives an inaccurate sampling of the actual node count as it doesn't take into account the nodes that doesn't allow incoming connection.


Based on the estimate and how much I've managed to sync over the last three days.

More importantly when I added a bunch of Nodes manually the estimate dropped to 40 hours. and speed of sync dropped dramatically.

Adding nodes may not always help. Some nodes are crawlers which will not help in your synchronization and would infact slow it down. The synchronization estimate will fluctuate quite wildly, when it hits a patch closer to the present day, the synchronization would slow down a lot as the more recent blocks contains much more transactions to be validated. Increasing the dbcache will help quite a lot.

Depending on your SSD model, some QLC SSDs will slow down significantly after the cache gets filled.
1890  Bitcoin / Electrum / Re: Lost Bitcoines In A Transaction to Coinbase on: February 28, 2021, 02:43:34 PM
1) how much of these transaction details do I need to share, and/or should I share publicly, without potentially being duped by someone else allocating my bitcoins (if the bitcoins are even retrievable)
Transaction's details are public on the blockchain, unless you're sharing your 12 word seed or your private keys, you should be fine. Sharing it does mean that your privacy would be gone; people can link the transaction to the account that you're using right now.
2) At the time I entered my coinbase wallet 'address', or so I thought, but nothing showed up, even after weeks of checking. so if I did end putting in the wrong coinbase number - does this mean coinbase could potentially help me in retrieving the bitcoins, or does this simply mean the bitcoins are lost in the deep ether of the internet?
I assume you are checking your transaction on a blockexplorer like blockchair.com? If it didn't show up on the blockexplorer, can you try searching up the address that you have sent the funds from? If the transaction ID cannot be found on the blockexplorer or if the address is wrong, Coinbase can't help either.
1891  Bitcoin / Development & Technical Discussion / Re: Does Bitcoin become more decentralized over time? on: February 28, 2021, 11:08:34 AM
The concept probably won't have any suitable metrics to be used as a gauge so I don't think there is any absolute answer to this.

With the growth of Bitcoin, you're going to inevitably eliminate the smaller scale miners who can't afford to keep their costs down. It would result in having miners probably being centralized around certain regions and farms. Mining would probably never be any more decentralized.

As for the full node count, I suspect that some nodes actively block Bitnodes crawlers as they publicly list their IPs and thus resulting in a much lower node count. Running a full node is obviously not so viable for most people; even in 2021 360GB+ is fairly significant if you consider that some laptops and/or desktops only ship with 1TB of storage. That, combined with the very few advantages over SPV (which I assume most actually wouldn't consider), will probably reduce the full node count over time. I can't see the point of most people running Bitcoin Core when using Electrum or Wasabi would suffice for their use case while wasting no time to synchronize whenever they're using it.

1892  Bitcoin / Bitcoin Technical Support / Re: Which scenario is safer than the other? on: February 28, 2021, 08:23:36 AM
So without RBF I guess I can still use Electrum to manually delete the transaction and re-broadcast it with a higher fee and differenr outputs? Is that because miners take higher fees with priority? I thought a non-RBF tx automatically means a re-broadcasted one will be invalid.
You can. Miners are ultimately the ones that determines the transactions that are included in their blocks.

By default, the reference client with those which recognizes opt-in RBF flags will not relay replacement transaction if the transaction that it is supposed to replace does not have a opt-in RBF flag. As such, having no RBF flag would only result in the replacement transaction having a poor propagation provided that those nodes have knowledge of the first transaction. Replacing a transaction without a RBF flag will not make that transaction invalid, just that the poor propagation will result in miners potentially having no knowledge of it.
1893  Bitcoin / Bitcoin Discussion / Re: Block chain "cleanliness" analytics on: February 28, 2021, 04:06:36 AM
does anyone know if coinjoin , wasabi, whirpool technology prevent tainted coins from entering mix pool?  
Most services actually prohibit CoinJoin transactions as they're pretty easy to detect, whether it's tainted or not. As said before, unless you're able to pay some Bitcoins to a miner for newly mined coins, there probably isn't a way around it to get 100% untainted coins.
1894  Bitcoin / Bitcoin Discussion / Re: Block chain "cleanliness" analytics on: February 28, 2021, 03:39:59 AM
Bitcoin is fungible. Taint is just a metric invented by governments or companies to try to seize your funds under the guise that it is used for illicit activities. Having a tainted coin should not diminish the value in any way. Most exchange and services only restrict accounts if they see evidences of the coins being sent directly through a casino or any other services that is prohibited within their jurisdiction.

Since there is no metrics to determine whether a coin is tainted, there really isn't a surefire way to determine a level of taint that is universally recognized. Every coin is tainted at some point in their history as it gets mixed around, unless it is a newly generated one which really means there is no point in trying to find one that isn't.
1895  Bitcoin / Electrum / Re: Create Multisig Wallet with public key? on: February 27, 2021, 02:59:36 PM
Those are addresses. You cannot create a multisig redeem script from addresses as they are the hash of the public keys.

If you have the ECDSA public keys of the addresses, you can create a multisig address and it's corresponding redeem script but you won't be able to import it. You can use createmultisig function from the console as below:
Code:
createmultisig(2,["PUBKEY1","PUBKEY2"])
1896  Bitcoin / Development & Technical Discussion / Re: How about placing miners into groups where each group is similar to a bank? on: February 27, 2021, 01:16:47 PM
but you would have the same level of security as when every single computer on Earth gets automatic windows software update every day from a THRUST worthy address such as Microsoft.com (instead of NorthKorea.com). Otherwise all of Earth's computers would presently be infected by viruses but they are not.
That alone would defeat the purpose of Bitcoin won't it? Making all of the computers ping certain centralized server is not good. There is really no such thing as "computer security", there are tons of zero day exploits which could be used by any adversary before it gets patched.

From what I can tell, you're basically describing something like a centralized banking system but instead of bank officials, miners are the ones that regulate this. It would be good if you could read up more about Bitcoin first and its derivative protocols. I think Lightning network would interest you with this particular aspect that you're talking about.
1897  Bitcoin / Development & Technical Discussion / Re: How about a cutoff date for mining on: February 27, 2021, 11:50:15 AM
How are you going to build and lengthen the blockchain without any miners?

If you are talking about switching to POS, it (probably) won't happen. The difficulty helps to balance it out, as the profit margin decreases, mining would be left to those with cheap electricity (probably hydro or other renewable sources) and efficient hardware. Not like electrical usage is really as much of a concern as the media makes it out to be.
1898  Bitcoin / Hardware wallets / Re: What is the most secure device to store Bitcoin? on: February 27, 2021, 11:48:49 AM
Then your private keys would never touch an online environment.  The problem is that the USD device to move the signed transaction might be a vector as well.
The USB?

Using a QR code might be better for this, it's like a one-way communication and would give a true airgap setup. I think there is some limits to the size of the transaction, but that shouldn't be of a concern. If it gets too large, then you can just use multiple QR codes to stitch it together or use a different encoding. Electrum uses base43.
1899  Bitcoin / Development & Technical Discussion / Re: MIT announces 4-year project that seeks to strengthen the Bitcoin Network Sec. on: February 27, 2021, 11:42:57 AM
Exactly what I meant, but it is normal to critize the network, but the criticism are not true. Also, bitcoin itself is said to be ponzi and all sort of things like that, all because it is open source. If it is close source like the monetary system that is centralized, it will not be critizied because they think govements will protect such but not knowing it is not perfect as open source and decentralized like bitcoin specifically. Check my quotes above to get the total picture of my post.
It's a blanket statement to dismiss it as untrue. Bitcoin does have its merits as a decentralized network but there's obviously a lot of work to be done. A 51% attack is not the focus of the project but to explore the other possible vulnerabilities regarding the protocol itself. Mining will never decentralized, at its current stage. Barring the Chinese government banning Bitcoin mining completely, it is impossible for them to not hold a majority of it; most ASIC manufacturers are based in China and the cost of mining is probably much lower there as well.

Obviously 51% attack is not economically viable if you were to just own the hardware and operate the ASICs yourself. The article doesn't dispute that but rather it was calling for a monitor *in the event* that it happens, which is completely rational. Bitcoin being open source doesn't mean that it won't have any vulnerabilities which I presume is what this is set up for. I don't think any of the statements mentioned in the article are unfounded, might be getting a bit offtopic with your replies here.
1900  Bitcoin / Development & Technical Discussion / Re: MIT announces 4-year project that seeks to strengthen the Bitcoin Network Sec. on: February 27, 2021, 09:43:59 AM
It is normal to critize anything open source, but the true design of Bitcoin makes 51% attack not to have occurred.
What? Bitcoin functions on the economics of game theory to ensure that 51% attacks are infeasible.

I can't really see anything bad that could affect Bitcoin. At best, they could contribute actively to Bitcoin development and at worst nothing happens. As for the 51% monitor (or rather double spend/forks), here it is: https://forkmonitor.info/nodes/btc.

Pages: « 1 ... 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 [95] 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 ... 461 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!