Firstly: https://proofofexistence.com/detail/59842392aaeb2503acc35951cbb1f6cf7629bcc62ba0a0bed02928fc99e85d7a
(to note when I created the document)
and then this: https://ciyam.org/qc_proofing.txt

It could probably be improved but is just a starting point to make sure that we will be able to make Bitcoin QC proof well ahead of any real threat of people losing funds (which I have no idea how far away is).

Well let's see how that goes but so far he has shown very little interest in Bitcoin so I very much doubt that his device will be a Lightning Node as I described.

Also bear in mind that his Tesla company doesn't even make a profit and now there are many competitors (so you might find Elon is actually not able to do much at all by 2020 as he might be broke).

Still has 1 BTC there (was that your point?).

I moved the other funds earlier in case you had missed that (decided that 10 BTC was really too much to leave there).

Not sure what other ideas have been put forward to address this issue (but QC is looking more and more like a real issue these days) so I thought I'd just bring up this idea (it may have been brought up before as I haven't followed this forum now for quite a while so sorry if I'm wasting anyone's time).

From memory I believe that stealth addresses worked using some magic to do with "adding" a value to public and private EC keys and I think this idea could be harnessed to prevent QC theft. Basically the method would be to divide a tx into two separate parts (that need to be confirmed separately) with the first part being a "tx commitment" and the second part being the "tx verification". The first tx looks pretty much like a normal tx but the public key is not valid at the time (as it has had a random X value added to it) although the signature would be valid with the munged public key (thus any QC trying to determine the private key will end up with the wrong private key value and AFAICT the real value can't be worked out until X is published).

After this first tx has been confirmed the funds should remain locked for N blocks (probably no more than 100 or so I'd think) so that interception of the second tx can't be then used to bypass this mechanism (and maybe a greater than normal tx fee should be required for the first tx to make sure people just don't try to lock up everyone's UTXOs in this manner for fun).

Once the commitment tx confirms enough times and no other tx using the same "munged public key" has appeared before it (which potentially could happen if the QC worked out the private key of the munged public key fast enough) then you would send out a "tx verification" that would reference the tx id of the commitment tx and provide the random X value which will then allow the actual ownership transfer to take place.

It's not very elegant and probably needs a lot of refining and improving but that's one idea to counter QC before we work out a completely new signature approach (presumably along the lines of Lamport signatures).

I had the idea of a "crypto router" back in 2016 (and some work had taken place on it in late 2016 and early 2017) but unfortunately things did not work out with the plan and it basically came to a halt (the original idea was a little different to what I am presenting here but not all that different).

I have given up on trying to find any business partners to work on this idea now and so am simply going to outline the concept for others to run with if they think they can make it happen (don't ask me for any help or funds though as that is not on offer - am just giving away the idea).

The home (or small business) WiFi router is about the least shiny but still mass-market computer related product that we have (normally kept either pretty much out of sight or somewhere that is not very noticeable) and therefore IMO one that has a huge potential for improvement. The improvements can be both in its UI, its functionality and its general appearance (i.e. make it a lot more attractive for a start so it becomes a "show piece" rather than just a boring box with some flashing LEDs that is only inspected when your internet seems to be dead).

The first idea I had about how the router can change to become a far more important device could be to add entertainment features into it (as they can all have a web UI which can be easily tweaked and improved then why not make it a music and video playing device that is accessible to every other device connected via a browser for a start). But the far more interesting idea that I had (when I realised that the Lightning Network was going to be the future for Bitcoin) is to turn the router into a Lightning Node (with a catchy name like perhaps "Lightning Rod" or "Leyden Jar" or ).

For merchants who so far haven't accepted Bitcoin payments but are becoming interested in doing so (and maybe not just wanting to immediately convert that BTC into fiat as was the case with the first wave of merchant adoption) this could be the easiest way for them to do this whilst at the same time helping to make the Lightning Network more decentralised (just imagine the impact if a large franchise encouraged all of its franchisees to install such devices).

One of things that people might not have realised was that pretty much *all* publicly located WiFi devices were found to be insecure last year and so are going to need to be updated this year (hence the right time to be creating this device is *now*).

I hadn't intended to ever log in here again but unfortunately thanks to LinkedIn (not taking my word and instead wanting me to use lawyers) I will just leave this here  to make sure that people are aware that at least one individual is currently pretending to be a "co-founder" of CIYAM (there is no such thing as people on this forum who have been around long enough will know that this organisation is pretty much all of my own work apart from a few small contributions here and there).

My guess is that perhaps some stupid new ICO might pop up pretending to have something to do with CIYAM - if it does then please understand that it has absolutely nothing to do with me. I have updated the main web page for CIYAM (http://ciyam.org) to reflect this and will keep it as it now is until this problem resolves itself.

(mods - please leave this in here for a day or so before moving it elsewhere as this could be important to prevent people from being scammed)

I just received an email today from BTCC with my balances (all of them) - not only is this surprising but incredibly insecure (have never heard of a bank sending you all your account balances via email).

If you are a US citizen using BTCC then you might want to carefully consider what to do now (unless you are running your own secured email server you should assume that the IRS now knows your balances at that exchange).

I haven't "promoted" the use of brain wallets but have simply stated (and have proven) that they "can be safe" as I think it is not reasonable for people to constantly state that *no brainwallet can be safe* due to being a human being (but I won't deny that perhaps for the vast majority it is probably not going to be safe).

I am considering to move that 1 BTC and then reveal the brainwallet passphrase that was used as an illustration of how one might go about creating such a thing (but I will not be *recommending* others to do this).

And yet if you look here: https://blockchain.info/address/1Au4v6dZacFVsWXeKUMJd99AtyBZeqti2L

1 BTC that has been there since 2012 is still there - I posted about this here: https://bitcointalk.org/index.php?topic=885616.0

It certainly isn't a simple thing to create an effective brainwallet but it also certainly isn't impossible (as I've demonstrated for four years).

That certainly is a surprise to me (thanks for the link and I deleted my own post to avoid any further confusion). Thinking about it more I guess it makes sense that in order to do a "rollback" it would need to be able to restore deleted data (as the size of a transaction could be huge it has to write all the recovery information and keep that at least until the commit has been completed and all final tx data has been flushed to disk).

But can you force rollbacks to occur after a successful commit (and especially after a checkpoint)?

Certainly I'm not familiar with any standard SQL commands for doing such a thing (and I wouldn't count nested transactions if supported as really being a solution) so I still don't see how you could use a traditional RDMBS to achieve a blockchain "re-org" (which is the main point that I was perhaps poorly trying to make).

Assuming that most RDBMS engines do work the same way regarding logging then perhaps it would at least be potentially possible to add some method of tagging the DB state at a certain "block height" and therefore later be able to "rewind" the DB back to the state it was at that specified tag (although I don't think that there is any such standard method).

The Trade package has been extensively improved to work along with the Wallet and Transaction packages so that nearly all of the ACCT operations (such as creating the required wallets and receive or refund transactions) are now automated.

A demo of a working ACCT dialog will be made available soon (although at this stage only to those involved with the CIYAM project).

Others wanting to get involved with the project further should send me an email address in order to get a Slack invitation.

Luckily you do not need to use LN and can continue to use "standard" Bitcoin (which is why the SegWit changes are a "soft fork").

Also the changes that have been made for LN support are really not very complicated at all (and have been thoroughly tested for many months now).

An interesting feature although from reading the documentation I think that is just for use with nested transactions.

The concept of a blockchain re-org though is not the same thing as you need to "rollback" transactions that have already been committed (something rather alien to how RDBMS transactions operate).

If you are paying X per byte in fees then how on earth can that possibly have *no cost*?

(five left - not sure I should waste them on stupid things)

Whilst I agree that 10% is probably not going to be enough to make a huge dent if the percentage starts to get a lot more than that (i.e. approaching 25-30%) and the block size has managed to vastly increase in size (as many supporters of BU seemingly are fine with) then this scenario does end up becoming a possibility.

In short a "fee market" needs to exist in order to ensure that a large enough number of different mining operations continue to confirm transactions.

Also the fact that a shit-load of non-fee paying txs (or too low fee paying) are flooding the network at the moment (as has happened a few times before) is perhaps proof that those wanting to do exactly what the @OP fears they are trying to do are pushing hard at that (by trying to convince people that we need much bigger blocks).

For blockchains (whose very purpose is to be a non-mutating structure) the "deletes" are only re-orgs (which although not that uncommon are generally not very large delete operations as most re-orgs are only one or two blocks deep) and depending upon how things are structured (such as if the structure of the chain itself is separated from the content of the blocks) would not need to involve much data.


A "true rollback" (which as I said isn't being used by an major RBDMS that I am aware of) would actually be much faster than any other method (i.e. you either are going to have to issue update queries to act as though things are being unwound or restore an earlier backup which you'd then have to perform a partial log restore from).

Understand also that even if deletes involve appending the data to the log you would still be able to truncate the log for "checkpoints" (at which point any of that extra wasted space is recovered).

As deletion (and in Bitcoin rollbacks) are infrequent operations it wouldn't practically be as significant an increase as you are imagining (but it would use more space for the translation log).


Normal RDBMS "queries" do not involve the log at all so it would not have any speed effect upon read operations (it would only slow down "delete" operations).

It has been very thoroughly tested and in fact actually helps to simplify things (by getting rid of tx malleability). Please don't FUD.

Those supporting idiotic ideas like Bitcoin Unlimited might delay things but those with the majority of mining power can already see through the nonsense so I think it will get there (and kudos to the development team for sticking to 95% unlike those fork happy idiots like BU who are pushing to fork at 75%).

Actually there is a method that you could use to lock UTXOs that is a kind of 2FA and that is by using a P2SH script that requires both a signed public key and a "revealed secret" (in much the same way as I've designed for doing Atomic Cross-Chain Transfers or ACCTs).

Of course you wouldn't want to trust some 3rd party for this but instead have some offline device providing the hashes and secrets for you (such as a mobile phone that has been placed in a Faraday cage).

Basically this would give you a way to have your keys on your online computer but still make things safe by having the secrets and hashes generated offline.

Just send 100 BTC to the address in my sig and I'll put him in touch.