My understanding of Gavin's motive is that the hard fork is purely ego driven. There's no urgency to change block size. He just wants to be dramatic and make his personal mark on it. But controversy, technical-wise, is that some Bitcoin users may have their coins lose compatibility with the new implementation. In a sense, it may be Gavin and Hearn's attempt to hijack the Bitcoin name and implement their own coin or make changes to the protocol.
Everything you said is inaccurate. The reason there is a debate is because there are a lot of people on both sides of the blocksize increase, Gavin is not even close to being alone on wanting to increase the limit. He does not want to be the one to make the call on what happens. If you haven't watched a recent Q&A with Gavin and Mike you should, they specifically discuss the blocksize issue at the 27 minute mark https://youtu.be/RIafZXRDH7w?t=27m50sAlso no one is going to lose any coins unless you are a miner receive block rewards and you start mining on the "wrong/old" fork. Or on the new fork depending on which one makes it ... Will you stop spreading nonsense ... how are we going to lose coins by your logic? You could loose your coins in case you use them after the fork on Gavincoin but then it turns out the gavincoin is plummeting in value (be it because some powerful people dump it or be it because techical problems arise) and miners switch back to the old fork on which your coins will be gone as MP already announced to mess with txs. It could likely happen that coins you spend on one chain happen to be spent on the other chain aswell as signed txs are the same on both chains and can and probably will be broadcast on both chains. You have no idea what you are talking about ... seriously! |
|
|
|
Okay, I am kinda getting tired of reading the nonsense being posted on these threads by people who have clearly not taken the time to read or understand Gavins proposal. Whether you support the bigger blocks or not you need to understand what is being proposed. This is leading to a common misunderstanding about the proposal on implementing the fork. The bigger blocks don't go live until the super-majority of nodes update their clients. What has been proposed is very simple: 1. If you do not care about the potential bottle neck in the future then stick on bitcoin-core and the 1mb blocks 2. If you want to support the movement to 20mb block then move to bitcoin-xt Current rules if no consensus as measured by block.nVersion supermajority.
Supermajority defined as: 800 of last 1000 blocks have block.nVersion == 4 Once supermajority attained, block.nVersion < 4 blocks rejected.
This basically means that only once super-majority is reached will the miners be allowed to create blocks >1MB blocks (bitcoin-xt) which would be accepted into the longest chain. The other 20% minority who rejects the new blocks (running bitcoin-core) would find themselves on the shorter chain... and left behind. I have said my two satoshis worth... |
|
|
|
A worst case scenario:
Half of the merchants/miners/users still use the bitcoin-qt, work on original chain; another half of the merchants/miners/users upgraded to bitcoin-xt and work on the new xt chain
Pre-fork coins can be spent on both chain, which means the total coin supply becomes 42 million if you count both chains, then price of the coins on both chains will be cut by half
Hash rate will also be cut by half on both chains if the miners are 50/50 divided. Having a competing chain with almost the same hash power as your chain is a nightmare: It means your chain will be easily exposed to attack ( almost 51%, so the attack will succeed every once a while), double spending and transaction reverse will be daily event if the majority of the hash power on the other chain decided to do so. There will be hash wars which benefit none
So, like Jeff Garzik said, the hard fork is extinction level event, it should be carried out with fully reached consensus
This is a common misunderstanding from those who haven't seen Gavin's proposal on implementing the fork. The bigger blocks don't go live until the super-majority of nodes update their clients. |
|
|
|
|
The funny thing is watch all these "against the 20MB blocks" still be here once the transition happens ...
|
|
|
|
My understanding of Gavin's motive is that the hard fork is purely ego driven. There's no urgency to change block size. He just wants to be dramatic and make his personal mark on it. But controversy, technical-wise, is that some Bitcoin users may have their coins lose compatibility with the new implementation. In a sense, it may be Gavin and Hearn's attempt to hijack the Bitcoin name and implement their own coin or make changes to the protocol.
Everything you said is inaccurate. The reason there is a debate is because there are a lot of people on both sides of the blocksize increase, Gavin is not even close to being alone on wanting to increase the limit. He does not want to be the one to make the call on what happens. If you haven't watched a recent Q&A with Gavin and Mike you should, they specifically discuss the blocksize issue at the 27 minute mark https://youtu.be/RIafZXRDH7w?t=27m50sAlso no one is going to lose any coins unless you are a miner receive block rewards and you start mining on the "wrong/old" fork. Or on the new fork depending on which one makes it ... Will you stop spreading nonsense ... how are we going to lose coins by your logic? |
|
|
|
<snip>
Drama, drama, drama
The ones who are most at danger to loose their value or coins are those like OP who don't know what the heck is going on.
The only drama here my friend is if *we* do nothing ... I for one am glad that Gavin has decided to take the bull by the horns and actually do something about it. |
|
|
|
Calculating:
2.7 (txs/s) * 60 (per minute) * 60 (hour) * 24 (day) * 0.0001 (fee) * 20 (Gavin factor) * 200 (usd price) = 93312 USD to spam up Gavincoin to full 20MB blocks and render it unuseable aswell as filling up peoples' harddrives around the world with 2,88 GB of data per 24 hours (!!!)
conclusion:
Gavincoin can not be defended against banks or governments or even a (bitcoin)millionaire
Anyone who is willing to spend around 100k$ per day can make Bitcoin unusable for almost anyone and bloat the chain in an extreme way and doesn't even need any mining equipement for the attack!
A measily 40 Million spent on such an attack would bloat the chain to 1 Terrabyte. For many entities that's not a lot of money.
#justsayin'
Gavincoin is not defensible against spam.
Thanks for stating the obvious .. so basically it will take 1/20th of that to do it today? I know which I choose and it is not in the single digits. |
|
|
|
|
About time someone will balls took the bull by the horns ...
|
|
|
|
Go to your own thread
No need for that. I still have 9 ShadowCash physical couns for sale. I am accepting ShadowCash for payment. Pm me if you are interested, have a good weekend all.
Wheelz1200
All the best with the sale ... good to see development on the merchant side. |
|
|
|
3. What Key Derivation Paths are used by Ledger Wallet direct and Coinkite? should for example one need to manually pull those keys if said service is down etc.
Ledger Wallet uses standard BIP 44 on account 0 for the time being, Coinkite let you pick your own derivation path on the imported xpub then derives incrementally each key. I think you should be able to retrieve the current index on their signing page. Thanks, in reference to the above; Not specific to Ledger but a general note. I noticed CoinKite starts its default at 1 ... going forward with more implementation and users being able to select which Subkey (at CK) on BIP44 path one could end up with clashes where addresses are being reused (say across multiple wallets using different implementations etc). Any thoughts on that? |
|
|
|
Couple of questions... 1. How much more secure in the mobile app for second factor compared to the security card? (I can see the potential concern with the security card; is the Ledger team confident that the mobile app provides sufficient protection?) 2. I understand the second auth is not available if the nano/hw1 is used for multi-sig .. any plans to support that or is this a design decision? 3. What Key Derivation Paths are used by Ledger Wallet direct and Coinkite? should for example one need to manually pull those keys if said service is down etc. Keep up the great work  Thanks |
|
|
|
Also i believe if 2FA was set up through a phone or 3rd party device, seperate from the cold wallet, it would be impossible to hack since the 2FA codes are always changing. If you as a keylogger would just wait for the user to enter the code, why has 2FA yet to be hacked? Why has no keylogger/hacker "just waited"? cause you cant, if you wait the code changes, and how can the hacker get the changed code from the phone or 3rd party device if he only has the device of the cold wallet bugged?
That is a misconception ... once you unlock your wallet I can easily steal your private key. Then no traditional 2FA in the world will save you. Traditional 2FA is not the answer. example, the hacker took 55k from my cold wallet.
AFAIAC your definition of cold wallet does not match mine. A cold wallet is not connected to the Internet. the hacker took nothing from my blockchain wallet locked with 2FA, BUT he attempted. He had full access, he cracked my fuckin pgp where all my blockchain info was stored with BOTH Mnemonic passwords. Did he not want to check my bitcoin wallet? or was he unable to? Ill go with the second one.
Because he/she was an opportunist v.s. real hacker! And again traditional 2FA provides unrealistic expectation for protecting crypto ... so great the front-end is protected by 2FA .. that is fine I will make my way straight to the bitcoin daemon which does not have 2FA and pull the keys from it. Then what you going todo? My point is simple and that is any 2FA (as of right now) which is not using multisig is a load of nonsense and providing nothing but false security. I have yet to see a solution which is better, I am sure with time we will see them. |
|
|
|
The Linux wallets have a readme in github which is fairly easy to follow. The first thing I ever did on Linux was install the wallet.
Shadowcoind is the command line wallet which is much more difficult than the gui qt wallet.
The learning curve is actually not that difficult. If you load the GUI Wallet and goto console and type "help" that is basically the same as running "shadowcoind help" ... start practicing there first (unlock wallet, send transactions etc), instead of using the GUI use the console (the commands are the same). Once your comfortable you can move onto linux etc and manage the Shadow wallet with ease from CLI. If you are going to go down this route, stick to a linux server behind your home router/nat v.s. a public VPS (as that then requires you to ensure the VM/VPS is secured and up-to-date) |
|
|
|
Is there a guide to set up multisig for laymen? If not, sounds like something child_harold could contribute!
*cheeky* This is the downside of multisig atm ... does require some knowledge to use it safely. |
|
|
|
Multisig with your Android wallet would be almost as secure as 2fa.
Best solution on the market at the moment for altcoins |
|
|
|
<snip>
if you say that, HD wallet is the solution for it...then HD wallet look like the most important improvement right now
You can achieve great security right now using multisig (like I do) and you will need to have access to multiple devices to move my funds... What HD wallet (BIP32, 39 and 44) brings to the table is a "standardised" way for say Trezor or Ledger Wallet to add support for Shadow and make it easy for the average person to feel secure with their crypto currency of choice. |
|
|
|
|
If you are infecting a file with a virus/malware/keylogger (call it what you want) you will adapt it; This is all within the reach of someone determined to get your funds.
|
|
|
|
it sounds like a good idea to me, but i dont know technically if it is possible
lets say they that lawgicc's all paswords in hand
they stole from his wallet but even if they know his bittrex pass, they can not steal his bittrex coins
i dont know if it is the case with lawgicc, it sounds 2fa is logical
In that scenario I would just sit there quietly until you logged into BITTREX and then withdraw the funds  Fibrecoin have something called FibreLock which require all password inputs to come from the mouse rendering keyloggers useless.
That is great apart from, I will just wait till you unlock your wallet before stealing your private keys ... I should add that keyloggers can be as stupid or intelligent as you want; i.e. they can take screenshots and capture mouse movements. So these solutions really don't add much of an improvement. The best solution atm is Multisig and looking forward hopefully once the new HD wallet is out we can look at going the next level up with Hardware Wallets etc. |
|
|
|
one question...
isnt it possible to integrate 2fa into wallets...there can be QR code or simple code at the first use of the wallet
it can be as an additional security, and even if someone gets ur password with a key logger he/she can not access ur coins
technically is it possible
It is not quite that simple ... adding 2FA to the wallet != 2FA to access your private keys. |
|
|
|
|
Everyone be extra careful and only download wallet which link to "shadow.cash" website - both aboutshadow.com and shadowcash.info link directly to downloads at shadow.cash.
|
|
|
|
|
Show Posts
