Bitcoin Forum
May 24, 2024, 07:17:17 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [16] 17 18 19 20 21 22 »
301  Other / Beginners & Help / Re: How to make real money from now on on: April 20, 2013, 09:03:07 PM
Get a job or an extra job and only spend half of what you earn and buy bitcoins for the rest. That was how I started.
302  Economy / Speculation / Re: Wall Observer - MtGoxUSD wall movement tracker - Hardcore on: April 20, 2013, 07:34:32 PM
here we go!
136.43 is the number to look for. That is the highest BTC has been since the minimum at 50.01 $/BTC.
303  Economy / Speculation / Re: Gold collapsing. Bitcoin up. on: April 20, 2013, 06:55:07 PM
And all you guys rambling about an energy crisis: Are you aware that the past 20 years we have been able to find economically extractable oil faster than we are getting it out of the ground? I suggest you look into these numbers before continuing your ramblings:

I'm sure oil "mining" is finite like gold mining, but oil production is probably "infinite", I'm sure BP wouldn't be a viable long term investment if they couldn't convince shareholders that peek oil wasn't a problem in the near future.
So BPs numbers are a conspiracy? then please answer the following questions:
1) They have publishe these numbers since 1965, don't you think someone would have figured out whether they were lying or not since then? BP actually only reports the numbers that the different governments themselves report so you are welcome to double check these numbers from the governments if you o not believe BP.

The fact is energy consumption is increasing on a steady growth trajectory doubling roughly every 10 years, and while production capacity is practically endless the finite supply is not.
And what would you say if the supply, i.e., known economically extractable resources grew faster than the production rate? The known resources have risen 60+ % since 1990 whilst the production has only risen 30-something %. Check BP's numbers before continuing this discussion, please.
304  Economy / Speculation / Re: Gold collapsing. Bitcoin up. on: April 20, 2013, 10:19:17 AM
I see little chance of a larger correction to gold price unless the economy starts a miraculous recovery, which I don't believe in. Peak oil is still the most relevant problem that probably won't go away easily, next decade the earliest. Energy is the backbone of the whole economy and the gradually and slowly rising energy prices are a major source of friction in the economy causing everyone to take on more debt. Players in the economy are desperately trying to sustain growth while fundamentally there can be no growth because the energy to support that growth is simply not there.
Peak oil is a scam.
Global oil production hasn't increased since 2005 most likely, yet demand keeps going up thanks to China and other growing economies.
False. Oil production 2005: 81.391m barrels per day. Oil production 2011: 83.576m barrels per day.
Source: BP Statistical Review.

And all you guys rambling about an energy crisis: Are you aware that the past 20 years we have been able to find economically extractable oil faster than we are getting it out of the ground? I suggest you look into these numbers before continuing your ramblings:
http://www.bp.com/sectionbodycopy.do?categoryId=7500&contentId=7068481
305  Bitcoin / Development & Technical Discussion / Re: An idea on how to reduce the risk of a 51 % attack on: April 19, 2013, 10:26:39 PM
As I see it this system does not have to be a part of the blockchain but can be a seperate system. You were around for the March 11th hard-fork - could this separate system not have given a warning if the operator of the green addresses was Mt. Gox. (and perhaps other trusted parties having a financial interest in the integrity of the blockhcain) and the one receiving the alarm was the mining pool operator of BTC Guild? These two very large players were on two different side of the forks. Would this system not have given the devs a warning 30-40 minutes earlier than you got it?
I don't think it is theoretically possible to get warning prior to 0.6.x and 0.8.x diverging - what would have helped would have been a way to contact people faster (including having the poolserver contact me instead of just logging it and taking a while before I noticed).
As a result of the March 11th events, the major pools have exchanged direct contact information with each other and that information is (I'm pretty sure) available to core developers as well.
When were you informed about the fork, after or before it became a hard fork (that means +6 confirmations, right?)?
No, a hardfork occurs the moment an older client rejects a block accepted by newer clients.
Eligius detected it immediately, but it wasn't until sipa was helping some other user experiencing the problem that I thought to check it.

Finally, it's also incompatible with miners rights to decline processing of any given transaction.
That's a good point. But if the probing transaction is made to look as much like any other transaction as possible (reducing the risk of a attacker identifying it) is it then not fairly predictable when it will be included? I think your problem with my system could be solved by checking block x, x+1, and perhaps x+2 instead of just x.
That doesn't make sense. The point here is that miners have the right to refuse even transactions from/to widely-trusted parties.
This is an important component to the Bitcoin system.
Sure, but when you receive some kind of message from a green address though the network you can go back in the block chain and see if it is there. It does not have to be in one specific block it can also be in a block one or two after. Does that make sense?
So what if all miners decide the transaction in question should not be mined?
The alarm is ignored, I guess. But it seems quite unlikely to me that the transaction whould not be included so the warning system should give very few (if any) false alarms thus being of high value.

As I noted, this system is not supposed to be a part of the direct verification of a mined block but instead a separate system used only as an extra warning system that something might be wrong.
306  Bitcoin / Development & Technical Discussion / Re: An idea on how to reduce the risk of a 51 % attack on: April 19, 2013, 10:08:35 PM
As I see it this system does not have to be a part of the blockchain but can be a seperate system. You were around for the March 11th hard-fork - could this separate system not have given a warning if the operator of the green addresses was Mt. Gox. (and perhaps other trusted parties having a financial interest in the integrity of the blockhcain) and the one receiving the alarm was the mining pool operator of BTC Guild? These two very large players were on two different side of the forks. Would this system not have given the devs a warning 30-40 minutes earlier than you got it?
I don't think it is theoretically possible to get warning prior to 0.6.x and 0.8.x diverging - what would have helped would have been a way to contact people faster (including having the poolserver contact me instead of just logging it and taking a while before I noticed).
As a result of the March 11th events, the major pools have exchanged direct contact information with each other and that information is (I'm pretty sure) available to core developers as well.
When were you informed about the fork, after or before it became a hard fork (that means +6 confirmations, right?)?

Finally, it's also incompatible with miners rights to decline processing of any given transaction.
That's a good point. But if the probing transaction is made to look as much like any other transaction as possible (reducing the risk of a attacker identifying it) is it then not fairly predictable when it will be included? I think your problem with my system could be solved by checking block x, x+1, and perhaps x+2 instead of just x.
That doesn't make sense. The point here is that miners have the right to refuse even transactions from/to widely-trusted parties.
This is an important component to the Bitcoin system.
Sure, but when you receive some kind of message from a green address though the network you can go back in the block chain and see if it is there. It does not have to be in one specific block it can also be in a block one or two after. Does that make sense?
307  Bitcoin / Development & Technical Discussion / Re: An idea on how to reduce the risk of a 51 % attack on: April 19, 2013, 09:43:36 PM

Its dependency on "green addresses" is, as you note, problematic as well, for the same reasons green addresses are themselves flawed.
Thank you for your answer, Luke.

As I see it this system does not have to be a part of the blockchain but can be a seperate system. You were around for the March 11th hard-fork - could this separate system not have given a warning if the operator of the green addresses was Mt. Gox. (and perhaps other trusted parties having a financial interest in the integrity of the blockhcain) and the one receiving the alarm was the mining pool operator of BTC Guild? These two very large players were on two different side of the forks. Would this system not have given the devs a warning 30-40 minutes earlier than you got it?

Finally, it's also incompatible with miners rights to decline processing of any given transaction.
That's a good point. But if the probing transaction is made to look as much like any other transaction as possible (reducing the risk of a attacker identifying it) is it then not fairly predictable when it will be included? I think your problem with my system could be solved by checking block x, x+1, and perhaps x+2 instead of just x.
308  Bitcoin / Development & Technical Discussion / Re: An idea on how to reduce the risk of a 51 % attack on: April 19, 2013, 09:33:13 PM
Quote
It works like this: Trusted parties could send some kind of random amounts of bitcoins from one seemingly random address to another both controlled by the same party or one controlled by another trusted party.
How do the parties establish their trust?
Have you read about green addresses? Green addresses are owned by entities which have a large interest in being trusted to not double spend their coins. In this way, a dealer can choose to trust the received funds from a green address to not be double spent and he does thus not need to wait for the six confirmations to deliver the purchased product to the customer. Green addresses are owned by the largest bitcoin companies in the community like Mt. Gox.
309  Bitcoin / Bitcoin Discussion / Re: Bitcoin's Dystopian Future on: April 19, 2013, 08:18:26 PM
A government is a company like any other company. Its business model might be challenged by crypto currencies just like Western Union's business model will be challenged but it will have to adapt.

If a government is a company, what is its core service? Security!

In an anarcho capitalistic world (no govenments), there would still exist a demand for security as you point out. This demand will be filled by some entity and the best way to provide security is to control a geographical area, like in a gate community - and what, if any, are the fundamental differences between a gated community and a government? None! We are already living in a world of "privately" owned security companies competing with each other. We just happen to call these kind of companies "governments". We are living in an anarcho capitalistic world already. We who call ourselves libertarians are just not too happy with the quality and price that these companies provide.

Governments will not die since there is a huge demand for their service - security. Governments will adapt and figure out new ways to get a revenue either through property taxes or through head taxes but many people will be hurt in this process as you correctly point out.
310  Bitcoin / Bitcoin Technical Support / Re: Need help on transferring money from cold wallet on: April 17, 2013, 02:12:56 PM
So I ended up making this work for Armory which actually seems to be working fairly well. Thanks for the help, though.
311  Bitcoin / Development & Technical Discussion / Re: An idea on how to reduce the risk of a 51 % attack on: April 17, 2013, 01:47:52 PM
This pretty much just shifts from trusting the network to trusting arbitrary green addresses.

Not a good idea.
This reply does not pass the Turing test. Please read OP if you wish to participate in the discussion.
312  Bitcoin / Development & Technical Discussion / Re: An idea on how to reduce the risk of a 51 % attack on: April 17, 2013, 01:43:47 PM
It's an interesting idea, but you've made too many assumptions on the actions of a 51% attacker. Why is it required that they do not include most transactions into their chain? Their competing chain could include every transaction in the honest chain except one (unspending their own coins) and defeat this protection. A 51% attacker cannot spend coins which are not his, all he can do unspend recently spent coins, in particular his own, allowing double spending. If he only ever changes his own transactions, then these canary transactions will never die and no alarm will sound.
Sure but this limits the scope of the destruction that the attacker can wreak plus it protects the network from March 11th style problems. Additionally, it is rather expensive to make a 51% attack so being able to unspend your own coins is likely worth less than it costs to make a 51% attack.
313  Bitcoin / Development & Technical Discussion / An idea on how to reduce the risk of a 51 % attack on: April 17, 2013, 10:26:55 AM
Building upon the idea of green addresses, I believe one can significantly lower the risk of a 51 % attack and also decrease the likelihood that a March 11th type problem would go unnoticed for as long as it did (into a hardfork with +6 false confirmations on at least one large transaction).


It works like this: Trusted parties could send some kind of random amounts of bitcoins from one seemingly random address to another both controlled by the same party or one controlled by another trusted party. Then n blocks later (n=3?) a green address could send out a message(d transaction) through the block chain containing the information on the transaction with a time stamp, a sender, and a receiver address or perhaps just the firstbits of these addresses. A 51 % attacker is unlikely to include the first of these transactions in his blocks since he would have to include all transactions to insure that he did not miss the special transaction used to check the integrity of the blocks created and if he includes all transactions, it is no longer an attack. And the attacker cannot send a signed message from a green address since he does not hold the private key of this address.

If this system was abused by an owner of a green address, the checks on this would be similar to the checks on the green addresses themselves: the economic majority would reject this particular green address.

I do not even think that this system would involve any changes to the blockchain or the bitcoin system. It is an independent system which mining pool operators could implement to check the integrity of the block chain and the mining pool operators could also be the ones paying the (small) transaction fees required to make this system work since increasing the trust in bitcoins is in their economic interest. The mining pool operator then checks whether block x+n contains a message from a green address to another address about a transaction occurring in block number x. If it does not, some kind of alarm should go off and actions can be taken from there. The messaged transaction does not even have to be included in a block but it could just be transmitted as a 0 confirmation transaction for the mining pool operator to check the validity of the previously mined blocks.

One probing transaction per block or perhaps even fewer would suffice since a random transaction's entropy is very high.

Some concern could be raised that this idea is not aligned with the decentralized idea of bitcoins and that the operator of a green address could be compromised or be part of the attack but I believe this issue is not much different than the issue of green addresses themselves. If the economic majority deems this green address to be unreliable, the alarm can be ignored.
314  Bitcoin / Project Development / Re: crypto.pm | an upcoming cryptocurrency exchange on: April 15, 2013, 02:56:19 PM
Where are you guys operating from?
315  Economy / Speculation / Re: what are the best charts on the web for bitcoin ? on: April 10, 2013, 09:59:21 AM
I also like Clarkmoody at http://bitcoin.clarkmoody.com/. You can see the order depth there and currently bitcoinity seems to be down.
316  Economy / Service Discussion / Re: Vote by Dropbox to accept bitcoin on: April 09, 2013, 07:17:49 AM
Great! Get in there and vote it up. You can vote six (6) times. Make sure to use all your votes!
317  Bitcoin / Bitcoin Technical Support / Re: Need help on transferring money from cold wallet on: April 08, 2013, 10:09:24 PM
I never used Armory yet so I can't say
And yes for the three questions
Thanks. I am not relinquishing my intention of a tip. I could have used a bit more details though but I will read through the pywallet manual instead, try the system and return to this thread within a couple of days.

If anyone else has some information to offer, feel free to add it here!

Edit: Pywallet is up and running on my Windows 7 computer and it was a bit of a hassle to install with all the dependencies but it works fine now. I assume that the new version is still not up since Github tells me that the newest version is three days old and the option that I need does not seem to be there even though I can find the public key from a private key?
318  Bitcoin / Bitcoin Technical Support / Re: Need help on transferring money from cold wallet on: April 08, 2013, 04:33:03 PM
Yes
Both :
- your hot one will display the transactions you can spend
- you'll have to choose which ones you want to use and the outputs
- it will return a string you'll give to the pywallet on your cold computer (by hand or qr reader)
- the latter will display the inputs/outputs and ask you if you're sure to sign that transaction
- it will then give you the raw transaction you can broadcast through bitcoind, pywallet or blockchain.info/pushtx
So this works a bit like Armory? I like that. So the private key never touches the hot computer and I do not have to download the blockchain on the cold computer? Only the public key touches the hot computer, right?
319  Bitcoin / Bitcoin Technical Support / Re: Need help on transferring money from cold wallet on: April 08, 2013, 03:01:05 PM
New version of pywallet is coming in around 6 hours and will include easy transaction creation
That option will be specifically developped for that use
So this will run on an old netbook and I will not have to download the entire blockchain to make a transaction? On whihc of my computers would you recommend that I install pywallet?
320  Bitcoin / Bitcoin Technical Support / Need help on transferring money from cold wallet on: April 08, 2013, 01:42:34 PM
Hi forum

I hope you can help me on this:

I have some bitcoins stored on a cold wallet made on a computer which has never touched the internet. The wallet was made on an old Eee PC from 2008, it has 1GB RAM and some slow processor. On this computer I do not use the harddisk since I boot directly from a Ubuntu 10.04 LTS USB pen drive (3.1GB free disk space but I do have larger USB keys available if needed) and no information leaves or enters this computer through USB drives or in any other ways.

I would now like to transfer funds from this cold wallet and distribute it to some other wallets, some belonging to others and one belonging to me and I am conflicted with how to transfer these money. I have a faster computer that I use for my daily use and it can thus not be considered safe. I could boot this "hot" (possibly tainted) computer from an Ubuntu 10.04 USB pen drive (16 GB, not the same drive as the EeePC's) and install the original Bitcoin client (qt) on this, let the computer download the entire blockchain, import the private key and make a transfer from this computer once the blockchain is downloaded and the private key imported. I could also just trust Mt. Gox or some other online wallet and swipe my private address there and then transfer the money from this but this does not seem like a very safe method. I also know that a client called Armory exists but I have never used this and I don't know how this would work and on which computer I should install it (the fast computer or my Eee PC?)

I would love some help on this issue, very useful and detailed explanations will be tipped at my discretion. I am fairly knowledgeable about the bitcoin system and I understand the concept of the blockchain, private key, public keys, ECDSA, SHA256 and addresses. I also have two-step verification on my Mt. Gox account but I am one of the 15,000+ in queue for verification there.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [16] 17 18 19 20 21 22 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!