Bitcoin Forum
May 09, 2016, 01:02:36 AM *
News: New! Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  Home Help Search Donate Login Register  
  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 23 24 25 26 27 28 29 30 31 32 [33] 34 35 36 37 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 ... 114 »
641  Bitcoin / Bitcoin Discussion / Re: Need clarification for a review of freebitcoins.appspot.com on: June 01, 2012, 05:39:57 PM
Once.

(it is actually once every couple of months, but that's a secret and might change so don't tell anybody that)
642  Bitcoin / Bitcoin Discussion / Re: Decline in listening hosts on: May 31, 2012, 02:03:14 PM
Sipa has been busy implementing IPv6 support and much better support for running bitcoin as a Tor hidden service. Both of those should help make the network more robust and resistant to attack. If a lot of people decide to run only inside Tor then it will look like even fewer nodes are listening, though.
643  Bitcoin / Development & Technical Discussion / Re: [Bounty] How-to Multi signature transactions on: May 31, 2012, 01:21:52 PM
How can I create several multisignature transactions using same addresses?
Use one of the send commands to send to the multisig address several times and you will create several multisig transactions.

addmultisigaddress does not create a transaction, it just creates a place for future transactions to go.
644  Bitcoin / Development & Technical Discussion / Re: Lost Bitcoin Recovery on: May 31, 2012, 12:33:08 AM
There will be 2.1 quadrillion satoshis.

There are approximately 770 trillion pennies in the US M2 money supply.

We've got a VERY VERY long way to go before bitcoins are as popular as dollars, and there are much higher priority things to work on right now than adding more divisibility for a problem that is pretty likely to never actually be a problem.
645  Bitcoin / Development & Technical Discussion / Re: Proposal: A Second Chain for Scalability on: May 30, 2012, 06:59:35 PM
etotheipi:

Sorry, I was responding to the original proposal, not yours, I should have made that clear.

Better protocol support for lightweight clients is a Good Idea.
646  Bitcoin / Bitcoin Discussion / Re: Decline in listening hosts on: May 30, 2012, 05:43:52 PM
...
within a year or so, only people with a dedicated ASIC (costing $1000+) can mine (even fewer people).

And in two years maybe anybody who can afford to buy an asic-mining-space-heater for their house can mine.  And in ten years maybe new houses will come pre-equipped with asic-mining-baseboard-electric-heaters.

Or maybe not.  Nobody knows what is going to happen, which is why I keep repeating BITCOIN IS AN EXPERIMENT IN PROGRESS.  If you can't handle uncertainty and the very real possibility that the experiment will fail, then don't get involved (but don't come back whining that you missed out if the experiment turns out to be a huge success).

Quote
The thing is that while that the raw hashing power needed to attack the network is growing, the number of miners you need to target by DDOS or otherwise (if you are a malign government wanting to take down Bitcoin) is getting lower by the day!
IMO the 3000 nodes that we currently have seems like an easier target for a well funded attacker than than the prospect of deploying 55,000+ spartan 6 chips to brute-force a 51% attack.

What do you think? Is the chronic decline in hosts a genuine problem for the backbone p2p network?
No, I don't think it is a problem, any more than the relatively small number of "backbone" routers are a problem for the Internet. The bitcoin network is evolving in roughly the direction I expected it would (lots of lightweight clients connecting to a smaller number of heavyweight "backbone" nodes).

All of the incentives are for merchants, exchanges, and big mining pools to accept lots of connections, relay only valid transactions and blocks, and be as DoS-resistant as they can afford. Merchants and exchanges want transactions to be validated quickly, the big mining pools want their payouts to be processed quickly and want their blocks propagated quickly, and they all want to be reliable.  The big exchanges and mining pools have ALREADY implemented DDoS countermeasures because they have ALREADY been attacked. And the network keeps chugging away, processing transactions....
647  Bitcoin / Development & Technical Discussion / Re: Transactions chaining ( create/sign ) question on: May 30, 2012, 05:23:03 PM
Chaining not-yet-signed transactions is impossible because transaction inputs are identified by the previous transaction's hash, and the transaction's hash includes everything about the transaction, including the signatures.

A multisignature transaction taking funds from #1 and paying them to #4 that requires signatures from #1, #2, and #3 should accomplish the same thing, though.
648  Bitcoin / Development & Technical Discussion / Re: Proposal: A Second Chain for Scalability on: May 30, 2012, 05:12:47 PM
So code up a prototype:

+ Implement code that computes and publishes 'balance blocks' and 'balance block hashes'. Convince a couple people with extra download bandwidth to run it.
+ Modify one of the bitcoin implementations to download the latest 'balance block' from some trusted place at startup, and use it if transactions/blocks can't be found in the traditional block database.
+ Extra credit/paranoia : query a couple of trusted places for the balance block hash, and make sure it matches the hash you got.
+ OR: randomly spot-check the balance block by requesting blocks in the traditional way, and make sure the balance block doesn't list any outputs as unspent that are actually spent.

You don't want bitcoin address balances, there are no addresses way down deep inside. You need to know which transaction outputs have not yet been spent, and the value of those outputs.

I'm not excited about this proposal, because I think it is solving a problem that doesn't need solving yet, and my priorities for bitcoin continue to be wallet security and network stability, not making it quicker for newbie solo miners to get a full blockchain so they can start validating transactions/blocks.

649  Bitcoin / Development & Technical Discussion / Re: cbitcoin - Bitcoin implementation in C. Currently in development. on: May 25, 2012, 01:15:06 AM
I'm not familiar enough with Satoshi client internals to easily understand what script_tests is doing.  Could you confirm my understanding of the format of the two JSON files?

The format is a list of pairs, where the first item is the scriptSig required to spend and the second is the scriptPubKey. The third item is ignored (useful for comments).

script_valid.json contains only valid scriptSig/scriptPubKey pairs.
script_invalid.json contains only invalid scriptSig/scriptPubKey pairs.

valid/invalid are defined by the rules of transaction validation, and the unit test actually constructs transactions and runs the verification routine on them to make sure that they succeed or fail, as expected.

650  Bitcoin / Development & Technical Discussion / Re: cbitcoin - Bitcoin implementation in C. Currently in development. on: May 24, 2012, 03:42:16 PM
Your unit tests look like they'll miss lots of edge cases.

I've been working on cross-implementation unit tests for Script, and am actually working on more tests today (and am working on a testnet reset that will embed the "should validate" tests into the testnet block chain).

JSON format tests are here:
  https://github.com/bitcoin/bitcoin/tree/master/src/test/data

(read by https://github.com/bitcoin/bitcoin/blob/master/src/test/script_tests.cpp )
651  Bitcoin / Development & Technical Discussion / Re: [Bounty] How-to Multi signature transactions on: May 22, 2012, 01:18:19 PM
Quote
$ ./bitcoind addmultisigaddress 2 '["0446fc07bc99bef8e7a875249657c65e1f1793fd0bf45e2c39d539b6f8fcd44676acc552ab886c1 1eb08f4a275e7bb7dc4fdaf9c4b2228856f168a69df7d216fbc","04df70eb0107ed08e1ddcd4b4d85d26bf8cca301f5c98fd15f5efef12ba4de72bfef7287f964e30 4207164c003029449740aaae2d6af1ff7ae3f6bb27f3012296c","046003581a3ff5bc3dedaa6da4834ce7bcd49d3f114ce15791f6b5de8b0cec81a46db2eb8cf84d2 db845854c57788c7283ab4040aeb3595bc5c68303a17fdde7c8"]'
Works in a Terminal on my Mac, returns:
Quote
3EffXJKyYB9zWh2dhx2hcccqBK8DGC7x2x
... which validates as:
Quote
Code:
$ ./bitcoind validateaddress 3EffXJKyYB9zWh2dhx2hcccqBK8DGC7x2x
{
    "isvalid" : true,
    "address" : "3EffXJKyYB9zWh2dhx2hcccqBK8DGC7x2x",
    "isscript" : true,
    "ismine" : false,
    "script" : "multisig",
    "addresses" : [
        "1HEmNY7Lpsqc81nP6JAymjGuuvdFLaqt1e",
        "1Gpuy32bmhtn3KL6dBDHdTHfMosXRH6xV4",
        "1AbU2FDgJRKejuY4e4XGYEfzo6uAGQ1Kyy"
    ],
    "sigsrequired" : 2,
    "account" : ""
}
I don't know enough about Windows CLI quoting rules to get ["...","...","..."] passed un-modified to bitcoind.exe.  
652  Bitcoin / Bitcoin Discussion / Re: Could this be used to attack Bitcoin? on: May 21, 2012, 12:25:16 AM
Could this be used to attack Bitcoin?
No. Bitcoin connections are TCP, so you can't forge the IP address.

I've also implemented denial-of-service checks that automatically ban misbehaving peers to make network disruption attacks more difficult. Trying to anticipate future DoS attacks is hidden engineering work that you will never notice if we get it right.
653  Bitcoin / Bitcoin Discussion / Re: Has anyone lost his wallet or have been stolen? on: May 18, 2012, 02:14:33 AM
The Bitcoin Faucet's wallet was stolen a couple of months ago:
  http://gavintech.blogspot.com/2012/03/bitcoin-faucet-hacked.html
654  Bitcoin / Development & Technical Discussion / Re: [Bounty] How-to Multi signature transactions on: May 18, 2012, 01:20:53 AM
Ok, I need to create multi signature transaction.. 2-of-3... What do I do?
Gather (or generate) 3 bitcoin addresses, on whichever machines will be participating, using getnewaddress or getaccountaddress  RPC commands (or copy and paste from the GUI).

Get their public keys using the validateaddress RPC command 3 times.

Then create a 2-of-3 multisig address using addmultisigaddress; e.g.

Quote
bitcoind addmultisigaddress 2 '["044322868cb17d64dcc22185ae2d4493111d73244c3668f8ac79ecc79c0ba8d30a6756d0fa20157 709af3281cc721c7f53321a8cabda29b77900b7e4fe0174b114","..second pubkey..","..third pubkey.."]'
addmultisigaddress returns the multisignature address. Be a little careful, the public keys are raw hexadecimal and don't contain checksums like bitcoin addresses do.

You can then send funds into that 2-of-3 transaction using the normal sendtoaddress/sendmany RPC commands, or the GUI (or anything that's been updated to recognize multisig addresses).

That will create a multi signature transaction.

If you want to then SPEND the funds sent in that 2-of-3 transaction... that isn't implemented yet (well, if bitcoin has all 3 private keys in it's wallet then the funds will show up in the wallet's total balance and it may be selected to be spent like any other funds received by the wallet). "We" need to implement RPC calls to implement BIP 10 or something like it.
655  Bitcoin / Development & Technical Discussion / Re: Deterministic wallets in the reference client on: May 15, 2012, 04:58:37 PM
What Pieter said. BIPs are intended to make it easier for different implementations of Bitcoin to inter-operate with each other. The existing network protocol is just one piece of that.
656  Bitcoin / Armory / Re: Building Armory on OSX on: May 15, 2012, 12:42:56 PM
Bitcoind doesn't run on ppc-- and minimum supported osx version is 10.5.

And Armory depends on bitcoind, right?
657  Bitcoin / Bitcoin Discussion / [ANN] Critical vulnerability (denial-of-service attack) on: May 14, 2012, 04:56:30 PM
We have been quietly notifying the largest exchanges, merchant service providers and mining pools about this issue, and waited until they upgraded or patched their code to go public with this:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

CVE-2012-2459: Critical Vulnerability

A denial-of-service vulnerability that affects all versions of
bitcoind and Bitcoin-Qt has been reported and fixed. An attacker
could isolate a victim's node and cause the creation of blockchain
forks.

Because this bug could be exploited to severely disrupt the Bitcoin
network we consider this a critical vulnerability, and encourage
everybody to upgrade to the latest version: 0.6.2.

Backports for older releases (0.5.5 and 0.4.6) are also available if
you cannot upgrade to version 0.6.2.

Full technical details are being withheld to give people the
opportunity to upgrade.

Thanks to Forrest Voight for discovering and reporting the vulnerability.


Questions that might be frequently asked:

How would I know if I am the victim of this attack?

Your bitcoin process would stop processing blocks and would have a
different block count from the rest of the network (you can see the
current block count at websites like blockexplorer.com or
blockchain.info).  Eventually it would display the message:

"WARNING: Displayed transactions may not be correct!  You may need to
upgrade, or other nodes may need to upgrade."

(note that this message is displayed whenever your bitcoin process
detects that the rest of the network seems to have a different
block count, which can happen for several reasons unrelated to
this vulnerability).


Could this bug be used to steal my wallet?

No.


Could this bug be used to install malware on my system?

No.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQIcBAEBCgAGBQJPsTpaAAoJECnZ7msfxzDB76cQALBqcEb40dQOtopbsk7vHDuL
FL4xd56B1/s3idyHGeCuwJX5bgxGD9b3svayXhDiLo9O+5E3sxsLY1HehTXnU8KV
BGpIQ7I+XLDcmarGYrDLMNMDLFOp/1hTipi08X3cr6oHNdYOxGbdtqCQR8xxtdfh
Mmo07ReYYWamlF+QbwoXIJQOEka2UVeWWgmk1C+WW1phI3P3Of5EvWvkmOurZsY1
zew7G3sk0Lu8glxSt8qq1SKlDXOaSqTBPxs+2FtgkUplNrAIyufu0vCTsnC44oie
ndJD6XZAaG6cYr3adGQKmUjRR+oyZarMtBdDHBvYHkrQI4uQclL1aS7DhkLtH8kp
fBRHdqmbBJpmpWOcs+OZeaQCzrArKihuVVZqP4HYbHgGHLV3Ls1bebyWm5eLZH6Z
C5l3B4Hz/lp50gJpVsIZI291l3KWfoBW2qGyQv51U4uByLU8tPzgr5bdyo6YCo4N
XQZHveNInMDI8jSimGyHg7WNm0YjkSAM8PEIJhQuL+RaHKgN/ghLPR+1K1YZnMjq
BPdJZVDpP2bgClyj6P+UkhAplEoenxZUsjyRmcs9EWjHZo3UUI9MLZW96vkR0Wlv
UBgq0/jSNQ6s3U3YwKM8CDFJ4OB7Mu1Ln6sn+Tu5sl3xtPyapARA5K67FYSpvqVX
GNIME8aiNjICQmtIFiuX
=9L8G
-----END PGP SIGNATURE-----
658  Bitcoin / Bitcoin Discussion / Re: Zero sum games on: May 14, 2012, 01:50:56 PM
I'm definitely not in the "speculators are evil" camp.  Speculation for the right reasons (hedging risk, for example) is a very good thing.

I personally think speculation for the thrill of gambling is not a good thing, but I'm also not in the "Every Bad Thing (where I get to decide what Bad and Good is) Should Be Illegal" camp. If you want to gamble you should be free to do so; I think it is stupid that we let rich people on Wall Street gamble with other people's money and yet have laws that make it illegal for not-so-rich people to gamble with their own money.

From his post, Tong thought about Bitcoinica and decided that he could be more effective at making the world a better place by working on something else that is more obviously positive-sum. Good for him!
659  Bitcoin / Bitcoin Discussion / Zero sum games on: May 14, 2012, 01:28:08 AM
It seems I touched a nerve when I said that getting better at playing a zero-sum game isn't a good way to make the world a better place.

I was thinking of day-traders at the time; people who don't care what asset they're buying and selling but just try to buy low and sell high to make a profit. Or high-frequency traders who try to be just a tiny bit faster executing transactions to take advantage of tiny inefficiencies in markets.

Probably I don't have a deep enough understanding of the value of liquidity in asset markets or a deep enough appreciation for their role in creating market prices, but it seems to me the world would get along just fine without them spending all their time and effort competing against each other.

I wasn't thinking of competition in general as being a zero-sum game, because in general it is not.  Competition drives efficiency, and efficiency (creating more by using less) is what makes the world a better place -- assuming that the thing you're making more efficient has a positive effect on the world.  Competing to build the most efficient bomb or assault rifle is not a world-improving activity.

To bring it back to Bitcoin: competition between Bitcoin miners is a zero-sum game for the miners, but if you think that Bitcoin will make the world a better place (I do) then the competition to be more efficient at mining is a net positive for the world as a whole.
660  Bitcoin / Bitcoin Discussion / Re: I'm leaving Bitcoin on: May 13, 2012, 02:04:26 PM
Good luck-- I share your view that coming up with better ways of playing zero-sum games is not the way to make the world a better place.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 [33] 34 35 36 37 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 ... 114 »
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!