[HYP] HyperStake | Generous Reward Staking | Advanced Staking Controls & Wallet

[bitmaster1x]

@Presstab.

I've noticed that when selecting coins for splitting. If the inputs are over 400-500 (I can't remember the exact number) it will fail.

[1714931278]

1714931278

[1714931278]

1714931278

[presstab]

@Presstab.

I've noticed that when selecting coins for splitting. If the inputs are over 400-500 (I can't remember the exact number) it will fail.

Yeah thats way too large. Honestly it has a hard time if it is more than 100, maybe I should put a hard cap in there.

[bitmaster1x]

@Presstab.

I've noticed that when selecting coins for splitting. If the inputs are over 400-500 (I can't remember the exact number) it will fail.

Yeah thats way too large. Honestly it has a hard time if it is more than 100, maybe I should put a hard cap in there.

The majority of crypto wallets suffer from this DB issue and once the file size gets to around 500MB or more it virtually becomes unusable.

[presstab]

@Presstab.

I've noticed that when selecting coins for splitting. If the inputs are over 400-500 (I can't remember the exact number) it will fail.

Yeah thats way too large. Honestly it has a hard time if it is more than 100, maybe I should put a hard cap in there.

The majority of crypto wallets suffer from this DB issue and once the file size gets to around 500MB or more it virtually becomes unusable.

Wait i thought you meant splitting into 400-500 inputs. Is that not what you meant?

[bitmaster1x]

@Presstab.

I've noticed that when selecting coins for splitting. If the inputs are over 400-500 (I can't remember the exact number) it will fail.

Yeah thats way too large. Honestly it has a hard time if it is more than 100, maybe I should put a hard cap in there.

The majority of crypto wallets suffer from this DB issue and once the file size gets to around 500MB or more it virtually becomes unusable.

Wait i thought you meant splitting into 400-500 inputs. Is that not what you meant?

Sorry about that... the latter stuff is just the byproduct of all the stuff  combined (as a large wallet.dat file), but yes, the number of inputs is the main culprit which basically affect the wallets ability to send, combine or split because after a certain number of inputs it fails whether it is selected from the coin control or automatically.

This is what I mean: https://www.crypto-city.com/index.php/photo/5750/selections-in-coin-control-over-a-certain-quantity-will-throw-a-fail-to-cre/

[iantunc]

@Presstab.

I've noticed that when selecting coins for splitting. If the inputs are over 400-500 (I can't remember the exact number) it will fail.

Yeah thats way too large. Honestly it has a hard time if it is more than 100, maybe I should put a hard cap in there.

The majority of crypto wallets suffer from this DB issue and once the file size gets to around 500MB or more it virtually becomes unusable.

Wait i thought you meant splitting into 400-500 inputs. Is that not what you meant?

Sorry about that... the latter stuff is just the byproduct of all the stuff  combined (as a large wallet.dat file), but yes, the number of inputs is the main culprit which basically affect the wallets ability to send, combine or split because after a certain number of inputs it fails whether it is selected from the coin control or automatically.

If the big number of UTXO's is your staking strategy (mine too), and that makes your life difficult, you can scale the wallet horizontally, i.e., set up a second staking machine and move a part of UTXO's there. It also adds extra security. I'm starting to think about it

[bitmaster1x]

@Presstab.

I've noticed that when selecting coins for splitting. If the inputs are over 400-500 (I can't remember the exact number) it will fail.

Yeah thats way too large. Honestly it has a hard time if it is more than 100, maybe I should put a hard cap in there.

The majority of crypto wallets suffer from this DB issue and once the file size gets to around 500MB or more it virtually becomes unusable.

Wait i thought you meant splitting into 400-500 inputs. Is that not what you meant?

Sorry about that... the latter stuff is just the byproduct of all the stuff  combined (as a large wallet.dat file), but yes, the number of inputs is the main culprit which basically affect the wallets ability to send, combine or split because after a certain number of inputs it fails whether it is selected from the coin control or automatically.

If the big number of UTXO's is your staking strategy (mine too), and that makes your life difficult, you can scale the wallet horizontally, i.e., set up a second staking machine and move a part of UTXO's there. It also adds extra security. I'm starting to think about it

Ya. I have like 10 machines, but it definitely is an issue when sending a transaction and if it includes over a certain number of blocks (over 500) it will fail to create the transaction.

[presstab]

@Presstab.

I've noticed that when selecting coins for splitting. If the inputs are over 400-500 (I can't remember the exact number) it will fail.

Yeah thats way too large. Honestly it has a hard time if it is more than 100, maybe I should put a hard cap in there.

The majority of crypto wallets suffer from this DB issue and once the file size gets to around 500MB or more it virtually becomes unusable.

Wait i thought you meant splitting into 400-500 inputs. Is that not what you meant?

Sorry about that... the latter stuff is just the byproduct of all the stuff  combined (as a large wallet.dat file), but yes, the number of inputs is the main culprit which basically affect the wallets ability to send, combine or split because after a certain number of inputs it fails whether it is selected from the coin control or automatically.

If the big number of UTXO's is your staking strategy (mine too), and that makes your life difficult, you can scale the wallet horizontally, i.e., set up a second staking machine and move a part of UTXO's there. It also adds extra security. I'm starting to think about it

Ya. I have like 10 machines, but it definitely is an issue when sending a transaction and if it includes over a certain number of blocks (over 500) it will fail to create the transaction.

The best thing to do is to not create transactions that large. I think there is even a limit to transaction size, I will have to look that up in the code.

[iantunc]

@Presstab.

I've noticed that when selecting coins for splitting. If the inputs are over 400-500 (I can't remember the exact number) it will fail.

Yeah thats way too large. Honestly it has a hard time if it is more than 100, maybe I should put a hard cap in there.

The majority of crypto wallets suffer from this DB issue and once the file size gets to around 500MB or more it virtually becomes unusable.

Wait i thought you meant splitting into 400-500 inputs. Is that not what you meant?

Sorry about that... the latter stuff is just the byproduct of all the stuff  combined (as a large wallet.dat file), but yes, the number of inputs is the main culprit which basically affect the wallets ability to send, combine or split because after a certain number of inputs it fails whether it is selected from the coin control or automatically.

If the big number of UTXO's is your staking strategy (mine too), and that makes your life difficult, you can scale the wallet horizontally, i.e., set up a second staking machine and move a part of UTXO's there. It also adds extra security. I'm starting to think about it

Ya. I have like 10 machines, but it definitely is an issue when sending a transaction and if it includes over a certain number of blocks (over 500) it will fail to create the transaction.

The best thing to do is to not create transactions that large. I think there is even a limit to transaction size, I will have to look that up in the code.

I have looked in the code. There is a limit of 100 kb per wallet transaction in the bitcoin code (manual transactions can be as big as the max block size). I haven't found such limit in the HYP code yet. Anyway, I also think that it's not a good practice to create too heavy transactions which consume not only disk space but CPU resources of every node and can potentially be an attack vector.

[presstab]

The best thing to do is to not create transactions that large. I think there is even a limit to transaction size, I will have to look that up in the code.

I have looked in the code. There is a limit of 100 kb per wallet transaction in the bitcoin code (manual transactions can be as big as the max block size). I haven't found such limit in the HYP code yet. Anyway, I also think that it's not a good practice to create too heavy transactions which consume not only disk space but CPU resources of every node and can potentially be an attack vector.

Yes I agree, just be a responsible HYPster and create smaller transactions if possible.

On another note, has anyone thought about the possibility of using segwit with PoS? I have begun looking through the segwit code for bitcoin. Although we don't have a scaling problem, segwit solves some other problems such as malleability. It could be interesting subject to explore.

[bitmaster1x]

The best thing to do is to not create transactions that large. I think there is even a limit to transaction size, I will have to look that up in the code.

I have looked in the code. There is a limit of 100 kb per wallet transaction in the bitcoin code (manual transactions can be as big as the max block size). I haven't found such limit in the HYP code yet. Anyway, I also think that it's not a good practice to create too heavy transactions which consume not only disk space but CPU resources of every node and can potentially be an attack vector.

Yes I agree, just be a responsible HYPster and create smaller transactions if possible.

On another note, has anyone thought about the possibility of using segwit with PoS? I have begun looking through the segwit code for bitcoin. Although we don't have a scaling problem, segwit solves some other problems such as malleability. It could be interesting subject to explore.

That does sound interesting, I've not seen anyone try to push HYP to its limits yet... However, I'm sure if it gets popular someone would likely try.

Something that might be of interest to look into over time is the wallets inability to deal a large number of records in the wallet.dat. This isn't HYP specific, but a general crypto wallet DB issue. Maybe a new parallel DB core engine and schema?  Someone might have fun with this.

[bitmaster1x]

hello - its been a while !   I have been out of the crypto world for a while now, but now have more time to commit.

HYP was my first "real" coin i got involved in so would love to see it succeed again - I am starting from a 0 HYP position (unless there is something lurking in one of my wallets which I am trying to get all synced up again!) so nothing to gain in the short term.

Please let me know if there are any active projects which I can help with ?

Welcome back into the fold.  You can go, but you can never leave.

[BitsifyOfficial]

hello - its been a while !   I have been out of the crypto world for a while now, but now have more time to commit.

HYP was my first "real" coin i got involved in so would love to see it succeed again - I am starting from a 0 HYP position (unless there is something lurking in one of my wallets which I am trying to get all synced up again!) so nothing to gain in the short term.

Please let me know if there are any active projects which I can help with ?

Welcome back into the fold.  You can go, but you can never leave.

Lol so true! It haunts you till the day you die 

[presstab]

hello - its been a while !   I have been out of the crypto world for a while now, but now have more time to commit.

HYP was my first "real" coin i got involved in so would love to see it succeed again - I am starting from a 0 HYP position (unless there is something lurking in one of my wallets which I am trying to get all synced up again!) so nothing to gain in the short term.

Please let me know if there are any active projects which I can help with ?

jaybeeuk great to see you back here. I myself have stayed pretty busy with a lot of other crypto-currency 'for hire' jobs, and have unfortunately not had time to develop HYP within the last year. Fortunately it was left in a great state and still works very well. I am starting up with a few ideas and looking over the codebase.

I don't know if there are any active projects, I would guess not. But let me know if you start working on something.

I would personally like to work on some code for staking activated governance system implemented in HyperStake. It would allow us to make decisions for HYP without as much smoke and mirrors. For example, there is absolutely no reason to continue hashing the block header in X11 instead of sha256, it just adds over 11 times more strain to the syncing process and no additional security.

[bitmaster1x]

hello - its been a while !   I have been out of the crypto world for a while now, but now have more time to commit.

HYP was my first "real" coin i got involved in so would love to see it succeed again - I am starting from a 0 HYP position (unless there is something lurking in one of my wallets which I am trying to get all synced up again!) so nothing to gain in the short term.

Please let me know if there are any active projects which I can help with ?

jaybeeuk great to see you back here. I myself have stayed pretty busy with a lot of other crypto-currency 'for hire' jobs, and have unfortunately not had time to develop HYP within the last year. Fortunately it was left in a great state and still works very well. I am starting up with a few ideas and looking over the codebase.

I don't know if there are any active projects, I would guess not. But let me know if you start working on something.

I would personally like to work on some code for staking activated governance system implemented in HyperStake. It would allow us to make decisions for HYP without as much smoke and mirrors. For example, there is absolutely no reason to continue hashing the block header in X11 instead of sha256, it just adds over 11 times more strain to the syncing process and no additional security.

Sounds like a plan. Having a mobile app for person to person transfer wouldn't hurt either.

Soon we're going to offer limited goods and services in exchange for HYP @ Crypto-city once we roll out our store front for our global crypto citizens.  

[billotronic]

i smell a hardfork coming.....

[presstab]

i smell a hardfork coming.....

Changing the algorithm from x11 back to sha56d would require a hardfork. It is not super high priority, but it does make a different for a coin with over 1 million blocks.

I did see that miner (staker in our case) activated forks are in fact a feature in the HYP codebase.

[presstab]

Sounds like a plan. Having a mobile app for person to person transfer wouldn't hurt either.

Soon we're going to offer limited goods and services in exchange for HYP @ Crypto-city once we roll out our store front for our global crypto citizens.  

Mobile app would be fantastic. Maybe we can poke our heads around and see what the pricing is for that.

Also as many use cases for HYP as possible the better, so that is great news concerning crypto-city

[presstab]

Sounds like a plan. Having a mobile app for person to person transfer wouldn't hurt either.

Soon we're going to offer limited goods and services in exchange for HYP @ Crypto-city once we roll out our store front for our global crypto citizens.  

Mobile app would be fantastic. Maybe we can poke our heads around and see what the pricing is for that.

Also as many use cases for HYP as possible the better, so that is great news concerning crypto-city

 you must do somthing dev. dont let this coin be like this.. if there is some good news happening i now the price of this coin will increase
look at xby coin it increase from 1 satoshi to 300+

this coin has the potentials

I am working on HYP right now. Nothing major will happen over night though. I am just making some small efficiency changes to the code here and there. If you are looking for major developments in the core code over night, its not going to happen. HYP is time proven, so I don't see any reason to rush out with shit code instead of being more methodical.

[Trololoh]

@presstab
If you going to add segwit don't forget to add LN as well.