Hard to argue with that well though out logic.

As you can see @OP you won't find any decent reasoning even used on this forum (that disappeared a few years ago) which is why I (and many others) rarely even bother posting any more.

So please continue on with the personal insults and non-technical babble - about the only people that are reading are "ad-sig posters" anyway who don't even care as long as they are paid to post more dribble here (for any decent technical information about Bitcoin it would be best to look elsewhere).

This is simply nonsense/propaganda - increasing the block size (or reducing the block speed) simply doesn't scale and anyone trying to say it does is either purposely misleading you or doesn't understand just what would be involved in scaling (anything much more than say ten times what can be handled now).

Unfortunately @OP this issue has mostly become about politics rather than practical solutions to the Bitcoin network.

A real "rollback" would require that the transaction log would have kept the full details of any deleted record (no major DB in the world does that AFAIA).

So if you want to "reverse history" it would be easy enough to recover "deleted records" using the transaction log.

Hope that makes sense.

I have worked with many RDBMS engines (including DB/2 and Oracle) and they are all very powerful things.

There is really no reason to prefer one over the other in regards to what you are wanting to do.

The only thing that no current RDBMS handles well is actual "rollback" in terms of a "re-org" (normally a DB "rollback" is actually just restoring a backup and then "rolling forward" the newer txs from the log).

AFAIA no modern DB can do this (although I do have a design for exactly this).

Whilst it is a great small SQL DB it isn't suitable for multiple users due to its use of global locking (unless they have completely reworked that in recent years).

I would favour using something like MySQL if wanting to have something that will scale hugely and handle multiple concurrent users.

Yes you can do this and I have written a Linux distro to help if you want to use or just review it for your own ideas: https://susestudio.com/a/kp8B3G/ciyam-safe

The distro I created uses just QR codes to talk between the online and offline computers (so "air-gapped safety").

It also combines Bitcoin with GPG and "scrypt" in order to make backing up possible and secure.

In order to determine the current block height one can call getblockcount but I see no equivalent in order to determine the value used for nBlocktime (the average time of the last six blocks if I recall correctly).

When determining when a CLTV transaction is going to be "ready to send" (without actually attempting to send it) this would be helpful.

Or is there already a method to determine this from RPC calls?

Will lock this topic now.

For anyone playing around with CLTV transaction using "regtest" you should note that you will likely need to generate multiple blocks between sending funds to the the P2SH script address with the future nLockTime and when you want issue the tx to spend those funds due to the handling of the nBlockTime being based upon an average of the last X blocks.

https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki

Frustrated me for a day so if you're getting the non-final errors when you think you shouldn't just try a "generate 10" and repeat.

It was interesting to see that the plunge in price started shortly after the appearance of the article on ZeroHedge - but that was 2am in China on a weekday - so I find it hard to believe that it was actually Chinese traders that live in China that were the ones dumping (far more likely that the dumpers were actually from the US).

There was also no media release made in China about this at all and also note that the "author" of said article is apparently Tyler Durden.

This is sane advice if you want to keep using the initial installation.

Incorrect information (bought account or you just don't know what you are posting about?).***


As I recommended try the old wallet on the new installation first.


*** (this is why I have basically stopped using this forum)

It doesn't matter if the wallet is not up to date in order to send coins and I'm pretty sure that the old wallet can also be copied to the newer version and should work fine (maybe try that first as you can always go back to the other approach if that fails).

You might also wonder how you can pay for purchasing things in China for 0% fees using the Chinese equivalent of PayPal and then further why the sellers are only being charged 1% (at most) for using the same service.

It basically comes down to the population size (well over 3x that of the USA) and the general expectation of low or no fees that the population has (unlike the US population who seem to be resigned to being constantly being ripped of with excessive fees by using services such as PayPal).

There are small percentages charged for the withdrawal of funds to banks by exchanges so the model isn't "fee free" but the lack of any trading fees and the support for "bot trading" guarantees the greatest liquidity possible.

Also as the large exchanges in China are closely tied to mining this liquidity is particularly important for them (so the Chinese exchanges work more like an overall Bitcoin service system than western ones do). In this regard you can even find that one exchange (BTCC) offers the ability for you to "create a permanent message" in the blockchain (just like Satoshi's initial message in the genesis block).

For sure - it wouldn't be a huge amount of work to do some GUI (Linux has some easy stuff for doing forms that actually works in the console).

You need to understand that I didn't create this project in order to make any money (so it had zero publicity and backing).

I created what I did in order to securely store a lot of Bitcoin back in 2013 and for that purpose it has worked flawlessly.

Of course after Segwit is released then maybe it will need to be revised to use the new forms of raw transactions required for that.

The "community" has not been interested in doing this since I created it (years ago) but in any case the software is there and is open source (the scripts and other software used are on github).

https://github.com/ciyam/safe

It uses a custom SUSE distro and although it does come with documentation it is "console stuff" (I never had the time nor the interest from others to bother with creating a nicer UI sorry).

I put together this years ago: https://susestudio.com/a/kp8B3G/ciyam-safe

It is an OS image that doesn't even have internet capabilities (your keys are safely kept on the offline computer and txs are done using QR codes so that you don't even need to have any "wire" attached to your offline computer apart from its power).

You can backup your encrypted private keys via QR codes also (it uses GPG to do the encryption of those).

The system has been used to safely look after well over 500 BTC since 2011.

It is because a BTC address is the hash of a public key that it isn't much help for creating an encryption key. The usual approach for encrypting messages with EC is to use ECDH to encrypt a message for two key pairs (you need one private and one public key from each pair to create a "shared secret" which you'd use for encrypting/decrypting).

By not announcing the public key until one "moves funds" Bitcoin has built in protection against possible future brute force attacks (which may become feasible with QC or some other tech) that might be able to determine the private key from the public key. Assuming said attack still might take some time (more than one hour say) then it wouldn't matter that the public key was disclosed assuming that the funds were being moved (and the address is not re-used) because after the tx has been confirmed a few times there is no danger.

With address re-use (which is not recommended for the above reason) you would be able to find the public key of a Bitcoin address that has had its funds moved. So if you are looking for a way to find a key pair (in terms of the public keys) you can use a known and already spent Bitcoin address from each party (but still there won't be room to put this message in a Bitcoin tx).

Thanks @DannyHamilton - I still remember when we used to be almost in competition trying to help people with technical problems a few years back (good memories).

I would be very happy to work with you on something in the future.