1 and 3 shouldn't be a big problem here, just a few json-rpc calls afaik. but 2 needs either an official standard code inside the html files that can be recognized by the addon or something like a database with all bitcoin accepting pages that have to be updated every now and then.
I don't know how to make Chrome extensions, just wanted to say something ontopic.
Interested in creating a MicroFormat for BitCoin payment options? |
|
|
|
|
Na dann oute ich mich auch mal als deutscher :-)
Wenn wir schon mit sport anfangen, hat jemand interesse an einem Wettportal mit Bitcoins?
|
|
|
|
Oh I'd love to get the CCC on board with this :-) I'm German so I could help out, but my formal german got a bit rusty and mixed with italian (long story don't ask  ) |
|
|
|
|
theymos is right about the code having to be readable by the processor, but this is possible by using smartcards which have their own processor and only talk through a well defined interface, never revealing important parts of their internal data. Sim Cards are probably the most widely used smartcards right now, and they hold a shared secret between you and your service provider, would someone be able to clone the contents they would be able to listen in on your communication.
Anyway for a game I'd use a server that awards the coins upon completing a level, since it does not require special hardware on the client side.
|
|
|
|
Performance shouldn't be measured in multiplies of the CryptoPP miner. Maybe you could give hashrate examples for typical CPUs.
Well the problem is that there is no typical CPU, or typical GPU for that matter. So you'd have to write down exactly your configuration and test that same configuration against all miners. I was thinking more in terms of list the requirements, and then what you usually get when fulfilling the requirements. It's not meant to be precise, it's just indicative of where users can go with certain miners. If results then vary +/- 10% the user wont care. It's a wrapper around the Main client, not a miner flavor. Looks like the patch by puddinpop, I have no viable benchmarks on this one. I'm quite interested in this one, would like someone with a good GPU posting some benchmarks. This is the main thread I took the idea from, but except puddinpop's code, it's all just generic talk. Help the little ol CUDA developer:http://bitcointalk.org/index.php?topic=1324.0 These are improvements to code that exists elsewhere Again just a fundraiser for puddinpop's code. This one I actually didn't know yet  Prehistoric thread on how to build the main client on Mac. Anyway the wiki is open, feel free to add anything important Oh and since I don't have a GPU in my notebook (not one I could use anyway) I'd be especially interested in benchmarks of the CUDA and openCL miners, since I can't provide them myself. |
|
|
|
Since I myself am losing the oversight on the various miners that are currently available or in use I started a wiki page that might introduce users to alternative miners: http://www.bitcoin.org/wiki/doku.php?id=bitcoin_minersIt would also allow us to collect some real world comparisons about how they perform against each other  Feel free to add yours |
|
|
|
|
Is there a plan for this to be merged into the main tree at some point?
|
|
|
|
I see the biggest threat to this project as the very system it seeks to displace. That is, the banking establishment.
Since the community is composed of hackers and ciphergeeks at the moment, it is indeed one of the goal. However, we don't know the true goal of Satoshi. I don't think we should question satoshi at every step. He gave us this great protocol (it's no more than that actually) and that's it. If we are not happy about a decision, we can change it, should the network deteriorate we can switch. Satoshi's done very much, and I don't think he has all these evil intentions everyone is dreading. I understand the need to be skeptical sometimes but in this case I think we have a fairly good idea of what satoshis intentions are: creating a nice little payment system that could one day be able to compete with the big players out there, not the world domination  |
|
|
|
|
Well it's after all a dev channel, so probably we should create a public discussion channel that would not be logged. As a developer myself I find it quite usefull to refer to earlier technical discussions, so a single link can replace having the discussion all over again :-)
Anybody against the channel split?
|
|
|
|
Just adding myself to the game 1DEcTfUsHpPscf1qC2BE1v5JugweEyQVcr |
|
|
|
i clicked a link from the bot to 'tell us what you think about [the loggging]' i was expecting a poll, but i dont see one, so:
i'm very, very, much against it, and am totally amazed anyone would be logging such a thing to the web for countless obvious reasons i'm not going to state for the same reasons
I seem to miss the point. Please tell us these reasons to either convince us to change our minds or create a public debate as to why they are relevant :-) To put it simply : if you log IRC, you're working for Big Brother. No I only have a smaller brother, and he's not listening in *ROFL* |
|
|
|
i clicked a link from the bot to 'tell us what you think about [the loggging]' i was expecting a poll, but i dont see one, so:
i'm very, very, much against it, and am totally amazed anyone would be logging such a thing to the web for countless obvious reasons i'm not going to state for the same reasons
I seem to miss the point. Please tell us these reasons to either convince us to change our minds or create a public debate as to why they are relevant :-) |
|
|
|
Masking the nicks of people is not exactly hiding information. What is important is what people say, not who actually said it and with which pseudonymous.
I guess we all agree that as soon as we write something in the channel or here on the forum, it will be associated with our pseudonym (nickname), so yes we could add additional barriers to recognize the person, heck we could even replace all the nicknames by their Numeric ID, and the discussions would still be meaningfull, however such a mechanism will be hard (if not impossible) to implement, and buggy. I will of course remove all mappings from pseudonym to IP address (IRC Join, Part, Whois, ...) but I guess keeping the nicknames in place would be acceptable for everybody, unless there are more people requesting rot13 on the nicknames, I'm always open to suggestions ^^ |
|
|
|
The main problem right now is that the network is completely unstructured, there is no guarantee that the network will not split and then continue on two different chains. This is a problem since any coins generated after the split will not be accepted by the other networks. If this happens often enough the whole system becomes pointless (what's the point of having 1m coins if you have nowhere you can spend it?). Also the fact that each transaction is broadcast to all clients will never scale. For Bitcoin to work properly the node that signs the block must have all transactions. What I'd like to see is a structured network (think torus or hypercube), at whose joints we create highly connected clusters of machines to be redundant, then each of these cluster tracks a certain prefix. Once a hash has been found the node that wishes to announce it just fetches all unsigned transactions (echo-algorithm), signs it and floods the block (hypercubes have incredibly efficient flooding, remember?). So to restate the constraints: - We do not want to allow network segmentation
- A node that generated a hash does have to know all transactions
- Transaction fetching can be delayed until a hash has been generated
- A block (hash + transactions) has to be broadcast to all nodes in the network
Advantages of a Hypercube with node clusters: - Highly redundant transaction tracking (depending on the size of each cluster)
- Flexible dimension (should a cluster become too big we just increase the dimension)
- Very efficient routing
- Very efficient broadcast
- Logarithmic storage need
And yes, I think the network topology should be documented and evolved on its own Wiki page :-) |
|
|
|
*&^%$# Oracle  +1 |
|
|
|
unu, fher, naq gura fbzrbar nccyl n fpevcg (ternfrzbaxrl?) gb ebg13 ntnva ^_^
> hah, sure, and then someone apply a script (greasemonkey?) to rot13 again ^_^
Doesn't matter, I just want not to make things too easy. Using rot13, at least my nick won't be indexed by Google or other robots. The log files are not indexed by search engine indexers, at least not the big ones who respect the "Robot: nofollow, noindex" headers so there shouldn't be a huge problem. |
|
|
|
So far we have the following standing: - For logging: 8
- Abstained: 2
- Against logging: 2
Strangely most of the people that agree on logging are from coming from IRC. In some cases I was unclear on whether you're for or against logging so there might be an error on my side in a few cases, so please correct me :-) As for the censoring, I'll do my best to come up with regular expressions to wipe personal data from the logs (telephone numbers, usernames that requested it, ...), but I can't guarantee that it'll work perfectly  |
|
|
|
Is it possible to rewrite portions of bitcoin so it runs entirely in GAE? Particularly the feature that handles transactions, so it is fully scalable?
I am thinking one can get the sourcecode from SourceForge and write the C code into GAE language (Python or Java).
We are in fact trying to build a small network module to interface the BitCoin Protocol in Python, if you'd like to help feel free to contribute: http://bitcointalk.org/index.php?topic=231.0 |
|
|
|
The archive should be excluded from search engines.
robots exclusion: noted |
|
|
|
|
Show Posts
