Do you deny that Segwit improves and makes Bitcoin more secure and robust?
Do you assert that SegWit makes Bitcoin more secure? If so, how? Do you assert that SegWit makes Bitcoin more robust? If so, how? Do you realize that after SegWit, miners may collude to roll back to non-SegWit? Do you realize that every previous SegWit then becomes a real 'anyone can spend' transaction? Do you realize that if this is done, the colluding miners may claim the value stored in these 'anyone can spend' transactions? Do you agree that this rollback/theft may be an incentive for miners to act counter to the intentions of the rest of the Bitcoin participants (whether or not sufficient to entice them to do so)? Are you at all concerned about this possibility? |
|
|
|
Can an employee be paid by BTC - avoid taxes?
If I understand your question, then in the USA, you cannot legally avoid paying taxes by getting paid in Bitcoin. Under the federal tax code, if one is paid in USD, the taxpayer is required to report the fair market value of what he/she received as income. Note: IANAL |
|
|
|
go read the scenario DINO presented!!
HE said if 10 pools all had 10% hash meaning all pools had 1000 s9's
then if 1 pool went at it alone it would take that pool 1 hour 40 minutes to make a block.
which would be wrong
Dude or dudette.... When I posted upthread that 'dinofelis was right about how mining works', that was just a polite way of expressing 'you are categorically wrong about how mining works'. i do understand alot more then you think
No - you MISunderstand more than you realize. Sorry. It's just how it is. |
|
|
|
No, the uninstall just gets rid of installation files. It won't touch any user files.
Thanks. Worked like a charm. Business was conducted. |
|
|
|
now can you see that if he only got 1 block out of 6 in the "consortium competition", he will get 6 out of 6 "on his own"
Yes. And in the time that it takes for him to get these 6 out of 6 on his minority chain, the 5x miners on the majority chain will have mined 30 blocks (+/-, after variance). |
|
|
|
What I don't know is whether I can freely mix and match versions. Is the logical route forward just to upgrade the Offline Signing machine to the latest and greatest Armory? Will they interoperate then?
You can use anything 0.93+ as a signer. Any gotchas on the install? Or can I just install it in place, over existing version?
sudo dpkg -r armory
sudo dpkg -i new_armory_package.deb
Cool. So when I -r it, will it remove all the data files as well? I assume this would require me to 'reinstall' my wallets from seeds? Or will the data be left in place? |
|
|
|
Some time back, I created my Cold Storage mechanism based upon Armory 0.88.1-beta. Somewhere along the line, I upgraded the online watching component in order to allow continued use of a hot wallet on the same system. Now I want to dip into my Cold funds, but find myself unable to. Upon creating the transaction, I get: *Version Warning*
<!>
Since Armory version 0.92 the formats for offline transaction operations has changed to accommodate multi-signature transactions. This format is _not_ compatible with versions of Armory before 0.92.
To continue, the other system will need to be upgrades to to version 0.92 or later. If you cannot upgrade the other system, you will need to reinstall an older version of Armory on this system.
OK, this all seems clear enough. What I don't know is whether I can freely mix and match versions. Is the logical route forward just to upgrade the Offline Signing machine to the latest and greatest Armory? Will they interoperate then? Offline Signing: Armory 0.88.1-beta ubuntu 12.04 LTS Online Watching: Armory 0.93.2 Mac OS X 10.8.5 Any gotchas on the install? Or can I just install it in place, over existing version? |
|
|
|
Core is not perfect, but BU is just sad. Might as well stand for Bugs Unlimited.
Can I add : with closed source update ? No, you may not. Code for all releases is publicly available. |
|
|
|
|
Franky1 -
You've made some good observations over the years. However, I think your clinging to bad analogies has you confused. On this mining issue, dinofelis is correct.
|
|
|
|
That said, full nodes are not totally useless, but their only use is for *their owner* who is the only one who can *check for himself*. But with that knowledge, he can do nothing else but acknowledge "that he has been had" or "that he hasn't been had", but that's about it. The other advantage of a full node, for his owner, is that his owner can send out his own transactions, and nobody can know that HE was the one sending that transaction, as, being a full node, he would also send all transactions of light wallets connected to him. So there is some kind of deniable anonymity of the IP address that sent out a transaction.
But that's about it. These can be sufficiently good reasons to run a full node, BTW.
Absolutely. With the caveat that despite the misappropriation of the word, entities that do not mine are not 'nodes', by the original definition. That aside, you sum up pretty completely the reason that I run a fully-validating-wallet. |
|
|
|
Hunh? I was always a BU shill.
FTFY. Go fuck yourself. A 'shill' is an advocate for hire. Nobody but me pays me for my advocacy of BU. I have fat stacks of Bitcoin, and want what is best for the system. Addocrdingly, I advocate -- on my own dime, mind you -- for BU. I have also consistently (for about a year) pointing out that non-mining entities (which I had formerly been mistakenly been calling 'non-mining nodes') have essentially zero power to influence the network, and provide essentially zero value to the network at large. I have, though, stated that such non-mining entities are what allow their owners/users to transact in a trustless manner. Benefit to the owner, no benefit to the network.
Which is complete nonsense. Wallow in your ignorance. If it were not for the fact that your misunderstanding causes you to take a wrong-headed stance on architectural directions for Bitcoin, I wouldn't care. But what I have recently learned is that Satoshi's definition of 'node' is necessarily limited to entities that mine.
No. Care to refute what he clearly wrote? Or do you just know better then he/she? So you know better than Satoshi?
The whole "satoshi" thing builds upon the assumption that miners are honest. We know today that this is not true Orly? Bitcoin is irredeemably broken? Then why do you expend so much effort upon it? (ASICBOOST,
Explain to me how this efficiency gain is 'dishonest'. Bear in mind that nothing stops a true attacker from using ASICBOOST against us. AntBleed,
Explain to me how this misguided feature is dishonest. Bear in mind that there have been exactly zero reports of it being used. empty blocks
Explain to me how mining empty blocks is 'dishonest'. Bear in mind that it has always been the miners' discretion to include in a block what the miner cares to. Due to this, everything that you've quoted is nullified.
Bullshit. It would remain true regardless. External circumstances do not affect the veracity of an independent claim. The primary thing protecting the network from mining cartel abuse are the non-mining nodes.
Bullshit. The primary thing protecting the network from mining cartel abuse is the ability of the users to abandon the chain, leaving it worthless. Do not get me started on Satoshi's failure to predict ASICs
Your ignorance is showing again: " At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node." - Satoshi Nakamoto Otherwise you're basically saying that 1 Bitmain = Bitcoin.
...aaand you fail to understand capitalism. If everyone else abdicates their power by refusing to compete with Bitmain, that is not anything you can blame on Bitmain. Don't destroy one of the greatest innovations of our lifetime in order to tilt the playing field. Get in there and build something. |
|
|
|
We can pretty much tell if it is a compromise when both sides agree to it.
Absolute nonsense. BU is cancer and no compromise can be made with their destructive technology. A compromise would be a simple max block size increase. This would completely nullify any issue with BU code quality. It is only due to the fact that core iteratively whittled away this idea down to nothing, that gave big blockers an incentive to create BU to begin with. |
|
|
|
In reality, non-mining nodes are irrelevant.
Absolute nonsense. This is sounding more like government agency talk. I thought you were a BU shill, what changed? Hunh? I was never a BU shill, though I have been a consistent BU supporter. What is the relevance? I have also consistently (for about a year) pointing out that non-mining entities (which I had formerly been mistakenly been calling 'non-mining nodes') have essentially zero power to influence the network, and provide essentially zero value to the network at large. I have, though, stated that such non-mining entities are what allow their owners/users to transact in a trustless manner. Benefit to the owner, no benefit to the network. But what I have recently learned is that Satoshi's definition of 'node' is necessarily limited to entities that mine. The miners do not, and have never been in, control of the network.
So you know better than Satoshi? Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.
Any needed rules and incentives can be enforced with this consensus mechanism.... Any needed rules and incentives can be enforced with this consensus mechanism.... Any needed rules and incentives can be enforced with this consensus mechanism.... Any needed rules and incentives can be enforced with this consensus mechanism.... Hmmm... yeah.... I guess miners have always been in control of the network, after all. |
|
|
|
All of the arguments that "nodes do matter" have the logical fallacy of taking the "intended way the network SHOULD work" as the "actually technically resulting technical operation".
I agree with all you say. However, the situation is even more dire. Turns out we have been lied to all this time. The reality is that no entity is a node, if that entity does not mine. Indeed, this is the true, original, and proper definition of a node. We need to reevaluate who 'sold us a bill of goods'. We have abdicated our authority in the network. In reality, non-mining nodes are irrelevant. Indeed, in the original wallet, nodes mine - period. from https://github.com/trottier/original-bitcoin/blob/92ee8d9a994391d148733da77e2bbc2f4acc43cd/src/main.h#L795// Nodes collect new transactions into a block, hash them into a hash tree,
// and scan through nonce values to make the block's hash satisfy proof-of-work
// requirements. When they solve the proof-of-work, they broadcast the block
// to everyone and the block is added to the block chain. The first transaction
// in the block is a special one that creates a new coin owned by the creator
// of the block.
GitHub trottier/original-bitcoin original-bitcoin - This is a historical repository of Satoshi Nakamoto's original bitcoin sourcecode (emphasis added) I don't know when the definition of 'node' became corrupted to include non-mining entities. I don't know who introduced this lie. Though I must admit to propagating it. For years. Sorry. I was ignorant. |
|
|
|
Bow down to your pool operator overlords!
We need to reevaluate who 'sold us a bill of goods'. You have abdicated your authority in the network. In reality, non-mining nodes are irrelevant. Indeed, in the original wallet, nodes mine - period. https://github.com/trottier/original-bitcoin/blob/92ee8d9a994391d148733da77e2bbc2f4acc43cd/src/main.h#L795 // Nodes collect new transactions into a block, hash them into a hash tree,// and scan through nonce values to make the block's hash satisfy proof-of-work// requirements. When they solve the proof-of-work, they broadcast the block // to everyone and the block is added to the block chain. The first transaction // in the block is a special one that creates a new coin owned by the creator // of the block. GitHub trottier/original-bitcoin original-bitcoin - This is a historical repository of Satoshi Nakamoto's original bitcoin sourcecode (emphasis added) |
|
|
|
I am expecting that once Bitcoin Unlimited gets over 50% of the hashing power then they will have enough confidence to attempt to win the battle of the block size.
Possible, but unlikely. Bitcoin is permissionless. Trying to make all miners adhere to a single plan is akin to herding cats. That said... The most widely discussed plan os to achieve >= 75% of solved blocks, hold that until the next difficulty retargeting (0-2 weeks), hold it for an entire difficulty retargeting, then start building blocks larger than 1MB (soft cap at 2MB seems to have some support). Again, it is possible that some miner jumps the gun. However, he is likely to find his blocks orphaned no only by the stragglers, but also by BU miners that are executing according to the new plan. There is the possibility that a new plan emerges. I've not heard of such. With this, the minority (legacy) fork will drop from being capped at ~250,000 tx/day to about 62,500 tx/day, leading to a near-stall. If more miners defect to BU at that point (which would be in their financial interest due to the slow rate), the minority fork may rapidly dwindle down to a hard core of the obstinate 1% true core believers. Which of course, will slow the minority fork even further. It may never make it to the next difficulty retargeting, when the rate could be (partially) adjusted. In no way would the retargeting occur before two months. The BU fork (assuming 2MB soft cap) would be capable of processing ~250,000 tx/day * 2MB/1MB * 75% = ~375,000 tx/day (more if further defection) until the next difficulty retargeting - in about 20 days (less if further defection), where it would jump to ~500,000 tx/day (more if further defection). The upshot is that the minority fork will be economically irrelevant. This will create market pressure to consider the majority fork 'The Real Bitcoin', and the minority fork 'that other bitcoin-like alt'. Accordingly, it would not rip the network in half, more like 99%/1% -- if that. |
|
|
|
Who attacks Unlimited?
I fully support the ideals and goals of BU. The elimination of the centrally-planned production quota would be the elimination of the most significant bug Bitcoin has. That said, it does not matter who is attacking. Better it be bitcoiners now than the vampire squid after BU becomes the majority client. These widespread crashes are embarrassing. They do demonstrate a lag in software quality. BU would benefit greatly from an influx of good developers. Making excuses is merely making excuses. Sometimes, I despair briefly from these events. Then I recall that each bug exploited, identified, and squashed, is one less bug in the system. A suboptimal implementation of the correct design decisions is infinitely better than the tightest implementation of the wrong design. In time, BU will prevail. |
|
|
|
But quadratically with block size meaning at 16MB blocks or so a 30% miner might still be able to block all nodes permanently.
No. As I explained (did you even read?), parallel validation routes around the quadratic hash time issue. More importantly, as miners who create blocks exhibiting this quadratic hash time issue have their blocks orphaned, they will be bankrupted. Accordingly, the creation of these blocks will be disincentivized to the point where they just plain won't be built.
For an attacker disrupting the network for a while might pay of via puts or rising altcoins or just by hurting Bitcoin. No. As I explained (did you even read?), parallel validation routes around the quadratic hash time issue. A Bitcoin network with a significant proportion of miners implementing parallel validation can not be stalled by quadratic hash time. Also let me remind you of the resource discussion further up. Of course it is relevant to this debate. Why do you oppose the technically sound and sustainable solution? Particularly as it happens to also bring other important benefits?
There was no resource 'discussion' upthread, an inadequate strawman of resource consumption was used to cast aspersions upon parallel validation. I oppose The SegWit Omnibus Changeset mostly due to considerations other than segwit itself. Namely: the SF nature; the backdoor of versionbit changes; and the centrally-planned magic 4:1 ratio. But mostly because the 1.7x or 2x or whatever capacity increase it ends up being is too little, too late, and we'll just be back at this same argument before the year is up. |
|
|
|
Blame it on Canada!
We can squarely blame this on Jimbo for not buying the dip. CAD will now experience a Chinese moment, where prices decouple by 20%. Blame me all you want.  The fact is that on May 6 we hit another daily average CAD ATH while everybody else slipped. Blame everyone else.  All in good fun, Jimbo... https://www.youtube.com/watch?v=bOR38552MJA |
|
|
|
- For buying "coffee" or who knows what other smallish stuff -> LN
So are you going to open up a channel -- with as much bitcoin as you plan to spend over the next n weeks -- with Starbucks? ANd another for Dunking Donuts? And a another with Caribou? And...? Or are you going to open a single channel with some bank-hub? Or are you going to open up a single channel with your cousin Ted, and hope that the trustless decentralized routing algorithm (which, buy the way, does not exist) will be able to somehow find a route from you to the coffee shop without eating up the total value you have locked up in the channel in LN-transaction fees? |
|
|
|
|
Show Posts
