Bitcoin Forum
May 09, 2016, 01:10:14 AM *
News: New! Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 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 »
1901  Bitcoin / Bitcoin Discussion / Re: Mining cartel attack on: December 14, 2010, 02:28:55 PM
The only rule oddity in the simulator is: when the Network (all those who are not the cartel) solves a hash, it is not credited a mined block if the preceding block was mined by the cartel. (In this case, the cartel would use its superior network connectivity to "override" the network's newly mined block with the cartel's previously mined block).

Did you simulate network connectivity at all?  Bitcoin is a semi-randomly connected network, where most of the connections are (I would guess) outbound connections from non-generating nodes who are sitting behind firewalls.  With a typical node having 8 random connections, to different /16 networks, it seems to me it would be pretty tough to get tight-enough control over enough network connections to consistently win the "announce a new block" race.

Anybody know how to estimate what percentage of connections the cartel would have to control to only lose the announce-a-block race 15% of the time?  It'll be way more than 15%....

1902  Bitcoin / Development & Technical Discussion / Re: 0.3.18 Bug Report on "getreceivedbyaccount" display on: December 13, 2010, 05:10:06 PM
You should be using getreceivedbyaddress rather than getreceivedbyaccount. You didn't assign that address to any account.

What theymos said.  You're asking for the balance of the account named '1Fs5rqB2sXZ3kax1r3HfuYpK2ksSxLYJT8', and there is no such account.

Whether bitcoin should return an error (instead of 0) if you ask for the balance of a non-existant account is debatable...
1903  Bitcoin / Bitcoin Discussion / Re: SHA v. 3 Algorithm Candidates Finalized on: December 12, 2010, 10:44:35 PM
Maybe I'm missing something here, but I'm confused... How would getting knowledge of a public key be even remotely dangerous ?

If the hashing algorithms are broken I might be able to generate an ECDSA private/public key pair where the public key hashes to the same bitcoin address as one of your public keys.

If I can do that, then I can spend your coins.

On my list of things to worry about, this is just below "Asteroid impact destroys the earth" (but above "Aliens invade and make me their slave").
1904  Economy / Marketplace / Re: I2P now accepting Bitcoin donations! on: December 12, 2010, 09:54:05 PM
That generates a new address for new CGI script invocation (== each page view).

An attacker, or just a popular web page, could fill your wallet with never-used addresses.
Well, a new address would only be generated on each visit of the "donate" page, not the main page.  I don't think it would be that much space consuming on disk.

Also, is there any other way to prevent public to know how much have been donated ?

getaccountaddress is designed for exactly this kind of thing-- it will return the same address over and over, until it gets used (until somebody donates).  After that, it returns a different address...

Of course, if "the public" is grabbing the donation address off your "Donate to Us" page, they could generate a list of donation addresses, add up the donations received on all those addresses, and figure it out.  Depending on how many donations you're getting that might be easy (scrape the page once per day) or hard (if you're getting dozens of donations per day).

You could make it much harder for anybody to figure out how much you're getting in donations by randomly donating to yourself (using the same address returned by getaccountaddress), preferably from a wallet shared by lots of other people (like a MyBitcoin or Mt.Gox account)... 

1905  Bitcoin / Development & Technical Discussion / Re: CGI script for donations on: December 12, 2010, 09:44:43 PM
You don't want to generate a new address for each web page hit.  That's a lot of useless addresses stored in your wallet.
Change "getnewaddress(label)"  to "getaccountaddress(label)" and you'll get the same address over and over, until somebody donates.  Then you'll get a different one.
1906  Bitcoin / Bitcoin Discussion / Re: SHA v. 3 Algorithm Candidates Finalized on: December 12, 2010, 09:36:58 PM
This thread talks in detail about Bitcoin's use of hashing of ECDSA public keys to generate bitcoin addresses.

Executive summary:
  bitcoinaddress = RIPEMD-160(SHA-256(publickey))

So you'd need to break both RIPEMD-160 and SHA-256 hashing algorithms.  And the RIPEMD break would have to be quite extreme-- more than just "add some random data to force a hash collision" (which is how MD5 is broken), because it is hashing a SHA-256 hash, so you're not able to add some random data to be hashed.

1907  Bitcoin / Bitcoin Discussion / How it Works (for non-geeks) on: December 12, 2010, 05:18:44 PM
I was sent this question in email:

Why can't somebody just create a version of the software that gives you extra bitcoins?

... and couldn't find a good, non-geeky answer in the FAQs.  So I wrote one:

When you spend some bitcoins, the software on your machine has to prove to the software running on everybody else's machine that those bitcoins are valid.

How does it do that? Well, it is a little bit complicated; you've got to understand how bitcoins are created, and how they are traded.

First, how they're created: 50 bitcoins are created approximately every 10 minutes. Everybody who is trying to create bitcoins is in a race to try to find those 50 bitcoins; they are really hard to find, but, once found, it is easy to verify that, yes, indeed, your bitcoin software found them, so you get to spend them.

Second, how they're traded: Imagine you did find 50 bitcoins (well, your computer found them by running the bitcoin software for a few months or a year– they are not easy to find, and are harder to find the more people who are looking for them). You trade them to me by sending them to my bitcoin address. Inside the software, a messages is created and then broadcast to everybody that says “These 50 bitcoins that we all agree are valid are hereby officially traded to somebody else (me– well, one of my bitcoin receiving addresses, actually).”

Now I've got them. If you try to trade those same 50 bitcoins to somebody else, it won't work– everybody running Bitcoin sees all the trades, so if you try to spend the same coins a second time everybody else's software will reject your attempt to cheat.

And that's it– that's how it works. Bitcoins are scarce because only about 50 are created every ten minutes. And you can't claim to have more than you really have because everybody else can check to see if your coins really were created by the “race” process, or if they were from valid trades.
1908  Economy / Scam Accusations / Re: Beware of scammers! on: December 11, 2010, 08:51:14 PM
So final question - is the designer or designers planning on implementing (into the core) a secure system, so none of this nonsense is a problem anymore?

I'm not the designer of Bitcoin (I am one of the developers), but I have been thinking a lot about what it will take to make it safe(r) for my grandma to use.

playanaut, I'd love to hear your suggestions on how to make bitcoin better.  And (shameless plug): I'd also love to know if you think my latest project, ClearCoin, is a step in the right direction.
1909  Bitcoin / Development & Technical Discussion / Re: Accounts: svn rev 188 (JSON-RPC API changes) on: December 11, 2010, 04:15:50 AM
Oh, and RE: privacy:

Mixing all of the 'coins' for all of the accounts together is, I think, an overall plus for privacy.  True, you might receive coins from somebody and be able to figure out "Hey, they sent me some of exactly the same coins I deposited in my BigBitBank account yesterday!   They must have an account at BigBitBank, too!"

But mixing all the accounts' coins together makes it much more difficult to figure out where any user's coins came from, or, if you know where they came from, where the user is spending their bitcoins.  Unless you can subpeona BigBitBank's records, of course...
1910  Bitcoin / Development & Technical Discussion / Re: Accounts: svn rev 188 (JSON-RPC API changes) on: December 11, 2010, 04:09:00 AM
I wrote all this up (minus the little man) for the wiki:
  http://www.bitcoin.org/wiki/doku.php?id=accounts

Let me know if it doesn't make sense.  Or, even better, fix it for me!
1911  Bitcoin / Technical Support / Re: Parse Error when using JayRock on: December 10, 2010, 05:31:15 PM
Sorry to send you on a wild goose chase, the problem is NOT CRLF issues.

The problem is in your HTTP headers; you're sending the request as:

Content-Type: application/x-www-form-urlencoded

The correct Content-Type for JSON-RPC over HTTP is:
  Content-Type SHOULD be 'application/json-rpc' but MAY be 'application/json' or 'application/jsonrequest'

I'm not sure what .net is doing with the body of the request, but by the time it gets to Bitcoin/PostBin, it has x-www-form-urlencoded it enough to confuse the heck out of them.

When you get this working, please update this thread, and for extra positive karma, add a .net section to the Bitcoin JSON-RPC wiki page.
1912  Bitcoin / Development & Technical Discussion / Re: Accounts: svn rev 188 (JSON-RPC API changes) on: December 10, 2010, 01:40:03 PM
So, how is the balance of an individual address managed ?
Lets say two accounts have an address each, i send 100 to address 1, then move the funds between the two accounts, will bitcoin actually use the first address for sending when sending coins from the second account ?

Accounts do not affect the previous-transaction-selection algorithm at all; if you sendfrom FOO, bitcoin doesn't make any effort to only use coins that were received by FOO.

Think of your wallet as being a big pool of coins.  Coins are not stamped with account names when they go in, instead, there's a little man with a green visor making entries in a ledger.

Each receiving address is a pipe that dumps coins into the pool, and the little man knows which pipes are assigned to each account.

Every send the little man grabs his shovel and picks a bunch of coins randomly from the pool.  Then debits an account.

And for moves, the little man doesn't have to touch the coins in the pool at all, he just adjusts his ledger.
1913  Bitcoin / Technical Support / Re: Parse Error when using JayRock on: December 10, 2010, 12:57:53 PM
How can I raise this as a bug?
You just did raise this as a potential bug, but you need to convince me that Bitcoin is not following the HTTP/1.1 spec, which says:

Quote
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see appendix 19.3 for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described in section 3.7.

       CRLF           = CR LF

... and, for 'tolerant' applications:

Quote
The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR.

What character(s) is JayRock putting between the headers and the body?
1914  Bitcoin / Development & Technical Discussion / Re: Accounts: svn rev 188 (JSON-RPC API changes) on: December 10, 2010, 12:49:35 PM
What exactly is the difference between move and sendfrom?  Is it just shorthand for getting the account address and sending the coins to it?  How does a moved coin act in the block chain?

moves do not touch the block chain, they add accounting entries to your wallet to adjust the balances of the accounts involved.
1915  Bitcoin / Development & Technical Discussion / Re: JSON-RPC method idea: list transactions newer than a given txid on: December 09, 2010, 07:41:33 PM
Gavin, could listtransactions have an option to list transactions for all accounts?

I'm not sure what the interface could be, maybe:
listtransactions <JSON null type> [count]

It would be hard to do that from the command line though.

I can't think of a good solution for the interface, that's the problem.  Maybe "*" special case like "" is.  Everyone would have to make sure no user can create account name "*".


Yes, listtransactions "*" <count> is possible.  The other account routines could return a new "invalid account name" error if given "*".

I've got two issues with it, though:

1.  listtransactions "*" will have to iterate over every transaction in the wallet (transactions are not indexed by time), which will be slow for large wallets and will get slower over time.  And indexing transactions just so that listtransactions * is fast violates the "an optional feature shouldn't cost anything if it is not used" principle.

2. What is the use case for "list the last N transactions across all accounts" ?   The only one I can come up with is developing an alternate GUI that communicates with bitcoind via the JSON-RPC, but to support that at least a couple of other features would have to be added at the same time (e.g. listtransactions would needs to add account and bitcoin address information to the objects it returns....)
1916  Bitcoin / Technical Support / Re: Parse Error when using JayRock on: December 09, 2010, 04:53:15 PM
Actually, thinking about it, are you sending \r\n for newlines?

Fricking PC versus Unix versus Mac line-endings will be causing problems until the end of time....
1917  Bitcoin / Technical Support / Re: Parse Error when using JayRock on: December 09, 2010, 04:51:35 PM
You're missing a blank line between the HTML headers and the HTML body-- PostBin and Bitcoin both think you're sending an empty request.

I dunno enough about JayRock to suggest how to fix that...
1918  Bitcoin / Development & Technical Discussion / Re: Automated nightly builds on: December 09, 2010, 04:43:13 PM
I'll be trying to create openSuse and SLE packages too, Debian would be possible too, but compiling wx, boost and libdb sounds a bit excessive to me, anyone interested in helping?

Nightly builds are a great idea; does the build service do an automatic svn update?  Anybody else willing to help get GUI-bitcoin building (or anybody know somebody on the wxWidgets team?)
1919  Bitcoin / Technical Support / Re: Parse Error when using JayRock on: December 09, 2010, 04:14:48 PM
Can you change the username/password in the authentication and then have it POST to:
  http://gavinpostbin.appspot.com/pwbba8

... so I can see all the headers/etc ?  You're probably not sending what you think you're sending...

1920  Economy / Economics / Re: The economics of generalized bitcoin on: December 09, 2010, 04:01:58 PM
Conceptually you have a single BitX chain with several bit-app chains weaving in and out of it.  Generating a BitX block will then allow you to generate a bitcoin block, a bitDNS block, a bit-foo block, etc.

...

The BitX chain is straight-forward although a key observation here is that BitX blocks should never be rejected for bit-app reasons, i.e. a client should be able to accept/reject a BitX block without ever downloading app blocks

Quick reaction:  what stops malicious or lazy BitX chain generator from implementing a type of denial-of-service attack against some bit-app they either don't like or don't know about?  If BitX blocks are never rejected for bit-app reasons, then what is the incentive for main-BitX chain generators to include only (or any!) valid bit-app hashes?   What stops me from constantly flooding the BitX network with bogus bit-app hashes and asking them to be included in BitX blocks?
Pages: « 1 ... 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 »
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!