The reason for connecting to many peers is for security. If you connect to only a few peers, or you design your peer-finding system poorly, an attacker might arrange things so that all of your connections were to computers that he controlled. Then he'd be able to hide published blocks from you, and to send blocks and transactions to you that don't reach the rest of the network. This would allow him to mount something sort of like a 51% attack, but with much less computing power.
In other words, the peer-finding algorithm is security-critical, so you shouldn't mess with it unless you know exactly what you're doing. The transaction and block relaying algorithms are, too, by the way; if a large fraction of the network stopped relaying because they wanted to be lightweight, then 125 connections might not be enough to stay safe anymore.
an attacker CAN NOT create block, just because you are outside the network, he still needs a high amount of computing power, to create a block every 10 min, or even 1 at all. and without any block, there will be no confirmations. thrust an attacker CAN NOT perfrom a double spend attack on you. |
|
|
|
This is multi-key escrow. I believe the blockchain supports it now, with current clients, although there's no GUI support. Ideally you'd use three keys: Alice's key, Bob's key, and a third-party judge's key, such that two of the keys together could release the funds. That way, an anonymous sender couldn't break his agreement and use the threat of withholding funds as leverage.
no because he have nothing to gain from it. |
|
|
|
|
please fork the client, if you want it to change!
i will keep my "wallet.dat" client.
|
|
|
|
Because unlike a bike shed, the term 'wallet' is confusing and leads to unfounded assumptions and more importantly, does not lead to important critical assumptions. A metaphor should not just lead to an immediate association (wallet=money) but imply features, extending the users understanding. The wallet metaphor is a dead end. Yes, it's money, but the entire metaphor stops and noting further can be correctly implied.
Copy wallet = two unique unrelated money vessels
Copy keys = two similar devices granting access to the same vessels
Delete wallet = money falls on the floor
Delete keys = access to money lost
Wallet addresses = makes no sense
Key addresses = similar to postal address, or safe deposit box number
Import keys to wallet = makes no sense
Import keys to keyring = perfectly logical
Backup wallet after receiving change = makes no sense
Backup keyring after generating new keys = perfectly logical
Explaining how bitcoin works with wallet = metaphor is unhelpful, need to describe keys
Explaining how bitcoin works with keyring = useful metaphor that can extend user understanding
suggestion: fork the client, and rename wallet to keyring. i will keep my bitcoin wallet.  |
|
|
|
From reading this: https://en.bitcoin.it/wiki/Running_Bitcoin?utm_source=lasindias.info/blogIt looks like the official client by default connects to up to 125 peers. I was surprised by how high this was but maybe I'm not understanding the overheard. For example, does this mean each transaction received has to be relayed to (potentially) 125 peers? When doing the initial chain download, does the client ever step on it's own toes, for example by doing onblocks to lots of different peers, and then getting lots of redundant inventory messages? Just trying to understand all the performance implications for another client I'm working on. Also, what would change if you only connected to say....8 peers? Thanks! no the client does not step on its own toes, see: https://en.bitcoin.it/wiki/Protocol_specification#inv |
|
|
|
he was proposing a new way of doing escrow transactions, more p2p, but he didn't give any technical details though.
Grondilu just did  yes but its have been know for a lot of time... |
|
|
|
|
its not diffie-hellmann. but yes it would work.
|
|
|
|
If possible, what would the benefits of this be?
Let's say 10-20% speedup in an ideal case. almost none. we could calculate sha256 a little bit faster, but only per block. we would need to optimize for every block...
I believe optimization can be done fairly quickly, thus its cost would be negligible. Especially if you use GPU for main computation and CPU for code generation. I would only be concerned with OpenCL/CUDA compiler not being fast enough, but that's just a technical difficulty. dream on... |
|
|
|
How does the address metaphor fit in with a wallet? Oh, that's right. It doesn't. keys = ... my post box
why can't we just not keep is as it is? bikeshed.org |
|
|
|
If possible, what would the benefits of this be?
almost none. we could calculate sha256 a little bit faster, but only per block. we would need to optimize for every block... |
|
|
|
|
UP UP AND AWAY! BUY BUY BUY!
|
|
|
|
What about purse then? A more universal word than wallet.
because wallet was the word chosen by Satoshi. are you are about to go against Satoshi? do you want to fight? |
|
|
|
I was developing my own bitcoin version, and I need to know. Can someone provide a list of clients that are trusted clients, to always be up, and at the latest version, 24/7. Something that would be hard coded into a bitcoin client.
trusted peers are NOT the way to go. and running the latest version is not possible as it is a opensource project with forks, and alternative clients trusted peers are what bitcoin uses if it can't hit the IRC channel. What do you propose instead? I think he means latest version of the protocol, not the client. These two things get confused all the time because they are both called "bitcoin." i do not trust the peers i connect to! its better to call them known peers. if you want trusted peers go to solidcoin. |
|
|
|
|
This is to all your newbies apparently experts on bitcoin and its inefficient way it works.
Bitcoin's aim is to be DECENTRALIZED, which means it does not need an external authority.
you know how this works right? blockchain, SHA256 hashes, GPUs, and stuff. right? GOOD!
bitcoin is just a voting system, where 1 hash = 1 vote.
because bitcoin is decentralized, it haves some disadvantage, and some advantage, in order to be secure.
Disadvantages:
Anonymous, oh shit! no one can trace you. you can't have, 1 person = 1 vote.
Inefficient, consumes a lot of Watts
Relative slow, compared to centralized systems.
Advantages:
Anonymous, win! no one can trace you. you can have 1 person = x votes
Can not be shutdown, does not have a central authority, where you just can pull the plug.
irreversible, stuff can't be undone.
Anyone can join, multiple times.
no need to trust anyone with anything.
so because you can't proof that you are who you say you are, its getting hard to enforce the "1 person = 1 vote"-rule. instead bitcoin relies on something you can proof that you have(or have access to): computing power! and there for transforms the "1 person = 1 vote"-rule into "1 hash = 1 vote"-rule, a thing that can be enforced in a anonymous-distributed system. bitcoin is not trying to limit the number of votes, instead it gives everyone an amount of votes, based upon stuff you can proof that you have.
the system can't be based on something that requires a central authority to function, consider the example:
Anyone who is verifyed somehow can have a vote.
now ask the question: "who is verifying?" a company? government? some sort of central authority? ... what happen if its going rouge?
if bitcoin had a central authority, is would be a no better system then the current creditcard company based system. where a central authority determinds what is wrong and what is right. can we all know who this will turn out right?
so please to all you "experts" please think before you type.
(MODS: please sticky)
|
|
|
|
Yep, right. So it is 768 bits in general case. But it doesn't make any difference in this context.
yes because you need to optimise for every single block, as the static-variables, will change with every block. also the internal state is larger then 256 bit, and it can be precomputed per block, but it will still change every block. i think it will take longer time to optimise for every block, then it will to just do the plain work. |
|
|
|
More-or-less so. The aim is, indeed, to 'reduce needless duplication of work'. However, it's not possible to process all inputs at once.
Generally speaking, main part of SHA-256 is a function of 512 boolean variables. We're going to change only 32 boolean variables to look for certain result, so we can assume other 480 variables fixed. So for a certain block header we can reduce SHA-256 to a function of 32 variables instead of 512 ones, optimizing it in process.
Furthermore, as we're using hardware which can do 32, 64, 128 or 256 binary operations at once, we can utilize this by considering many combinations at once. Let's say for a 64-bit hardware we can, essentially, vary 6 bits at once. Thus we already have a function of (32-6) = 26 variables, so we need only 2^26 combinations. Furthermore, it is possible to optimize things a bit for each such combination.
Processing 64 (or more) combinations at once merely makes it competitive with traditional implementation, it does not reduce number of bit ops done by CPU. Number of bin ops should be reduced at a step when we assume certain bits fixed.
you are forgetting the SHA also is having a internal state... |
|
|
|
I was developing my own bitcoin version, and I need to know. Can someone provide a list of clients that are trusted clients, to always be up, and at the latest version, 24/7. Something that would be hard coded into a bitcoin client.
trusted peers are NOT the way to go. and running the latest version is not possible as it is a opensource project with forks, and alternative clients |
|
|
|
Can be cheated or played, special HW requires central authority. - I am identified in mtgox through a yubikey (+ some personal data - see wikipedia link)
Requires a central authority to manufacturing yubikeys- I am identified in Bitcoin forum through my activity (+ some personal data - e-mail, ...)
can be played, and requires a central authority[/list] bitcoin is designed to be DECENTRALIZED, it is a feature! Therefor it does not need a single point of weekness. your plan is to introduce a SPOW into the bitcoin system, which is BAD. if we did that there would be no need for a blockchain at all, as the central authority could just validate every transaction, like creditcard companies does right now. |
|
|
|
I just <3 the newbie forum.  |
|
|
|
|
Show Posts
