Can anybody confirm developer still working on burst? Do we need community take over of coin?
Confirming I'm still here. Sorry things have been slow lately. Ummm That's it? What are your future plans for the coin? What about binladen saying increase the rewards or he will dump the coin to dust? While the guy has a piss-poor attitude, he does raise some valid points. A lot of people sitting on a lot of coins that were massively mined when block rewards were so much higher and difficulty much lower. Shrinking block rewards are killing the coin because it is making it too hard to mine. People do not want to invest in the coin nor equipment because of all of the large bag holders sitting on their stash. It would be nice to hear you address this. Thank you. 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) No need to change block reward. Just implement PoC2 which suppose to be out soon?
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. |
|
|
|
Can anybody confirm developer still working on burst? Do we need community take over of coin?
Confirming I'm still here. Sorry things have been slow lately. |
|
|
|
Burst 1.2.3https://mega.co.nz/#!PwwCyBAL!R89Dkzc6cn-tI-5CeNLeceEV7irgU1X4Brs8Lu-JGD8sha256: 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. Thanks! I just pulled updates from https://github.com/BurstProject/burstcoinrecompiled and the server shows Burst server 1.2.2 started successfully.
But I see in the logs the 1.2.3 commits. Its because of its still block < 92000 ? 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.3https://mega.co.nz/#!PwwCyBAL!R89Dkzc6cn-tI-5CeNLeceEV7irgU1X4Brs8Lu-JGD8sha256: 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.
|
|
|
|
Hello BURST community !!
Can anyone please guide me on how to create a custom burn address?
Will appreciate your kind help.
bump 0.05 btc to the one who can create it BURST-0000-0000-0000-0000 That is a burn address. Could you swap that BTC into burst and send it to the address in my sig? Thanks! The addresses use Reed-Solomon encoding, so making a valid address is not that easy. |
|
|
|
If vandalay really meant a burn address this would not help completely, as he would have access to it. Well, at least I would not trust a burn address like that, just send coins to genesis acc Can you please elaborate on the genesis account? I know it exists for NXT as well how is it provably unspendable? and what is the public key of the BURST gen account? You guys are sure it works in Burst as well? I could see burstdev having removed it and it just being a regular account.. which has a known password. You should probably test it by sending a couple Burst there before using it as a Burn address. 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. |
|
|
|
How are calculated the pay on the pool ? I see "reward" and "total earned". What is it ?
when the pool forges a block, you get paid out. 60% of the round reward goes to the current round shares, and 40% goes to the historical round shares. So the screen is showing what you'd earn if we were to forge this block - you'd get your reward under current round + reward under historic shares. Total Earned is how much the pool has paid you so far. Ok ! The bigger the pool is, the best it is ? And in this case, what's the best pool ? burst.ninja. It's got what I think is the fairest payout system. Most of the other pools only payout on your historical share, so if you're a small miner and you find a block, you'll get a small payout. ninja payouts on current round + historical, so if a small miner gets a block, they get a large payout for finding it, plus their smaller historical share. 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. |
|
|
|
I've got a little problem when I try to plot. I followed the crowetic's guide and when I set 75% of my memory (the total is 8192 MB so 75% is 6144 Mb), it says me not 6144 MB of memory used but 15XX MB of memory used (I forgot the XX number but it isn't very import, you can see that it isn't the same number). To hit the 6144 MB of memory used, I need to put a number close to 18000. What's the problem ? Can you help me ?
The memory size when ploting is expressed in nonces (256KB) not MB. So to get 6144MB, you need to multiply by 4 - so use 24,576 instead. And I'd normally aim for closer to 50% rather than 75% H. Thank you ! And what's the utility of this memory ? 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. It can't be changed once plotted ? Not in place. You can optimize it from one hdd to another. |
|
|
|
I've got a little problem when I try to plot. I followed the crowetic's guide and when I set 75% of my memory (the total is 8192 MB so 75% is 6144 Mb), it says me not 6144 MB of memory used but 15XX MB of memory used (I forgot the XX number but it isn't very import, you can see that it isn't the same number). To hit the 6144 MB of memory used, I need to put a number close to 18000. What's the problem ? Can you help me ?
The memory size when ploting is expressed in nonces (256KB) not MB. So to get 6144MB, you need to multiply by 4 - so use 24,576 instead. And I'd normally aim for closer to 50% rather than 75% H. Thank you ! And what's the utility of this memory ? 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. |
|
|
|
I think that the scoop is 32-bytes, but for the deadline calculation it used 2 scoops (64-bytes), the calculated and the next one. tex81 is correct. it should say 64 bytes |
|
|
|
end_loop:
FUN A_to_Tx_after_Timestamp $timestamp
FUN @tx_info check_A_Is_Zero
BZR $tx_info :end_loop
FUN @timestamp get_Timestamp_for_Tx_in_A
FUN B_to_Address_of_Creator
FUN send_All_to_Address_in_B
JMP :end_loop
end_loop:
FUN B_to_Address_of_Creator
FUN send_All_to_Address_in_B
JMP :end_loop
(I dont see a reason looping through the tx's. All you want is to send all the amount to the creator. ) Yes, there should be $monthly_payout in the repayment_loop I just re-did the crowdfund AT, where it is implemented this way, so I thought its important. Also I have question: in the CF is SET @funded #0000000000000002 but @funded is never used then. Why? Also, how are the infinite loops done? Why there is no sleep there? @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. |
|
|
|
Hi everyone, is it possible to modify wallet code to force lower deadlines on testnet to speed up testing?
In the constants.java file add a couple 0s to the end of initial base target. I modified the crowdfund AT, to expect 1,050,000 BURST after 4 day after creation. 1,000,000 will be provided by the owner ow the script. 5% will be provided by anyone who wants to block the amount for the next year. When the target is not met, BURSTs will be sent back (same as in crowdfund) If the amount will be greater or equal it starts sending BURST to the owner of the script. 1/12 each 30 days (10800 blocks). It can be modified by adding delay before first sending (optional $blocks_before_first_repayment) DISCLAIMER: Its my first script, so take it only as proof of concept. Can someone who understands ATs check it for mistakes? Thanks :-) SET @months #0000000000000012
SET @interest_decision #0000000000001440
SET @month_in_blocks #0000000000010800
SET @target_amount #0105000000000000
FUN @block_height get_Block_Timestamp
SLP $interest_decision
FUN @amount get_Current_Balance
BGE $amount $target_amount :repayment
FUN @timestamp get_Creation_Timestamp
refund_loop:
FUN A_to_Tx_after_Timestamp $timestamp
FUN @tx_info check_A_Is_Zero
BZR $tx_info :end_loop
FUN @tx_amount get_Amount_for_Tx_in_A
FUN @timestamp get_Timestamp_for_Tx_in_A
FUN B_to_Address_of_Tx_in_A
FUN send_to_Address_in_B $tx_amount
JMP :refund_loop
repayment:
FUN @monthly_payout get_Current_Balance
DIV @monthly_payout $months
FUN B_to_Address_of_Creator
(SLP $blocks_before_first_repayment)
repayment_loop:
SLP $month_in_blocks
FUN @current_ammount get_Current_Balance
BGE $monthly_payout $current_ammount :end_loop
FUN set_A1 $current_ammount
FUN send_A_to_Address_in_B
FUN @timestamp get_Last_Block_Timestamp
JMP :repayment_loop
end_loop:
FUN A_to_Tx_after_Timestamp $timestamp
FUN @tx_info check_A_Is_Zero
BZR $tx_info :end_loop
FUN @timestamp get_Timestamp_for_Tx_in_A
FUN B_to_Address_of_Creator
FUN send_All_to_Address_in_B
JMP :end_loop
Very nice! Nice to see someone is trying to write ATs  . With a quick review I found these issues. I will check it later ( when I have more free time) for other issues . SET @months #0000000000000012 <- should be converted to hex f.e 12 -> #000000000000000c
SET @interest_decision #0000000000001440 <- should be converted to hex
SET @month_in_blocks #0000000000010800 <- should be converted to hex
SET @target_amount #0105000000000000 <- should be converted to hex
FUN @block_height get_Block_Timestamp
SLP $interest_decision
FUN @amount get_Current_Balance
BGE $amount $target_amount :repayment
FUN @timestamp get_Creation_Timestamp
refund_loop:
FUN A_to_Tx_after_Timestamp $timestamp
FUN @tx_info check_A_Is_Zero
BZR $tx_info :end_loop
FUN @tx_amount get_Amount_for_Tx_in_A
FUN @timestamp get_Timestamp_for_Tx_in_A
FUN B_to_Address_of_Tx_in_A
FUN send_to_Address_in_B $tx_amount
JMP :refund_loop
repayment:
FUN @monthly_payout get_Current_Balance
DIV @monthly_payout $months
FUN B_to_Address_of_Creator
(SLP $blocks_before_first_repayment)
repayment_loop:
SLP $month_in_blocks
FUN @current_ammount get_Current_Balance
BGE $monthly_payout $current_ammount :end_loop
FUN set_A1 $current_ammount // you want to do montly payments. Each payment's amount is monthly_payout? if yes then change $current_ammount -> $montly_payout
FUN send_A_to_Address_in_B
FUN @timestamp get_Last_Block_Timestamp
JMP :repayment_loop
end_loop:
FUN A_to_Tx_after_Timestamp $timestamp
FUN @tx_info check_A_Is_Zero
BZR $tx_info :end_loop
FUN @timestamp get_Timestamp_for_Tx_in_A
FUN B_to_Address_of_Creator
FUN send_All_to_Address_in_B
JMP :end_loop
end_loop:
FUN B_to_Address_of_Creator
FUN send_All_to_Address_in_B
JMP :end_loop
(I dont see a reason looping through the tx's. All you want is to send all the amount to the creator. ) 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. |
|
|
|
a ponzi scheme ofcourse!! do the math.
nope, he does not require you to deposit the funds there, just to confirm your account by sending some coins to yourself. now, what I asked the dev is: can this compromise your wallet's security? 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. |
|
|
|
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.
This is interesting. AT assembler? What kind of code is this? It's assembly language for the AT vm. Some examples can be found here, https://bitcointalk.org/index.php?topic=949438.msg10408276#msg10408276and full specs are here http://ciyam.org/at/at.html and http://ciyam.org/at/at_api.html |
|
|
|
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.
I'm not sure this is what you want to hear, but as your average Joe miner, I still have no idea what ATs are and what they mean to me as a miner or a user of burst. Best I can tell, you can use them as fundraisers, but there is currently no way of actually looking at them or doing anything with them without a bunch of messing around (special scripts). 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. |
|
|
|
It can be exchanged trustlessly with any other coin to implement AT's, yes  There's a reason ether received millions in funding to implement these features(and we beat them to it, by a long shot, thx to vbcs, burstdev and ciyam). Exchange with other AT's is just not good enough, for the time being, we are stuck with BTC. But it can be done. BURST daemon would have to monitor the BTC blockchain. Doesn't need to be the whole blockchain, last N blocks will suffice. So you make a contract like this (example): I commit 10000 BURST, if within the next 10 BTC blocks 0.015 or more are posted to 1HB5XMLmzFVj8ALj6mfBsbifRoD4miY36v, we wait 6 more confirmations and the 10000 BURST will be released to whatever burst address, I was making the transaction with. No more exchange fees, no more exchange site hacks, no trust required. To prevent spam, you might require that 10 burst are deposited to your address before you initiate this AT, or whatever it would be called. I think it's perfectly doable, and not too difficult either, and it would totally rock. 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. |
|
|
|
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. ok, let me see. is it trustless? though I'm repeating myself, I'm also interested in improvements to burst. 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. 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.
yes, we'll have to see, what I was just asking was: "Who wants to see?" and with deflationary coins, I insist that if the price increase isn't keeping up with the reward decrease, the coin has not good prospects, and right now things don't look so good with burst. and thus far only bitcoin has managed to make comebacks from such situations. and yes, I do think that tweaking the tx fees and aging fees is essential, and having good features also is. perhaps it would need a few forks until it reaches a stable coin. and useful features would also be critical, as I proposed anonimity cryptonote style, and trustless exchange with some other blockchains, btc being the most obvious. integrating with nxt features even better (does burst have non nxt features, other than the POC hashing?) ATs are the most important one, but burst also has built in escrow and subscription(automatically re-occuring transactions) |
|
|
|
I am not a smart dev....just a noobie one....but if AT's can support crosschain, then i'm sure they can mix in the same way that cryptonote does it.
It may not be possible, but i'm sure it could be accomplished.
Hmm, I'll have to look into what exactly an AT does, but I kinda doubt it can CryptoNote relies on Zero-knowledge proof to make the TX-es themselves. You cannot tell for sure which input generated which output, hence it's blockchain analysis resistance. 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. Wheat and gold are different.
No doubt. But I'd rather have a huge million dollar worth farm, than 1M in gold, I think it's way more stable. It's a thing to invest and to secure your capital in. Gold is more of a gamble, and bitcoin is even more so. As for wheat becoming useless after 100 years, you're right, it's old after a few years, but i think that a 5 watt HDD with burst can last a bit longer than that, even if it isn't worth investing in in a few years. I can see a 4tb drive bought now still mining in 5 years time, quite easy actually.
No no, wheat becomes useless eventually, the value is in consuming it (spend on tx fees... sell it to people who need to send money and/or anonymize, and they will gladly spend it) Then you jump to the hard drive, that's similar to the farm, not to the wheat. The farm still has value in 5 years, though if you don't keep upgrading and repairing it, it will eventually have 0 value, but then you already sold a lot of wheat anyhow. 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. |
|
|
|
Is there anyone in here that would be willing to 'authenticate' that I own the address BURST-SDHJ-Z6DP-YEWT-G47AZ? I can send a message or a bit of burst to someone. I'm currently trying to get my old account back which was hacked and someone needs to vouch that I own the above address as the people I'm talking to refuse to download a Burst wallet. https://bitcointalk.org/index.php?topic=991008As 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 |
|
|
|
the only way to "play" with the blockchain is to ddos the miner wallets by massive nonce submission to the blockchain.
the result of this may be that many mining wallets simply freeze up and the tb mining with it wont get fresh blocks.
i am not aware how the automatic ddos protection works and how fast bad ips would get blacklisted.
this attack vector may have happened before (sorry i cannot proof) because after not finding a block for several hours i directly found blocks as usual after a wallet restart and fresh peers. i have'nt traced this down to its origin but the watched effect looked suspicious.
lately the diff went too high to see this effect directly anymore so i stoped a further investigation.
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. |
|
|
|
|
Show Posts
