|
@ribuck
they look way to similar. But I like the concept. I still like the ฿ symbol. It is easy to read, and people instantly understand that it is money.
The ⓑ looks too much like the copywrite symbol; something that I don't like.
|
|
|
|
Bitcoin on Freenet. Draft Specification is out for comments! Draft on Freenet! Talk about this project @ eng.bitcoin on freetalk! Please post below about changes, features and possible attacks. Development Bounty Working implementation, in MIT style licence. Looking for pledges! We are about to commence the development stage, need to hire developers 
Fund-raising thread: https://www.bitcoin.org/smf/index.php?topic=7181.0 |
|
|
|
|
can you please tell us where the ip-address are from?
|
|
|
|
With public key registration you could associate arbitrary information like ip addresses, ssl certificates, ... ?
Or has public key naming already been solved?
All the chain needs to include is a name and a fingerprint of a public key. Anyone who uses that name can supply the public key, and people can cross-reference the public key with the fingerprint. The system is simple and secure. |
|
|
|
I'm more than willing to offer recommendations for personal research, but not so willing to duplicate the best work of others; particularly on an anonymous Internet forum that is not even peer reviewed.
It was hard forme to wrap my head around the technical and crypto aspects of the system. I'm sure that you can work your way around the economics in due time. I was impressed that (largely) one man created this system, assuming that Satoshi is actually a person, and not an avatar for some greater organization. I found out, as you shall, that those that are new to the idea alwasy seem to think of the same set of potential problems, long since resolved if they were ever a problem to start with. Most older forum memers just begin to ignore these newbie posts, which is why you only have myself and kiba in this thread to represent the counterpoint. Dive into the forum's search function, there is much there.
I was the same, once I got the technical component of bitcoin it instantly 'clicked' the importance of bitcoin succeeding! However I think that creighto and I come from a very similar school of economics. Bitcoin has the potential to do more good for this world than any other single effort in the last 50 years! If you let th people control their own money, you let the people control their own destiny! |
|
|
|
Cool I'm in Australia, on wi-fi.  my connection isn't the best thing. |
|
|
|
I feel doubtful that a nation state is what it would take to control 50% of the CPU power, given plenty of disincentives for mass crowds to generate blocks. Didn't someone recently say that an investment in $140,000 of video cards would be enough to presently overtake the 50% mark?
I don't know who might have said that, but they were wrong. I said that, http://bitcointalk.org/index.php?topic=2227.msg29538#msg29538, I don't believe that I was wrong. It is true that bitcoin is under generated atm. However I do not expect that to remain true for long, it is just too profitable! |
|
|
|
|
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Cameron Garnham>ping mining.bitcoin.cz
Pinging mining.bitcoin.cz [109.74.195.190] with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 109.74.195.190: bytes=32 time=417ms TTL=49
Reply from 109.74.195.190: bytes=32 time=415ms TTL=49
Ping statistics for 109.74.195.190:
Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
Minimum = 415ms, Maximum = 417ms, Average = 416ms
C:\Users\Cameron Garnham>ping mining.bitcoin.cz
Pinging mining.bitcoin.cz [109.74.195.190] with 32 bytes of data:
Reply from 109.74.195.190: bytes=32 time=414ms TTL=49
Reply from 109.74.195.190: bytes=32 time=414ms TTL=49
Reply from 109.74.195.190: bytes=32 time=414ms TTL=49
Reply from 109.74.195.190: bytes=32 time=414ms TTL=49
Ping statistics for 109.74.195.190:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 414ms, Maximum = 414ms, Average = 414ms
C:\Users\Cameron Garnham>ping mining.bitcoin.cz
Pinging mining.bitcoin.cz [109.74.195.190] with 32 bytes of data:
Reply from 109.74.195.190: bytes=32 time=414ms TTL=49
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 109.74.195.190:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
Approximate round trip times in milli-seconds:
Minimum = 414ms, Maximum = 414ms, Average = 414ms
C:\Users\Cameron Garnham>
|
|
|
|
|
I'm regularly getting the error on the m0mchil's GPU miner: "IOError: [Errno socket error] [Errno 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond"
|
|
|
|
ok I'll help you guys out for a little while.  the blocks are two easy!  They need to be about twice as hard. |
|
|
|
ok I'll help you guys out for a little while. |
|
|
|
How long this debate had been going on? I am still unclear on whether or not you guys agree on anything.
The longer we wait, the less chance of success we will have.
Hmm, I don't think that the longer the wait the less chance of success... I'm interested in comments about my proposal. I think that it solves much of the issues in a logical manner. |
|
|
|
Deflation is not a threat to an economy, and is not destructive in the same way that inflation is. Think about it this way, what is the harm to the economy if the consumer can buy milk for less than yesterday? And do you really buy the talk that the increasing value of a currency will lead to hoarding? If so, why doesn't it lead to hoarding now?
Spectators do all the working out for you. The price of bitcoin will have the deflating price factored in at any one point. So people will trade bitcoin knowing that they are paying a higher price than the 'real price without expected deflation'. The only thing to keep in mind is that the price of bitcoin will be directly related to the size of the bitcoin economy. So, just buying bitcoins and hording them, is directly equivalent to investing in the entire economy that uses bitcoin. |
|
|
|
As a matter of fact my wife uses Bitcoin, even generates (or tries to) coints on her laptop. She's only getting 7000 khash/s on her built in Radeon, but it's the fact that counts.
Of course, she found out about it from me. Women usually take over man's hobbies and interests, and that is a sad fact.
Maybe you could get her to go out and buy a couple of 5970's  they are still profitable. |
|
|
|
|
wow this forum is so sexist...... But....
But think. If we all start giving our wives / girlfriends / mothers bitcoins instead of dollars, all the shops will start bending over backwards to accept them!
So: "Send out your women, with bitcoins!"
|
|
|
|
Don't get hung up on a "strong scripting language" for checking application-specific data in the bitcoin chain.
Yes, any strong scripting language language will do. I'll leave it up to the programmers to pick the language.  |
|
|
|
In my proposal: http://domainchain.org/wiki/doku.php?id=bitnameThe proposal that I have made has covered 3 main areas. First: Changes to the Bitcoin Protocol. Expanded templates, (allowing to check transactions based upon what they claim to be). This also allows new services to be run within the chain without changing the protocol. Using a strong scripting language it should be possible to make 'plugins' for generators so that they may accept new types of bitcoin transactions. Transaction Grouping, this allows transactions to be grouped together by template. Clients will only need to download the summary and the hash tree, unless they want more detail. Burning transactions. This is a new sort of transaction fee that 'burns' over time. It contains two qualities, firstly total number of coins to be to be burnt, and secondly, the rate (per block) that it is burnt at. This is the basis of the compensation to generators for including extra data in the block chain. When the transaction stops burning, the extra data may be deleted. Second: BitName BitName is a named address that has a fingerprint of a public certificate. Instead of sending bitcoins to 13TSBH4wdchsMqFTwqyLjvPES99sZ96MaP, one could send bitcoins to 'da2ce7'. The BitName concept is built upon burning transactions. Each transaction that declares a name, must include a burning transaction to keep the name active. The higher the rate of burning the more likely that the transaction will be accepted. If the rate is too low, the network will likely ignore or forget the name early. If a generator accepts a new transaction of the same name as a pre-existing, the network will likely orphan the block, unless the burning fee is so low that the network regards the name as spam. The other significant benefit from having a BitName is public certificate verification, when one sends a message that is signed, the key signing the message can be check against the known name of the source. The fingerprint included in the block chain then can be used to verify the signer. Third: BitDNS BitDNS is derived from BitName. A BitName should be used to make any new BitDNS records. This requirement in the future can be used for spam prevention. Both the top-level root domains and the 2nd level domains need to be globally unique. Root BitDNS records are expensive and both the initial fee and the burning fees are network enforced. The main purpose of the root domains is top provide a service to the 2nd level domains. To be accepted by a top-level domain, the fees defined by the top-level domain must be paid to its address. This is enforced. 2nd level domains behave much like BitNames, with two main difference: first, to be used the domain must pay registration fees to at-least one top-level domain. Secondly, IP addresses can be binded to these domains. Since the domains all have fingerprints of their TLS certificates, when one connects to a server defined by a BitDNS record and the server replys with a secure connection, the client can check if the secure connection is valid, not by using a CA, but rather cross-referencing it with the fingerprint included in the block chain. Man-In-The-Middle attacks are very, very, very difficult under this system. I'm still working on the sub-domain structure. |
|
|
|
"1.c. Codified verification that can rigorously check if a transaction is valid or not for that particular template."
Would this be codified by an extended scripting language, or by hard-coded logic in the client? I think it has to be a scripting language, otherwise it will be too hard to get agreement to add new templates. We would need to create scripting extensions to allow a wide range of new applications. For BitDNS we would need the ability to look back in the block chain and check if a given name has been registered before.
I think that a scripting language would be adequate, however it would have to be fully unit-tested. "3. Every transaction must still comply with the existing enforced network rules. Such as no, double spending."
In this view, the core logic of Bitcoin would check that blocks had the required difficulty, were properly formatted, and that their scripts all return true. Everything else would be done by application-specific layers.
Every Transaction still needs transaction fess, double spending is important to check at a foundational level. |
|
|
|
|
Show Posts
