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

[fivebells]

Just got burst running.  I chose parameters to run_generate.sh which will fill the drive completely.  Does the generator still delete the generated file if it runs out of space?

[uray]

I have a concern about the Burstcoin mining process and it possibly being susceptible to selfish mining attacks. I'm hoping that the dev, or someone more familiar with the mining process can alleviate my concerns.

Basically, my concern is that a miner might be able to artificially increase their hashrate by manipulating which transactions get included in a block. A malicious miner could find a block, but only include a set of specially created transactions such that it ensures (or at least increases the odds) they find the next block as well.

Am I missing something, or is this a real concern?

Unlike most coins that try to find a nonce where hashing the block contents meets a target, burst includes information proving an address is eligible to mine that block, and then signs it with that address. This allows us to lock down the numbers used in the calculations by only using information from previous blocks in the algorithm. The only information that is used is generation signature, block height, and the user who mined the last block, so the only manipulation possible is to choose not to mine a block you are able to. The generation signature is based on the same values from the block before it. Changing the transactions won't change anything, so that isn't a valid attack vector.

Ok, thanks for the explanation! I think I am getting a better understanding of how it all works.

However, this brings up another concern. Does this mean that the transactions themselves aren't encoded in the blockchain in any way? If that's the case, then it seems it would be trivial to perform double-spends. Sorry if this is a stupid question!

The transactions are in the block, and the block's transactions are part of the hash that is done while the miner is signing the block, it's just that the transactions don't affect whether that miner is eligible to mine that block.

Ah, ok good. So, the transactions are an input into the generation signature, which I think means that the transactions affect which miner is eligible to sign the next block, correct?

If so, it seems a selfish mining attack is still possible, but rather complicated. A malicious miner could choose a transaction set which manipulates the generationSignature such that when they do find a block, they're also almost guaranteed to find the next block. I still feel like I must be missing something :/

Dev, can you comment on this?

generation signature is shabal256(lastblock.generationsignate concat lastblock.miner)
scoop is chosen with shabal256(generationsignature concat blockheight) modulous 4096
deadline is calculated shabal256(scoopcontents concat generationsignature) / basetarget

transactions are never factored into eligability.

u r genius dev...

thats why we dont have merkleroot to hash...

[twig123]

Trying to use these instructions:http://burstcoin.info/miner.php
...to Pool mine on pool: http://178.62.39.204:8121/

I generated 100GB of plots currently...

Keeps saying "No valid shares to submit to pool", is this normal?

{
  "height": "9105",
  "generationSignature": "ec79ee33a32f2f0b2ff3fe2ab1f6f0f4710333d9ed037f6ea0df6669bb6b861a",
  "baseTarget": "8374378",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9106",
  "generationSignature": "3bb1b78101c19fa7418c1418c469b51573235759db1713bc0ec4f9c32c2df69b",
  "baseTarget": "8349171",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9107",
  "generationSignature": "15347af6d03766f2e4cc8079121bb3df57b794a12142497edc3a04e5d1d8bca5",
  "baseTarget": "8277311",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9108",
  "generationSignature": "d6e3889d4421b9a42335f3dc59c0024725eec9d5a079491bf6a85e8b6856363a",
  "baseTarget": "8389409",
  "targetDeadline": "75000"
}
Found pool share: 13991743533807458994:340221
Submitting shares to pool
Received share/s
{
  "height": "9109",
  "generationSignature": "a6b28927f6d90ea94197799c4027e435347e51cc58a49ba4a59f9156f08112c1",
  "baseTarget": "8543315",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9110",
  "generationSignature": "6c60eda6d39341099f03cc99eefe5a280368a55e2604c464579eed4b3f25ce07",
  "baseTarget": "8659262",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9111",
  "generationSignature": "ecee18ed45d053d1626cae495843ceee09d0b3f430866265ea8a05a59bf1059a",
  "baseTarget": "8910974",
  "targetDeadline": "75000"
}
No valid shares to submit to pool

Also, I have a quad-core system, 4GB RAM... I have a 4TB drive that will arrive tomorrow. What are the best settings to generate the Plots for a 4TB drive?

[tacklebox]

what does it mean when it says

Submitting share
<"result": "Passphrase does not match reward recipient">

[twig123]

what does it mean when it says

Submitting share
<"result": "Passphrase does not match reward recipient">

try renaming your passphrases.txt file to passphrases.txt.old then restart your miner

[Dzus1k]

Trying to use these instructions:http://burstcoin.info/miner.php
...to Pool mine on pool: http://178.62.39.204:8121/

I generated 100GB of plots currently...

Keeps saying "No valid shares to submit to pool", is this normal?

{
  "height": "9105",
  "generationSignature": "ec79ee33a32f2f0b2ff3fe2ab1f6f0f4710333d9ed037f6ea0df6669bb6b861a",
  "baseTarget": "8374378",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9106",
  "generationSignature": "3bb1b78101c19fa7418c1418c469b51573235759db1713bc0ec4f9c32c2df69b",
  "baseTarget": "8349171",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9107",
  "generationSignature": "15347af6d03766f2e4cc8079121bb3df57b794a12142497edc3a04e5d1d8bca5",
  "baseTarget": "8277311",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9108",
  "generationSignature": "d6e3889d4421b9a42335f3dc59c0024725eec9d5a079491bf6a85e8b6856363a",
  "baseTarget": "8389409",
  "targetDeadline": "75000"
}
Found pool share: 13991743533807458994:340221
Submitting shares to pool
Received share/s
{
  "height": "9109",
  "generationSignature": "a6b28927f6d90ea94197799c4027e435347e51cc58a49ba4a59f9156f08112c1",
  "baseTarget": "8543315",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9110",
  "generationSignature": "6c60eda6d39341099f03cc99eefe5a280368a55e2604c464579eed4b3f25ce07",
  "baseTarget": "8659262",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9111",
  "generationSignature": "ecee18ed45d053d1626cae495843ceee09d0b3f430866265ea8a05a59bf1059a",
  "baseTarget": "8910974",
  "targetDeadline": "75000"
}
No valid shares to submit to pool

Also, I have a quad-core system, 4GB RAM... I have a 4TB drive that will arrive tomorrow. What are the best settings to generate the Plots for a 4TB drive?

I started also today have 200 GB plot and this fail error message im getting last 6 hours. I think its something wrong with it.

[tacklebox]

what does it mean when it says

Submitting share
<"result": "Passphrase does not match reward recipient">

try renaming your passphrases.txt file to passphrases.txt.old then restart your miner

It say it can't mine without the passprases file

[omgbossis21]

200 gig is nothing when people like cloudshare have 120+ tb plots.  I got 1TB and now get fewer and fewer shares....

[jamoes]

I have a concern about the Burstcoin mining process and it possibly being susceptible to selfish mining attacks. I'm hoping that the dev, or someone more familiar with the mining process can alleviate my concerns.

Basically, my concern is that a miner might be able to artificially increase their hashrate by manipulating which transactions get included in a block. A malicious miner could find a block, but only include a set of specially created transactions such that it ensures (or at least increases the odds) they find the next block as well.

Am I missing something, or is this a real concern?

Unlike most coins that try to find a nonce where hashing the block contents meets a target, burst includes information proving an address is eligible to mine that block, and then signs it with that address. This allows us to lock down the numbers used in the calculations by only using information from previous blocks in the algorithm. The only information that is used is generation signature, block height, and the user who mined the last block, so the only manipulation possible is to choose not to mine a block you are able to. The generation signature is based on the same values from the block before it. Changing the transactions won't change anything, so that isn't a valid attack vector.

Ok, thanks for the explanation! I think I am getting a better understanding of how it all works.

However, this brings up another concern. Does this mean that the transactions themselves aren't encoded in the blockchain in any way? If that's the case, then it seems it would be trivial to perform double-spends. Sorry if this is a stupid question!

The transactions are in the block, and the block's transactions are part of the hash that is done while the miner is signing the block, it's just that the transactions don't affect whether that miner is eligible to mine that block.

Ah, ok good. So, the transactions are an input into the generation signature, which I think means that the transactions affect which miner is eligible to sign the next block, correct?

If so, it seems a selfish mining attack is still possible, but rather complicated. A malicious miner could choose a transaction set which manipulates the generationSignature such that when they do find a block, they're also almost guaranteed to find the next block. I still feel like I must be missing something :/

Dev, can you comment on this?

generation signature is shabal256(lastblock.generationsignate concat lastblock.miner)
scoop is chosen with shabal256(generationsignature concat blockheight) modulous 4096
deadline is calculated shabal256(scoopcontents concat generationsignature) / basetarget

transactions are never factored into eligability.

OK, I think I finally get it now! Thanks for your patience and continued explanations. Please let me know if the following is correct:

There are two signatures:
  - The blockSignature, which the account owner must sign. This signature signs the entire block, which includes the transaction hashes, as well as all other pertinent data.
 - The generationSignature, which the account owner must also sign. This signature only signs the previous generationSignature as well as the block height and previous block's account address.

So, double spending is prevented by assuming that the same entity won't be able to mine more than a few blocks in a row. However, this is different than bitcoin which actually includes the transaction hashes in the generation signature. As a result, if the same entity does happen to mine multiple burstcoin blocks in a row, it is costless for them to modify the history of transactions by simply modifying the blockSignature. Of course, after 10 of so blocks, the odds of the same entity mining all blocks is very very low.

Also, as a corollary, it also seems that a burstcoin transaction with just 1 confirmation is much less secure than a bitcoin transaction with 1 confirmation. It's possible for a malicious miner to create multiple versions of a block, all which spend their burstcoin differently, and then broadcast each version of the block to different portions of the network. Of course, as soon as another block is found by a different entity, all but one malicious block will be dropped. Basically, it seems that 1 confirmation in burstcoin is analogous security-wise to zero confirmations in bitcoin.

Is my understanding correct now? Thanks again for your continued explanations! Assuming you confirm that I'm right, I think my understanding is now strong enough to confidently explain this all to others.

[tacklebox]

Is there anyway to confirm that i'm mining and it's going towards my account

[sscott1958]

Concerning uray's v2 pool:


Whenever I try the reward assignment I enter my passcode with the number listed on the pool and I get the following error message:

{"errorCode":5,"errorDescription":"Unknown account"}

I searched on this message but no hits so I am asking what am I doing wrong?

Thanks

Steve Scott

[familiaverde]

Concerning uray's v2 pool:


Whenever I try the reward assignment I enter my passcode with the number listed on the pool and I get the following error message:

{"errorCode":5,"errorDescription":"Unknown account"}

I searched on this message but no hits so I am asking what am I doing wrong?

Thanks

Steve Scott

Do u have a at least 2 BURST in your account ? if not u cannot mine ... serch the forum for the faucet ..is 2,3 pagaes back i think

[tacklebox]

here's the faucet: http://burstfaucet.com/  type in your ID and you'll receive 2 burst

[tyson187]

How long will it take before someone makes a Burst clone with POS , is that even possible ?

[familiaverde]

How long will it take before someone makes a Burst clone with POS , is that even possible ?

the exact time untill next clone was made after Litecoin was on Scrypt mining

[Irontiga]

Trying to use these instructions:http://burstcoin.info/miner.php
...to Pool mine on pool: http://178.62.39.204:8121/

I generated 100GB of plots currently...

Keeps saying "No valid shares to submit to pool", is this normal?

{
  "height": "9105",
  "generationSignature": "ec79ee33a32f2f0b2ff3fe2ab1f6f0f4710333d9ed037f6ea0df6669bb6b861a",
  "baseTarget": "8374378",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9106",
  "generationSignature": "3bb1b78101c19fa7418c1418c469b51573235759db1713bc0ec4f9c32c2df69b",
  "baseTarget": "8349171",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9107",
  "generationSignature": "15347af6d03766f2e4cc8079121bb3df57b794a12142497edc3a04e5d1d8bca5",
  "baseTarget": "8277311",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9108",
  "generationSignature": "d6e3889d4421b9a42335f3dc59c0024725eec9d5a079491bf6a85e8b6856363a",
  "baseTarget": "8389409",
  "targetDeadline": "75000"
}
Found pool share: 13991743533807458994:340221
Submitting shares to pool
Received share/s
{
  "height": "9109",
  "generationSignature": "a6b28927f6d90ea94197799c4027e435347e51cc58a49ba4a59f9156f08112c1",
  "baseTarget": "8543315",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9110",
  "generationSignature": "6c60eda6d39341099f03cc99eefe5a280368a55e2604c464579eed4b3f25ce07",
  "baseTarget": "8659262",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9111",
  "generationSignature": "ecee18ed45d053d1626cae495843ceee09d0b3f430866265ea8a05a59bf1059a",
  "baseTarget": "8910974",
  "targetDeadline": "75000"
}
No valid shares to submit to pool

Also, I have a quad-core system, 4GB RAM... I have a 4TB drive that will arrive tomorrow. What are the best settings to generate the Plots for a 4TB drive?

It's fine, you just need to wait till it finds a deadline below 75k

[familiaverde]

Trying to use these instructions:http://burstcoin.info/miner.php
...to Pool mine on pool: http://178.62.39.204:8121/

I generated 100GB of plots currently...

Keeps saying "No valid shares to submit to pool", is this normal?

{
  "height": "9105",
  "generationSignature": "ec79ee33a32f2f0b2ff3fe2ab1f6f0f4710333d9ed037f6ea0df6669bb6b861a",
  "baseTarget": "8374378",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9106",
  "generationSignature": "3bb1b78101c19fa7418c1418c469b51573235759db1713bc0ec4f9c32c2df69b",
  "baseTarget": "8349171",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9107",
  "generationSignature": "15347af6d03766f2e4cc8079121bb3df57b794a12142497edc3a04e5d1d8bca5",
  "baseTarget": "8277311",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9108",
  "generationSignature": "d6e3889d4421b9a42335f3dc59c0024725eec9d5a079491bf6a85e8b6856363a",
  "baseTarget": "8389409",
  "targetDeadline": "75000"
}
Found pool share: 13991743533807458994:340221
Submitting shares to pool
Received share/s
{
  "height": "9109",
  "generationSignature": "a6b28927f6d90ea94197799c4027e435347e51cc58a49ba4a59f9156f08112c1",
  "baseTarget": "8543315",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9110",
  "generationSignature": "6c60eda6d39341099f03cc99eefe5a280368a55e2604c464579eed4b3f25ce07",
  "baseTarget": "8659262",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9111",
  "generationSignature": "ecee18ed45d053d1626cae495843ceee09d0b3f430866265ea8a05a59bf1059a",
  "baseTarget": "8910974",
  "targetDeadline": "75000"
}
No valid shares to submit to pool

Also, I have a quad-core system, 4GB RAM... I have a 4TB drive that will arrive tomorrow. What are the best settings to generate the Plots for a 4TB drive?

It's fine, you just need to wait till it finds a deadline below 75k

}
Found pool share: 13991743533807458994:340221
Submitting shares to pool
Received share/s

This mean u find a deadline below 75k

[burstcoin]

I have a concern about the Burstcoin mining process and it possibly being susceptible to selfish mining attacks. I'm hoping that the dev, or someone more familiar with the mining process can alleviate my concerns.

Basically, my concern is that a miner might be able to artificially increase their hashrate by manipulating which transactions get included in a block. A malicious miner could find a block, but only include a set of specially created transactions such that it ensures (or at least increases the odds) they find the next block as well.

Am I missing something, or is this a real concern?

Unlike most coins that try to find a nonce where hashing the block contents meets a target, burst includes information proving an address is eligible to mine that block, and then signs it with that address. This allows us to lock down the numbers used in the calculations by only using information from previous blocks in the algorithm. The only information that is used is generation signature, block height, and the user who mined the last block, so the only manipulation possible is to choose not to mine a block you are able to. The generation signature is based on the same values from the block before it. Changing the transactions won't change anything, so that isn't a valid attack vector.

Ok, thanks for the explanation! I think I am getting a better understanding of how it all works.

However, this brings up another concern. Does this mean that the transactions themselves aren't encoded in the blockchain in any way? If that's the case, then it seems it would be trivial to perform double-spends. Sorry if this is a stupid question!

The transactions are in the block, and the block's transactions are part of the hash that is done while the miner is signing the block, it's just that the transactions don't affect whether that miner is eligible to mine that block.

Ah, ok good. So, the transactions are an input into the generation signature, which I think means that the transactions affect which miner is eligible to sign the next block, correct?

If so, it seems a selfish mining attack is still possible, but rather complicated. A malicious miner could choose a transaction set which manipulates the generationSignature such that when they do find a block, they're also almost guaranteed to find the next block. I still feel like I must be missing something :/

Dev, can you comment on this?

generation signature is shabal256(lastblock.generationsignate concat lastblock.miner)
scoop is chosen with shabal256(generationsignature concat blockheight) modulous 4096
deadline is calculated shabal256(scoopcontents concat generationsignature) / basetarget

transactions are never factored into eligability.

OK, I think I finally get it now! Thanks for your patience and continued explanations. Please let me know if the following is correct:

There are two signatures:
  - The blockSignature, which the account owner must sign. This signature signs the entire block, which includes the transaction hashes, as well as all other pertinent data.
 - The generationSignature, which the account owner must also sign. This signature only signs the previous generationSignature as well as the block height and previous block's account address.

So, double spending is prevented by assuming that the same entity won't be able to mine more than a few blocks in a row. However, this is different than bitcoin which actually includes the transaction hashes in the generation signature. As a result, if the same entity does happen to mine multiple burstcoin blocks in a row, it is costless for them to modify the history of transactions by simply modifying the blockSignature. Of course, after 10 of so blocks, the odds of the same entity mining all blocks is very very low.

Also, as a corollary, it also seems that a burstcoin transaction with just 1 confirmation is much less secure than a bitcoin transaction with 1 confirmation. It's possible for a malicious miner to create multiple versions of a block, all which spend their burstcoin differently, and then broadcast each version of the block to different portions of the network. Of course, as soon as another block is found by a different entity, all but one malicious block will be dropped. Basically, it seems that 1 confirmation in burstcoin is analogous security-wise to zero confirmations in bitcoin.

Is my understanding correct now? Thanks again for your continued explanations! Assuming you confirm that I'm right, I think my understanding is now strong enough to confidently explain this all to others.

This is correct with 1 exception. generationSignature doesn't need to be actually signed, it's just a hash, and block height isn't factored into generationSignature, only previous generationSignature and previous block's address. Height is only factored in for selecting which scoop to use(which part of the plot data to read)

Trying to use these instructions:http://burstcoin.info/miner.php
...to Pool mine on pool: http://178.62.39.204:8121/

I generated 100GB of plots currently...

Keeps saying "No valid shares to submit to pool", is this normal?

{
  "height": "9105",
  "generationSignature": "ec79ee33a32f2f0b2ff3fe2ab1f6f0f4710333d9ed037f6ea0df6669bb6b861a",
  "baseTarget": "8374378",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9106",
  "generationSignature": "3bb1b78101c19fa7418c1418c469b51573235759db1713bc0ec4f9c32c2df69b",
  "baseTarget": "8349171",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9107",
  "generationSignature": "15347af6d03766f2e4cc8079121bb3df57b794a12142497edc3a04e5d1d8bca5",
  "baseTarget": "8277311",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9108",
  "generationSignature": "d6e3889d4421b9a42335f3dc59c0024725eec9d5a079491bf6a85e8b6856363a",
  "baseTarget": "8389409",
  "targetDeadline": "75000"
}
Found pool share: 13991743533807458994:340221
Submitting shares to pool
Received share/s
{
  "height": "9109",
  "generationSignature": "a6b28927f6d90ea94197799c4027e435347e51cc58a49ba4a59f9156f08112c1",
  "baseTarget": "8543315",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9110",
  "generationSignature": "6c60eda6d39341099f03cc99eefe5a280368a55e2604c464579eed4b3f25ce07",
  "baseTarget": "8659262",
  "targetDeadline": "75000"
}
No valid shares to submit to pool
{
  "height": "9111",
  "generationSignature": "ecee18ed45d053d1626cae495843ceee09d0b3f430866265ea8a05a59bf1059a",
  "baseTarget": "8910974",
  "targetDeadline": "75000"
}
No valid shares to submit to pool

Also, I have a quad-core system, 4GB RAM... I have a 4TB drive that will arrive tomorrow. What are the best settings to generate the Plots for a 4TB drive?

It's fine, you just need to wait till it finds a deadline below 75k

Notice the bolded text. It's working fine, and you have a balance in the pool.

[tyson187]

How long will it take before someone makes a Burst clone with POS , is that even possible ?

the exact time untill next clone was made after Litecoin was on Scrypt mining

I don`t think it will take that long , especially if the chinese see a profit opportunity .

[jamoes]

I have a concern about the Burstcoin mining process and it possibly being susceptible to selfish mining attacks. I'm hoping that the dev, or someone more familiar with the mining process can alleviate my concerns.

Basically, my concern is that a miner might be able to artificially increase their hashrate by manipulating which transactions get included in a block. A malicious miner could find a block, but only include a set of specially created transactions such that it ensures (or at least increases the odds) they find the next block as well.

Am I missing something, or is this a real concern?

Unlike most coins that try to find a nonce where hashing the block contents meets a target, burst includes information proving an address is eligible to mine that block, and then signs it with that address. This allows us to lock down the numbers used in the calculations by only using information from previous blocks in the algorithm. The only information that is used is generation signature, block height, and the user who mined the last block, so the only manipulation possible is to choose not to mine a block you are able to. The generation signature is based on the same values from the block before it. Changing the transactions won't change anything, so that isn't a valid attack vector.

Ok, thanks for the explanation! I think I am getting a better understanding of how it all works.

However, this brings up another concern. Does this mean that the transactions themselves aren't encoded in the blockchain in any way? If that's the case, then it seems it would be trivial to perform double-spends. Sorry if this is a stupid question!

The transactions are in the block, and the block's transactions are part of the hash that is done while the miner is signing the block, it's just that the transactions don't affect whether that miner is eligible to mine that block.

Ah, ok good. So, the transactions are an input into the generation signature, which I think means that the transactions affect which miner is eligible to sign the next block, correct?

If so, it seems a selfish mining attack is still possible, but rather complicated. A malicious miner could choose a transaction set which manipulates the generationSignature such that when they do find a block, they're also almost guaranteed to find the next block. I still feel like I must be missing something :/

Dev, can you comment on this?

generation signature is shabal256(lastblock.generationsignate concat lastblock.miner)
scoop is chosen with shabal256(generationsignature concat blockheight) modulous 4096
deadline is calculated shabal256(scoopcontents concat generationsignature) / basetarget

transactions are never factored into eligability.

OK, I think I finally get it now! Thanks for your patience and continued explanations. Please let me know if the following is correct:

There are two signatures:
  - The blockSignature, which the account owner must sign. This signature signs the entire block, which includes the transaction hashes, as well as all other pertinent data.
 - The generationSignature, which the account owner must also sign. This signature only signs the previous generationSignature as well as the block height and previous block's account address.

So, double spending is prevented by assuming that the same entity won't be able to mine more than a few blocks in a row. However, this is different than bitcoin which actually includes the transaction hashes in the generation signature. As a result, if the same entity does happen to mine multiple burstcoin blocks in a row, it is costless for them to modify the history of transactions by simply modifying the blockSignature. Of course, after 10 of so blocks, the odds of the same entity mining all blocks is very very low.

Also, as a corollary, it also seems that a burstcoin transaction with just 1 confirmation is much less secure than a bitcoin transaction with 1 confirmation. It's possible for a malicious miner to create multiple versions of a block, all which spend their burstcoin differently, and then broadcast each version of the block to different portions of the network. Of course, as soon as another block is found by a different entity, all but one malicious block will be dropped. Basically, it seems that 1 confirmation in burstcoin is analogous security-wise to zero confirmations in bitcoin.

Is my understanding correct now? Thanks again for your continued explanations! Assuming you confirm that I'm right, I think my understanding is now strong enough to confidently explain this all to others.

This is correct with 1 exception. generationSignature doesn't need to be actually signed, it's just a hash, and block height isn't factored into generationSignature, only previous generationSignature and previous block's address. Height is only factored in for selecting which scoop to use(which part of the plot data to read)

Makes sense. Thanks again! I continue to be very confident in burstcoin's long-term success