Bitcoin Forum
May 26, 2024, 12:52:06 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 »
1  Bitcoin / Development & Technical Discussion / Re: Brute force private key tool? on: September 17, 2013, 09:53:10 PM
Is there a tool that is able to brute force the private key, given a full Bitcoin address? I know it's nearly impossible, but want to try just for fun.

That's the problem, people can't even imagine how unlikely it is to find the correct private key without knowing anything about it except the public key(no shortcuts in the algorithm etc.). It's safe to replace the word "unlikely" by "impossible" in this case without altering the sense.

Thinking about low probabilities:

Take your pen and let it fall of your desk. While falling the pen will convert its potential energy to kinetic energy. The air in your room will absorb some of that energy and the rest will be absorbed by your floor when the pen impacts. Now in theory it's possible that the molecules surrounding your pen while it lays on the ground are all moving up and therefore pushing the pen up. But considering the amount of molecules it's very very unlikely one would even say impossible to happen(actually it's so unlikely that the 2nd law of thermodynamics even forbids it). It's much more likely that some molecules from above push it down and some from underneath push it up, same goes for right and left -> it won't move.
Now what would you tell someone who asks to borrow your video camera to film the pen 24/7 to see when it will fly back on the desk because it's theoretically possible?

Don't try to brute force it. Just wait until some bird's shit on your car takes the form of the private key.
2  Bitcoin / Development & Technical Discussion / Re: Block Chain Size Solution: Gather all bitcoins into super account, redistribute on: September 15, 2013, 07:59:16 PM
Well, as far as i can see you are proposing to prune everything but unspent outputs. That's nothing new. The only thing that's new is doing this by transfering everything to a developer and then back to individual wallets, so in your scenario the developer holding that super account can fck up everything if he wants to.

Doesn't sound very good to me.
3  Bitcoin / Development & Technical Discussion / Re: Questions behind mining on: June 20, 2013, 07:59:55 AM
As far as I see, the basic idea of mining, is that we get piece of data, where we need to try all variants of 4 specific bytes = 2^32 variants, we hash this data using SHA256 and if we get value meeting our difficulty requirements we "win"(?)

The basic idea of mining is that you proof that you did something. Actually you don't do anything useful while mining you don't solve any problems or anything. You are just doing something where you may get result which others can verify and see how difficult it was to get (on average). That's needed because if we didn't have that mechanism anyone could create thousands of blocks per second and the blockchain would be useless.

That's accomplished by hashing data. Hashing functions are rather complicated. Just think of it as a machine that will take data and give you a fixed length result. If you give the machine the same input again it will give you the same output again. We are unable to compute the input from the output  of a hashing function (at least if it's a good one like SHA256).

Let's say a block only contains some transactions, the bitcoin address of the one that gets paid the block reward and some random data for the sake of simplicity.

A block is considered a valid block if it's hash is lower than a certain value determined by the current difficulty.

Now let's get back to your understanding:

We don't need to try all variants of 4 specific bytes. We can change as much data in the block as we want, and we don't have to go through everything. No need to try 1 then 2 then 3 then 4 etc.
You can change the nonce, the extra nonce you can add more transactions or you could change the payout address to change the hash since that's all part of the input that goes to the hash function. Usually the nonce/extra nonce are increased until a solution is found, but you don't have to do it like that.

1) How it's made that different clients does not work on the same variants?

Well if you're solo mining you don't mind, since you are using your very own payout address so other people are giving another input to the hashing function even if they use the same nonce.
But what if someone tried that very combination already somehow?
That's so unlikely that we don't consider it as a possibility. Think about you going out of your home with your shovel and you teleport yourself to a random planet in the universe to a random spot on that planet. How likely is it that someone else dug there already? It's pretty much the same with your bitcoin block.

If you are mining in a pool the pool gives you the work and it can give you a certain nonce range or it could give every member another payout address (which is still owned by the pool) or it could add extra transactions to every member. Get creative Smiley

2) How it is prevented that client who found solution would "steal" 50BTC, instead of submitting solution to the pool server?

Imagine you found a solution a solution. Now you change the payout address in the block to get the btcs for yourself. Now you have changed the block and therefore the input of the hash function -> you're solution doesn't fit to that input anymore -> it's an invalid block

3) How does pool software process this solution to get 50BTC and notify whole system that everyone (including other pools & individuals) need to work on next block?

You submit solutions to a pool which aren't real ones. They are easier to get but you still give them to the pool to proof that you are working. Actually they are useless it's only to proof that you should get something if anyone else finds a real block.
If someone finds a real block (it contains the payout address of the pool and the user is unable to change it see question 2) he can send it directly to the bitcoin network or the pool which will send it to the network. That block will earn the pool a reward which it will distribute to all the pool members according to how much easier shares the pool got from every member (that's why those shares are needed, they don't have any value but to show the pool that a member deserves something)

4) Is that correct that all fees associated with newly generated solution are "payed" to the owner of this solution in the nearest minutes after it's generation?

It's payed to the payout address contained in the block. That address doesn't have to be the address of the solver it could also be your grandma's or some address you found on the internet. If that sounds stupid to you, that's exactly how the reward in pooled mining goes to the pool see question 3.

I have to go now so I'm unable to check my post for typos etc.
srry Shocked

I hope it's useful to you though.
4  Bitcoin / Mining / Re: Why does everyone think Solo Mining is a waste of time? on: May 07, 2013, 10:40:16 AM
Pooled mining = steady job
Solo mining = playing the lottery for jackpots of 1000 dollars

See the difference now?

but playing the lottery with 0% house edge. Important difference from normal lottery.
5  Economy / Service Discussion / Re: BFL's site is incredibly amateur... on: May 03, 2013, 07:24:59 AM
Agree with mustyoshi. People go to jail for a *long* time for doing what n4ru just did.

Which is ridiculous. We need people to focus on security if they are coding something especially a website. Sometimes I think that all that some programmers think while they are coding is that it has to work during their 10sec testing and if someone breaks into their system they say: "It wasn't my fault it's always these evil hackers who have nothing better to do than destroying my hard work".
Breaking into systems and therefore exposing ppl to the laugh of the public must be legalized to improve security. There are way to many amateurs running big projects. We need a way to legally knock them out.
6  Bitcoin / Development & Technical Discussion / Re: What version of Linux? on: April 28, 2013, 10:35:15 AM
Ok, but then you did something wrong when you were trying ubuntu 32bit, because that should also have worked fine. You have probably mistaken the 64bit version for the 32bit while downloading.

Also the amd64 in the iso name doesn't mean it only runs on 64bit amd cpus, it also runs on 64bit intel cpus, the name is just because of historical reasons.
7  Bitcoin / Development & Technical Discussion / Re: What version of Linux? on: April 28, 2013, 01:44:14 AM
why not use vmware?

because it's proprietary software? afaik they even want you to register somewhere.

OP isn't the first trying to run ubuntu in virtualbox. It should work just fine.
8  Bitcoin / Development & Technical Discussion / Re: What version of Linux? on: April 28, 2013, 01:30:58 AM
RMS is that you in disguise?

No, I wouldn't auction a gnu for pounds on the bitcoin conference.

"This Kernal Requires X86-64 CPU, but all that is detected is i686 CPU, please use a kernal appropriate to your CPU"

I don't think a 32bit kernel is capable of spitting that message out. So did you triple check that you have the correct iso mounted?
9  Bitcoin / Development & Technical Discussion / Re: What version of Linux? on: April 28, 2013, 12:33:39 AM
https://www.kernel.org/
you should use the most recent version (3.8.10).

Well I know what you meant and probably does everyone else. But I just want you to know that Linux itself is just the kernel which on it's own is pretty useless for an enduser. And therefore asking for a version of Linux is misleading.

You are searching for a GNU/Linux Distro that suits your needs. Although I do think gentoo is the best to use, it's probably not the best for you.
You want something that works out of the box so Ubuntu should be fine for you. You could also use xubuntu if you prefer it's GUI but it's basically the same.
If you don't want cannonical to sell you to amazon follow this tutorial right after installation:
http://askubuntu.com/questions/192269/how-can-i-remove-amazon-search-results-from-the-dash

Now about your installation:
If your PC has a 64bit CPU use the 64bit version of course. Don't even try the 32bit version.

Are you running it natively or in a VM?

Your hardware shouldn't be a problem the only problem with hardware support you could get is 3D performance. WLAN problems are part of the past and your box should definitely boot up.

Could you please write down the reason for the kernel panic? The last time I installed ubuntu on someone's pc it messed up the partitions somehow and panicked that it couldn't find the root partition. After configuring grub myself it worked.

Also I don't think there's any use for the LTS version unless you are lazy because you can always do a release upgrade I suppose. Correct me if I'm wrong.

//edit
you are definitely using a 64bit image on a 32bit CPU. You probably messed something up during download.
Use this one for xubuntu: http://cdimages.ubuntu.com/xubuntu/releases/raring/release/xubuntu-13.04-desktop-i386.iso
10  Bitcoin / Development & Technical Discussion / Re: Forked block chain on: April 22, 2013, 08:57:43 AM
The blockchain is publicly available data. You can print it out to use it as your toilet paper or you can use it to feed your program with data. What your  program does with that data is up to your program only.
11  Bitcoin / Development & Technical Discussion / Re: Mining is cracking SHA-256 24/7 on: February 28, 2013, 09:05:49 PM
I'm just curious whether in some future there will be a very bitcoin-specific method to predict, say, if you are going to have some zeros in the output or not.

There is one today already. Compute the hash and check.
12  Bitcoin / Mining / Re: Spike in hash rate today on: February 17, 2013, 04:31:17 PM
It's an estimate as you graph says since there is no way to know the actual hashrate. It's probably just variance.
13  Bitcoin / Development & Technical Discussion / Re: Why does the difficulty adjust every 2016 blocks? Why not every block? on: February 09, 2013, 08:49:17 AM
Well it was said already that the 10mins are the average time needed to find a block. But let me put it in some more understandable analogy.
Think of the difficulty as the sided of a dice. All sides are black except one which is white.
Now you roll the dice, white means you have found a block and black means you didn't.
Let's assume you can only roll the dice once per minute. If the dice has 6 sides you have a chance of 1/6 to find a block every minute. So in average you need 6 minutes to find a block.
But it's also possible that you get the white side on the first try, which means you can also find a block in one minute.

If you are able to somehow increase your speed and you can roll the dice twice a minute now then you would get a block every 3 minutes in average. But if we want the generation time to be constant we need to increase the difficulty which means we take a dice with 12 sides and the generation time is back to 6 minutes in average.

As you can see it's pretty easy to set the difficulty if the global hash rate of the network is known. The problem is that we actually can't know about the hash rate directly, but we do know the elapsed time since the last block was found. Combined with the current difficulty that's enough to calculate the hash rate. But there is a very high error rate. Let's go back to our analogy. Imagine you set the difficulty after every found block(which is what you wanted to know about), then with a dice with 6 sides it's actually pretty common to get the white side on the first try. The Network only knows that we found a block after 1 minute with a difficulty of 6. The Network wants to have a constant rate of 6 minutes per block which is why the difficulty gets adjusted to 36. As you can see the difficulty was multiplied by 6 although our hash rate didn't really change.

The solution for the problem is to average between block generations. If the number of blocks to average is too high, the difficulty will stay on the same level for too long. But if it's too low we will have huge difficulty jumps.

So changing the difficulty after every block would work, but it would be a mess because of the jumping difficulty. However as already said "running averaging" would also be an option. But I think we can agree on that the current system works just fine.
14  Economy / Speculation / Re: Call the Peak Contest/Experiment (1 BTC Prize) on: January 30, 2013, 01:03:56 PM
23.52$
15  Bitcoin / Development & Technical Discussion / Re: How did this address come into being 1BitcoinEaterAddressDontSendf59kuE? on: January 15, 2013, 08:19:07 PM
You people are really funny. You belive you know almost everything. There is just so little of unknown left in your world. Yet, the truth is
none of us know anything more but human partial truth, countless times proven wrong. Thousands of geniuses of their time were already
proven wrong, yet you are so sure you got things right. You learnt nothing from the past. There is no room in your heads for unthinkable.

Off to altcoin part of forum, people there are so much more open minded.

Oh yea we are really ignorant for believing that the total entropy of a system will always increase. If it wasn't like that, brute forcing some stupid hash function to steal other people's money would definitly be our least concern. We could fly to the moon with no fuel needed woohoo.
16  Bitcoin / Development & Technical Discussion / Re: How did this address come into being 1BitcoinEaterAddressDontSendf59kuE? on: January 14, 2013, 08:58:40 PM
No matter how many times you repeat "billion", there might be computer - or entity - one day that will do the job in an instant.

I am arguing here just because there are way too many people like you, spreading LIES around. Be factual or be quiet, thanks!

No. There won't be such a machine, never. No matter how fast your computer is there's a theoretical minimum amount of energy required to compute a private/public key and the corresponding address. No matter how efficient your computer is, you won't be able to get below that. Practically you won't even get close. That means we are able to calculate the AVERAGE amount of energy needed to brute force the priv key for a given address, and that energy is far more than the sun emits in it's entire life. If humanity is able to use the energy of multiple stars we are probably advanced enough to forget about currencies in general.

So forget about brute forcing once and for all. However the algorithm can be flawed, but that's something else. Flawed usually means that you can speed it up by less than 100 times You would usually still have more than a lifetime to convince everyone to switch to a new algorithm.
17  Bitcoin / Project Development / Re: [Electrum] merchant script on: November 14, 2012, 08:42:06 AM
I like it because it's so simple. Looks easy to setup and easy to use.
No blockchain is needed and the interface is trivial to use.
18  Bitcoin / Development & Technical Discussion / Re: Problematic block timestamps and number of transactions? on: November 02, 2012, 02:55:25 PM
So, all it takes for an attacker to "paralyse" Bitcoin is to takeover major miners and set them to ignore transactions?

You would need 50% of all miners and thats alot to increase the average confirmation time from 10minutes to 20minutes. That doesn't really sound like a threat does it?
There's no financial interest in doing so and humans usually follow their financial interest. Even if you could get 50% to not include transactions, fees would increase and therefore more ppl would start including transactions again instead of losing money.
19  Bitcoin / Development & Technical Discussion / Re: Problematic block timestamps and number of transactions? on: November 02, 2012, 02:24:14 PM
I'm pointing to ridicule situation - there are thousands of unconfirmed transaction but block will be accepted, which means
blockchain size will be increased by 1, even though mentioned block has no transactions other than 50BTCs payout. Since
that is possible, it's possible for determined attacker to "freeze" all non-BTC-generating transactions (almost) indefinitely.

Not really.  There are actually several ways to counter this if we ever need to... we can make it costly to be antisocial if we really need to.

How much worse the situation must become for that to happen? If there are already ways to fight it, why wait with implementation?

Because it's already implemented. It's the fee. It was discussed how to block antisocial blocks in the past and the result was pretty much that it isn't possible. If miners don't want the fees they are free to not include transactions. If Deepbit doesn't include transaction they are actually telling everyone that they think the fees are too low and there's nothing wrong about that.
20  Bitcoin / Bitcoin Technical Support / Re: Failing at installing Bitcoin on USB linux: "Disk space is low" - crashing on: October 24, 2012, 03:09:53 PM
Thank you.  I understand that not all bitcoin clients have to download the blockchain to operate however, something I'm not clear on is whether or not those clients properly sync up a wallet.dat. As I understand it, if I store away a wallet.dat in a vault and then pull it out six months later, it needs to see all the new blockchain transactions to be caught up, and I'm concerned that software that does not download the full blockchain will not provide the necessary transactions to the wallet.dat.  I hope that makes sense.

Nothing is changed in the wallet.dat when you receive or send transactions. The wallet.dat only holds your private keys and that's why you can keep it offline because it doesn't need to be synced. You only need to be synced if you want to know your balance.

simple:
wallet.dat <-- priv keys(access key to your bitcoin adresses)
blockchain <-- transaction history of everyone publicly available for anyone with a internet connection (looks same for everyone independent of the wallet.dat)

wallet.dat + blockchain -> balance can be calculated

The wallet.dat only changes if you add additional addresses to your wallet. It doesn't change if you receive btcs. It's pretty much like with bank account numbers. They also don't change if you receive money.

And that's why lightweight clients work because those 2 things are separated. The wallet.dat is very small and the blockchain is very big. But you only need the blockchain if you want to know your balance so why not keep the wallet.dat for yourself and use the blockchain of someone else? Remember the blockchain is the same for everyone. That's what electrum for example does. It keeps your wallet on your PC so your safe as long as your PC is safe and uses the blockchain of a server. If the server crashes you can also use another server or in 100 years if noone uses electrum anymore download your own blockchain.
Pages: [1] 2 3 4 5 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!