 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
|
I think Bitcoin can handle both regulated scenarios and unregulated scenarios, just like paper money is handled legally and illegally today.
Full traceability will be the norm for everyday consumers and businesses using green addresses or some other trust mechanism, but with the possibility of being used anonymously with enough caution. The FBI, IRS, or equivalent would step at the same time and in the same way as if they are catching millions of paper US dollars going across the border.
The question is, at what quantity of 'anonymous' Bitcoins does the regulation begin? I think for USD bills it starts raising eyebrows with $6,000-10,000 moving around...
|
|
|
|
The problem that I have with fee values is that the purchasing power with Bitcoin is not fixed - a passport created 3 years ago might have needed to burn 100's or 1000's of BTC to claim legitimacy; requiring any application to have some sort of exchange rate lookup as part of the passport application. I would think it would be better to have some adjusted-purchasing-power token that you can purchase, and then those could be traded on an alt-chain explicitly (kind of like in Anon136's comment above.) Since it lives outside of Bitcoin there is much more flexibility to the rules that can be enforced explicitly to implement contracts and the like with real power, instead of a web-of-trust method of servers checking hashes or polling for fraud notices that live inside the Bitcoin block chain. It is transferable so you don't have to worry (too much) about key compromise destroying the whole reputation. I posted a thread on this system a few days ago in Repcoin: a decentralized reputation currency. Unfortunately I think it's not really the right audience in Alternative Cryptocurrencies, and I haven't really gotten any good feedback, even a 'you suck and this system sucks' would be valuable though ...  |
|
|
|
When you "roll" you could use the current value of the s&p, an image of a tree in your back yard blowing in the wind or the static in the radio as a seed for random function and present it as something indepentently verifyable. Just be sure you have the most up to date seed otherwise your users might scoop you.
Depending on how you implement it, a tree blowing in the wind or radio static is not necessarily independently verifiable, since you'd have no way of knowing whether the site operator is reusing tree images or creating their own special winning static. Basically, start off with some random data, hash it, and publish those hashes ahead of time in public (like the blockchain, or in the page itself like MyriadCoins.) Then use the random data and bet data (optional) as inputs to a cryptographically-strong hash during the game to get a randomly distributed output. Release the random data after some period of time after the game, so users can verify it. The strength of this comes from the strength of the hash functions used (very good assuming lots of entropy in the random data) and the security of the random data up to the point where it is used (depends on your development skills, and hax0rs.) Also, if you haven't yet, read up on how SatoshiDice implements the verification - it is a good writeup. If you are talking about other games, like proving a sports bet was paid out fairly, that's a whole other topic... |
|
|
|
Thanks, I haven't seen that!!! It seems like it is developing a rating system over the existing PGP Web-of-Trust model, and defines an example contract and some common data format schemas so the data can be kept in the existing PGP web of trust. I would think that using Repcoin as a base layer instead of PGP would work better, as it offers some additional features beyond PGP: - Transferal of reputation credits - allows for things like a path forward from a semi-compromised PGP key (i.e., it has been exposed but not used yet); however, if contracts and such are linked to a certain key identity, then maybe it would be better to have an explicit key transfer protocol. - The central blockchain - instead of requiring a web crawler or http archive to maintain backups of reputation values, instead formalize the storage system into something that all interested parties implement. This (like Bitcoin itself) ensures the strength of the network is proportional to the amount of use it gets, instead of the amount of sysadmins thrown at it. Note that this will probably be unwieldy after a certain size, if you allow arbitrary contract data in there. So it might still be an issue. - No existing web of trust requirement - how do you know how much to trust a new party? With this there is a way to bootstrap your way to a level of trust without needing cooperation from other users. It's the same issue I have with the PGP web of trust - there is no way to initiate a conversation without having a network in place already. The other ideas in there, i.e. contracts, the rating system, and trust metrics, could be used on top with minor modifications. Some really great ideas though! |
|
|
|
Saying it's decentralized is all well and good, but how exactly is that going to work? What is the technical mechanism that returns credits to the defrauded individual? What lines of software code actually implements it?
OK, sorry for the rambling, and I don't want to hijack the thread. Just imagine a centralized implementation of an insurance system then, since that's more straightforward. If I figure out a good mechanism for decentralization, I will post it separately. I have spent some time and fleshed out my idea for a decentralized reputation system, and it incorporates your idea of using fidelity bonds and has some examples of network rules. Here: Repcoin: a decentralized reputation currency |
|
|
|
Yay, I like this topic... I have always thought that there really needs to be some trusted third-party verification service for Bitcoin addresses, which would work in a similar fashion to an SSL CA. I don't believe the pgp-style web-of-trust model gives enough guarantees (or has enough defense against bad actors (edit, CACert is pretty close)) and using a cryptographic solution invites namespace-collision problems (i.e. the super secure third-party escrow solution at casacius.com.) You would in practice also have a network of trust providers such that no one player has any control over the system. Bitcoin applications would operate similar to the perspectives project and pull trust information from many providers. This is a straightforward way to get a useful protocol going. Simply add Bitcoin-OTC metrics, add a dash of GPG sigs, and toss in some IRL identity verification, and you'd be there. Add thanke's or etotheipi's method on top for more security and anonymization. -- This was my old favorite solution to this problem. But wow, from retep's work with creating fidelity bonds and thinking about it a lot more I have spent the last couple of hours fleshing it out into an entire system, and I have a new favorite.  Instead of hijacking the thread here which I can be prone to doing I have written this up on another thread in Alternative Currencies: Repcoin: a decentralized reputation currencyIt would be a good candidate solution for this problem. |
|
|
|
Here's my thoughts on how a decentralized reputation system might work. This is a response to casascius's lament ( There needs to be a new bitcoin address format...) that there are no good trust systems for Bitcoin. Also a lot of thinking from retep's work on how to create fidelity bonds. I haven't seen any proposals like this yet but please feel free to point me to any that I missed. I'll refer to this concept as 'Repcoin' because it sounds cool and because has not been used yet afaict (see below.) The Repcoin System1) Repcoins are managed on an alt-chain so they can be traded similar to Namecoins, and to have the value float with respect to BTC. 2) An individual generates a public/private keypair, known as the Reputation account. These would reuse the Bitcoin address format. 3) For example, say one acquires Repcoins by donating a special value (see 4) to BTC miners or possibly a charitable fund address using BTC (straight out of retep's work on fidelity bonds). A marker in the Repcoin blockchain would identify the creation of the Repcoin, it's destination Reputation account public key, and the source BTC transaction which satisfies the rules. 4) Other Repcoin users can verify that the creation of these coins matches the software rules and they can determine the value of each Reputation account by scanning the Bitcoin blockchain for creation and the Repcoin chain for accounting. Some rules: 5) Donation amounts are based on a constant purchasing power. Work out an agreeable algorithm that pegs the repcoin cost with respect to a BTC:fiat ratio that floats. This might be an exchange basket. Maybe use fixed point instead of integer coin values. 6) A certain small amount of time-based deflation (easier when it is pegged to USD) is built-in so that older coins have more trust value? maybe not, idk. The early adopter effect would be a good jump start to the system. Usage: To use this, the sender would sign a transaction or their receiving address using their reputation keypair. It would turn into a sort of digital identity. You could decide on the amount you are willing to trust them based on their purchasing power they used to acquire the reputation (retep's fidelity bond.) Some problems: 7) Bad actors that have spent a while dumping money building up a reputation starting to scam people: This is a very difficult problem, I would think there would be a method for users to burn the reputation of other users by burning their own repcoins in a special SCAMMER transaction - say -2 repcoins for every 1 repcoin burned. Since this is also in the public and signed with the other person's account it becomes a reasonable way of seeing an overall picture of trust. Since real BTC is involved and the reputation is on the line hopefully it wouldn't be abused too much. There could possibly be another message that would nullify the hit to the other user in the case of resolution but the burned repcoin would still be gone. 8 ) Yet another chain to keep track of, though this one is mostly just an accounting table. Future: If using charitable organizations, they would need to get their addresses in the software without software patches. It could be bootstrapped with a few orgs at the beginning, then after a certain # of blocks a new election for the top n charitable organizations would be determined, by vote of people by share of their reputation. Users who are acquiring reputation could use any of those n. Organizations would hit up big repcoin owners to get votes for funding, kinda like how the world works today. See also: Whuffie, or read at least the prologue to see how this might turn out in practice. Uses of Repcoin: nothing on this forum, searching google yields a very interesting paper (pdf) with this name that attempts to solve this problem but the implementation is still too centralized; and openassembly.org (site down) has decided on this name for a currency on some random page. Quote from the end of the 'Reputation Systems for Anonymous Networks paper' (pdf), in the 'Future Directions' section talking about how to decentralize it: Note that this would require two significant changes: using a digital cash scheme that does not require a central bank, and devising some other mechanism for inflation resistance.
This is what it was like in 2008 I guess! |
|
|
|
I will give 10 BTC bounty for someone to create a pull request to modify bitaddress.org to give me an option to create an encrypted paper wallet using BIP 38.
You should contact the winner of the bounty of the other thread, I know there were some other competing entries as well so you should have a good shot at getting this implemented.Oops, didn't check the other thread first. Good luck! |
|
|
|
Nah we should blame gweedo instead.  Don't blame me cause you got owned by DeathAndTaxes and are now changing your view. ASP.NET Framework unless you have a lot of time to make it work like pof which to be honest is not worth it and very lazy will never scale like php and python. To be honest (Probably going to start a flame war) I hate python, I hate the syntax, and I would pick python over ASP.NET for any web project today. Lol, just joking around... I know I am mostly to blame for derailing this thread... This thread honestly should put in the trash too much false information don't listen to anything in here and do your own research.
Yep, there's a good reason why good programmers are so expensive |
|
|
|
I see your point, paybtc!
Of course I would prefer a "dedicated" wallet hardware.
It seems a lot of effort was put into the Ellet (at least the announcements was made to sound like it). Nevertheless, the original post was on 07.June.2012, 02:14:52 and now it seems to be on halt, precisely because of the hardware..
Maybe Bitcoin is still too small for such a hardware project. Other hardwareprojects are crashing and burning in these very days, in a spectacular way.. ;-)
Hardware random number generator - this might be a KO-criterium , thanks for the hint!
I am sure we will eventually hold a neat dedicated piece of bitcoinhardware in our hands!
Ente
Designing hardware is definitely difficult and can be expensive, and I believe that this project was a bit too broad in its goals (especially as one of the first devices in an unknown market.) However, there are actually some hardware wallets for Bitcoin in the works right now!!! https://en.bitcoin.it/wiki/Hardware_wallet |
|
|
|
I guess Azure may be an option I have never done testing to see how responsive their database in the cloud can be to very high loads. Oh yeah, I should point out that I haven't checked out Azure personally, but I consider all cloud providers incompatible with Bitcoin security requirements (which is unfortunate because my Linode VPS is great.) I agree there is value in open platforms and SQL Server is one of Microsofts most expensive and most restricted products. I think this got somewhat sidetracked (partially my fault). The original claim (not by you) was that asp.net doesn't scale and is expensive. asp.net can use any RDBMS as a backend and is highly scalable. For a new startup SQL Server is likely the easiest route as there is going to be some skills overlap but beyond 64GB or 16 cores I agree there is significant cost. It is something a startup would need to consider.
As a personal note:
To avoid vendor lock in whenever possible I try to keep the database code as ANSI SQL compliant as possible to allow a "backdoor" by keeping the migration costs & complexity to a minimum.
Nah we should blame gweedo instead. I wasn't clear enough in my original post since I do think that ASP.NET is OK for scaling technically, but I just wanted to point out some gotchas and hidden costs on the business side. Granted those are probably a bit out of the range of a Bitcoin business for a while, but I can always hope for crazy volume... Also, RAM is incredibly cheap now! I'm sure MS will change their licensing tune if they can foresee a hit to the Server and Tools business. |
|
|
|
paybitcoin ... not sure where you got your info
Sorry, this is mostly off the top of my head so it could be wrong. 2) Your pricing but it is way off. Standard can be licensed per user (CAL) instead of per core which is much lower cost for applications like web backend datastore.
This is not correct, you still need to have one CAL for every user you plan to have then. It is called 'multiplexing' and is technically not usable with a website. See: http://serverfault.com/questions/120276/how-are-sql-server-cals-countedFrom the licensing info doc I posted: The Server+CAL licensing model provides the option to license users and/or devices and then have low cost access to incremental SQL Server deployments. However, for customers who cannot count users or require premium database capabilities... Pretty sure if they are worried about having you count users then a website on the Internet is fairly incompatible with with the Server+CAL model. Of course you would have to call MS licensing to be sure (bleh.) 3) SQL Server 2012 Standard does have a 64 GB memory limit but honestly the number of databases in the world affected by that is pretty small. Hardly a deal killer for a startup. To my knowledge no Bitcoin venture uses a larger database than that (startup or note). Very few companies in the world do and they tend to be very large companies which are spending six figures on salaries anyways.
Sure, but in your earlier example you posted a 256 GB RAM server with the example that 'RAM is cheap.' I agree that everything is pretty small now, but to get a server with mega RAM and find out you can't use it all because you need to pay MS more $$ is very frustrating. 4, 5 i agree with... 6 (32G RAM limit) bit me personally... Now $1,800 isn't free but hardly impossible for a startup and closed source projects require a license for MySQL too. Beyond 64GB (today) on SQL Server 2012 gets significantly more expensive as 2012 Enterprise no longer has a server + CAL option (which is optimal for web applications). You are talking about $5K per core so if you need more than 64GB it can be very costly. The number of databases needing that level of performance are very few and well outside the realm of startups. It's great as a technical solution, but has a bad value proposition as a web startup solution. Which is why bizspark was created. Three years of essentially unlimited licenses. Then a graduation with conversion of licenses at 70% to 90% off retail. Any company older than three years is hardly a startup.Can it be done on other platforms for less? Sure but there is no reason for FUD. Still asp.net can be use MySql as the datastore. As you pointed out the windows license is downright free compared to SQL Server. Microsoft's big competitor for SQL Server is Oracle and there pricing makes SQL Server look downright cheap. Yes, there was a reason I used only PostgreSQL in my earlier post, MySQL is pretty much dead ever since it was purchased by Oracle. PostgreSQL is completely Free, with almost all of the features of something like MSSQL Enterprise and I can see many many companies starting to migrate from MSSQL or even Oracle in the near term future. It is wonderful not having to think about licensing restrictions, to be able to use the full capacity of your hardware at all times (buy a 256 GB RAM server? why not?), and not have arbitrary features locked out. And to not worry about things like the cost of CALs jumping 25% randomly with 2012 or BizSpark's 3 year grace period that runs out and leaves you paying MS for the rest of the company's existence.  |
|
|
|
I think it was suggested before, somewhere.
It seems like hardware is the main moneyburner here.
Why invent it again?
Use some small device with a bit cpu power, a good enough display, battery, usb connection and buttons.
Sounds familiar?
--> MP3 Player <--
So, why are people burning truckloads of money on re-inventing the hardware? It's all in the software anyway!
Ente
Hi Ente, This is a very good point, and can be part of a very good solution. Going with a rockbox platform, you would get a great development environment (qemu target simulation) and some reference platforms that work well with Rockbox. I can think of some downsides: 1 - Ability to scale, not tied to a manufacturer. It is very important to be free from a certain product lifecycle. If the vendor stops making your reference platform, you get kinda stuck. Designing it yourself gets you 5-10 years of useful life. 2 - Single reference platform. Rockbox looks like it is very platform-independent. It is nice to keep things simple with a single platform, though that isn't a big issue, just pick one and turn away users that have another one (or get them to port it.) Trying to debug dozens of USB HID implementations can be tedious. 3 - Crypto-specific requirements. It is pretty important to have a good hardware random number generator on board, to create a strong private key and to limit some attacks. Most importantly, 4 - Developing hardware is kick ass, and has a reasonably low barrier to entry. Even if you will never get to the quantities that would make your device cheaper than an MP3 device, it is still a great experience and solves all of the above problems. You also get a nice development environment, more security, and can optimize for Bitcoin-specific use cases. There is a strong open-source mentality around Bitcoin, and using open hardware fits better than an off-the-shelf retrofit. My 2 mBTC. Having Bitcoin wallet software integrated on top of Rockbox would still be sweet. |
|
|
|
* Scale up would mean increasing the performance of a single (or small cluster) or database servers. Where scale out would be replicating the database across a much larger cluster to achieve similar performance. Since SQL Server is licensed the licensing costs are lower when scaling up vs scaling out. The drop in server costs at the high end as well as moving storage to the SAN has made scale up less of a critical issue than in the past. RAM has gotten a lot cheaper. Building out a database server with quad xeons (32 cores) and 256GB or RAM as well as high end SAS controller (24x 2.5" backplane) is under $8K. Going to 1TB of RAM, SSL offloading, and off server storage array is still under $10K.
This is exactly the point I was trying to make with scaling up on the Microsoft stack. If you were to go to Dell and build your $8k DB server, you would still need a $3000 license for Server 2008 R2 Enterprise edition (arbitrary 32 GB RAM limit with Standard; note this is better if you use Server 2012 Standard, then its just $800), and a $10,500 MS SQL Server Standard license, and even that can only use 4 of your 32 cores!!! Want to mirror your DB for redundancy? Sorry, that's Enterprise edition, (4 cores or 1CPU only even!) = $29,339.95 for each server!!!Granted I don't keep up with MS licensing details since they change with every edition and are very confusing. But using Linux and PostgreSQL you end up with an entire redundant copy of your beefy DB server for the cost of 1 MSSQL license. This is especially bad since the MS cost doesn't hit you at the beginning on a small server when you are using their nice tools to develop it (or bizspark), but only when you need to scale to a beefy server and are already locked in. Anyone proposing using the MS stack for a startup should be familiar with the licensing (PDF: MSSQL licensing, Windows Server licensing) up-front. It's a total mess. Even worse with VMs in the mix. That's pretty much the root of my problem with scaling with the MS stack; having just a bit of knowledge of Linux & related solutions you can run circles around an MS solution at a far lower cost. This is critically important for a startup without a reliable revenue stream. BTW, we use the ASP.NET and MSSQL server stack where I work, and I have used it quite a bit (admittedly, for Intranet-style apps, but they get a reasonable amount of traffic.) It's great as a technical solution, but has a bad value proposition as a web startup solution. --- Then again someone who finds a $300 conference "outrageous" likely hasn't had a very successful career in database development so don't beat yourself up for continually spewing nonsense. I mean these are things picked up on the job and I doubt you will learn that stocking the shelves at Best Buy is very rewarding.
U mad? U MAD LMAO dude your still mad over that thread WOW LMAO don't worry butthurt lube takes care of that... Sorry, this counts as a troll thread. Granted it was a reply to a troll thread but I don't think that's the proper counter-troll response. |
|
|
|
My opinion
My personal preference when it comes to choosing a web development language is ASP.NET MVC for the follow reasons:
It is really testable/maintainable - TFD/TDD (Test Driven Development)
It demands a good architecture - Once again TDD is a contributor to this as it makes you think about how to architecture the software
Scalable - Like many other languages ASP.NET is very scalable
Developers - There are a lot of ASP.NET developers out there (a lot of competition for hiring them too), however in my personal opinion, I find that ASP.NET developers have higher standards than your average PHP developer.
Familiarity - I'm an 8am - 5 pm ASP.NET Webforms developer
Security - It does a good job of giving you the necessary tools to make the application secure (a lot of security holes with php sites come from simple human error of forgetting to escape strings).
Could you PM me your skype so we can discuss this at some stage?
ASP.NET is still used? WOW, I think glassuser with choose either python or php cause those are the most logical choices, there are a lot of bitcoin projects in both so the developers are there. Both can be secured quite easily if the developer knows what they are doing. Most host can support php right out of the gate. Honestly if we can all sit here all day and argue but at the end of the day php and python are just the best for web right now, today. From scalability to security. I'm going to have to side with gweedo as well... ASP.NET is horrible for scaling. Not technically, although the things POF.com have had to do to make it run well are pretty damning, but financially. A startup could really put to better use the $800 spent on each Windows Server license, not to mention the $2500+ for a MSSQL server (1 core!!!) license. Even their bizspark stuff has costs looming in the future. Also, for a Bitcoin web site you don't want to touch Azure for security reasons (at least not for the backend.) Personally, I see lots of .NET shops considering moving off of the framework in general since Microsoft is very sketchy on the roadmap with WinRT/Windows 8 and especially with the disconnect between ASP.NET and the web. MVC is a step in the right direction but I don't think it has enough traction to be viable long term. Also, if Microsoft ever pulls the plug, you get stuck... Python all the way!!! Edit: oh yeah, you should ping all the people that posted in this topic: Anyone looking for work? (Lol, none of them are .NET devs) |
|
|
|
Don't forget about randomart used with ssh keys: http://superuser.com/questions/22535/what-is-randomart-produced-by-ssh-keygensample: Your identification has been saved in test.
Your public key has been saved in test.pub.
The key fingerprint is:
20:e9:b0:5b:5a:2b:ad:e8:4d:e4:b3:a0:32:49:2d:97 evan
The key's randomart image is:
+--[ RSA 2048]----+
| |
| . |
| . o . |
| + . . |
| o.= S |
| ooE . |
|.o*+o |
|=.+oo |
|=o.o |
+-----------------+
|
|
|
|
The ownersalt is encoded plaintext in the encrypted key and is handled like an IV. Casascius changed BIP 38 since I last looked at it (boo!) and now it seems to be called ownerentropy (which can be 8 random bytes or derived from a 4-byte random number + lot and sequence #.) Encrypted Key = base58(0x01 0x43 + flagbyte (1 byte) + addresshash (4 bytes) + ownerentropy (8 bytes) + encryptedpart1[0...7] (8 bytes) + encryptedpart2 (8 bytes)). Actually looking further into the spec it seems like my BIP 38 cracker is now incompatible with the spec with the addition of prefactor and hashing it with ownersalt to get passfactor. |
|
|
|
OK, I understand your system as planned will include all of these pieces but it is a lot to take on. I am going to describe it in the context of some existing projects that have taken on chunks of the problem, for more research areas you may want to look into... Good question; I'd imagine the p2p nodes are basically super nodes and clients only relay small bits of data .
If the client trusts the source of the private key, it doesn’t matter how the data is sent or received as. (Example, if I trade keys face-to-face it won't matter how the data gets there or received). The issue is that people from china can't all practically swap keys face-to-face, and not everyone is a "Crypto-wizard" to know how to evade "Man in the middle attacks during key exchange over an electronic interface". This is when the "P2P node trust" system comes in to play, basically two people exchange keys on the non p2p network (perhaps a facebook message or IRC). Once to people have their public keys they now can ask the p2p nodes to validate the key by asking for and validating various information transparently for the user.
So there would be a component that would operate like a PGP/GPG keyserver, but with additional validation over other channels like what the the CACert Web of Trust CA is doing. Why do i think this is awsome?
As of right now for a "layman" to accomplish this they have to be educated that they need more than one channel of communication to prove that there was not a man in the middle attack during the trading of public keys, so this solution makes the whole experience transparent becuase unless you meet face to face for publickey exchange your most likely going to exchange public keys through gmail, hotmail, IRC or facebook and unless a "layman" is educated to "resend the same key on a different email address or chat channel and "match the public key letter by letter", then they are vulnerable to man in the middle attacks".
Very true, you just have to make sure the validation process has air-tight security - for example, if someone posted a public key for Josh on this site (with some cleanup to make it look legitimate of course) is that enough trust? Obviously not. Systems like CACert require a face-to-face meeting with trusted community assurers and checks of government ID to finish the signing process for the Web of Trust cert. It depends on what level of trust you want to place in the system. Other notes....
New clients can build trust by helping relay small chunks of data;
the actual trust is gained by other nodes if your data seems to match up with nodes that those recieving nodes trust, the more your information matches the more your trusted over time, however if your client is relaying 100% or even 20% false data all nodes are advised to deny data from that client or node (A better solution would be to lower the priority of processing from your node as an attack could be happening and "triggered block occurred")
This would be difficult to protect against, what's to stop me from feeding a node bad data continuously with a coordinated attack from multiple new accounts, slowly increasing the percentage of bad data it relays to take it offline? How does the node itself verify the trust of the original party when it is deciding whether to pass the data along? Also, how do you know you are talking the real person's identity, and not someone that has created an account claiming to be that person? This p2p crypt app could also provides other opportunities
*Like perhaps even be the leader of SSL certificate authority systems in the far off future: I ponder that if everyone online has everyone else’s key who is currently online along with a rating of "trust" that node is then perhaps we won't need to have CA's at all because there is no more risk of man in the middle attacks (which is why there is CAs certificate list is in browsers).
Yes, once the trust system is in place, it could be used for many awesome things. *SSL and non SSL enabled websites could rely on the p2p crypt trusted web to initiate a secure login session, cookies and other methods to turn HTTP into a "State full" protocol literally is 2+ decade old technology and computers getting faster while captcha methods failing; The sessions are under constant attack and its time to move on.
HTTP could be used to serve webpages while P2P crypt could allow websites to initiate a "secure session" regardless of an SSL connection. this could allow safe login sessions that are harder to attack on.
This I have to object to, SSL works well, is extensively tested, and highly trusted. HTTP can be stateful without any encryption at all. User authentication/captchas is a separate issue, and in that area it is true that the web of trust would provide an additional authentication option (possibly taking the place of SSL client side certificates.) Also, how does your system compare to something like Retroshare? I know the end goal you want to get to for the trust side, since having a working system of decentralized trust is a 'holy grail' for online systems, and a lot of research has been done in this area as it contains a lot of hard CS problems. The wiki article on Web of trust is a good resource, and there are many papers (search for 'trust management problem' or 'decentralized identity'.) Even just a face-to-face-public-key-sharing (or via Bitcoin public keys...) crypto app would be very useful in its own right, however. In any case, I am looking forward to seeing where you take the project! |
|
|
|
|
