Bitcoin Forum
July 16, 2018, 05:45:25 AM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 38 39 40 41 42 43 44 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 ... 464 »
1741  Other / Beginners & Help / Re: Continuity of support on: March 12, 2013, 09:38:21 PM
Just like there is a Continuity of government http://en.wikipedia.org/wiki/Continuity_of_government, it seems to me there ought to be a Continuity of support (or whatever it should be called) for the Bitcoin capabilities.

Well, what services are needed for the Bitcoin network to continue?

Yesterday, the services offered included management advice: (obtaining consensus among a small group of trusted individuals (core developers on #Bitcoin-dev) to decide on a plan and then to persuade the parties affected (mining pools, large solo miners, etc) to participate.), communications (the notice on the Bitcoin.org website, the Bitcoin client network alert broadcast, forum post by Sipa, twitter post @GavinAndresen).

If it had involved a software patch, release of that would have been another service the group provided.

If there was just a fraction of the team members available, or they couldn't use IRC and had to communicate via e-mail or something like that I don't know what the outcome would have been.

So there definitely was reliance on a set or people and a method.

The contingency plans touch on some of this:

 - http://en.bitcoin.it/wiki/Contingency_plans
1742  Other / Off-topic / Re: Client 0.8 has taken forever on: March 12, 2013, 09:25:51 PM
before fork, client did start and shutdown much faster than the previous versions...

why rollback when everyone shouldve moved forward

There was some misinformation in the first minutes.  v0.7 and prior had the bug, but a purposely configured v0.8 allowed it to be exposed and cause the fork. 

v0.8 works fine for a user and merchant.  Until there is a v0.8.1 then if you are a mining pool (including p2pool) or large miner (i.e., mining solo) then you want to use v0.7 as blocks mined using v0.8 could still produce blocks that v0.7 (now used for the longest chain) won't accept.


As far as your v0.8 client not syncing, that should be resolved by now.  Has it?
1743  Bitcoin / Development & Technical Discussion / Re: Apollo 13 film vs the handling of block chain fork, which is better thriller? on: March 12, 2013, 09:19:57 PM
I suggest everybody willing to read a thriller take a look at the chat log in Bitcoin-dev while the chain fork was taking please and a miners and developers tried hard to agree on what to do. Every line is chilling...

Read it at http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12

Have fun! Best regards, Sergio.

What time was the network alert broadcast?

I see a few questions like "anyone know how to contact [specific top 10 exchange]", "how to contact [specific top 10 pool]".  

A significant blockchain fork was an eventuality but it was alarming to see how non-automated communications were such a crucial component to getting a resolution, and how those communications are so inefficient due to timezones (middle of the night in Europe), language differences, differences in market impact (the top exchanges and merchants got contacted, the smaller ones didn't), etc.

There is a lot that needs to be learned from this incident.
1744  Bitcoin / Bitcoin Discussion / Re: Reversed transactions due to fork on: March 12, 2013, 08:13:49 PM
Within seconds, Armory told me it was no longer synced to my Bitcoin client, and within a few minutes after that, Armory crashed.

What you are describing is not a "reversed transaction" but simply a transaction that apparently never got broadcast.

The Bitcoin-Qt/bitcoind client does not send out a spend transaction until it has reached sync.  So it could have been perfectly bad timing where just before when your transaction was communicated to bitcoind (which is what Armory uses underneath I believe), that client discovered a block at a greater height and did not send the transaction. 

Now when the client is restarted it does not automatically re-broadcast a transaction.  The bitcoind needs to remain running, sometimes a half hour or (or longer maybe) for any transactions to get re-broadcast.

So, at this point -- make sure you've left everything running for a long enough period to make sure no spend transaction is just waiting to get re-broadcast.

If that doesn't change anything then I'm pretty much out of suggestions.  If the Bitcoin network doesn't know of your transaction (e.g., blockchain.info doesn't have any knowledge of it) and your client isn't re-broadcasting it then either the transaction was invalid and no peers will relay it or it somehow never got saved. 

The bitcoind wallet uses BDB so I suppose if that got taken down with a crash and the database wasn't closed that a rollback in the local BDB wallet.dat database could have occurred to the point it was at prior to you sending the payment.

If this is to an address in your own wallet, there's nothing really to worry about if the transaction were somehow later be re-broadcast.  If it was to some other party, one way of ensuring that the lost transaction becomes moot is to spend those coins with a new transaction.  So if your wallet has 1.123456 BTC, send a payment to an address you control with all 1.123456  (less transaction fee) so that even if that missing transaction were somehow to resurface at some later time it would not be a valid transaction (as you've since re-spent those funds).
1745  Other / Beginners & Help / Re: Unable to transfer wallet to new computer...or access it on my old! on: March 12, 2013, 11:58:33 AM
If I install one from, say, 10.2012 will it fail to show my transactions since then? what other problems will it cause? 

The wallet contains keys in a key pool.  So a backup taken today will already include the keys for my next 100 transactions where a new address is generated for change (or where an address is generated because I clicked New).

So any recent backup probably has all the keys you've used ... unless you do a lot of SatoshiDICE wagers or that kind of activity.

Wallets can be restored, then another one restored without any impact.

You will want to launch the client with -rescan though the first time after each restored wallet.dat.
1746  Bitcoin / Bitcoin Discussion / Re: Miners: Demand more in fees from the userbase by blocking spam transactions on: March 12, 2013, 11:56:50 AM
isn't 0.01 btc closer to 50c?
5 cents actually.

Redo your math.  It is 1/100th of BTC/USD, so about $0.44 at current rate.

Except that is not the mandatory fee assessed low priority transactions.   If you have low priority transactions, you will be assessed 0.0005 BTC per 10KB.   If you have a high priority transaction, there is no mandatory fee.

This has been this way since version 0.4 or something like that. 

If you are being asked to pay a 0.01 BTC fee it is because you have a low priority transaction that is huge.   How does one avoid this?   Stop using bitcoin as a micropayments network.  If someone is sending you bitcoin dust (like SatoshiDICE does for losing payouts), then stop patronizing that service.
1747  Bitcoin / Bitcoin Technical Support / Re: Files to erase on: March 12, 2013, 11:56:00 AM
So if some one steals my computer they their is no wallet.dat for them to get!!!!! or use or see.

Oh.  Minor detail.   Cheesy

You are actually asking how to securely remove a bitcoin wallet from your system  (or the more extreme, remove any trace that Bitcoin was ever on a system ?)

Know that deleting a file does not necessarily delete the file (that's why they have "undelete" tools).    So if you had a wallet without passphrase encryption, and then you delete that wallet.dat, there are ways of still recovering the keys.  There's even a nice utility to scan your hard drive to find it:

Bitcoin private key/wallet.dat data recovery tool!
 - http://bitcointalk.org/index.php?topic=25091.0

1748  Bitcoin / Development & Technical Discussion / Re: Cancelling unconfirmed transactions on: March 12, 2013, 11:48:52 AM
...
The first thing to know is that all nodes will forget about transactions after a few hours
...
How long time does bitcoind remember a transaction?

It isn't just the duration, it is space in the memory pool.  As that space fills up, older transactions get bumped out.
1749  Other / Beginners & Help / Re: How does the generating new addresses work? on: March 12, 2013, 11:48:12 AM
Btw, is there a way to delete already created address?
Especially after it's empty?

Nope.   The best you can do is export all the keys, create an empty wallet, then import the keys except those you don't want.
1750  Other / Beginners & Help / Re: orphan on: March 12, 2013, 11:47:54 AM
IF my transaction occurred on an orphaned block, block 225451, will my transaction go through to the address I sent it to, or must I redo the transaction?

Your transaction is still valid so you definitely shouldn't be sending a new transaction. 

The transaction will likely get included in a block at some point.  Is it currently showing on blockchain.info as unconfirmed? 
1751  Other / Beginners & Help / Re: Where does authority lie in a decentralized system? on: March 12, 2013, 10:22:54 AM
Ok, if there was some major major bug that happened and people couldn't just revert to an older version, would there be some coder authority as to who was fixing the code?

I'm a little unclear as to how open source projects get worked on.

This was actually a good example to help describe this.

When the plea came for miners to downgrade to v0.7, those pools (and large solo miners) who had already solved the six or so blocks on v0.8 (v0.8 was ahead by about six blocks at that point) had the option of continuing on v0.8 instead of abandoning those blocks (and the bitcoins they would earn) when downgrading to v0.7.  Let's say these miners held their ground in order to try and keep the bitcoins from those six blocks.    

It would soon be apparent that the plea was being ignored by enough miners and that there was still plenty of hashing on v0.8 such that it would take a long time for v0.7 to catch up.  So instead it would then be those mining on v0.7 that would be faced with a decision:
 - a.) Do nothing and continuing to mine against a fork in which every block stays orphaned
 - b.) Upgrade to v0.8 (which could take hours or days to complete)
 - or c.) Implement a fix and start mining using it.

If the BDB issue was fixable, there would likely have been a bunch of frantic development and testing performed and code slipstreamed into production.  (i.e., option "c.)" would have been chosen)

So if there was a fix, that code would have been running by pools and large solo miners before there was even an release published.      Source code containing the patch can be transferred via a pastebin/gist/text file/e-mail attachment in most instances.     It wouldn't be forced on them, but when choices are limited, the path of least resistance is often chosen.   Fixing v0.7.x (again, if it was fixable in a reasonable amount of time) might have been the outcome instead.  

Eventually releases with the fix would be published through the more formal process (built and tested prior to release, etc.) so that even those who don't build directly from the source code themselves can switch over and resume mining on the longest chain.

This process isn't uncommon.  There have been vulnerabilities where the developers share the remedy with pool operators, large miners and others before sharing the fix publicly.  So building from source code is something most pools and large miners are prepared to deal with.
1752  Other / Beginners & Help / Re: Campbx problem transferring bitcoin on: March 12, 2013, 10:19:52 AM
campbx apparently doesnt hold onto randomly generated wallets? I dont have the one they generated for the exchange. Sad

You sent bitcoins to an address that Camp BX gave you but now you don't know what that address is?

What tool or site did you use to send the payment (or request a withdrawal) from?  Usually there you can see a record of your withdrawal to know what Bitcoin address those coins were sent to.
1753  Bitcoin / Press / Re: NEW articles in Press Forum on: March 12, 2013, 09:41:18 AM
2013-03-11 Arstechnica: Major glitch in Bitcoin network sparks sell-off
https://bitcointalk.org/index.php?topic=152129.0
1754  Economy / Service Discussion / Re: Okpay debit card - experiences on: March 12, 2013, 09:39:24 AM
do they accept US clients?

Yup.
1755  Other / Beginners & Help / Re: Campbx problem transferring bitcoin on: March 12, 2013, 09:14:14 AM
Is there a way to check for 6 confirmations? Im not sure how to do that.

Using Blockchain.info you can paste the Bitcoin address you sent the funds to.  It should show your transaction.  If that transaction has six confirmations, then Camp BX should be crediting your exchange account for that deposit.

 - http://www.Blockchain.info
1756  Other / Beginners & Help / Re: BTC disappeared from my wallet???? on: March 12, 2013, 08:34:29 AM
what I put in the wallet disappeared, also the transaction I can't find it anymore too.

Ok, if your v0.8 client is sync'd it should now show everything correctly.  Did the problem resolve itself?
1757  Other / Beginners & Help / Re: Where does authority lie in a decentralized system? on: March 12, 2013, 04:24:35 AM
I was curious how this message manifested itself?  If there is no central authority, how does this message come about?

Quote
These people have alert keys and should be contacted ASAP in case of emergencies:
Satoshi
Gavin
theymos

 - http://en.bitcoin.it/wiki/Contingency_plans#Alerts

Quote
Also, in the really long thread describing this situation, it was mentioned several times about the possibility of forcing users from .7 to .8.  Something about a last block for .7.  Again, I have the same question, how would this come about in a system without a central authority?

There is an authority, it comes from the longest chain.  That is reached through consensus.

Right now the longest chain is block 225453:
 - https://blockchain.info/block-index/357985/000000000000031803e492a0103154d243c9945ef78dbdba42a1ecfdb5bc5dbb

So normally a miner would be building off of the block at the greatest height and now working on extending that ... building the next one, 225454.

Except we know that that specific one is created using v0.8.  And it will be orphaned.  And a miner that solves an orphaned block gets 0.0 BTC as a reward for that effort.  Miners can only spend generated coin from blocks once that block has 120 confirmations.

So now a (large) majority of miners are now running using v0.7, and the block with the greatest height that v0.7 client knows of currently is this 225445:
 - https://blockchain.info/block-index/357992/000000000000012966aca980b406faa35b4c7abcc896846794f2c3f6f9b63aa0

So even without an authority ordering miners around, miners do what is in their own best interest.  Everyone on the same blockchain chain.  And to get there, dropping to v0.7 was the quickest way to get there.
1758  Bitcoin / Bitcoin Discussion / Re: Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks on: March 12, 2013, 03:52:58 AM
All transactions already have been reprocessed on new fork. [/iquote]

Has this been confirmed?  If so, source?

In fact the very first few blocks on new branch should contain all transactions in old branch.[...]The threat of double spending is theoretical, because when fork occurred there were miners working on both branches.

Sure the v0.7 nodes could have known of the transactions but there were fewer v0.7 blocks and the contents of the blocks were different from the v0.8 mined blocks.

I'm not expecting that this happened, but some of the new nodes that downgraded from v0.8 wouldn't yet have those "not-yet-onfirmed-in-v0.7" transactions in their memory pool, which opens a truck-sized hole for someone attempting a race attack.  

So I'lm not sure I'ld call it a "theoretical" risk.  If there was one or more successful double spends as a result I wouldn't be surprised, and had someone prepared in advance for this and had perfect timing and good luck, significant losses for a couple exchanges could have been the result.
1759  Bitcoin / Bitcoin Discussion / Re: Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks on: March 12, 2013, 03:42:49 AM
anyway that chat log can be shared? I know a lot of people would love to read it.

 - http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12  

There might have been a couple reports of issues on the 11th.  The times are UTC so this starts on the 12th.
1760  Other / Beginners & Help / Re: BTC disappeared from my wallet???? on: March 12, 2013, 02:36:01 AM
I'm really new at Bitcoin, I just bought some BTCs and made a transfer a few minutes ago into my wallet, but now they seems to have all disappeared from my wallet?? and I receive this message at my client "chain fork, stop mining on version 0.8"?? and also my client isn't updating blocks.

Did it really disappear or just did it revert back to unconfirmed?
Pages: « 1 ... 38 39 40 41 42 43 44 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 ... 464 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!