[ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000

[MamaGoose]

no news about Uray's pools?

[1713582345]

1713582345

[1713582345]

1713582345

[MelodyRowell]

This is such an underrated coin!

[yellowduck2]

This is such an underrated coin!

Its gaining momentum. Hope we can keep it going and make it big next year.


Goal for 2015 , burst to be best coin of the year.

[q327K091]

one word for you there is never going to be an ASIC for it, conceptually impossible, please argue otherwise, you all lucky you (top 100)

[pinballdude]

I just tested Windows 10 tech. preview 64bit, on one of my boxes. The burstcoin wallet and the burstcoin reference miner (the original one, and wallet was 1.1.5) works just fine.

it all works straight away, i didn't have to change anything after upgrading. I upgraded in-place so i could keep settings and stuff.

one noticable difference is that RAM usage was much improved, the windows 7 bug where you suddenly either have exhausted all physical RAM, or is left with a 100GB pagefile and a pretty unresponsive and crashing system is totally gone.  I tried to throw 11 drives at it, totalling i don't know, maybe 30TB or so.  CPU gets maxed out just after a block starts, but that's not really a surpise given more than half of the drives are external USB ones, which utilizes CPU when transferring.

mining speed is comparable to windows 7, when win7 is not going memory berzerk.

Tech. preview is free until end of apr. but of course sort of alpha software so no guarantees that it won't be upgraded the next day and blow up spectacularily.

[pist0la]

Is there a plot optimizer for Windows? I can only find the one for Linux.

10 seconds Googling for "burst plot optimizer":
Plot Optimizer v1.6 - j6jq @ https://burstforum.com/index.php?threads/plot-optimizer-v1-6-j6jq.268/

However, bitshare.com is lame - PM me if you can't download the file and i'll get you v1.5.

you need just to read OP

dcct's plot tools(faster generator, plot optimizer, c miner): https://bitcointalk.org/index.php?topic=731923.msg8879760#msg8879760

Hm, why did I think dcct's tools were only for linux..

Thanks for the info.

[jamoes]

I'm pretty excited about the prospect of Automatic Transactions getting added into Burst. I've been reading up on them, and I'm trying to wrap my head around everything they're capable of. One big question I have is, is possible to use ATs to achieve unlinkability between accounts? (i.e, is it possible to use ATs as a way to increase privacy and anonymity?)

I'm trying to think of ways to use ATs for some sort of automatic CoinJoin, or perhaps an anonymous lottery where the winning account is unknown to any of the participants other than the winner. Has anyone thought about how ATs might solve these problems?

[CIYAM]

I'm trying to think of ways to use ATs for some sort of automatic CoinJoin, or perhaps an anonymous lottery where the winning account is unknown to any of the participants other than the winner. Has anyone thought about how ATs might solve these problems?

Thanks for the interest in AT and hopefully it will be a core feature that a lot of other very useful things can be built on top of.

As AT cannot keep secrets I think a very simple version of what you are wanting is not really going to be possible, however, I can think of one approach that might make it very hard for anyone to "follow the funds" and that is to make a variation of the current "atomic cross-chain transfer" use case (http://ciyam.org/at/at_atomic.html) in which the hash published in the initial AT is not the same as what is used in the other AT (which is created on another blockchain).

The idea would be that the second AT would have a hash that is a function of the first hash (rather than just the secret itself - you'd therefore have to calculate the relevant hash to feed the second AT offlineoffchain). Although when there are very few ATs in existence it would still be easy to track the funds when there are thousands or more of such ATs it would become very hard to work out which transaction matches which (thus starting to approach the plausible deny-ability of CoinJoin assuming the function you used is sufficiently complex enough to not be discovered).

[yellowduck2]

I'm trying to think of ways to use ATs for some sort of automatic CoinJoin, or perhaps an anonymous lottery where the winning account is unknown to any of the participants other than the winner. Has anyone thought about how ATs might solve these problems?

Thanks for the interest in AT and hopefully it will be a core feature that a lot of other very useful things can be built on top of.

As AT cannot keep secrets I think a very simple version of what you are wanting is not really going to be possible, however, I can think of one approach that might make it very hard for anyone to "follow the funds" and that is to make a variation of the current "atomic cross-chain transfer" use case (http://ciyam.org/at/at_atomic.html) in which the hash published in the initial AT is not the same as what is used in the other AT (which is created on another blockchain).

The idea would be that the second AT would have a hash that is a function of the first hash (rather than just the secret itself - you'd therefore have to calculate the relevant hash to feed the second AT offline). Although when there are very few ATs in existence it would still be easy to track the funds when there are thousands or more of such ATs it would become very hard to work out which transaction matches which (thus starting to approach the plausible deny-ability of CoinJoin assuming the function you used is sufficiently complex enough to not be discovered).

WOW. I think u are the first legendary member to speak on this thread !

[jamoes]

Thanks for the interest in AT and hopefully it will be a core feature that a lot of other very useful things can be built on top of.

As AT cannot keep secrets I think a very simple version of what you are wanting is not really going to be possible, however, I can think of one approach that might make it very hard for anyone to "follow the funds" and that is to make a variation of the current "atomic cross-chain transfer" use case (http://ciyam.org/at/at_atomic.html) in which the hash published in the initial AT is not the same as what is used in the other AT (which is created on another blockchain).

The idea would be that the second AT would have a hash that is a function of the first hash (rather than just the secret itself - you'd therefore have to calculate the relevant hash to feed the second AT offline). Although when there are very few ATs in existence it would still be easy to track the funds when there are thousands or more of such ATs it would become very hard to work out which transaction matches which (thus starting to approach the plausible deny-ability of CoinJoin assuming the function you used is sufficiently complex enough to not be discovered).

Very interesting, thanks for the insight. And congrats on nearing completion of getting ATs integrated into Burstcoin!

I like the idea of using the cross-chain transfers mechanism to trade funds between accounts in a way that is nearly unlinkable. It seems like this could even be used to trade unequal amounts, by incorporating randomness into the ATs (users that did this would have to accept a risk that they may lose coins for a given trade, but they should break even in the long run). This would help solve one of the major problems of CoinJoin - that you need to find people that want to trade the exact same amount of coins as you. The only major downside though, is that it still seems to need some sort of other channel of communication in order to communicate the secret function between the 2 parties.

It would be awesome if it were possible to create a lottery AT that uses some sort of zero-knowledge algorithm to choose a winner. The winner could claim their winnings by sending a message to the AT that proves they are the winner without revealing which account they originally sent the coins from. I feel like this should be possible, given that ATs are Turing complete, but I don't have an in-depth enough understanding to really say for sure.

[redHairy]

This is such an underrated coin!

we are all hoping like you!!!

but burst is an investment for the long run...

non for pump&dump!!!

we are waiting for the next dev updates...

some pages ago, i have read who dev is helped from other delvelopers...

so the team it is growing!!!

and this is good!!!

[CIYAM]

My gut feeling is that the mixing approach I've outlined using "atomic cross-chain transfer" is going to be "the only method" for anonymizing but I can see that if we get AT on numerous blockchains then it could become the ultimate "mixing machine".

BTW - props should be for @vbcs and @burstcoin for getting AT integrated with Burst (I only created the specifications and C++ prototype).

[vbcs]

Indeed - this variation of the acct can be used to "mix" the funds. I was always trying to figure out a way to use ATs for anonymity but always had in mind one underlying blockchain, and never thought "mixing" them between different blockchain's. I think this is the only way we can achieve "anonymity" with ATs. This way you still can trace the funds on each blockchain from one account to another, but lose the trail in between the blockchains.

[mczarnek]

Can't you always just send your funds from a Burst like blockchain to a Monero like blockchain, that has anonymity, send money from one account to another one over there, then then send it back over to a Burst blockchain again? Just make sure it's a standard amount of money being sent, such as breaking it into 100 Burst per mix so you can't match amounts.

[burstcoin]

Indeed - this variation of the acct can be used to "mix" the funds. I was always trying to figure out a way to use ATs for anonymity but always had in mind one underlying blockchain, and never thought "mixing" them between different blockchain's. I think this is the only way we can achieve "anonymity" with ATs. This way you still can trace the funds on each blockchain from one account to another, but lose the trail in between the blockchains.

Any method of mixing across multiple chains using ACCTs can also be done on a single chain to obscure things. Amounts can also be broken down by having one or both sides making more than one AT. There doesn't even have to be a corresponding 2nd AT. Someone could just make one side that releases to another address they control, and release it after waiting a while to simulate coins being swapped.

[MelodyRowell]

When is this happening? https://bitcointalk.org/index.php?topic=893271.0 A partnership here would be a prime opportunity.

[vbcs]

Indeed - this variation of the acct can be used to "mix" the funds. I was always trying to figure out a way to use ATs for anonymity but always had in mind one underlying blockchain, and never thought "mixing" them between different blockchain's. I think this is the only way we can achieve "anonymity" with ATs. This way you still can trace the funds on each blockchain from one account to another, but lose the trail in between the blockchains.

Any method of mixing across multiple chains using ACCTs can also be done on a single chain to obscure things. Amounts can also be broken down by having one or both sides making more than one AT. There doesn't even have to be a corresponding 2nd AT. Someone could just make one side that releases to another address they control, and release it after waiting a while to simulate coins being swapped.

Yes you are totally right. Of course the idea to be feasible needs a lot of acct use cases to be running. The more coins support ATs the more feasible it gets to provide anonymity.

[vbcs]

When is this happening? https://bitcointalk.org/index.php?topic=893271.0 A partnership here would be a prime opportunity.

We already work with burstdev from mid November on integrating AT into burst and we are almost ready to release it. Also qora coin will have ATs, so this use case might be out there faster than i thought.

[jamoes]

I've thought about it more, and I think ATs could also be used to create CoinJoin transactions in a trustless manner without requiring any communication channel between users other than the blockchain itself..

The setup: there are two users, Alice and Bob, each have 1000 coins in their two public accounts: account_a and account_b. They both want to do a transaction such that their funds are transferred to anon_account_a and anon_account_b, while keeping it impossible for any observing parties to determine who owns which of the anon accounts. To this this, they could create a special AT:

1) Alice and Bob would each send the AT a message from anon_account_a and anon_account_b. The message would indicate to the AT where to send the funds to after it was fully funded.

2) Next, Alice and Bob would each send their 1000 coins to the AT. If either one fails to send, the AT would just issue a refund after a certain amount of time.

3) After the AT is fully funded, it would disperse the funds to anon_account_a and anon_account_b. Any outside observer would be unable to determine who owns which address.

This technique could easily be expanded upon to any number of people. The only downside to having more accounts participating in the transaction, is an increased risk that someone doesn't fund the AT in step 2.

One major drawback to this whole approach is that the anon_accounts will need to be funded somehow in order to send the message to the AT in step 1. This presents a challenge if you're trying to fund the account for the first time.

Am I missing anything, or is this a viable use-case for Automatic Transactions?

[g00gsy]

Stuck at the first step,

run_dump_address.bat doesnt generate anything in the txt file it makes :/

java installed/win81

anyone know why ?
NM i fixed it, some1 posted instructions for windows users to change java cmd to damn syswow folder :/, removed that and it worked
i also had to change the path in the wallet server batch file too :/

this coin has become a nightmare with a plethora of info about mining, some1 should consolidate it and maybe update the OP, the way it is they will lose a lot of newbies due to the mudbath of info on it...