Will it be open source or proprietary?
Open. |
|
|
|
My first objection to this is that it doesn't solve the problem of miner front-running; it just makes it more difficult. A few of the largest miners will just make an arrangement to mutually-process each other's fee adjust transactions. Almost inevitably, the design will produce a small group of large registrar-like operators.
More than 40% of the network would have to cooperate to get free domains. If malicious people are getting that much CPU, we have bigger problems. Even if this happens, servers can raise the limit to 7/10 or whatever. Smaller percentages will get you a "discount", but I don't consider that to be a big deal. In particular, it'll be pretty easy to get a 1/5 th discount if you can ever expect to create a block. It's not a problem if people buy up names and then sell them on the market. This is an appropriate way to distribute unique resources. It's like homesteading some land in order to sell it later at a profit. We just want to prevent people from claiming millions of domains for free and then not using/selling them. As for front-running: the first registrant will have an advantage in the race to get 4 adjusts. The first person has to send 4 more messages, while the attacker has to send 5. This can't really be done automatically, either, as people would attack the automated system by registering useless, random domains. |
|
|
|
What is the difference between an address and an account? Are they not the same thing? In version 0.3.13 they seem to perform the same function.
"Label" was renamed to "account" recently. Addresses are grouped into accounts. Lots of people have been confusing "address" and "account". The name should be changed to something more clear. |
|
|
|
Someone (I wont say who) was discussing investing $200 000 into computer hardware which would mean they would control the network for the conceivable future.
Benevolent dictator anyone?
I trust ArtForz even more than Satoshi. If he did that, it would be a great benefit to the network. |
|
|
|
|
Addnode only works with IP addresses.
Also, if you manage to get I2P's proxy to translate the IP address properly, make sure you use an address in the 192.0.2.x range. Bitcoin un-proxifies most other private ranges.
|
|
|
|
|
Nanotube and I will be developing an implementation to go along with our proposal. If you like your idea, create it and let the market decide.
|
|
|
|
|
Only one connection is required, though more is desired for safety.
An I2P "Bitcoin proxy" would have to somehow connect simultaneously to both I2P peers and Internet peers. Otherwise anyone connecting to you would be segmented in I2P.
You will attempt to connect to Internet peers even with -noirc. You will just use the addr/seednode bootstrap mechanism instead of the IRC one. If you want to limit outbound connections to only peers you specify, use -connect=ip or -maxconnections=x in combination with exactly x -addnode=ip switches.
To connect to Bitcoin peers on Tor hidden services, it's necessary to use Tor's MapAddress option. Does I2P's proxy have a similar option of mapping an I2P address to an IP address?
|
|
|
|
|
You should be using getreceivedbyaddress rather than getreceivedbyaccount. You didn't assign that address to any account.
|
|
|
|
Nothing in Bitcoin's JSON-RPC can be used to see generations, apparently. In rpc.cpp, you can see checks like this: if (wtx.IsCoinBase() || !wtx.IsFinal())
continue; Removing the "wtx.IsCoinBase()" check should allow you to see the transactions. I haven't tried it, though -- maybe they won't be handled correctly. |
|
|
|
Is that really true? I thought the "longest chain" was now defined in terms of the difficulties of the specific hash values in the chain, so I would expect that once a client has seen both blocks, it will build on whichever has the smaller hash value. Is it not working that way? Of course until you see the second block, you build on the first one, and it may take some time to switch.
Length has always been defined as "total work", but this is just the number of blocks multiplied by the difficulty of the blocks (for each 2016-block section). A smaller hash is not considered to be better than a larger hash. |
|
|
|
So how much data does the chain contain right now ?
- 97,289 blocks - 56,806,614 bytes - 206,775 transactions - 248,937 outputs - 278,362 inputs - 162,871 addresses |
|
|
|
What happens when two people both transmit a different valid next block? How does the network determine which chain to keep growing?
You build onto whichever one you saw first. |
|
|
|
|
Are you running Microsoft Security Essentials? You need to add an exception for Bitcoin in that case.
|
|
|
|
|
Only generators need to store the entire block chain. Non-generators only need to store the tiny block headers. This is already mostly implemented (see fClient in the source).
|
|
|
|
Am I understanding the mechanism for transactions properly or is it possible for someone who knows what they are doing and has a lot of computer power to spare (say the US Govt..) to build a mostly complete database of all transactions?
No supercomputer is needed. I've already done it: http://blockexplorer.com/How hard would it be to scour the net for these and match them up to the public keys we have so conveniently handed over? Pretty easy to get a list of addresses<->people. Then by following transactions you can get many more addresses owned by the same person. It's harder to see how they got coins, or how they spent them, because Bitcoin tries to mix coins around to some degree. Certainly not impossible, though. I wonder if perhaps some Chaum-ian blinding scheme might be in order - thoughts? How do you do this in a decentralized way? |
|
|
|
Easy? Really?
Yes. If you don't have an Internet connection and the person you're receiving BTC from does, they can double-spend without even modifying the Bitcoin code (by switching out wallets and carefully controlling their Internet connection). |
|
|
|
The pool mining service just happens to run on the same machine. But the payment address did not come from the client in question.
And besides, I wouldn't expect the pool mining service to cause any "Generated" message in anyone's client. Wouldn't it just come in as a regular payment?
It does show up as "generated". I'm sure that you did use an address from that client for pool mining Did you use an address from that computer for just a few minutes? That would also explain the low amount. |
|
|
|
Is it possible to modify the original client to have a "lightweight" mobile-friendly mode and support for offline transactions? Something to ponder before digging into a new bitcoin implementation.
A lightweight mode is already partially implemented. In this mode, you only need to download a few megabytes instead of the entire block chain. Offline transactions would make double-spending attacks easy. |
|
|
|
and I heard the guest talking about some of the economists etc that worked on the project- I wonder if there are some names we could drop (with their permission) to help bring confidence that this isn't some scam etc. Bruce was "exaggerating" about that. Satoshi created nearly everything by himself, and he is known for nothing other than Bitcoin. His professional qualifications are not known. No fees required for transactions (free) This will change in the future. Once people start actively attacking Bitcoin, free transactions will be extremely slow. Fees should always be reasonably low, though. more secure encryption system than online banking (Security) Bitcoin uses no encryption. All of your transactions are transmitted in plaintext. "Cryptography" would be a better word -- Bitcoin uses digital signing and cryptographic hashing. Whether this is stronger than banks depends on your threat model. If no one will get your wallet.dat, then it's basically impossible for someone to steal your money. But if you want protection from wiretapping, Bitcoin offers you nothing, whereas banks have HTTPS. It's as anonymous as you want it to be (privacy) Unless you're really careful, Bitcoin has poor anonymity. See http://www.bitcoin.org/wiki/doku.php?id=anonymity |
|
|
|
For those who wish to remove the restriction on inclusion and relaying of non-standard transactions, here is a patch on 0.3.18 to do so: http://pastebin.com/raw.php?i=Z0DVga74It does these things: - IsStandard is not checked when including transactions or relaying them. - An older, similar restriction on transactions with an unusual size or number of scriptSig OPs is also removed. - Non-standard transactions become ineligible for free space. You will not accept non-standard transactions if they don't include at least a fee of 0.01. You will relay such transactions, however. Generators that apply this patch will potentially receive more fees. However, I doubt anyone will actually produce any non-standard transactions for a while. You are still Bitcoin-compliant by applying this patch. You will not end up on a separate network (unless Bitcoin is changed to make these restrictions network-enforced). Edit: Modified version for SVN 200: http://pastebin.com/raw.php?i=6aQiEJDz |
|
|
|
|
Show Posts
