The problem is basically achieving ACCT with Bitcoin - the technique that forum member TierNolan outlined is what the ACCT AT was based upon but it relies upon nLockTime which is "non-standard" (until after the time has been reached) so although possible it would be a bit clumsy to do with Bitcoin.

With Qora to Burst it will have a simple UI and work without requiring trust or any centralised website.

The account would be determined as a hash of the actual machine code for the AT (which might also take into account the account of the creator and perhaps some other metadata such as its description, etc. to ensure there should be very little chance that your AT create tx fails due to an existing AT with the same account id).

All initial data for an AT is part of the AT creation tx (so is of course stored in the blockchain) but subsequent state data does not need to be sent around nor stored in the blockchain (just the hash of it does).

AT is actually an extremely "lean and mean" design (and IMO the most efficient Turing complete solution on offer).

To clarify a couple of points - indeed AT stands for Automated Transactions (the "Turing complete" blockchain transaction solution created by CIYAM Developers which is detailed here: http://ciyam.org/at).

As ATs are stored in a blockchain (which is a public ledger) there is simply no way that it can store secrets, however, it can stored "hashes" of secrets which can later be revealed to match (this is the basis of the Atomic Cross-Chain Transfer AT).

Complete anonymity is never going to be possible with ATs but the technology would allow for "mixing" (of same amounts) that would make it impossible to connect inputs to outputs (but development of such an AT will be done after we have implemented and demonstrated ACCT between Qora and Burst).

One key feature of ATs is that they have their own account (so you can send them funds and messages and they can do the same). The AT machine code cannot be changed once the AT has been created so provided you (or someone that you trust) can vet that the AT does what it has been purported to do then it can act as a trustless 3rd party.

Thanks for the suggestions so far - note also that it would be most preferable that I can pay in BTC.

I barely have time to post here so thanks for your "advice" but I'll just keep on working on what I am working on (it isn't really a big deal if I simply stop running Bitcoin Core).

Will lock this topic now as I think it has come to a conclusion.

As stated the slowdown started at least mid last year and upgrading to 0.10.0 hasn't changed anything noticeably in that regard.

For certain using UDP for VPN basically stopped working a few months back (after further "upgrades" to the GCF).

I think probably the best bet for now would be to run locally (not tunneling) with a list of seed nodes within PRC (if any networking expert plans to come to China for a holiday maybe they could have a play "from the inside").

Bitcoin testnet seems to actually work much better (but that maybe simply due to much less traffic).

In general it appears since the latest "upgrades" to the GCF your choice of port matters little. Even my client is now having troubles running a (plain HTTP) web-server (and they have tried using numerous different ports).

For HTTPS that goes "outside" of PRC all traffic appears to be throttled (and often sessions get killed) and within China is basically restricted to certain fixed IP addresses.

Bitcoin traffic appears to have started to be targeted by the GCF around mid last year (although I can't remember for certain exactly when I noticed how slow syncing had become).

Great to see the debugger published!

I have been thinking that we might be wise to add a couple of "end of life" variables to the creation data (with constant values for defaults) in order to provide a way that ATs can actually become "de-activated" (with any tx attempting to send simply becoming an invalid tx from that point on).

One might be an absolute block number to cease being valid (default to zero meaning lasts forever as is currently the case) and the second would be a maximum blocks for inactivity (and as we haven't released any "dormant funds" ATs into the wild yet this value might be fairly small by default - say a few thousand blocks).

Not only would this provide a natural way to "clean up" old CFs that are just hanging around for no further real purpose (such as say a "2015 NY Conference Airfare" AT) but will also allow a neater way to create CFs that might simply stop functioning after their deadline has been reached (rather than continue as a donation as it doesn't always make sense for it to work that way).

I'd think that in the UI ATs which are inactive would appear "disabled" and after they have been inactive for a period of time (say a week?) then they would cease to be display at all (and can be removed from any DB index).

I realise that this sort of change would introduce a fork risk so it would of course need to be introduced at a particular block height to minimise that potential problem (it would also need to be decided where any remaining balance for the AT gets sent).

The DNS lookup filtering was what they did 10 years ago - they have moved on a long way since then.

Now if you tunnel to outside it *can tell* no matter what port you use and it will simply throttle you down to the 1980's (if it doesn't kill you with purposely injected bad packets).

HK is *not China* (in terms of the GCF).

The GCF does not operate in HK so anything you have in HK is *useless* in mainland China.

Perhaps you don't understand that I cannot even do decent internet speeds to HK?

SSL VPNs are blocked (apart from a few very expensive ones - you can probably understand how that works) and even ones using UDP don't work any better now (or ICMP if you're thinking they haven't worked out that already).


Tunnels work but are "slowed down" to the point of 9600 baud in general (as soon as the traffic goes outside of China). The GCF *detects* encryption and either "kills it" or "slows it down to a snail's pace" (I have one other way around it but I am not going to publish that).

The 3rd world war *is the internet* and I am seeing the "front line" (it will become more apparent to others in the next few years I think).

I do get the concern and would not protest if we decide that "sticking to the initial UI" is the rule.

Whether there is any reasonable way to upgrade UI (beyond the generic side) is perhaps not something to be considering at this stage anyway (I think if we get the metadata approach right we hopefully won't have any real problems).

Indeed I do think this is a complicated area as you would not want the user to be "tricked" by a new UI that apparently "changes the rules" (although the underlying rules in the AT themselves cannot be changed).

For sure I would not want to see UI upgraded "automatically" (it would need to be up to each user to decide) and perhaps there would need to even some sort of majority agreement amongst nodes to accept any change.

The case in point that lead me to ponder this was the CF AT which currently displays "Pledge" even when the CF has reached 100% (arguably it should show "Donate" after this point even before the target block is reached).

Such a UI update would not alter the function of the AT at all but I do agree that some other change might not be as acceptable. Another possible idea is that you could choose to use the original UI always (if you don't trust any updated UI).

This is one of the main reasons why I think that UI needs to be implemented using metadata rather than any "code" in the AT.

Also with metadata I think it might be easy enough to recognise "display only" changes (i.e. not functional ones) which should be harmless enough to permit.

Fundamentally the "real interface" is defined by the AT itself in terms of the "txs and messages" it processes - so you could actually allow for multiple UIs for the same AT (none should be able to cause any trouble so let the users work out which they like the most).

I think Vitalik is wise to consider other approaches and (once we publish the paper) I think he might be interested to study what CIYAM has come up with.

We'd love to publish it now but unfortunately CIYAM doesn't have the 15M budget of that project so we have to wait until they have committed before we can "show our cards" (but it will be published prior to the publicly announced release of our blockchain software).

There are ways (and I won't mention any details as this topic is most likely being "watched") but unfortunately unless you have very high-grade commercial internet (not easy to get without a properly registered Chinese company) your bandwidth just ends up being like a 9600 baud modem (i.e. nearly useless).

And people thought I was being "too paranoid" when I created a QR code system for doing offline Bitcoin tx signing (whereas Armory still uses a USB stick).

The key thing that Bitcoin has brought to us is "decentralised consensus" (sometimes called the "Byzantine Generals problem" or perhaps more commonly the "double spending problem").

Prior to Bitcoin there was basically no solution to the dilemma of trust when each node you are connected to could be dishonest. This was the "genius" that Satoshi brought us (he didn't invent anything else really).

The very idea of a blockchain is something that no accountant would ever come up with (as no traditional accounting system has ever worked this way).

Other ways of being able to provide such consensus are now being built and tested and although nothing can ever take away from Satoshi's invention I think that other approaches (that don't need so much energy consumption) will likely end up being the future (although I would not be surprised to see Bitcoin remain as "digital gold" for a very long time).

The PoS approach is not one that I particularly like but there are other approaches (such as Ripple and such as the new proof that CIYAM plans to unveil soon) that hold promise (it's still not clear what method Ethereum plan to launch with).

Won't work here (if you can name it then it is already blocked - the people that do the GCF are aware of every project going on).


Not surprised at all (am probably going to give up trying to run a node myself).


I was hoping that the headers stuff might make some difference (but seemingly not).

Recently I find that Bitcoin Core has become almost unusable in China (due to either direct attacks by the GCF on use of the protocol or indirect attacks on anything that comes from outside of China).

I had hoped the new version would help but after testing it for hours today it is no better (and I don't think I can *ever* catch up the blockchain now without either forking out for an expensive VPN or physically leaving the country).

What the GCF does is attack all traffic it doesn't like (that includes anything encrypted that comes from outside the country and any ports or IP addresses they don't like within the country which of course includes Bitcoin).

It crashes connections regularly (which still results in general protection failures in Bitcoin Core even though I read some of those had been addressed) and makes it impossible to even try and use Bitcoin Core at the same time as use your web browser or nearly anything else (your connections just get stuck in some sort of GCF sticky glue that makes the 1980's seem fast).

I don't know if there is anything that can be done but I do worry that soon there will be very few people running full nodes in China.

Please don't suggest TOR as that doesn't work in China (and 99% of VPN's don't either).

As Bitcoin doesn't encrypt blocks this statement seems to be rather odd - care to explain (or did you just mean to say ECDSA sigs already stored in the blockchain)?