Check the wallet locking/unlocking functions.

I think there is an appropriate place for you to advertise your device, but this ain't it.


Among other problems, this jumped out at me.  It suggests that you might not have an entirely firm grip on how double spends work, which calls into question other aspects of your project.

I didn't read your wall of text, and I doubt that anyone else will either, but this jumped out at me.

The proof of capability is work.  If you prove that you did work, you have proved that you had the capability of doing that work.  Nothing else is necessary, nothing else is sufficient.

Generalize this to everyone else, and you'll understand why I'm done with this topic.  To me, it makes no difference whether an objective ordering exists, but is not knowable, vs does not exist at all.  It would be more productive to define double spending as any transaction that does not have the approval of the Easter Bunny.  The arguments are the same:

When there are new posts in a watched/subscribed thread, if all of the new posts are from users that are on your ignore list, that topic should not show up on the list as having been updated.

Einstein is snickering at you from his grave.

Objective reality is like a platonic ideal of a sphere or a straight line.  One might exist, but you'll never see anything better than an approximation.  When time gets involved, relativity says that when information is constrained to finite speeds, like it is in our universe, even the approximations are personal to each observer.

At any rate, all that you can accomplish with this sophistry is to swap the labels on the problem around.

In a sudden catastrophic break, that is exactly what would happen.

Of course, such a break is widely regarded as, ahem, unlikely.  Like "getting arrested for going over the tag limit on your unicorn hunting license" unlikely.

What will happen in reality is that some day, someone will publish a theoretical attack that weakens a wildly reduced form of SHA2.  A few years later, people will start to take notice as someone manages to produce an attack on a moderately (or maybe even just slightly) reduced version.  Around that time, someone will make a pull request that invokes the 75/95 rule*, triggering a new rule that says that starting a few tens of thousands of blocks after the majority is achieved, blocks that satisfy the target using either SHA-256 or some other hash function will be accepted**.  Then, someone on the mailing list will pipe up and suggest a different new algorithm that no one has ever heard of, and no one but djb trusts.

We'll spend the next year or so painting that bike shed good and hard, eventually settling on something newer than SHA2, and using a different fundamental compressor, but still something that has been around for a while, and widely respected.

Probably about a quarter million blocks after that, SHA will be retired.

By now, we are a decade past the first signs of weakness, and the cryptographers are getting close to shaving a bit or two off of the full version of SHA2.  Ten or twenty years after that, and SHA2 will be moderately unsafe against an institutional attacker, in some applications, none of which will ever apply to bitcoin.  At some point, the attacks get good enough that cryptographers are creating collisions on napkins at cocktail parties to impress women (to paraphrase the famous timeline), and yet bitcoin would have remained totally safe because the attacks that break hash functions simply do not generalize to short inputs with rigid constraints.

* Yes, I know that the 75/95 rule is for soft forks, but nothing else seems to fit here.  The devs are a conservative lot, but this hard fork can't be dodged.  Most likely, the "tens of thousands of blocks" that I mention next will really be on the order of 100k.

** The mechanism is very simple.  Try the new algorithm.  If it hits a valid target, accept.  Otherwise, try SHA2.  IF it hits a valid target, accept.  Otherwise, junk it.  Notice that there is no need to change any of the structure or fields of the blocks or header, and no new block version is necessarily needed.

Does anyone have useful contact info for campbx?  I've tried explaining this to their helpdesk live chat several times now, but they think the problem is on my end.

Campbx uses kayako for helpdesk service.  If you click their helpdesk link, you'll eventually come to https://support.campbx.com/Tickets/Submit.  Problem is that the page has a kayako.com cert, not a campbx.com cert, which causes a SSL error in sane browsers.  Simple enough to bypass this one, just go to https://campbx.kayako.com/.

Also, the kayako helpdesk software forges emails claiming to be from support.1@campbx.com, but they actually come from a kayako.net server.  Problem there is that campbx.com has published SPF records that do not allow mail from the kayako IPs.  If you have a sane mail system, meaning one that understands and follows SPF records, it will end the session with a permanent (5xx) error as soon as it figures out that it is talking to a peer that is explicitly denied by the published policy.

No, this is not how the network works.  Not even close.

Please browse this board for a while.  Most (all?) of your ideas are already here, complete with discussions revealing how and why they don't work.

Nonsense.  The blockchain defines the order of transactions.  If we had some way to determine which transaction was "broadcast first", we wouldn't bother with all of the hashing.

Bank security, ultimately, comes down to one simple thing.  Money isn't real.

What a bank protects is not money, but a list of debts owed (deposit accounts, etc) and debts owned (loans, etc).  And literally nothing in banking is ever final.  If someone tampers with the debt lists, they can just untamper them during the next audit.

A lightweight wallet has limited capabilities, relying instead on external services.  The term is widely understood in programming, engineering, etc.  Armory is a good example of a general external wallet.  It exists today, and indeed has for several years now.  But it is far from lightweight.

I have a job, a life, and indeed a variety of other interests.  In addition, I rarely use C++, so working on the official client is difficult for me, and because of the aforementioned other interests, I have not yet got around to investing enough time to improve my skills in that area (and probably never will).  However, all is not lost.  What I have built works very well for me, though it will never be suitable for general release to the public.  And other people are implementing similar things in their own way, so it isn't like the world is deprived of any great benefit by my continued inattention.

My point is that it is possible to use the existing tools to implement a bitcoin wallet outside of the standard node, today.  Bringing that wallet up to your standards will require a bit more, such as an extra service that implements the extra RPC calls that I identified 3 years ago.  But that isn't hard to do at all.

Bitcoin is a volunteer effort.  The developers either follow their own whims, or the whims of their employers.  Unless you are footing the bill, there isn't much point in complaining that your pet project isn't getting attention.

Your wallet is just a lightweight version of a general wallet.  You are correct that the current API does not support lightweight wallets.  See the second link in my sig for a look at exactly what changes would be needed to support them.

But a heavier wallet works just fine with what we already have.  Actually, the only thing that is hard to do today is sweep privkeys.

You can already hook up an external wallet using the RPC functions.  Optionally, add the notifiers to reduce polling.

Look in txdb.cpp, CCoinsViewDB::GetStats.


I didn't follow the objects around, but at first glance it looks like the txid and sequence number (in varint form).  That works out pretty well with your 35 bytes per output calculation.

If only there was some way to establish a network of transaction-risk management companies to assist in cases like these...

I wrote the ultimate guide many times.  Eventually got sick of it.

The short version is that there is no "sender", much less a "sender address".

I haven't kept current with the recent changes to the client, but I believe that a transaction will go from zero to -1 confirmations when the client sees a conflict in the block chain.  The idea is that zero means "not confirmed yet" and -1 means "and never will".

If you use walletnotify, you can examine each transaction and compare the input and output sets to your 0 and -1 transactions, looking for a match.  If you see one, you can mark them as equivalent in your own system.

There has been some talk of making an immutable ID.  For all I know, it is already done and in the client.  The block chain requires that the signature be included in the ID hash, otherwise blocks would be impossible to verify (or at least harder).  And it is useful almost all of the time to present that same ID to the user.  But a signatureless hash can be useful too.

Again, your question is confused.

But, I promise you that your string will not change if someone else mutates your transaction.  If they re-serialize their version of your transaction, they will get a string different from the string you have, but your string will not have changed.  Unless you have a quantum computer, haha.

Note that their transaction and your transaction are not the same transaction.  They have the same inputs and the same outputs, but a different ID.  This is mostly a matter of philosophy though, because we've defined the transaction ID as the sole identifier of a transaction.  If we defined a transaction by their input and output sets, they would be the same.

This, by the way, is the core of the malleability problem.  If you track transactions by ID, you can end up having problems if someone manages to get a changed version of your transaction into a block instead of your version.  You must track by inputs, and you must be prepared for the ID to change between when you create it and when it is safely frozen into the chain.

"coin" has many meanings.

A transaction creates "coins" as outputs, and the values of these outputs are granular (currently) in lumps of 0.000 000 01 "(bit)coins".

So, skip over the chicken/egg problem for a moment.  Say you have keys to 3 unspent outputs, 1 BTC, 2 BTC and 3 BTC.  You want to pay someone 4.5 BTC.  Your wallet creates a new transaction that spends the 2 BTC and 3 BTC "coins" and creates two new ones: 4.5 (sent to the recipient) and 0.5 (sent back to you).