|
It's wrong; I don't know what it's doing in the wiki. At best it describes an undesirable hard-fork. Every discussed light-weight node proposal involves requesting unknown blocks/transactions from peers, and only one peer would have to have a full history.
|
|
|
|
Confirmed with @nefario on IRC that an NDA would be required of anyone that picks up theymos' shares. That's not standard for investors, and a deal-breaker for me  |
|
|
|
thx  Thanks for the fix, it will work with prev version of bitcoind v0.6.3
how do we fix it for version v0.7.0?
The system I was working on still has v0.6.3. What changed with v0.7.0? Does it throw a new error? |
|
|
|
|
I'll give you a hint: look at the timestamps/received-time of that block and the one before it.
|
|
|
|
Also going to give ecoinpool a try - a wonder i came that far but its still not working. root@j064:~/ecoinpool# ./test_launch.sh
==> ecoinpool (compile)
==> ebitcoin (compile)
==> rel (compile)
==> ecoinpool (compile)
Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:4:4] [async-threads:0] [kernel-poll:true]
Eshell V5.9.1 (abort with ^G)
(ecoinpool_test@j064)1> [12:29:23.245][ebitcoin/fatal] config_db - couchbeam:open_or_create_db/3 returned an error:
{ok,"401",
[{"Server","CouchDB/1.2.0 (Erlang OTP/R15B01)"},
{"Date","Thu, 30 Aug 2012 12:29:23 GMT"},
{"Content-Type","application/json"},
{"Content-Length","67"},
{"Cache-Control","must-revalidate"}],
<<"{\"error\":\"unauthorized\",\"reason\":\"Name or password is incorrect.\"}\n">>}
{"init terminating in do_boot",{{badmatch,{error,{shutdown,{ebitcoin_app,start,[normal,[]]}}}},[{ecoinpool_test_launch,start,0,[{file,"src/ecoinpool_test_launch.erl"},{line,34}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
root@j064:~/ecoinpool#
Im really not a linux super geek and pretty happy i got that far, would be very happy about a little support. Not much, but ill give 1 BTC to the person who gets this working (posts the right solution here). EDIT: i have also edited the local.ini to bind the couchdb to 0.0.0.0. In case anyone else encounters this same problem, it appears to be a case of source code atrophy. The most recent builds of ecoinpool's dependencies no longer work together as expected. Pegging the dependencies to versions around the same time as p2k's last commit solved it for me: {sub_dirs, ["apps/ecoinpool", "apps/ebitcoin", "rel"]}.
{deps, [
{protobuffs, ".*", {git, "git://github.com/basho/erlang_protobuffs.git", "e0f5f6ea4c3dcb4e7b824496d2b48333fbd5a8c8"}},
{ejson, ".*", {git, "git://github.com/benoitc/ejson.git", "820ff1725008e664293b88e13c16193857afc072"}},
{oauth, ".*", {git, "git://github.com/refuge/erlang-oauth.git", "f332b77371d334d0faa13e106d0c36f948b325b6"}},
{ibrowse, ".*", {git, "git://github.com/cmullaparthi/ibrowse.git", "eb8b62cf84ccae141700c8fd251277df8be27f28"}},
{mochiweb, ".*", {git, "git://github.com/mochi/mochiweb.git", "b7f3693a9008de6d31a67174f7184fe24093a1b4"}},
{couchbeam, ".*", {git, "git://github.com/benoitc/couchbeam.git", "7148bbdb19aca91b7b74e5392a23c94d33ca4e27"}},
{log4erl, ".*", {git, "git://github.com/SemanticSugar/log4erl.git", "ec580f75ef9e28dfcfac92dc0d42c435520bd3d7"}},
{mysql, ".*", {git, "git://github.com/elbrujohalcon/erlang-mysql-driver.git", "1dd4e22a80546fa1bda81607d6397a549fd791ae"}},
{epgsql, ".*", {git, "git://github.com/wg/epgsql.git", "fc434772276475ac4e5b0bed6b18ed4732502156"}}
]}.@sippsnapp, does that offer for 1BTC still hold? 17SRxATG3LZrD7WWTCr5EfCapprShVEtP  |
|
|
|
Amazing work @MatthewLM, expect some pull-requests coming in |
|
|
|
Private insurance is available for any company to buy, that will cover data loss or data theft.
The company must pass a very strict security audit, at their expense, to the satisfaction of the underwriter.
The mechanism for this already exists.
This type of “insurance” service doesn't exist. Please re-read the OP. I would be on board, need more info please contact me in pvt message to see if you can handle what I need.
I'm not offering this service, although I'm hoping somebody else will. It could be very profitable, but would take up far more time and resources than I have available I think the idea has merit, but I much prefer a proactive approach over a reactive approach. I think it makes more sense to focus energies on prevention of theft instead of how to respond to theft. Until we've exhausted all preventative measures, of course. It should be quite obvious that we are nowhere close to exhausting those measures (hot wallet / cold wallet for starters).
The problem is, the costs from proactive or reactive measures will be transferred to the customer, and most customers seem to be more concerned with fees (and convenience) over security.
What we need is intelligent consumerism.
Unfortunately the wild-west nature of bitcoin is getting in the way of serious growth, and proactive measures only go so far. Thefts already happen with no recourse and limited police response--it will only get worse as the criminals responsible acquire capital and refine their techniques. Anyways, non-regulated “insurance” companies of the type I advocate would probably increase deployment of proactive measures as they themselves would be a security company with skin in the game. |
|
|
|
|
This is an idea that I've been thinking about for a while but do not and surely never will have the time to properly implement. I'm posting it here in the hopes that someone else will, as I believe it is a service greatly needed by the bitcoin community. Especially in light of what's happened recently with Bitcoinica and now Bitfloor.
What I advocate would most accurately be called a bitcoin insurance company, but probably not what you think of when you hear those words. It is a security company that assumes the risk of theft or destruction of its clients bitcoins, in exchange for a premium and a contractual obligation to implement what the company determines to be minimally adequate security measures.
Should a theft/destruction occur, the company immediately pays out the value of the lost coins to the client, in exchange for ownership of the stolen/destroyed coins--the premium being an on-going option for the insurance company to buy the coins at face value. This is where it differs from a traditional insurance company: the company takes off its actuary hat and becomes a policing organization. The company has become the legal owner of the stolen or destroyed property, and it uses whatever legal means available to find the one responsible and extract restitution (NB: restitution, not retribution--I'm talking principal + interest + collection fees, etc.).
If Bitcoinica had such insurance, it never would have gone permanently offline in the first place. Instead the insurance company would have gotten some bridge financing to cover the rather large payout, then launched a well-funded white-hat and black-hat operation to identify those responsible and extract restitution. Bitcoinica would have been back up and running within a week, and one more scammer would have learned not to mess with the bitcoin police.
The bitcoin economy is very fragile, and we need policing organizations to keep the scammers and con artists at bay. And there's really no reason this can't be a service provided by the community itself--and paid for through the mechanism of insurance.
|
|
|
|
oh look. he got 4 bitcoins!
...
so what?
why did he have to write an article about it?
Journalistic integrity? |
|
|
|
Chance are negligible. If collision occurs with a funded address, attacker you can transfer funds elsewhere.
Chances are still negligible when 1 billion people are using it? also can't I just run some kind of bots, that randomly generate addresses to see if they have funds in them? Yes, chances remain negligible. You could run your bot, but it'd be a waste of electricity. Chances are you'd wait the lifetime of the universe before finding a collision. |
|
|
|
|
Yes, this would be useful for me.
|
|
|
|
We're nearing feature-freeze for the beta. The beta, release planning, and launch will all occur on the Freicoin forums. This very well might be my last post on the topic here at bitcointalk. If you haven't yet, I recommend checking out the Freicoin forums: http://freicoin.freeforums.org/ |
|
|
|
Wow, that was an awesome read. Thank you. |
|
|
|
He was 70. Pirate is 30.
I thought he was 40 |
|
|
|
It's kinda cute, but the GTA4 Liberty City map as bg befuzzles me. I noticed that too. I guess the image that best represents PPCoin is grand theft? |
|
|
|
|
But in the existing, community-vetted proof-of-stake proposals nobody is given control because of a high balance. In Mini's proposal, for example, PoS is simply a method of voting on checkpoints. It's therefore reactionary and you'd have both significant mining power *and* a significant balances to execute a double-spend attack. With PPCoin you need either significant mining power *or* a significant balance to execute a double-spend. That's not a trivial difference.
|
|
|
|
|
There's no need for a "master block chain", if I'm reading your post right. Just update the existing client to support multiple chains side-by-side in a single running process. This is something that I was going to work on eventually, if for no other reason than to simplify the process of running bitcoin and freicoin side-by-side and sharing patches.
But for most of your needs, Open Transactions fills the bill. A bitcoin-like block chain is only ideal for a small number of use cases that require peer-to-peer distributed services. For most financial applications there is inherent centralization in the problem, making Open Transactions a better, more lightweight solution.
|
|
|
|
|
Show Posts
