Hmm... I think this silly topic has now started to go too far even for entertainment purposes.

Then unfortunately the only thing to say about that is that you probably shouldn't repeat that (and oops - I just quoted you so now you can't erase it - damn that stupid internet never forgets thing).



And while your at it I guess you would also believe 100% in this: https://en.wikipedia.org/wiki/Russell's_teapot

The fact that they publish nothing about this supposed algorithm suggests that it is in fact a hoax rather than some revolutionary new thing.

It's strange that people will just accept "we can't publish stuff because of X" when in fact they could publish the specific algorithm used (for the supposed video mentioned) without giving away how that algorithm was created (as supposedly the algorithm was simply one of an infinite number that this amazing AI could create).

It's actually a very simple (and I think probably standard) way to check whether an encryption algorithm is badly flawed (i.e. if the encrypted data can be shrunk by any standard algo like gzip then it obviously hasn't been encrypted properly).

Yes - gzip won't do much at all - why don't you try it and see for yourself?


Things like SegWit (you could search to find out if you're interested although I suspect you're just trying to age your account in order to qualify for an ad sig).

Blocks consist of transactions that for the most part are effectively random numbers (such as hashes, public keys and signatures) so they simply won't compress much at all (as you can't in any sensibly usable way compress random information).

The efforts that are going on behind the scenes will make a much bigger difference than any tiny percent you could compress the content of a block.

You would be best advised to never overwrite an existing backup but instead make new backups regularly (just in case something goes wrong with your latest backup there should always be at least one previous one that might help recover funds).

To make it easier to remember what is what you could include the date in the name of the backup.

I am fairly certain that "change addresses" do not appear in that list - but you can see them if you switch on Coin Control and click on the Inputs button in the Send dialog.

In general there is no need to worry about them - just pay attention to your Balance and check your Transactions list (to work out whether or not it is confirmed).

But *do* remember to back up your wallet after every X transactions (for your own piece of mind I'd do that after every few txs but technically X is the number of keys/addresses that have been generated in advance which by default is 100).

A prototype Trade package (for being able to list, locate and lock into ACCT trades) has been developed.

Some screen snapshots can be found here: https://bitcointalk.org/index.php?topic=1316199.msg13571110#msg13571110

Well despite not being convinced that this is going to be a case of "build it and they will come" here are some screenshots of the prototype Trade application (this part will initially be hosted on ciyam.org and would not contain any sensitive information other than addresses and secret hashes).

Firstly "user1" has created a Trade Offer:



and we can see the details of that here:



assuming that they clicked the "Open Offer" button and assuming "user2" had done similar then if we were logged in as "guest" and were wanting to sell some LTC for BTC we would check the list of Open Offers:



Although the offer from "user2" is higher the minimum amount is perhaps more than "guest" has to trade so he clicks on the offer from "user1":



And assuming he clicks the "Create Transaction" button he might create a potential ACCT like this:

Although I think decentralised crypto trading is an important technical achievement the question is whether people are really going to use it.

As time stamps in Bitcoin (and its clones) are not very accurate (two hours variance is allowed) then at a minimum you would want the automatic refund to be at least more than two hours.

Once the P2SH address has been worked out and funds sent to it then the party that is going to reveal the secret isn't going to do so until they see at least one confirmation (and you'd probably be best advised to wait for more than one confirmation in case of a possible re-org) so I can't see a single trade happening much faster than around half an hour (if we are talking about Bitcoin).

My guess is that having to wait half an hour to do a single trade is going to be simply too unattractive to the average Joe who can trust a (unfortunately likely to eventually get hacked and go bankrupt) website with their coins in order to do near instant trading.

Also no matter how much the UI is simplified it will at least require a secret to be provided by one party and then entered by the other which is going to be an extra step for at least the second party (assuming the secret was able to be automatically generated for the first party).

So as much as people are screaming out that they need a decentralised exchange I would have to say that I am not very optimistic that they will actually use what CLTV ACCT will provide.

No-one should ever be trusting a server "not to store private keys" (and no such server should ever even see them) so if that is what they are saying then I would be even more worried about it being a shady operation.

If that was to be of bother to me then I don't think I would have posted.

Welcome to PM me if you like or also to ask questions publicly - as I've not released many details (other than the source code) my project is pretty much "under the radar".

To be 100% clear I have not "nailed it" as I still have a Sybil issue I need to work out (but I think I have come up with some interesting stuff).

I think that the idea of using POW vs. latency is an interesting one (the only really original idea I've noticed in this topic actually).

The design for the CIYAM blockchain works very differently (to everything I've read so far) but it also has not resolved a specific Sybil problem which is why I have taken some interest in this topic (although there is a lot of noise here so I've only decided to post now that it has got a little quieter).

I don't intend to introduce my approach "piecemeal" so no need to worry about that - am just observing and interested to see if anything discussed here will help with the problems that I am trying to solve.

Yup - mostly the ad sig spammers had kept away from the tech. discussion and project boards (where I pretty much only post nowdays) but it appears that now they won't even respect those two boards.

A few improvements were made to the ACCT demo script (https://github.com/ciyam/ciyam/blob/master/src/test_acct_cltv.cin).

Previously the actual "secret in hex bytes" (and its SHA256 hash) were just hard-coded but now after adding some new environment variable transformation functions the secret can be provided like this:


(so it will now automatically work out the hex bytes given an ASCII secret as well as its SHA256 hash)

There is only a technical aspect about "blockchain consensus" (anything else would be basically nonsense as it wouldn't work).

Maybe you need to rethink exactly what it is that you are advocating?

It has been discussed before - the issue is that as a protocol Bitcoin is far more problematic than something like say email where it doesn't really matter if some software works perfectly or not.

For blockchain consensus you need 100% precise behaviour and even languages like C++ are problematic when it comes to that (if Bitcoin were to be compiled with say VC++ you might find some unusual compiler bug/quirk that means it won't agree with the g++ builds).

So I very much doubt we are going to see an RFC that suddenly becomes the definition of Bitcoin's consensus (but the libconsensus stuff is a very good step in that sort of direction).

The concept is related to my own blockchain R&D and so perhaps not relevant to other uses.

If possible the idea would be to create a P2SH address that has this special script in it which can be redeemed if (and only if) the private key holder signs two messages (it is basically a higher-level mechanism to prevent attempts and double-spends in a non-POW implementation).

Assuming we have a simple message such as:

<public key>
<block height>
<signature>

then if a block creator was to create two blocks at the same height (which would require the same public key due to other mechanisms) then if some funds had been stored in the P2SH address to redeem then anyone could take those funds at that point in time.

I think the idea might not be really very practical anyway as the block creator themselves would be the first person to attempt to spend the funds so it is probably going to require a bit more thought.

Hey @DannyHamilton - great to see that you are still here.

I don't think that this is going to be an easy problem to solve and I might offer a BTC reward for the solution (but no point in offering a reward if the problem is not solvable).