Okay - well when (even) one of the devs says that your idea is a good one then I'll admit that I should have not rejected your idea.

Fair?

So you refuse to say about anything relevant and want to carry on with some silly stuff that no dev has replied to or will.

Good luck!

If you mean any Bitcoin devs then I'm sorry - none of them have (or likely will) respond to this topic.

Please go and actually find out about the pruning that Bitcoin uses already before proposing something inferior to replace it with.

Try and understand that naive (and sometimes just plain stupid) ideas to "improve Bitcoin" are suggested every day on this forum by people with no software development skills whatsoever (and you have failed to show that you have any).

If the developers were to waste their time having to read and respond to every suggestion such as yours then they would never have time to actually do the work that they are doing (which is why you are not going to get a response from them).

So again - if you really have anything serious to offer then firstly go and study how Bitcoin pruning works before trying to tell others how "it should work" (when you've not even displayed that you can code).

No - you have a silly idea and it was pointed out to you why that is so - yet you ignore that and still think the "community" should pay attention to you.

Please read more about the actual blockchain technology before "trying to improve it" (you'll notice that no Bitcoin dev has taken the slightest bit of interest in your idea although maybe next you'll say that is some sort of conspiracy).

You provide no technical details and have clearly very little understanding about the technology (from what you have posted).

Yet you think you have come up with some grand idea that others should look at?

No-one is going to waste their time with your ideas unless you actually show that they have the slightest bit of merit (which so far they do not).

Understand how the blockchain works before trying to improve it.

I don't think there is a "perfect" solution to what you are wanting so basically it just comes down to the trade-off between the amount of disk space and bandwidth you are willing to sacrifice for a full node.

If you use the pruning you can limit the disk space to about 2 GB (depending upon how many active keys you have of course).

Prior to 0.12 you couldn't use pruning with a wallet but since 0.12 this is now possible but of course even though it doesn't need to keep the entire blockchain it will still need to have processed it all (so it might take a few days to set it up).

I am fairly certain that having watch-only addresses in a wallet with 0.12 should work fine provided that you create them prior to pruning (so best to do that before you even begin syncing).

Unfortunately I don't think it will support adding further watch-only addresses currently (although that should be permitted if you are not requiring a re-scan).

If you send funds to an address for which the private key is unknown (such as 1BitcoinEaterAddressDontSendf59kuE) then the Bitcoin has effectively been "destroyed" (as it can never be recovered).

This idea is actually used by some "proof of burn" implementations (such as Counterparty).

I think the OP wanted to mix a seeded wallet with watch only addresses which would appear to be not possible in accordance with the FAQ (so he would need to create two separate wallets).

Now that Bitcoin supports "pruning" (with a wallet) perhaps the OP should consider using Bitcoin Core instead of Electrum (that should let you create a mixed wallet although you would lose the ability to restore from a seed so you'd have to import all the private keys into a new Bitcoin Core wallet and then be sure to create regular backups of that wallet).

They simply don't care - they take money and publish crap news - do you not understand that (it's the model that most of the world's media uses these days)?

A key file that is only generated the first time that the CIYAM application server is run is called ciyam_server.sid and this file is unique to every CIYAM system and is used as a source of entropy for encryption (technically it is what is known a UUID).

Backing up this file is essential if you are going to be able to restore a CIYAM system in case of it being damaged and it is also essential if you were wanting to migrate to new hardware so a commit was pushed today that will display a "fingerprint" of this UUID the first time that you run Meta (which you should record as well as more importantly making sure that you have backed up the ciyam_server.sid file).

The next important focus is going to be on extending the Wallet package to be able to work with Atomic Cross-Chain Transfer transactions (that use CLTV).

Why would you doubt that?

(most of the websites like it publish for a fee and they most often just copy and paste the PR that the person paying to have it published has provided them with)

No - the "importaddress" is for "watch only" addresses (but if you don't provide the rescan parameter to them they'll behave in the same manner so I thought it was relevant to list both of these commands for others that might be following this).

For a private key you just use the "importprivkey" command (adding false after the label).

There is an option to stop it from doing a re-scan (after the private key and label) so for newly created addresses you should use that.

You might want to try one of the wallets that offers "cold storage" as a feature (am pretty sure at least a couple of those exist) and the other thing that might be suitable for you is a hardware device (such as the Trezor).

I understand that dealing with raw txs is "not for the average person" and agree that if you are at all worried about doing that then it would probably be best not to (hopefully at least you've learned a little more about how Bitcoin works at the lower-level although perhaps that is more than you really wanted to learn about that).

I created the CIYAM Safe as a means to securely do "cold storage" and it does work well but it isn't very user friendly (as you're finding out). If someone wanted to help improve the UX then maybe it could be turned into something you'd actually want to use (but unfortunately I am far too busy to do more work on that at the moment).

I'm not familiar with the other tool - but unless there was a copy and paste error that would seemingly indicate the UTXO was somehow non-standard (is it supposed to just be a simple P2PKH UTXO we are talking about?).

You'll need to use bitcoin-qt at least in order to execute the "createrawtransaction" command (that webpage can't create a raw tx itself) and yes it is just the hex string after the HASH160 that is what you need for the "Script Public Key" field (conveniently you can just double click on it to highlight it for copying and pasting).

The final result will be a "signrawtransaction" command which you would then feed into your offline Bitcoin software (that has the private key).

The QR code stuff is not necessary (but is arguably the most secure way that you can move the "signrawtransaction" information from online to offline).

If not using QR codes then you'd most likely want to perhaps use a new USB flash drive to move the information (remembering also that you'll need to move the signed raw transaction hex code back).

You can push the signed raw transaction using: https://blockchain.info/pushtx

Read above (I edited it - sorry it takes a bit of time to explain properly).


Indeed this is a very simplistic approach that only expects to use one output (so whatever input value that is not sent to the output is the fee amount).

If we fill in the remaining fields at the top of the helper page with 1BTCeX2cQJCgWFttvoWQWPfBaY7dKFNu3v as the Destination Address and 0.01 as the Amount of BTC to Send and then click on the Create Raw Transaction Command button you'll see the following appear below that button:


Now that is what you'd then need to copy and paste into the bitcoin-qt Help->Debug Window->Console window in order to get the raw transaction hex bytes (or use bitcoin-cli to execute the same command).

You would then copy and paste that hex response into the Raw Tx field below and now we come to the Script Public Key part.

To find that we go back to the blockchain.info tx page and scroll down to the Output Scripts part (at the bottom of the page) where you see the following:


You simply copy and paste from the first output (which is vout 0) the hex stuff in the middle (so 06c1991c6466a550b66931ea48970cfd17ff51b3) and then click on the "Sign Raw Transaction Info" button to create the "signrawtransaction" command.

Assuming you've done this you'll notice this:


Which identifies a UTXO of 0.01317234 for the 1ciyam address.

Because that UTXO is the "first output" then its "vout" number is 0 (if the second one was the unspent output then its vout would be 1).

The txid is 135e55010a9caccd412d2c793a18236e9eebbb38412e97dca2b09aa8c354e1c0 for this tx (you can copy and paste that from blockchain.info).

So back in the "helper" page we paste in the txid where it asks for:


and we type in 0 where it asks for:


(hope you are still with me this far)