My account was compromised...  It can't have been a brute-force attack. My password couldn't have been brute-forced. |
|
|
|
That is a quite negative view I think. This could easily be resolved by requiring that the list of peers being sent from a supernode is up-to-date (as in, the nodes are still online). When the client begins to connect to the list of peers received and hits a certain number of failed connections, block all updates from that supernode.
I suggested something like that earlier in the thread... I'm not saying the idea is bad. I'm just saying that not broadcasting your own IP will by itself not be very helpful in the long-term, and thinking only of that might lead down the wrong path. For example, if we know that supernodes will need to check peers, a new network command for "am I reachable?" will not be necessary. You can just see whether you appear in the addr lists of your peers (if their version is OK). |
|
|
|
Ah I just assumed since the software seems to list number of blocks instead of block number there would be a difference of one since the first block was number 0.
Both Bitcoin and BBE consider the genesis block to be block 0. Bitcoin's getblockcount is named very misleadingly (for historical reasons): it actually reports the block number instead of the block count. There's actually getblockcount+1 blocks if you count the genesis block. |
|
|
|
Blockexplorer will normally appear to be 1 block behind because their counting starts at 0 rather than 1.
Bitcoin Block Explorer counts the same way Bitcoin does. It just has a slight delay. |
|
|
|
sure, but that has very little to do with bitcoin, no? the same central signer could support paypal, wire transfers, etc., all at the same time.
i suppose what's novel with bitcoin plus a central signing service is that the signed tokens could be denominated in bitcoins, but that still seems to have little technically to do with bitcoin. in other words, it has about as much to do with the bitcoin protocol as otc trades of bitcoin balances on mt. gox.
It just seems to fit. Bitcoin and blinded tokens are cryptographic systems with swapped strengths and weaknesses. Auditing is easier with Bitcoin, since anyone can see the funds owned by the central authority. (Of course, proving that they have a full reserve is more difficult.) |
|
|
|
|
This seems unnecessary to me. I have not seen any posts that apply only to Canadian people, and even ones that are somehow related to Canada would not fill a page.
|
|
|
|
|
Bitcoin is not very anonymous, but a lot of people want it to be. With blinded tokens, BTC can be transferred anonymously.
You send some bitcoins to the service and get the appropriate number of tokens back. Transfer of these tokens is untraceable after this, even by the central server. When someone who has tokens needs BTC, they can convert them back.
Instant transactions and low fees can be done without the blinded tokens, but you might as well add that benefit as long as you're using a central server.
|
|
|
|
You mean... do exactly what they can do now?
Yes. There's no point in making these changes if an attacker can easily undo their effects, though. |
|
|
|
|
My view of a perfect fee system:
Senders can choose any fee they want. The default fee is calculated by analyzing past blocks. Sends must be cancelable, which will allow people to test fees and make mistakes without losses.
Mining fees start at a reasonable default, but they can be changed in the GUI.
For relaying, non-free transactions (determined based on configurable rules with reasonable defaults) are always relayed. Free transactions are dropped randomly with a probability according to their priority. So you can always get free/cheap transactions broadcast if you keep resending long enough.
|
|
|
|
|
A leaf/supernode distinction is definitely needed.
If this only changes whether a peer will broadcast itself, it seems that an attacker could break these rules and flood bad addresses. Maybe addresses need to be checked before being relayed (possibly with a random chance of checking).
|
|
|
|
|
Once transaction cancellation is possible, it will be safe to let the user pick any fee they want, since there will be no serious consequences. Right now sending a transaction with too low a fee might get it stuck permanently.
|
|
|
|
The topic should reflect the content of the thread. For off-topic discussion, a new thread should be created. (Occasional off-topic posts might be ok).
These rules already exist. They are part of "common sense". Use the report feature if you see this stuff. Further discussion about existing topics should be posted in the existing thread(s). I don't like this rule. Often there is a lot of new and useful discussion in "duplicate" threads. Even the constant "Deflationary=bad" threads get very good replies. |
|
|
|
|
Currently I am keeping logs forever. I have logs since BBE was first started (and before). Make sure you use Tor while accessing BBE if you need anonymity.
|
|
|
|
|
Chaumian blinded tokens would fix many of the problems with Bitcoin. They provide much better anonymity and instantly-clearing transactions. It must be centralized, though.
I predict that they will become very popular.
|
|
|
|
|
They just organize addresses. There's no way to control which addresses you actually send from yet.
|
|
|
|
|
The lowest I personally bought at was 0.00805.
|
|
|
|
The lowest purchase/sale on a public exchange was for 0.003/BTC, it's mentioned in a recent thread here, by the seller who has no regrets.
Yep, I traded at that price. I believe it's the lowest.  |
|
|
|
|
I sold 15,000 BTC for about $45, and I've bought at around that price, too. It really was worthless a year or so ago.
It was surprising when the price reached $0.01 -- I had been trading at below a cent for some time.
|
|
|
|
|
As far as I know, latency is currently acceptable, though the simple broadcast network Bitcoin uses is known to be unscalable. In the future lightweight clients will connect to a few full nodes and not relay blocks/transactions. It will be a hub-based network like gnutella.
|
|
|
|
|
Show Posts
