Changing the block reward would be unfair to anyone who made decisions based on the stated supply and distribution schedule. Nothing is perfectly distributed, but I don't really see it being that bad. Excluding the stuff we can't tell apart sitting in exchanges, the next highest address has a little over 2%. I don't see adding more coins which will probably just end up flooding the market being a solution for anything. Theres a lot of things I would have done differently in retrospect but I don't think block reward is one of them.

The next update or 2 will be some long overdue extra account security features. There will be the ability to authorize another account to spend from an account with spending limits(amount / time)(allow access to your funds while keeping the account its in cold stored or other ), and accounts will be able to be set up for multisig. The authorized spending backend stuff is all done and has been tested successfully on a testnet, but has no user interface yet. Multisig is still in progress. I haven't decided whether those will be released separate or grouped together.
Afterwards AT interfaces will become a priority, and I also plan to do a bit of block header restructuring some time soon(header only validation cannot currently be done, but could be with some restructuring)


None of the PoC2 attempts have worked out well in practice unfortunately. Plotting ends up being horribly slow(much worse than PoC1) and large gains can be had by shaving bits off and brute forcing them with gpus. PoC2 is now on hold until a better solution is found.

Confirming I'm still here. Sorry things have been slow lately.

Looks like I forgot to add the Nxt.java file to the commit. I'll push that right now.

All builds are fine, it's just the version that didn't get pushed, and the posted archive of compiled+source was compiled with and has the correct version number.

Burst 1.2.3

https://mega.co.nz/#!PwwCyBAL!R89Dkzc6cn-tI-5CeNLeceEV7irgU1X4Brs8Lu-JGD8
sha256: b0008bc63aab921ef427b6a9c817d8747cd34252560996343c4183ddfb6fad98

Hard fork at block 92000, so all users must update within the next 5 days, but are recommended to update as soon as possible.

This release fixes bugs with ATs and the asset exchange and changes the windows run.bat to a universal one that doesn't depend on java 7.

The addresses use Reed-Solomon encoding, so making a valid address is not that easy.

Genesis address is BURST-NU58-Z4QR-XXKE-94DHH
It's pubkey is 0000000000000000000000000000000000000000000000000000000000000000

really anything that entirely has numeric meaning(unlikely to have a pubkey found by chance would work)

iirc account 0 is BURST-2222-2222-2222-22222, so that works nicely also.

I think burst.ninja is the only one that cares significantly about historic data. dev v2 only cares about the past hour or so, v1 only cares about the time since it previously found a block, and uray's source used for most pools I thought only cares about it's last few rounds.

Not in place. You can optimize it from one hdd to another.

With more memory it's able to arrange the data better so it can read what it needs with less disk seeking, which is both faster and puts less stress on the hdd.

tex81 is correct. it should say 64 bytes

@funded exists so the interface file can check and display the state of the cf.

sleep is not needed in that end loop since the AT will stop when it has no balance, and send_All_to_Address_in_B will empty the balance, so after that instruction it will stop and only resume if more funds are sent to it.

In the constants.java file add a couple 0s to the end of initial base target.


Did a quick read-through also, and another problem is your usage of send_A_to_Address_in_B. send_A_to_Address_in_B sends a message to address B with the message being in A. send_to_Address_in_B like you used in the other loop is the correct way to send funds.

There's nothing someone can do from you sending coins to yourself.

This initially seemed a bit strange to me also, but it could make sense if for example a large miner wanted to sacrifice a small portion of their coins to try to reduce the amount that gets sold so they can get better prices on the rest of it.

It's assembly language for the AT vm.

Some examples can be found here, https://bitcointalk.org/index.php?topic=949438.msg10408276#msg10408276
and full specs are here http://ciyam.org/at/at.html and http://ciyam.org/at/at_api.html

This is the main thing being worked on currently. I have a site I'm working on which has various AT tools, some simple, and some more advanced. It will have a AT creation tool which will allow you to choose templates and options and it will tell you what to plug into burst to make that AT. There is an AT examine tool which dumps the state of an AT and disassembles tje code so you can see what it does. On the more advances side, there's an in-browser version of the AT assembler, and an editor for creating AT interfaces. In a future update ATs will be able to have interface data attached to them so they can be interacted with without all the extra html file stuff that's currently used. I know the current toolchain is rather ugly for those without knowledge of the internals.

I'm not sure exactly where the limits are on Bitcoin's scripts, but it likely is able to handle at least the simple side of the previously described transfer. Monitoring btc's blockchain would introduce a ton of unwanted traffic, and would only assist in transfering between one coin instead of any.

The transfer is trustless, however either party would be able to expose the exchange, intentionally leaving a link between them if they wanted.

The original(not-mixing) atomic transfer AT works like this

AT code is used with a destination account, refund account and hash supplied. the AT once created and funded will run trustlessly on the blockchain
party1 will create a secret value and the hash of that is what will be used in the ATs
p1 creates an AT with that will release to p2 when supplied with a message that the hash of the message equals the hash it was created with
p2 also creates an AT like that, since they know that if their AT is released they can use message that released it to release the one p1 created
p1 sends the message to p2's AT to get funds, and p2 uses the same message to release p1's AT

now in order to make an anon version, we alter it to use 2 extra secret values, and some more complicated verification.
p1 will make s1 and s2
p2 will make s3
p1 hashes s1 and sends it to p2 who hashes that with s3 and sends it back, so hash(s3 concat hash(s1)) is known
p1 makes an AT that will release with either s2 or both s1 and s3 (the hash in the previous step is embeded, not hashes of s1 and s3 individually)
p2 creates an AT that will release with s1
p1 releases p2's AT by sending it a message with s1
if p1 is honest they will give p2 s2 that can be used to release p1's AT (and using it will have no messages or hashes shared between the ATs)
if p1 is dishonest p2 can still collect their money by getting s1 from the transaction p1 used to release funds, and combining it with s3 and sending that to the AT. In that case s1 will have been sent to both ATs, leaving a link between them

In both of these cases, the ATs can be on different blockchains.


ATs are the most important one, but burst also has built in escrow and subscription(automatically re-occuring transactions)

While not as good as ring-sig or zk methods, it is possible to mix with ATs, swapping coins with yourself or another user on 1 or across multiple blockchains. The algorithm described here: https://bitcointalk.org/index.php?topic=893271.msg9839547#msg9839547 can be done with ATs and can likely be expanded to work with more inputs or outputs.


While hashrate-based block rewards would be interesting to see, unless there was a large amount of use of the coin and transaction fees were significant  I'd guess the market would just get flooded from the never-ending supply being mined and dumped without demand from those hoping for a value increase.

As long as you send a message unencrypted the message will be viewable on the block explorer at burstcoin.eu. send the message anywhere and link them to that transaction on that block explorer

If you receive 1 invalid block from a peer you ip ban them for 10 minutes. You'd need a massive number of ips to attempt an attack like that.