Bitcoin Forum
November 21, 2017, 04:26:58 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 241 »
481  Bitcoin / Development & Technical Discussion / Re: Pasting untrusted blocks/ and chainstate/ to new pruned node safe? on: February 15, 2016, 11:59:31 PM
Beyond the issue of potential problems in the data itself-- there has been no auditing or effort to make sure these raw database files are safe for malicious input. (In the case of the bdb wallet files, I'm reasonably confident that they are not safe.)

Running a database (chainstate, txindex, blockindex) or wallet from an untrusted third party might result in giving them arbitrary code execution on your system.

The loadblock raw blockfile imports, otoh, are handled the same way as data from the network and are designed to handle untrusted input.
482  Bitcoin / Development & Technical Discussion / Re: Bitcoin 0.12 release on: February 11, 2016, 09:13:59 PM
This could be the greatest plus thing we need and then I would be more than happy in contributing again.
When you talk about future, how far is this future? thanks  Wink
I think it would be done now, if not for all the drama in the last year.

In 0.12 you can run a pruned node and you'll at least relay blocks on the tip.

I hope to see more sophistication maybe towards then end of the year; I'm hesitant to give any concrete numbers in the current climate.
483  Bitcoin / Bitcoin Discussion / Re: ToominCoin aka "Bitcoin_Classic" #R3KT on: February 11, 2016, 03:51:07 AM
It seems like even Garzik doesn't agree with the '28 days' nonsense.
28 days seems to be the consensus for an “if we must” hard fork. In the context of a production upgrade cycle at a financial shop, 28 days is more like an emergency update than planned update. 3–6 months is a minimum in that context.
I've told the 'forkers' this several times.
I've wondered if any of them have any experience with large scale production systems at all-- esp any that must have multi-vendor interop.  It's unbelievable.
484  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core vs. Bitcoin Classic on: February 10, 2016, 02:00:35 AM
I just wonder why Gavin is so sure that "thousands of Classic nodes will appear". They didn't appear for XT. Maybe, he knows that "a little help from unknown friends" is sure to come...
I thought the post was pretty clear, it was " People are committing to spinning up thousands" and 'not thousands of people are committed to spinning up a node'-- it's a planned sybil attack-- and that is also what I've seen from this rise of "classic" "nodes". There are several less obvious node count measures that don't show the growth.

AFAICT, the latest strategy is to fake out the node counts with large numbers of sybils and then try to use that to pressure miners into adopting classic; which would then pressure actual users to go along with it. This isn't going to work, and most charitable way I can explain the strategies used by the people frantically pushing for a controversial hardfork is that the people involved in these forks keep thinking that everyone else in Bitcoin is stupid.  How else can you explain the faux urgency-- that almost no one bought-- or the bait and switch policies for miners-- to the cheap characterization that Bitcoin Core is all blockstream and so on?

All these nonsense and attacks frustrate me-- they waste a tone of time and energy that could be used driving Bitcoin forward.
485  Bitcoin / Bitcoin Discussion / Re: Estranged Core Developer Gavin Andresen Finally Makes Sensible 2MB BIP Proposal! on: February 10, 2016, 12:08:34 AM
That's not how it works.

Nodes relay information to other nodes but one node doesn't need to broadcast to the entire network!
The burden of 'massive redundancy' you speak of is distributed across the thousands of nodes,
each responsible for communication with other nodes.
Wow. Now I understand why you're so confused about this blocksize issue.  That _is_ how it works.

Every node in the network must receive and process every transaction in every block. There is no distribution or sharing of that load.

Are you suggesting that jtoomim is not the lead maintainer? Are you playing ignorant regarding the definition of a hard fork?
I don't think classic has been very transparent about its governance. Jtoomim is supposedly lead maintainer, but if you look in the repository he has only made a few small changes and not done much merging. Meanwhile, the project was supposedly created with extensive involvement with people at cryptsy but they seem to have backed out and been removed from the site; ... and Jeff Garzik had one of his change requests summarily overridden and closed by Olivier Janssens. Beyond non-developers with commit access like Olivier there are also many commits being made by people I've never heard of before such as "rusty-loy". None of the membership of the project appears to be public.
486  Bitcoin / Bitcoin Discussion / Re: Hard Fork = Bitcoins * 2 ? on: February 09, 2016, 08:27:00 AM
How best to conduct a hard fork then to avoid coin doubling?
Step 1. Don't conduct one that is being opposed by a economically significant portion of users.

Fortunately this isn't very limiting. In my experience, most feature upgrades that people ask for are most naturally deployed as soft-forks.
487  Bitcoin / Bitcoin Discussion / Re: Matt Corallo proposes 1.5mb blocks after segwit on: February 09, 2016, 08:15:47 AM
It's funny to me that 1.5MB is a slap in the face, yet 2MB (as long as Gavin pushes it) is acceptable.
It's funnier than that: Matt's "1.5MB" would have 31% more capacity than the "Classic" 2MB.

488  Bitcoin / Hardware / Mining history... some odd avalon boards on: February 09, 2016, 07:28:02 AM
At my local hardware surplus place a bunch of gen 1 Avalon boards showed up.

Among them was a board that had none of the Avalon silk screening.

There were also a couple of  interesting mod-wires.

Due to lazyness I haven't dug up my batch 1 museum pieces to see if it looked like these.

(if anyone wants some dusty mining boards for $20/ea)
489  Bitcoin / Bitcoin Discussion / Re: Is it good or bad that Core development is virtually controlled by one company? on: February 09, 2016, 02:07:14 AM
Of course nodes could ignore their blocks, and holders can dump their coins.
There is no need to dump any coins. The nodes _will_ ignore their blocks, as that is the very design of the Bitcoin system-- embodied in every implementation ever shipped; one which _completely_ deprives the ability of miners (even a super-majority) to carry out a broad spectrum of coercively acts against the users of the system. These protections are an essential part of the economic balance which keeps miners honest. Saying "if you shit it up, people will take huge losses (since-- who will buy if everyone knows its screwed) selling out and use something else" is a pretty fringe protection... as a concrete example it's one which has been fairly ineffectual in constraining the monetary policy of popular currencies.

Miners are incentivized by the market to make decisions, they don't make these decisions in a vacuum free of consequence.
I never suggested they did-- quite the opposite. Rather, I point out that the consequence of failing to comply with the hard rules set by the users of the system is that their hashpower is completely discarded while the users notice _nothing_ (except, perhaps, some slower confirmations for a few weeks or until they get a clue).
490  Bitcoin / Bitcoin Discussion / Re: Will Bitcoin 'Hard Fork' in any useful features.. ? on: February 09, 2016, 01:43:59 AM
but then when features like confidential transactions become a thing. the mainblock will have extra data in it that only 1500 transaction would fit. not the old 2000 anymore. and
No, 99% additional data from CT is witness data (the range proofs). So what you're arguing would be true for "classic"'s 2MB direction, but not for Bitcoin Core's roadmap.

I suppose it's not an issue for classic: none of the people involved for it have ever proposed or implemented extensions like that to Bitcoin, none of them are likely to do so.
491  Bitcoin / Bitcoin Discussion / Re: Is it good or bad that Core development is virtually controlled by one company? on: February 09, 2016, 01:33:53 AM
I count 8.89% of all nodes now... where are you getting your data?
/r/btc Bitcoin Classic math: Computing a proportion as x/y instead of x/(x+y). But hey, they're totally ready to handle making critical survival decisions for a global decentralized cryptography consensus system.

Miners have direct control. Nodes /users, merchants, processors/banks/exchanges can and do influence miners by buying or selling their product, the coins. They may even form an altcoin if miners go against them in a way that is intolerable.
This is simply untrue.  Lets imagine that 75% of miners start paying themselves 50 BTC again instead of 25 BTC per block.  Nothing, it's the same as if they simply turned off (which they may do when the subsidy halves). Nodes simply ignore their blocks. So much for "direct control".  Miners do have power over some things-- they can choose the order of unconfirmed and recently confirmed transactions; but they can't break the rules of the system enforced by the nodes... if they do, they're not miners anymore as far as the nodes are concerned.
492  Bitcoin / Bitcoin Discussion / Re: Is it good or bad that Core development is virtually controlled by one company? on: February 08, 2016, 10:46:19 PM
This was already answered. Full nodes can veto the miners at any given moment. All of the miners investments can instantly become expensive useless liabilities if the economic consensus of full nodes rejects the miners longest chain.  
FWIW, full nodes have rejected the most-pow chain on several occasions in the past. E.g. in 2010 there was an incident where software errors caused miners to mine a block that minted a billion bitcoins out of thin air. That fork grew to about 75 blocks. There was another incident in 2013 which made it to about 35 blocks.  More recently, at the enforcement of strict-der, nodes started enforcing the new soft-fork rule with 95% hashpower support, and miners not in conformance with the rule (then a hardfork) managed to produce a chain of blocks 5 longer.

By block count, litecoin's chain has more 'work' than Bitcoin, and yet bitcoin nodes don't follow it.

I think that many people, versed in pre-cypherpunk organizational modalities constantly seek to attribute control to some authority in any system. When they look at Bitcoin they see mining and say "ah, here is the parties that are in charge" (or, alternatively and less  often, some software developers).  They're wrong about that: no one is simply "in charge", and that is a big part of the point and value. It also makes some people uncomfortable, because what they want is the old way of doing things with singular authorities which can be influenced in traditional ways... rather than the personal autonomy of cryptographic proof that backs Bitcoin.

493  Bitcoin / Bitcoin Discussion / Re: Is it good or bad that Core development is virtually controlled by one company? on: February 08, 2016, 10:07:26 PM
Not a word in that link re. "ways in which non-mining full nodes "deeply constrain miners""
Sill waiting, still confused.
They simply ignore blocks which do not conform to the rules of the protocol (and ban the peer(s) that sent them). If the block isn't valid it does not exist any more than a litecoin or a namecoin block exists to the Bitcoin network.
494  Bitcoin / Bitcoin Discussion / Re: Is it good or bad that Core development is virtually controlled by one company? on: February 08, 2016, 07:52:51 PM
I think its safe to say non-mining nodes *never* had any power. In the white paper the word 'node' was synonymous with the word 'miner'. It's only over time that this 'node/miner' separation has arisen.
Bitcoin is defined by hashrate, and the arguments (from all sides, me included heh) that something else *should* matter seem a bit petulant! ...
Hate to agree, but ... That.
but ... that ... is just untrue; it reflects a deep and fundamental misunderstanding of what Bitcoin is. The design of the bitcoin system deeply constrains miners-- and doing so is precisely how it creates economic incentives to keep them honest in the other ways it needs them to be.  Miners cannot mine except in conformance with the rules imposed by the users of the system: it's physically impossible for them to break them.
495  Bitcoin / Bitcoin Discussion / Re: Estranged Core Developer Gavin Andresen Finally Makes Sensible 2MB BIP Proposal! on: February 07, 2016, 10:20:42 PM
there is no HF without them at all regardless of how many people switch.
Hardforks are orthogonal with miners. If a miner is not complying with the rules of the network, then as far as the network is concerned they simply aren't miners. It was "classic"'s choice to gate their hardfork on miner support-- perhaps not a bad choice (though 75% is pretty much the worst possible threshold)-- but no force of nature made them do that.

The best reason for classic to use mining support as the trigger is, I believe, because most of the support for it is substantially fabrication and they believe it will be easy to trick the small number of miners needed to reach 75%, and by taking away 3/4 of the network hash-power they hope to coerce the users of Bitcoin to follow along. I think they greatly underestimate miners and the users of Bitcoin.
496  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core vs. Bitcoin Classic on: February 07, 2016, 10:12:01 PM
Wouldn't citing the results of votes from here require partial trust to the creator/maintainer? It wouldn't be hard for them to hide certain votes from the public to manipulate total results would it?
If you note, the way I always refer to it is to just point to the huge amount of economic opposition to a particular hard fork. That isn't something that is vulnerable to hiding signatures.

But if someone notices their opinion being censored, they could just post their signature anywhere-- here, on facebook, send it via email-- whatever.. and anyone/everyone could try adding it and prove to themselves that the site was hiding views.  So it would be effectively impossible for the site to secretly hide views on a sustained basis.

but I don't really see how it could be turned into a secret ballot.
I know exactly how to turn it into one. But then we'd have the problem of institutions being able to secretly use customer funds with total impunity.
497  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core vs. Bitcoin Classic on: February 07, 2016, 08:29:53 PM
bitcoinocracy has been spammed between every blockstream fanboy and affiliate imaginable.. thus not a fair indicator.
I'm afraid you're confused. Bitcoinocracy is a cryptographic opinion site-- it has its limitations (terrible privacy, etc.) but at least it is resistant to sybils.  Due to the privacy issues, the only places I've ever posted it has been in response to people claiming that no one opposes these recent hardfork proposals. The reality is that much of the promotion of classic is powered by sockpuppets, when you go to more sockpuppet resistant venues (like in person meetings or bitcoinocracy) you see far less to none at all of it.
498  Bitcoin / Bitcoin Discussion / Re: ToominCoin aka "Bitcoin_Classic" #R3KT on: February 07, 2016, 03:55:28 AM
Can anybody explain to me in small words how it's possible for Fidelity or whoever to have planned to send 0-fee 0-value transactions? Is that a bug?
Because the project was to issue securitized assets in "a blockchain" to allow transfer among users.

The bitcoin protocol allows the creation of and transfer of zero value coins. From a technical perspective this is quite useful, for example-- if there were ever a desire to increase the granularity of coins or deploy confidential transactions in a backwards compatible way.. this would be used. Zero value coins could also be used as semaphors in complex smart contracts.

But in the present without applications it's an obnoxious DOS vector and so Bitcoin Core won't relay or mine them; but miners can easily bypass that restriction and already do so.

Plus, even if zero was blocked blocked... the alternative would be to use 1e-8 BTC payments which is so tiny as to be almost nothing. (A single Bitcoin in 1e-8 BTC payments would use 6GB of blockchain space).  The point that these "applications" can be done without any use of the Bitcoin currency _at all_ just lays bare what an abuse of the system they are.

BlindMayorBitcorn, I can't help but observe that flooding a thread with tripe-- as you appear to be doing-- when it isn't going your way is literally straight out of the GCHQ public communication subversion playbook. Also, did you forget to switch accounts? You're responding to yourself.
499  Bitcoin / Bitcoin Discussion / Re: ToominCoin aka "Bitcoin_Classic" #R3KT on: February 07, 2016, 02:59:25 AM
Presumably because "Bitcoin Classic" is probably the most offensively newspeak-ish name in the history of software development.
500  Bitcoin / Bitcoin Discussion / Re: ToominCoin aka "Bitcoin_Classic" #R3KT on: February 06, 2016, 09:40:51 PM
Another concern for them is the "Fidelity Problem" where certain institutions and business models simply won't directly use bitcoin because it cannot handle the volume that is required
It's important to speak specifically about what this proposal was.

What they wanted to do was use payments of zero bitcoins to track non-bitcoin related assets by storing their data in the Bitcoin network. No Bitcoins would have been involved in this project, likely not even for fees: bypassing the network anti-spam rules would have required a relationship directly with a miner-- and then they could have been paid directly in fiat (saving them exchange fees).

No remotely sane amount of block size would have reasonably satisfied this application in any case (you'll note that this kind of ask never comes with the requirement spelled out: the business requirement is almost always, "as large as we need"-- something which is fundamentally impossible in a decenteralized network like this).

I think those of us who actually own Bitcoins should be looking at this, with a sigh of relief and not concern-- a situation where the system's costs were increased tens to hundreds fold by someone not using the Bitcoin currency would be potentially devastating to the systems' decentralization. If it means anything at all to us, that project should be considered a great example of why a blocksize limit is important and protective even over miner imposed soft-thresholds.

-Aren't > 100kb transactions already non-standard?
-Why yes they are, blunderer! You're so smart!
Yes, they are.. which means they're available to be used in the future when a need arises. The transactions that are CLTV or P2SH spends used to be non-standard, and now they're frequently used. Prohibiting larger transactions would be a really unfortunate reduction in capability.  Some people don't think so, because they believe that Bitcoin is centrally administered and that all users can be forced to upgrade in less than a month should the administration decide to undo that decision.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 241 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!