Who's that woman: Anna LeeI don't know nuthin 'bout changing video default images. If anybody does, I'd be happy to replace or tweak the link to the video at bitcoin.org. |
|
|
|
Let's say there is a scenario where I am one of two different people who claim to be responsible for sending bitcoins for a purchase. How could I prove to the merchant that those bitcoins came from my wallet and nobody else's?
Something like this is possible (I've been thinking about doing it, although I have higher priority things on my TODO list): - Sophisticated user runs a tool on her computer that, giving the bitcoin address payment was sent to and "here's a description of me or what I paid for" string. Tool looks in the wallet.dat and figure out which keypair(s) were used to pay. Then it does some openssl magic and exports a file that contains the string, the public keys and ECDSA signatures using the private keys of the "description of me or what I paid for" string.
- Sophisticated user uploads that file to a "Prove I Paid" website, which checks the signatures and adds info to the database.
- Unsophisticated user goes to website and pastes the receiving address. The public key corresponding to that address is looked up, and all the "here's a description of me or what I paid for" strings for that public key are shown.
bitcointools+openssl (see grondilu's thread about "a shell-script implementation of bitcoin) are enough to do all all the public/private key, file-creation, and signature generation/checking stuff. |
|
|
|
All serious institutions (like banks) never use floats for currency calculations because they know the dangers.
If we want to be seen as "serious", float is not an option.
You know, I was looking at the PayPal payment API yesterday, and $1.01 is sent as... 1.01 "transmitting" != "calculations" |
|
|
|
Then we can make nAPIVersion 0.5 supporting the int64 with appended .0 as luke-jr has done in his gitorious branch.
That's just dumb. If the problem is jsonrpc-supporting-environments that don't support double-precision floats, then multiplying and slapping a zero on the end won't fix the problem-- you'll just either lose precision as it gets squeezed into a 32-bit float or get a 32-bit-integer-overflow error. |
|
|
|
Is there a PHP implementation that does not use double-precision floating point? After doing a little googling I couldn't figure out the answer to that. I will be MUCH more sympathetic to changing the JSON-RPC api if there is. And mizerydearia: re: the witcoin issue: You say: "I see the transaction as 0.94 However, http://json-rpc.org/ retrieves the data as 0.93999999999999994671" So why when you display that value are you truncating it instead of rounding it to 8 decimal places? For example: > php -r "printf('%.8f', 0.94);" #CORRECT
0.94000000
> php -r "printf('%.16f', 0.94);" #WRONG
0.9399999999999999
... or to convert to an integer-number-of-base-unit: > php -r '$val=0.94; printf("%d", round(1e8*$val));'
94000000
All of that assume that your php support double-precision floating point, which brings me back to my question: are there any php implementations that do not? |
|
|
|
It seems reasonable to me to start with UPnP disabled by default. As long as enabling it in the client is easy enough to do, the network will benefit because some nodes will "opt-in" that wouldn't have before. We can change the default later, after we gain more confidence about remote vulnerabilities.
Who knows enough about wxWidgets to add a checkbox to the Settings UI for "Enable UpNP" (grayed out #ifndef UPNP...)? Wanna coordinate with BlueMatt to get that done? |
|
|
|
Seems like this feature doesn't need to be part of the RPC interface-- why not just (ignoring error handling/etc) do the equivalent of: ADDRESS = $(curl https://fishysnax.com:443/path/to?id=genjix)
bitcoind sendtoaddress $ADDRESS 1 ... from whatever code is calling the RPC? |
|
|
|
I had the impression the roadmap called for a BitDNS-like decentralized mapping system, since Gavin asked to map "strings" to addresses. Maybe I misunderstood.
In my head I was imagining a way of telling bitcoin to subscribe to some service(s) that did the mapping-- maybe a setting in the GUI where you could specify "use these six services, in this order, to try to resolve bitcoin addresses that aren't plain-old-bitcoin-addresses." With the services specified by name+URL (and some standard REST-ful protocol was defined for mapping string to bitcoin address). Or maybe name+pattern+URL. I haven't looked at genjix' patch, and haven't thought deeply about security issues-- but I bet there are lots... |
|
|
|
PHP solution: write/maintain my own JSON parser.
Why can't you just multiply the numbers by 1.0e8 and then round to the nearest integer? That integer WILL ALWAYS BE EXACTLY RIGHT (assuming you're not running PHP on some really weird hardware). According to the PHP manual: The size of a float is platform-dependent, although a maximum of ~1.8e308 with a precision of roughly 14 decimal digits is a common value (the 64 bit IEEE format).
I added a Python JSON-RPC library example on the Proper Money Handling wiki page. |
|
|
|
Gavin, you should make it much more obvious about how to give back to the Faucet. In the end I had to click to (try to) get another .05 BTC, at which point it said I had already gotten some, but if I wanted to I could give back to a specific address, which I assume is the Faucet. Is it ok to post it here for confirmation?
The Donate: address is hiding down at the bottom of the page: 15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC ... and I just updated my forum signature, too. |
|
|
|
|
I think you have an incorrect assumption in your argument: what makes you think there will be a high variability in block rewards (because they're mostly fees) 40 years from now?
Assuming bitcoin is still around in 40 years, there should be at least tens of thousands of transactions per block, and with that many transactions sum(fees) should be pretty darn stable.
|
|
|
|
And I dont know how you'd be able to detect that you were being attacked if an attacker simply controlled a large % of the connectible peers. (which reminds me you could actually control 75% of the current network with just 1500 ips because only about 500 peers are connectible)
Well, imagine an attacker did manage to surround your node. What can they do? a) Dropping outgoing transactions-- a send-coins denial-of-service. b) Dropping incoming transactions-- a 0-confirmation-receive-coins denial-of-service Can these be exploited somehow to the attacker's advantage? Maybe if attacker and attackee were competing on a bidding site or the site being attacked was a bidding site and the attacker wanted to squash competing bids. Rounding up thousands of IPs to try to get a better deal on biddingpond hardly seems worth it. And an old-fashioned DDoS attack can probably take out any one particular node anyway, with or without bitcoin involved. c) Dropping new block announcements (that would be a 1+-confirmation-receive-coins DoS) d) ... and maybe feeding the attacked node attacker-generated blocks (d) is more serious, because the attacker could generate bogus N-confirmation transactions. But it should be detectable; assuming the attacker doesn't have as much hashing power as the rest of the network, blocks will be generated much more slowly (either much more slowly after the last compiled-in block checkpoint if you're downloading the block chain, or much more slowly since the last time your node connected to the network). |
|
|
|
|
RE: 25 outbound connections instead of 8:
If I recall correctly (and I probably don't), the percentage of nodes currently on the network that are accepting incoming connections and the -maxconnections limit isn't great enough to support every node trying to make 25 outbound connections.
The major merchants and exchanges should accept incoming connections, so they have many more than 8 connections. That will make them basically immune to Sybil attacks (e.g. the Faucet has 55 connections right now).
I like the idea of major merchants and exchanges (also) communicating with each other over an invitation-only, trusted "backbone." That would be in addition to the mostly-randomly-connected p2p network we have now, not instead of it.
I'm concerned about Sybil attacks as a denial-of-service technique (attacker "surrounds" an 8-connection node and then drops all of their transactions just because they can). Randomly disconnecting and re-connecting seems like a good approach.
Detecting that you're being subjected to a Sybil attack seems like it might also be a good approach. You don't really care if you're seeing a bogus version of the block chain unless you're in the middle of confirming one or more transactions; perhaps if transaction confirmation is taking significantly longer than expected the client should find some fresh peers.
|
|
|
|
Making the fee transaction depend on the block's coinbase would run afoul of this code in CTransaction::ConnectInputs: // If prev is coinbase, check that it's matured
if (txPrev.IsCoinBase())
for (CBlockIndex* pindex = pindexBlock; pindex && pindexBlock->nHeight - pindex->nHeight < COINBASE_MATURITY; pindex = pindex->pprev)
if (pindex->nBlockPos == txindex.pos.nBlockPos && pindex->nFile == txindex.pos.nFile)
return error("ConnectInputs() : tried to spend coinbase at depth %d", pindexBlock->nHeight - pindex->nHeight);
... and the entire block would be rejected as invalid. Which is a good thing, otherwise miners could get around the "no spending newly minted coins for COINBASE_MATURITY blocks" rule. |
|
|
|
1) bitcoind - I think this might be the same as configuring bitcoin to run as server. I believe it uses an RPC API to run transactions from the command line.
Pros: Everything stays on my server
Cons: I have to find a server that will let me compile and install this, rather than just some PHP/MySQL farm in the cloud, which is what I prefer
You can run the front-end on one server and the back-end on another (and communicate via JSON-RPC over HTTPS). That's how I'm able to run the Faucet and ClearCoin on Google's App Engine (they talk with bitcoind processes running on linode.com and aws.amazon.com servers). bitcoind doesn't take much memory, bandwidth, or CPU (just don't turn on coin generation), so, for now, anyway, you can even use an Amazon "micro" server (which costs something like $100 per year). I'm not selling anything so can't comment on the shopping cart interfaces. Screen-scraping web pages is a bad idea for lots of reasons. |
|
|
|
I've been thinking about splitting out the files, too. No functional changes, just moving things around. I think that might help its adoption into the main trunk.
Somebody did that a few months ago (theres a message here in the forums SOMEWHERE...) If I recall correctly, after he was done he found that it wouldn't compile on Windows any more. |
|
|
|
|
Maintaining the faucet isn't a big drain on my time-- most days I don't think about it.
Given the number of newbies who wander into #bitcoin-dev and mention they got 0.05 BTC from the faucet, I think it is still valuable as a nice introduction to using bitcoin.
And Jim: thanks! Without donations the Faucet would have run out of coins long ago...
|
|
|
|
|
You can't send messages with transactions.
There was some discussion of adding another "standard" transaction type that allowed you to add N bytes of arbitrary data. I think that is a good idea (I think people would find all sorts of interesting uses for it), but there are higher priority things on the development roadmap.
|
|
|
|
|
Thanks-- there was indeed a bug in the "weren't you just here?" code...
|
|
|
|
|
The Bitcoin Faucet ran out of coins this morning, so I took that as a sign that I should make some changes that I've been meaning to make for a while.
The big change is the Faucet now requires you to have a Google account (and login with your Google Account) to get coins. With IPv6 starting to happen, and people getting ever more creative in the ways they tried to get around the "X bitcoin per unique IP address" rule, I decided to let Google catch people trying to create lots of accounts.
From what I remember, the cost of buying a google account is much higher than the value of the coins I'm giving out (as opposed to the cost of hiring somebody to solve captchas), so the only people working hard to create new Google accounts to try to rip off the Faucet will likely be teenagers with way too much time on their hands.
One little change: Faucet pay-outs are now:
0.11 BTC when balance > 500 BTC
0.05 otherwise (same as before).
And an invisible change that actually happened a few days ago: the Faucet pays a 0.01 transaction fee every time it sends coins. That makes Faucet transactions get into blocks quicker when there are lots of other free transactions on the network, and leaves more room in blocks for free transactions.
|
|
|
|
|
Show Posts
