Would be nice through to add it in the details view  |
|
|
|
The answer is to have a billion banks.... What if opening a bank was as simple as installing a client?  Yeah, but then you're back at 0, since you'd have to convince users that they can trust you. |
|
|
|
Flood-fill scales in practice, because interested network parties keep upgrading to handle the load. DHT is pointless, as you could lose information to network partitions or simply if an unlucky set of participants disconnects.
Overall the current system is designed for Big Players With Capacity to survive on the P2P network long term. It is simply not meant for small players. Not really a good argument, why impose the need to keep up, if simple changes can lower the barrier? Remember that if we can think of it, others will too, if we don't implement it, others will. And if they do you can be sure they'll start a new block chain, eventually surpassing our community in size, because of the added flexibility, and thus making all our hard earned Bitcoins worth less. Unfortunately we continue to await the development of the much anticipated "lightweight client" that will not need to receive every tranasaction and echo it, etc. satoshi added the "getheaders" network message recently in order to better support lightweight clients, which permits casual connectivity, pulling only the block headers needed since last connection. Which is basically the implementation of a 2 hierarchical system as proposed earlier. It is by no means the definitive solution to everything, since even the inner network will eventually become too busy to handle the message complexity. I would rather we just remove the "fee for < 0.01 transactions" rule. If people want to spam, they can spam with 0.01 BTC transactions, and fill up the free-TX area in each block. Making everyone else pay? To be really resilient we have to make the network Dos proof, and while there is no definitive solution to this, we can make steps in the right direction. |
|
|
|
|
I actually think we're going at it the wrong way, the problem is not so much that micropayments are prohibited by the current implementation, that was just a reaction to people voicing the concern of a DDoS, which then actually was carried out (don't remember the thread right now).
The thing is that the current network topology and message routing is not scalable and a large number of transactions will actually bring it to its knees. It just so happens that using a nanobitcoin makes it really easy to put heavy load on the network, hence the code avoiding small transactions. But I do see a huge increase of the number of transactions in the near future, and we will see the same limits be hit again.
One of the very frequent questions I have to answer to is "how scalable is the Bitcoin network?" and my usual answer is that it isn't at all scalable. Simply the fact that every transaction is broadcast in a random fashion is incredibly wasteful. Were we to adopt a nicer system (pulling transactions only when a block is found, upstream aggregation, DHT style responsability sharing, ...) it would work so much nicer and would scale better.
The current limitation on the size of transactions is just trying to cure the symptoms but the root cause can only be cured by a better structured topology, improved routing mechanisms and a reduction in message complexity!
|
|
|
|
|
The base certificates should have been shipped with your OS or your Browser, otherwise it is not really secure, because you trust the certificate issuer that they are who they claim.
|
|
|
|
|
Well and there I was assuming the really nice part of Bitcoin was it's being completely decentralized, by letting "banks" do the aggregation you not only create single points of control but also single points of failure. It's nice that they also act as aggregation points, there's no discussing this, but the system should be developed in a direction where it becomes better scalable and may potentially handle all transactions natively, as long as we're not there I'm be fine with having aggregation points but the ultimate goal should always be a currency handled only by the peers.
P.S.: micropayments is not the only place this applies, basically the network does not care if I move 0.01 Bitcoins or 100 Bitcoins, but we'll incur the same problems when growing in the near future.
|
|
|
|
|
Should I ever need to fill Bitcoin equivalents in my tax declaration I'll use the exchange rate at the beginning of the year, since I expect value to increase over time ^^
|
|
|
|
Well I think a set of small changes could make the bitcoin network scalable and add the ability for micropayments. First of all a structured network is needed since the just broadcast to everybody method used now is incredibly network intensive, then we have to split the network in two parts, one is composed of all generating nodes (they need to know all transactions) and non-generating nodes (just publishing blocks with aggregated transactions is enough for these). Also one might start thinking about segmenting the network by adding a second smaller difficulty which aggregates transactions in a small cluster which would then be aggregated and signed off by the core network composed of the current implementation. The current network design does not scale at all, we need to either change it or build a micropayment system around it |
|
|
|
Well there is a way around all the hassle, just declare bitcoins a digital asset, which is then distributed among the employees And finally some people are seeing the need to embrace governments to survive |
|
|
|
|
On what ground and what's bad about svn? svn does have an established community and many programmers are familiar with it, git just addresses a more distributed scenario, which is not always needed.
I love bitcoins from an academic viewpoint, not so much the so celebrated anarchic, self regulating side.
|
|
|
|
I can confirm the cryptopp_asm algo to be working and also got the shortest ever waiting time for a yay $ ./minerd --userpass user:pass --url http://mining.bitcoin.cz:8332 --threads 2 --algo cryptopp_asm32
2 miner threads started, using SHA256 'cryptopp_asm32' algorithm.
DBG: found zeroes in hash:
78bf640434f5b45f8095269ed74d04ce23ea3fdaf6e16f0233006b8400000000
HashMeter(1): 1336480 hashes, 887.16 khash/sec
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!) |
|
|
|
Nothing a good API couldn't fix ^^ I love the idea  |
|
|
|
|
Oh yeah, forgot to say: I got 2 payouts until now, so thanks slush ^^
|
|
|
|
Does anybody have a comparison on how Linux against Windows machines are performing when running the GPU miners?
No, but Linux runs faster. Great news I was already dreading I'd have to setup a Windows machine ^^ |
|
|
|
Ultimate Mining Infrastructure: UMI Sounds cool, doesn't mean anything |
|
|
|
|
Does anybody have a comparison on how Linux against Windows machines are performing when running the GPU miners?
|
|
|
|
cdecker: I hate ads in Android apps, how about a paid client?
I see some interesting possibilities here. What if the app would transfer a small fraction of a bitcoin to Cdecker, once for every day in which the user made a transfer? Or perhaps, users could send, with the app, a certain amount to Cdecker and in doing so disable the ads? Oh please no! Automatically stealing a few cents per transaction would start the whole mess about the puddinpop cuda client again, don't worry I'll probably stick to opensourcing the core and make an ad based Frontend and give people the option to disable the ads by sending me a few coins :-) |
|
|
|
First of all welcome ^^ What you're computer is doing, when generating, is trying to find a hash matching certain criterias. It's basically a proof-of-work which is hard to do at first, but easy to check for everyone once you finished. Think of it this way: it's a lottery, and the winner will be the one that first finishes his work. He'll be the one taking all the transactions, checking them and if it all seems right he'll use his newly gained authority (lottery winner) to sign them off as accepted. He'll be the authority checking that no one is double spending in the network for the past ~10 minutes. For his work he'll earn the blocks 50 Bitcoins as a reward. The whole proof-of-work scheme is used to have a single authority that decides what transactions are valid, and which aren't, and having completed the proof of work all others will accept the decision. Also it is used to distribute the initial Bitcoins among all users, and not have Satoshi sell them (single point of failure). |
|
|
|
Cdecker, I agree there was some misconception in payment before. I din't say system worked perfectly. I believe they care about their 0.6 bitcoins. But I 10x said "ok, I know about it, I'm working to make it better". I already made it better and explained why I cannot send money from old blocks instantly. So I don't know what to say more. I'm glad that it has been cleared now, I really love your Pool and it works like a charm (for me). Just wanted to get everything on track and stop some whiners from influencing too many |
|
|
|
|
Show Posts
