Search content
Sort by

Showing 12 of 12 results by burstcoin
Post
Topic
Board Altcoin Discussion
Re: Understanding the Automated Transaction system (AT)
by
burstcoin
on 17/02/2015, 19:52:44 UTC
My AT debugger is now on github here: https://github.com/BurstProject/ATDebugger

You can load AT source and run it, set breakpoints, step through it, and view and edit variables.
Post
Topic
Board Altcoin Discussion
Re: Understanding the Automated Transaction system (AT)
by
burstcoin
on 17/02/2015, 18:39:33 UTC
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).


Even "display only" changes can be dangerous, such as swapping the labels on buttons to make users choose the wrong choice.

Any sort of offering multiple interfaces complicates things for the end user, who is most likely to accept the most recent version without considering the consequences or comparing the differences. People are already blindly trusting ATs that they haven't looked at the code at, and I wouldn't expect any better for interface metadata.
Post
Topic
Board Altcoin Discussion
Re: Understanding the Automated Transaction system (AT)
by
burstcoin
on 17/02/2015, 18:06:27 UTC
In thinking about the UI we have made some interesting observations.

Firstly the "code" for an AT cannot be changed (otherwise you could never trust it and basically the main point of ATs is that can act as entities that require no trust beyond understanding their code) but it is possible that the UI could be improved (without changing any of the machine code of that AT).

How this is best handled is still something that requires some consideration but it does make sense that the UI might be able to be upgraded despite the fact that the AT machine code cannot be.


It seems to me that if the ui is intended to be a reliable method of viewing and interacting the AT, the ui should not be updatable. If the ui can be swapped out and show different variables or send a different message when a button is clicked it could cause a user to perform unintended actions or make decisions on wrong information even if the AT and ui has been previously confirmed to work as expected.
Post
Topic
Board Altcoin Discussion
Re: Understanding the Automated Transaction system (AT)
by
burstcoin
on 16/02/2015, 01:18:20 UTC
an attack to recurrence ability because resources are not infinite.

Try creating an "infinite loop" AT - I'll even give you the machine code for that here:

Code:
1A000000

Now see what damage you can do with it. Smiley

(hint - you can't do any more damage with that than any other sort of DoS type of attack on the network)


ok, will try it! thank you!  Wink

That code is missing a byte on the end, should have 8 0s, not 6. Also if entered into burst the parser assumes lowercase on the hex, so 1a00000000 is correct.

Here's what would happen if that was submitted on burst(or any other coin that implemented AT):

that hex is the equivelant of JMP 0 (jump to first position, which is that same instruction again)
once submitted to the network, the AT will be created and not do anything yet.
Once funds are sent to it, it will run the loop, subtracting a step fee each time it executes that instruction until it runs out of funds or hits the max steps for one block.
If the max steps were hit, it will continue the next block.
Once the funds have been used up it will stall until more are sent.

In burst it has a per block limit of 2000 steps, with normal operations counting as 1 step, and api calls counting as 10 steps, so it could run 2000 iterations per block, costing 200 burst per block until it is drained.

Due to the step costs, it would be much more effective and cheaper to attempt to dos the network by spamming it with normal transactions than with loops like that.
Post
Topic
Board Altcoin Discussion
Re: Understanding the Automated Transaction system (AT)
by
burstcoin
on 11/02/2015, 16:37:44 UTC
I'd like to give/explain another AT example.

This is AT code for 'fund management'. The AT will store coins, and have 5 authorized users. If 3 of the 5 users send it the same message containing a destination address and an amount, the AT will make a transaction of that amount to that address. If no funds are transfered out for a set amount of time, the AT can be sent a message and the AT will assume it became inaccessable(lost keys, etc), and transfer it's funds to a set address.

Code:
FUN @txIterTime get_Block_Timestamp
^declare scratch
^declare counter

at the top we store the current time for use when iterating transactions.
declare can be used to force variable in specific positions, which can be useful to force variables to the begining if you want to pass initial data on at creation to have them initialized before the AT starts, but we don't do that here, so it's only for demo puposes

SET @numUsers #0000000000000005
SET @neededVotes #0000000000000003
SET @dormantTransferAddress #0000000000000000
SET @dormantTransferMinutes #0000000000000028

we set up some constants used, num users, num votes needed, address to tranfer for inactivity, and minutes of inactivity until transfer(should be much higher, but had it low for testing)

SET @dormantDeadline $txIterTime
FUN @dormantDeadline add_Minutes_to_Timestamp $dormantDeadline $dormantTransferMinutes

we set a deadline for when we'll transfer to fallback if no transfers out occur

^allocate allowedUsers 5
^allocate votesAccount 5
^allocate votesAmount 5

allocate sets aside the specified number of spaces and also adds a SET command setting the variable name specified to the starting address of the block so it can be used as a pointer to an array

^comment set user ids in scratch assignments
CLR @counter
SET @scratch #a9d3c7e1052e59b6
SET @($allowedUsers + $counter) $scratch
INC @counter
SET @scratch #d588a72e511f576a
SET @($allowedUsers + $counter) $scratch
INC @counter
SET @scratch #878344bc465ee397
SET @($allowedUsers + $counter) $scratch
INC @counter
SET @scratch #5b4a79c0ad8542ea
SET @($allowedUsers + $counter) $scratch
INC @counter
SET @scratch #fca2612346d6d33b
SET @($allowedUsers + $counter) $scratch
^comment end user id assignments

here we just hardcoded some user ids. for demo purposes these are the id numbers for burst accounts with passphrases a, as, asd, asdf, and asdfg.

ERR :dormantTransfer

we set an error handler. if for some reason the at get stuck and is unable to continue(trying to access address out of address space, divide by 0, etc), it will jump there instead of dieing. The risk of something like that happening here is low due to the simplicity of this at, but it's always a good idea to have a handler dumping the coins somewhere, otherwise they'll all end up in transaction fees going to the miners if you did make a mistake somewhere

PCS

pcs sets a new start point. the AT will resume from here instead of the top when we do finish calls, skipping over the initialization.

txloop:
FUN A_to_Tx_after_Timestamp $txIterTime
FUN @scratch check_A_Is_Zero
FIZ $scratch
FUN @txIterTime get_Timestamp_for_Tx_in_A
FUN @scratch get_Type_for_Tx_in_A
BZR $scratch :txloop

here we have a loop that tries to get the next transaction. an id of 0 is returned if there is none, so we finish if none was retrieved(FIZ = finish if zero). if we did get a tx id, we store the timestamp to use for the next tx retrieval attempt, and then check what type of tx we have. a normal payment is 0, but if there is a message attached it is a type 1. we ignore normal payments transfering funds in, but continue on processing if there is a message

CLR @counter
FUN B_to_Address_of_Tx_in_A
FUN @address get_B1
findUserLoop:
SET @scratch $($allowedUsers + $counter)
BEQ $address $scratch :foundUser
INC @counter
BLT $counter $numUsers :findUserLoop

here we check to see if the user is on the authorized list. we retrieve the address who sent us the tx, and loop through authorized users, and jump to :founduser if we found them in the list

^comment check dormant time
BLE $txIterTime $dormantDeadline :notFoundUser
JMP :dormantTransfer
notFoundUser:
JMP :txloop

if the user wasn't found, we check the timestamp against the inactivity timestamp. due to a limit on the distance a branch op can jump and limitations of the currently available assembler, a workaround needed to be used here of branching over a jmp. the most recent but not yet publically available version can automatically convert too far branches to branch jmp combinations, so this is a temporary issue
if the inactivity deadline is up, we jump to :dormanttransfer, and if not we return to the tx loop.

foundUser:
SET @userIndex $counter
FUN message_from_Tx_in_A_to_B
FUN @address get_B1
FUN @amount get_B2
SET @($votesAccount + $userIndex) $address
SET @($votesAmount + $userIndex) $amount

if the user was found in the authorized list, we save the counter from the loop to use as the array index for that user's state. We get their message and save the intended destination and amount as that user's current vote

CLR @voteCount
CLR @counter
countVotesLoop:
SET @scratch $($votesAccount + $counter)
BNE $scratch $address :notSameVote
SET @scratch $($votesAmount + $counter)
BNE $scratch $amount :notSameVote
INC @voteCount
notSameVote:
INC @counter
BLT $counter $numUsers :countVotesLoop
BGE $voteCount $neededVotes :votePassed
JMP :txloop

now we loop through all the votes, and count up the amount which are identical to the one we just recorded. If the amoount is at least the threshold specified in the constants at the top, we jump to :votePassed, otherwise we head back to the tx loop

votePassed:
FUN clear_B
FUN set_B1 $address
FUN send_to_Address_in_B $amount

when the vote is passed, we send that amount

CLR @counter
CLR @scratch
clearLoop:
SET @($votesAccount + $counter) $scratch
SET @($votesAmount + $counter) $scratch
INC @counter
BLT $counter $numUsers :clearLoop

we clear out all the votes after a send

^comment update dormant transfer deadline
SET @dormantDeadline $txIterTime
FUN @dormantDeadline add_Minutes_to_Timestamp $dormantDeadline $dormantTransferMinutes
JMP :txloop

then we set a new inactivity deadline, and head back to the tx loop

dormantTransfer:
FUN clear_B
FUN set_B1 $dormantTransferAddress
PCS
sendAll:
FUN send_All_to_Address_in_B
JMP :sendAll

if the inactivity deadline runs out a jump from above can take us here, and this is also the error handler. we set the fallback address as destination, and put ourselves in an infinite loop sending there. the script will halt due to lack of funds immediatly after the send, so it will only get activated when it receives more, which it will then proceed to send, then halt
Post
Topic
Board Altcoin Discussion
Re: AT can be used to anonymize inter-blockchain transfers (who would have thought?)
by
burstcoin
on 15/12/2014, 10:57:11 UTC
I don't know if someone's made better tools, but I just pushed onto github a basic AT assembler I hacked together somewhere around 1 - 2 weeks ago: https://github.com/BurstProject/ATAssembler/blob/master/src/scala/ATAssembler.scala

No docs on it, but for an example I was using this AT for to stress test API call abuse on testnet is:
Code:
start:
FUN @createtime get_Creation_Timestamp
SET @currenttime $createtime
toploop:
FUN A_to_Tx_after_Timestamp $currenttime
FUN @aiszero check_A_Is_Zero
BZR $aiszero :start
FUN @currenttime get_Timestamp_for_Tx_in_A
JMP :toploop
Post
Topic
Board Altcoin Discussion
Re: AT can be used to anonymize inter-blockchain transfers (who would have thought?)
by
burstcoin
on 15/12/2014, 06:49:06 UTC
I was actually intending the + to mean concat, although combining them with a different operator would work also to keep it to 32 bytes, but I think xor would be a better choice than addition anyway, so no 256 bit math operations are required.

Yes - so perhaps we should add XOR_A_with_B and XOR_B_with_A to the API (as these will be very easy to implement).
Sounds good, I'll do this right now.

Sending 2 separate messages for the case of having to provide secrets 1 and 3 would be another alternative to handling compatibility with btc clones,

I think sending two messages could be problematic as it opens up a potential attack vector where others might try to inject a message *between the two*.
That could be avoided by hardcoding an address the messages must be received from. I do agree that it is a less desirable setup, but some may prefer having a higher level of security.
Post
Topic
Board Altcoin Discussion
Re: AT can be used to anonymize inter-blockchain transfers (who would have thought?)
by
burstcoin
on 15/12/2014, 06:30:59 UTC
Party1 makes secret1 and secret2.
Party2 makes secret3.
Party1 calculates sha256(secret1) and sends it to Party2.
Party2 combines it with secret3 to calculate sha256(secret3 + sha256(secret1)) and sends it to Party1
Party1 creates an AT that releases on either secret2 or (secret1 with secret3).
Party2 creates an AT that releases on secret1.
Party1 releases Party2's AT using secret1.
If Party1 is honest, Party1 provides Party2 with secret2 which can be used to release Party1's AT without leaving a link to Party2's AT.
If Party1 is dishonest and does not provide secret2, Party2 can still retrieve their funds with secret1 that was used to release their AT along with secret3, however there will be a link left in the blockchain, as both ATs will have received secret1.

I think I get this - so: sha256(secret3 + sha256(secret1)) is what Party1's AT would literally have to have coded (with a test that the result of said calculation == hard-coded value that was passed to Party1 by Party2).

If we added some 256 bit math functions (such as Add_A_To_B which is described in the API docco although it was not expected to be implemented until a later point in time) then we would be able to do this.

In order for "two secrets" to be passed in the one message it'd probably require that secret1 and secret3 would need to be both 16 bytes rather than 32 (I don't think that is really an issue as 16 bytes is still secure enough). The message limitation of 32 bytes is in order for AT to work on Bitcoin clones (messages being implemented as OP_RETURN values).
I was actually intending the + to mean concat, although combining them with a different operator would work also to keep it to 32 bytes, but I think xor would be a better choice than addition anyway, so no 256 bit math operations are required.

Sending 2 separate messages for the case of having to provide secrets 1 and 3 would be another alternative to handling compatibility with btc clones, although having an extra api call that retrieves messages without the size restriction might be good also so you only have to work within the limitations of the coins you are actually transferring between.
Post
Topic
Board Altcoin Discussion
Re: AT can be used to anonymize inter-blockchain transfers (who would have thought?)
by
burstcoin
on 14/12/2014, 19:43:02 UTC
I may be missing something, but I don't see how this technique is useful. The point of atomic cross chain transactions is that neither party needs to trust the other one. The 2nd party(who does not have the secret) is willing to create an AT that releases the funds when a secret he does not know is provided because he knows that when it is released he will be able to see and use that secret to release the other AT. If the hashes in the ATs are different, he no longer has a guarantee that his AT being released will provide him with the required information to release the other one.

A possible way to allow different hashes would be to use ATs that check sha256(salt + sha256(secret)) with a different salt for each AT, since the creator can reveal sha256(secret) to the 2nd party before the ATs are created to prove that the same secret will release both ATs, however since the same secret would still be used for both ATs, there would still be a clear link.

It seems to me that this would require one party to be trusted, in which case it offers no advantage over sending ordinary transactions.

EDIT: After thinking more about this, I think this might be doable without links with an extra release condition, such as the following scheme:
Party1 makes secret1 and secret2.
Party2 makes secret3.
Party1 calculates sha256(secret1) and sends it to Party2.
Party2 combines it with secret3 to calculate sha256(secret3 + sha256(secret1)) and sends it to Party1
Party1 creates an AT that releases on either secret2 or (secret1 with secret3).
Party2 creates an AT that releases on secret1.
Party1 releases Party2's AT using secret1.
If Party1 is honest, Party1 provides Party2 with secret2 which can be used to release Party1's AT without leaving a link to Party2's AT.
If Party1 is dishonest and does not provide secret2, Party2 can still retrieve their funds with secret1 that was used to release their AT along with secret3, however there will be a link left in the blockchain, as both ATs will have received secret1.
Post
Topic
Board Announcements (Altcoins)
Re: [PRE-ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre
by
burstcoin
on 10/08/2014, 13:51:42 UTC
So for instance would 1Tb be the equivalent of double the speed of 500Gb?

Your HDD space is like your hashrate, so as much as you're willing to use.

Exactly.

Will the miner be able to use USB connected HDD?

USB3 ones are fine, I've tried them on the testnet. I'm guessing USB2 might not have a high enough transfer speed, but I haven't testing one.
Post
Topic
Board Announcements (Altcoins)
Re: [PRE-ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre
by
burstcoin
on 10/08/2014, 10:54:32 UTC
Looks interesting. How much HDD space is required?
Your HDD space is like your hashrate, so as much as you're willing to use.
Post
Topic
Board Announcements (Altcoins)
Topic OP
[ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000
by
burstcoin
on 10/08/2014, 03:16:15 UTC


A short Introduction to BURST's POC mining
Burst uses a new algorithm for proof of hdd capacity (POC) mining. Miners pre-generate chunks of data known as 'plots' which are then saved to disk. The number of plots you store is effectively your mining speed. Every block the miner will skim through the saved plots, and come up with an amount of time until it is able to mine a block if another block hasn't yet been found. After reading through the plots is complete, your hardware can idle until the newest block.




sha256: b0008bc63aab921ef427b6a9c817d8747cd34252560996343c4183ddfb6fad98
Github: https://github.com/BurstProject/burstcoin

Alternative wallets: 

Multi OS:
Download AIO Wallet V1.2.3 Win/Linux/MacOS with Blockchain (21.04.15) and Addons

After running wallet, access it through a web browser at http://localhost:8125 When upgrading wallet, move burst_db folder into new wallet folder to avoid re-downloading the blockchain. For detailed instructions, see Guides below.

Windows:
Download Windows Wallet (Client) based on AIO Wallet V1.2.3   

WebWallet:
https://wallet.burst.city:8125/index.html


Websites

EN: http://burstcoin.info
EN: http://www.burstcoin.sk
FR: http://www.burstcoin.fr
DE: http://www.burstcoin.de
JP: http://www.burstcoin.jp
CN: http://www.burstcoin.cn
 
FB: https://www.facebook.com/burstcoin.sk
Slack: http://burstcoin.slack.com - Join the Discussion!


Guides for BURST mining

Install the Windows wallet (by bobafett)

Install the Linux wallet (by bobafett)

Basics Burst Mining (by bobafett)

Mining with Windows Part 1: Plotting (by bobafett)

Mining with Windows Part 2: Solomining (by bobafett)

Mining with Windows Part 3: Poolmining (by bobafett)

Mining with Windows Part 4: Plots optimizing (by bobafett)

Mining with Windows Part 5: Solomining with more PCs that point to one PC with wallet (by bobafett)



Windows mining guide (thanks to crowetic)


Plotters


Miners

Blago’s Windows Miner
(source: https://github.com/Blagodarenko/miner-burst)

luxes’s GPU Miner for Win/Linux/MacOS

Uray's Miner
Linux x64 OSX x64 Windows x64
(source: https://github.com/uraymeiviar/burst-miner)

dcct's c miner for Linux

Dev's POCMiner in java



Pool Mining
Warning: there is no standard protocol for pools at this time, so different pools require different miners.

dev's pools
v2 pool. allows you to use solo plots:
https://bitcointalk.org/index.php?topic=731923.msg8604606#msg8604606
v1 pool, requires you generate plots for this pool only usable there: https://bitcointalk.org/index.php?topic=731923.msg8448276#msg8448276

uray's US, SG and EU pools (allows solo plots):
https://mining.burstcoin.io

Irontiga and Crowetic's ( http://byte.enterprises ) v2 pool (allows solo plots and ANY MINER ((custom source)):
http://burst.ninja

koko2530's v2 pool (allows solo plots; based on uray's source):
http://cryptomining.farm/

Elmit's v2 pool in Singapore (allows solo plots; based on uray's source):
http://mininghere.com:8001/

PCFiL's v2 pool (allows solo plots; based on uray's source):
http://burst.poolto.be:88

Italian pool v2 pool (allows solo plots; based on uray's source):
http://pool.burstcoin.it/

Burstcoin.de Pool (allows solo plots; based on uray's source):
http://pool.burstcoin.de/








IRC:
Freenode: #burst-coin

Reddit:
https://www.reddit.com/r/burstcoin/

Mining Calculator:
https://bchain.info/BURST/tools/calculator

Block Explorers:
http://burstcoin.eu/
http://burst.cryptoport.io/
blockex.burstcoin.info




Bounty:
none currently



















Miners generate and cache chunks of data known as 'plots', which are divided into 4096 portions known as 'scoops'. Plots are generated by taking a public address and a nonce, then hashing it, pre-appending the resulting hash, repeating the hash-pre-append cycle many times, and then hashing the whole thing and xor'ing the last hash with the whole thing.

Plots are staggered together so chunks of the same scoop number are together, then written to disk.
Each block has a generation signature which is derived only from the previous block's generation signature and miner, so it is difficult to manipulate.

When mining, the scoop number to be used for a block is derived from the generation signature and the block height, so the miner reads all relevant scoops(each plot will have 1 relevant scoop, and staggering allows for larger sequential read with less seeking) Only 0.024% of the stored data will need to be read each block.

The generation signature is hashed with each scoop. 8 bytes are taken from the hash, then divided by a scaling factor (inverse difficulty). The resulting number is a number of seconds. If that many seconds passes since the last block without a new one, the address/nonce combination used to generate that plot/scoop is eligible to announce a new block.

The miner's hardware can just sit idle until either that time or a new block.The address/nonce is included in the block as proof of eligibility, and the block is signed by that address.

Technically, this mining process can be mined POW-style, however mining it as intended will yield thousands of times the hashrate, and your hardware will sit idle most of the time. Continuously hashing until a block is found is unnecessary, as waiting long enough will cause any nonce to eventually become valid.




Flow chart of the process
The plotting part is done once for each nonce, and the results are saved to disk, and the mining reads the saved data from disk.


Emission Rate



Technological RoadMap
Basic pool support (done)
Improved pool support (done)
Advanced transactions(escrow, subscription, reserve funds then transfer not yet known portion later)(some done)
Automated transactions (turing complete smart contracts) (done)
BurstId authentication system
Allow linking BurstId to burst account for transfers with spending limits.
DHT for off-chain services
Off-chain encrypted messaging and voip between burstid accounts
File storage (disclaimer: still figuring out a good way to do this. this will take a while.)





   
Software Development


Windows:
https://github.com/Blagodarenko/miner-burstBlago's Windows Miner
https://github.com/BurstTools/BurstSoftwareBurst Windows Plot Generator for SEE4 / AVX / AVX2
https://github.com/dawallet/burstwindowswalletBurst Wallet for Windows
 
 
Multi / Linux / MacOS:

https://github.com/BurstProjectMain Develeopment: Main Wallet, Java Miner by burstdev, vbcs
http://www.ciyam.org/at/Automated Transactions
https://github.com/bhamongpuPlotGenerator, BurstMine(graphical plotter/miner)
https://github.com/kartojalBurst OS, Burst ARM Tools, DCCT Tools GUI, gpuPlotGenerator
https://github.com/KurairaitoBurst Plot Generator by Kurairaito
https://github.com/Mirkic7Improved Linux Burst Plotter / optimizer / miner
https://github.com/uraymeiviarC Miner, Pool, Block Explorer, Plot Composer (not active anymore, fork?)
 
 







Announcements