I decided to mess around and make a brain wallet. I used the website www.brainwallet.org. Supposively, this javascript is client side only. Anyway, I made a brain wallet and decided to test it. I moved my spare change (I keep most of my BTC in cold storage) about 0.178 BTC to the new brain wallet I made "15WjmFwpZ1mp3fG55JGoGv3p5y9jtehEB2". Literally within seconds, it was moved to a new bitcoin address not owned by me "1Lp3S4PajwhuFCyrAXSFdVGxLuqTsXtVQC" https://blockchain.info/address/15WjmFwpZ1mp3fG55JGoGv3p5y9jtehEB2I am very security conscience and am certain my wallet file was not compromised. My only thought is the brainwallet website has been compromised instead and some bot is stealing the private keys generated there and then instantly transfering any funds deposited to these compromised wallets to their own bitcoin addresses. DO NOT USE www.brainwallet.org and if you have used it, then immediately move your funds to a new location ASAP. I am not complaining though, I only lost 0.178BTC - it could have been much worse. Is your passphrase just too simple? |
|
|
|
No, that's not true at all. The whole point of running a Bitcoin full node is that you do NOT blindly follow any rule changes miners agree on. That's fundamental. If you do blindly follow them then you're using simplified payment verification.
If the majority of miners decide to restrict block size to 100kbytes, what non-mining full node could do? They could either follow, or join a shorter fork with bigger block size (i.e. hardfork ). Non-mining nodes don't really have much choice While true, because miners control transaction selection, there are a great many rule changes that miners cannot make, no matter how much hash power they have. Sure, I am talking rules tightening only. Something like increasing block size must be a hardfork |
|
|
|
No, that's not true at all. The whole point of running a Bitcoin full node is that you do NOT blindly follow any rule changes miners agree on. That's fundamental. If you do blindly follow them then you're using simplified payment verification.
If the majority of miners decide to restrict block size to 100kbytes, what non-mining full node could do? They could either follow, or join a shorter fork with bigger block size (i.e. hardfork ). Non-mining nodes don't really have much choice |
|
|
|
Rule changes could be backwards compatible, e.g. allowing homosexual marriage would not make any existing or future heterosexual marriage illegal. The opposite is true for bitcoin: tightening rules would not make existing clients obsolete
The point of a soft fork is that the rules don't tighten - from the perspective of old clients, anyone can spend any zerocoin and you will happily accept blocks that contain bogus spends written by unauthorized users. This reduces your node to SPV level security (you blindly trust whichever chain the majority of mining is done on). Silently downgrading peoples security level is not only a nasty hack, it's untrustworthy behaviour which is why I objected to it for P2SH. Bitcoin has never been designed to "soft fork". That's something other people came up with later. Everything in Bitcoins design is intended to trigger hard forks when the protocol changes. Hard forks are not impossible or the end of the world, they just require co-ordination and communication. It is the right way to do things and I will continue to strongly object to "upgrades" that convert full nodes into SPV nodes. No soft-fork is possible without majority of miners agree. If they decide to tighten the rules, all users have no choice but to follow. This is a known feature (or vulnerability) of bitcoin from day one. Sometimes it is called a "soft-fork", while sometimes it is called a "51% attack". Anyway, it's the users' responsibility to keep their client up-to-date to adopt the tightened rules. If Satoshi had never thought of possibility of soft-fork, I couldn't see why he included so many useless OP_NOP codes in the script. |
|
|
|
Although it's a neat idea, it underestimates the blockchain bloat that comes with it. If this became standard, and we had 1000 tx per block, that's potentially 1,000 extra UTXOs we wouldn't otherwise have. Adding 1000 UTXOs per block would be pretty rough, and the total blockchain size would increase pretty dramatically in an effort to spend all those.
No, OP_TRUE can be spent by anyone. It implicitly means "pay to miner". Ofc, some miners might not detect them and so it becomes pay to the first miner who finds them. Oh, I understood that part, but I forgot about the part where they don't have to provide a large signature in order to spend it to themselves. And I missed the part that they can mine all of them in a single transaction and produce only one extra output for themself. Okay, it's kind of cool. After thinking carefully I believe your original proposal is better. It allows the HW wallet to sign a partial transaction (e.g., a user wants to sell smartcoins for ordinary bitcoin. The HW wallet has to know the exact amount of smartcoins being sent.) With scriptSig Malleability (https://en.bitcoin.it/wiki/Transaction_Malleability), a variation of the original proposal could be done with a soft fork:
First, redefine OP_NOP1 to OP_CHECKVALUE. If the top stake item does not equal to the value of the input, the script fails. If they are equal, OP_CHECKVALUE does nothing.
The scriptSig for a standard send-to-key-hash transaction will look like this: <sig> <pubKey> <value> OP_CHECKVALUE OP_DROP
and the combined script will be <sig> <pubKey> <value> OP_CHECKVALUE OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
For old version clients, OP_CHECKVALUE is simply OP_NOP1, which will do nothing. OP_DROP will then remove <value>. So the design is completely backward compatible.
(This is my first time designing a script. Please comment)Edit: sorry it doesn't work, as the <sig> does not sign <value> |
|
|
|
2013/06/13
15:16:48
withdraw Status: confirmed $10,000.00000 $4,408.06989
Withdraw to account BENDIGO BANK LIMITED
Still not processed, so the $1M must have all been withdrawals requested before 13 June.
Please report here when you receive the wire |
|
|
|
I think there is another way to do this, but still need a soft-fork: 1. Define a new transaction version: valid only if total input amount = total output amount 2. Miner fee is sent to OP_TRUE 3. The rest will follow https://gist.github.com/gavinandresen/2355445This has 2 bonus effect: a. People using this type of transaction will not accidentally send a huge amount of transaction fee b. In multi-parties contracts, people can define fee explicitly The drawback is that would cost extra block space, so the transaction fee will be higher in long run Comments? |
|
|
|
Rule changes are, by definition, not "backwards compatible". That is the whole point of Bitcoin. You are SUPPOSED to get hard forked off if the rules change and the fact that blocks stop being processed at that point is deliberate.
Yes, if you were to introduce something like ZeroCoin, ordinary users would expect it to be a hard fork. Soft forks are a nasty hack that violates peoples expectations of how their nodes will behave in the face of rule changes.
Rule changes could be backwards compatible, e.g. allowing homosexual marriage would not make any existing or future heterosexual marriage illegal. The opposite is true for bitcoin: tightening rules would not make existing clients obsolete The ability to soft-fork is one of the most visionary design in bitcoin |
|
|
|
Sounds like a good idea. So these mini-blocks would only contain the time, the previous block hash, and the nonce? Would they also contain the previous mini-block hash or just the previous normal block hash? I am assuming that you would expect miners to choose the chain with the most mini-blocks in the case of a fork? That makes a lot of sense.
The proposal here is to just use it to determine total network power. In my thread (referenced in the OP, but not linked), the proposal was to have miners count the number of mini-blocks confirming each full block and then use that to break ties. This would move the majority of the network hashing power onto a single block much faster than the current system (when 2 blocks are found at around the same time). The current system waits until the next block happens before breaking the tie. As an experiment, I think it is good to first implement it as a voluntary system like OP, and make it mandatory when we have more data |
|
|
|
The idea is interesting, but I think I don't fully understand it, or there's a flaw: without the full block with TXs, how can everyone else verify the PoW is within 1/20 of the required one?
all you need is the block header to verify |
|
|
|
|
Assuming this is true, I suspect they might have deliberately withheld the announcement to cause panic and drive the price down, i.e. dump and pump
|
|
|
|
https://mtgox.com/press_release_20130704.htmlStatement on Resumption of Withdrawals and Improved Banking TOKYO - JAPAN - July 4th, 2013 Dear Mt. Gox Merchants, Mt. Gox is happy to announce that global account withdrawals have now fully resumed as of today, after several days of testing our new system for processing transactions. We want to keep you informed about our progress in this arena, and especially assure our customers that their funds are accessible. Progress in the Previous Two Weeks While we announced that there would be a temporary hiatus on withdrawals, during our testing over the past two weeks we managed to process over $1,000,000 USD to customers. As this required a great deal of manpower and was not a perfect solution, we are quite happy with the progress made despite the conditions. New Banking Partners Mt. Gox has now formed relationships with several new banking partners both in Japan and around the world, and we are still in the process of finalizing even more. This means that we will have increased stability and ability to transmit withdrawals going forward. Current Back-log The new system is just now getting under way, so there is still a back-log of withdrawals that we need to process. Our team is working hard to increase transaction speeds, but there is approximately a two-week back-log we need to overcome. It will take a few weeks to get back to normal, and we thank you for your patience during this time. Moving Forward We at Mt. Gox are proud to be one of the first advocates and entrepreneurs in this growing ecosystem, but much still needs to be accomplished to bring trust and stability to a mass market. In addition to our improved withdrawal system and new trading engine, we are very excited about the innovation happening across our industry and around the world. Despite the hiccups, these are exciting times and we are eternally grateful for your confidence and support along this bumpy road. Regards Mt.Gox Co. Ltd Team.
|
|
|
|
So, is the only thing that will decide whether this is used or not is whether miners will be willing to include the larger transactions?
We need a hard fork for this to work. Coins are changing owner based on some added cryptography. gmaxwell said it could be a soft fork: https://bitcointalk.org/index.php?topic=216982.0I don't really understand the math behind zerocoin. However, if the "added cryptography" is more restrictive than current rules, that would be a soft fork |
|
|
|
Pretty sure this will never happen. I don't think theymos wants the forum to be holding money for random people.
I had an idea about that, though I'm not sure whether I'll do it. The forum could accept BTC and in return give "forum credit", which could not ever be withdrawn for BTC, but which could be used for ads and donations. Since forum credit has value, a market would develop with an exchange rate somewhat less than 1 BTC per BTC of forum credit. A micropayment system could be based on forum credit; receiving 1 BTC of forum credit would be just a less convenient and more centralized way of receiving ~0.95 BTC. Micropayments are a very low priority in any case, though. You can use the bitcoinj micropayment channel, so you don't need to hold a huge amount of BTC in hot wallet |
|
|
|
JP Morgan has been using its tricks to heavily manipulate the silver market for years. Everybody in silver is bitching about them, but now if the Winkle-evil's do the same thing in BTC everyone cheers them because that will very possibly increase the BTC price in the short term, which is the only thing most of people in here cares about.
It's pretty pathetic and destructive and it's not only here, it's the majority of bitcointalk and r/bitcoin who are happy to scam the unsuspecting public out of the option to withdraw Bitcoins and store them as long as it makes the current Bitcoin holders money. This is nowhere like with gold where it's simply unfeasible. Unfortunately this has become the world we live in. Regardless, it probably won't be approved by the SEC anyway. Every single satoshi in ETF should be backed by real bitcoin. If they publish their cold storage addresses to prove they are not short-selling paper bitcoin, I can't see why this is not good |
|
|
|
From my understanding, even if you do have 51% of the hashing power, modifying the source code to change the block rate, reward, or difficulty, will have no effect. Are there any parameters that an attacker with 51% of the hashing power could potentially modify in the source code to gain some kind of advantage or cause damage to the network?
see my reply at #9. with similar logic the government with 50% hashing power can also force people to pay transaction tax (by adding an extra output to the gov account for all transaction) or freeze accounts with illegal activity. They can also turn it into a Solidcoin-like system, which requires every block to be signed by the central bank. Zerocoin (if ever implemented) will be prohibited. p.s. the IPO document says "manipulate", not "modify" |
|
|
|
In the Winklevoss IPO filing: https://www.sec.gov/Archives/edgar/data/1579346/000119312513279830/d562329ds1.htmIf a malicious actor or botnet obtains control in excess of 50 percent of the processing power active on the Bitcoin Network, such actor or botnet could manipulate the source code of the Bitcoin Network or the Blockchain in a manner that adversely affects an investment in the Shares or the ability of the Trust to operate. I get that such an attacker can double spend their own coins, but how does controlling more than 50% of the hashrate allow anybody to manipulate the source code?? Yes, people COULD manipulate the source code if they control >50%. Just imagine a government with >50% wants to request everyone register their bitcoin addresses. They will put these addresses to a whitelist, and only those transactions sending money to whitelist addresses will be accepted. They will also publish the whitelist and request all miners to follow. They will reject any blocks involving non-whitelist addresses. In order to survive, miners have to follow the rules and modify their bitcoind sourcecode to implement the whitelist policy. Winklevoss uses the word "manipulate", which means "to influence or manage shrewdly or deviously". Good point, thanks. I had the same doubt as yours when I first read this. IMHO, this IPO document is a very professional summary of bitcoin ecology and the risks of bitcoin investment/technology |
|
|
|
The people saying that they don't see the point in an ETF because you can manually purchase your own bitcoins are living in a bubble world.
Not everyone is a Bitcoin nerd.
If you make anything easier to access, you expand the market. The ETF isn't for people on this forum. It's mainly for everyone else.
Some people are still stick in 2010 thinking the entire world of BTC is just a few thousand computer geeks. The world has moved on. The ETF is a great idea.
And for many institutional investors / pension fund managers, they may not be allowed to invest in physical commodity directly. They can only invest in instruments on a public exchange like NASDAQ and the Bitcoin ETF will be their best and only choice; and these are where the real big money comes from. And if you are trading bitcoin purely for speculation, Bitcoin ETF on NASDAQ will be a better choice. You don't need to worry about the incompetency of MtGOX. You don't need to worry about wire-transfer halt. You don't need to worry about DDOS as that also means DDOS of everything on NASDAQ. |
|
|
|
In the Winklevoss IPO filing: https://www.sec.gov/Archives/edgar/data/1579346/000119312513279830/d562329ds1.htmIf a malicious actor or botnet obtains control in excess of 50 percent of the processing power active on the Bitcoin Network, such actor or botnet could manipulate the source code of the Bitcoin Network or the Blockchain in a manner that adversely affects an investment in the Shares or the ability of the Trust to operate. I get that such an attacker can double spend their own coins, but how does controlling more than 50% of the hashrate allow anybody to manipulate the source code?? Yes, people COULD manipulate the source code if they control >50%. Just imagine a government with >50% wants to request everyone register their bitcoin addresses. They will put these addresses to a whitelist, and only those transactions sending money to whitelist addresses will be accepted. They will also publish the whitelist and request all miners to follow. They will reject any blocks involving non-whitelist addresses. In order to survive, miners have to follow the rules and modify their bitcoind sourcecode to implement the whitelist policy. Winklevoss uses the word "manipulate", which means "to influence or manage shrewdly or deviously". |
|
|
|
"Big blocks will make bitcoin centralized" is a common argument against increasing block size: http://www.youtube.com/watch?v=cZp7UGgBR0IThis is not new but I would like to summarize the solutions for this problem. 1. Partial validating node with web-of-trust. Currently, there are 3 major types of bitcoin clients: full clients (e.g. bitcoind), SPV clients (e.g. bitcoinj), server-trusting clients (e.g. electrum). We can implement the 4th type: partial validating clients (PVC). User may assign certain amount of system resources (CPU power / bandwidth / storage space) to bitcoind. If the node is unable to verify a block before the next block arrives, it will automatically turn into a PVC. Instead of verifying every blocks, a PVC will skip some of them. When a block is verified, a PVC will publish a signature for the block. Through a web-of-trust, people will be reasonably confident that the longest chain is a valid chain. This could even be extended to mobile device. For example, a smartphone, which is normally running as SPV, may turn into a PVC when it is connected to AC power and wifi. Even only one block is verified per day, the network is strengthened as a whole. 2. Mining pools and full nodes on trusted platform. As some people are advocating centralized "bitcoin bank" running on trusted platform (TP), I think mining pool and public full nodes can also use TP. A full node on TP will accept new blocks and new transactions through encrypted channel, so that the network administrator won't be able to censor any block/transaction. They will also answer queries like normal full nodes but also in an encrypted way. With remote-attestation and fidelity bond ( https://bitcointalk.org/index.php?topic=134827.0), it is very unlikely that the operator may cheat. Based on TP full nodes, we can further establish TP mining pools. It's like a normal getblocktemplate mining pool so miners are free to construct their blocks, without doing any transaction validation themselves, assuming that the pool is trustworthy. Again, the integrity of the pool is secured by remote-attestation and fidelity bond. Therefore, mining will be decentralized even with huge block size. Mining over TOR is also possible. Again, people will verify the integrity of TP full nodes with the partial validating nodes I described. 3. Limiting the size of UTXO in a block. This may not be necessary, but some have raised related concerns ( https://bitcointalk.org/index.php?topic=153133.0). When the max block size is raised, we may put another hard limit for the growth of UTXO size: Total size of new outputs - Total size of spent outputs. This will also encourage people/miner to merge dust outputs. 4. Distributing historical blockchain offline. Currently the blockchain could be stored in 2 DVD-R (4.3GB). A single BD-R (25GB) should be enough for the coming year. The next generation disc (Holographic Versatile Disc) will store 6TB. We shouldn't depend on the p2p network to distribute the historical blockchain. |
|
|
|
|
Show Posts
