Bitcoin Forum
March 31, 2017, 12:52:06 AM *
News: Latest stable version of Bitcoin Core: 0.14.0  [Torrent]. (New!)
  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 ... 235 »
1  Bitcoin / Development & Technical Discussion / Re: Is the feature "reclaiming disk space" really implemented in Bitcoin Core? on: March 25, 2017, 09:40:44 PM
That being said, while Satoshi's idea with reclaiming disk space is not implemented exactly as he describes, we do have blockchain pruning. This however does require still downloading all 110+ GB however it will not all exist at the same time on disk. Currently pruning will delete on the fly, once a block becomes old enough, it is deleted to make space for the next block. Pruning has been around for over a year now, it was first introduced in Bitcoin Core 0.11.
You make it sound like pruning is worse, in fact it's tens of times more efficient than whats described in the whitepaper. Both have the need to transfer data in the first place (note that it's 'reclaiming disk space' not 'avoiding bandwidth usage' Smiley ).

To the unanswered part of the OP's post:

Sites like aren't nodes. They are custom databases that take up many terabytes of space. They don't validate things (at least not completely) and often show invalid data.  What they do is unrelated to how nodes work.
2  Bitcoin / Bitcoin Discussion / Re: Fuck: SegWit, LN, Blockstream, Core, Adam Back, and GMazwell on: March 25, 2017, 09:37:23 PM
Would you please stop obsessing over me?  It's creepy.

I am not your mommy.

You do not get to determine how I spend my time, you do not get to restrict what I say or believe.  I don't force anyone to do anything. You will you make me cow down and obey you through threatening me by lying to the public to try to raise a mob of idiots against me, and even if you do manage to get me killed you will not stop bitcoin, you will not convert it to the centralized coin you seem to so desperately want.

So give it a break.

3  Bitcoin / Bitcoin Discussion / Re: Article 2,Section 1, Articles of Federation of BU + Closed Source Patch!? on: March 23, 2017, 01:37:41 AM
Of which specific libraries was this a license violation?

4  Bitcoin / Bitcoin Discussion / Re: Article 2,Section 1, Articles of Federation of BU + Closed Source Patch!? on: March 22, 2017, 11:37:46 PM
it seemed to be predicated on the fact that immediate release would reveal the precise nature of the vulnerability to additional attackers.

There was exploit code for this latest crasher posted on the 13th, and people on the BU forums pointing to it... the "new" vulnerability was just above the old one in the control flow.

What was there to protect when almost all the reachable BU nodes were already down?

Whether or not that was the proper course of action is something that can be debated.
I can't think of a single piece of free software that has done this in the last decades, including highly critical software like OpenSSL. It's absurd. What BU did was also technically a license violation of some of the libraries.

I think the only thing left to debate is if they're trolling or if they're really that clueless. Smiley
5  Bitcoin / Bitcoin Discussion / Re: Segregated Witlessness on: March 18, 2017, 07:08:55 PM
you do know even when activated core wont have a walet enabled release for people straight away...
The wallet in Bitcoin Core supports segwit (it's what most people use for testing!), it just doesn't use it by default.

you do know why segwit needs to be upstream filters and actively ban other non-segwit nodes from being upstream. this includes banning pools and their non segwit blocks from being added on after.

Lie. They do not ban non-segwit nodes.

you do know why segwit will not relay segwit unconfirmed tx's to non-segwit nodes.


not only that but the sigop quadratic spamming is not solved due to it not stopping native tx's

Misleading: you can't cause much problems with tx limited to 1MB, esp due to other optimizations. Which is why nothing other than optimize was done about it before.

Segwit fixes it where it was critical to do so... and it can't be 'fixed' for old transactions without confiscating funds.

the malleability is not solved because it does not stop native tx's

Lie. You can choose you make your transactions completely immune to third party malleability with segwit. (Malleability is a feature which you can _choose_ to use, explicitly supported-- it's only the unwanted, unpreventable, third party malleability which is an issue, and segwit eliminates that.)

the tx count wont reach expectations because it does not stop native tx's

Native? you mean the older kind.  Well duh people can make needlessly big transactions and pay more to do so-- that is true for any block size change.

(some attacks have been highlighted. even i highlighted the main one last year, which led to the whole ordeal of not releasing the segwit key wallet until way after activation. but even then there are still attack vectors that can and will happen with segwit tx's and native nodes after activation).

Another lie.

hint: though segwit nodes mess with ban lists

Repeated lie.

and not auto relaying unconfirms to native nodes..

Repeated lie.

some script kiddie can manually copy the segwit mempool and push segwit unconfirms into their native nodes mempool and have a nice play around.

Another lie.

Gee, franky1 do you get paid by the lie, or what?
6  Bitcoin / Bitcoin Discussion / Re: Why can't the NITWITS understand that SEGWIT IS DEADWIT on: March 16, 2017, 07:24:24 AM
The things you are calling out explicitly there, the taking coins and creating coins-- those were flaws in the very first release of Bitcoin-- many of them design flaws in the algorithms, not just software bugs.  (and several of those items aren't bugs at all-- but just updates for past softforks.)

And they were issues in the whole large program, not just a "few" changes recently made.

The resource exhaustion attacks are things that BU even refuses to fix, e.g. BU has a trivial dos of xthin via collision attack and they just won't fix it. ::shrugs:: In fact, one of the items there "A transaction that takes at least 3 minutes to verify" BU reintroduces but zillions of times worse.

BTU is the third of these absurd amateur hour clones of Bitcoin Core.  All the other ones have fizzled when the people realized that they are a lot of hard work when you can't just count on copying from Bitcoin Core.

There were larger miners than now actively opposing P2SH, not just not using it yet.  Have patience.  Bitcoin is forever, not just for next week.
7  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 14 mod on: March 16, 2017, 07:14:55 AM
Download a third party pre-compiled binary at your own risk.

static const int MAX_SCRIPTCHECK_THREADS = 32; /16/

Useful for those who have PC's with greater than 32 physical cores, otherwise increased context switching will make it slower.

This is not useful when you have more than 16 cores: it will be considerably slower, even when you do have many cores. The numbers were set based on actual measurement on 48 core systems. Overheads dominate by the point of 16 script check threads.

Similarly, increasing outbound connections just wastes resources, severely _hurts_ your latency, and will end up getting you banned by many people (same thing for the addnode maximum).  (Several people correlate hosts that are mass connecting and add them to shared ban-lists -- once your address is on these lists it won't come off for a long time).

It will also not improve your sync speed on practically any system-- sync is verification/database bound and when it isn't, it's usually reorder buffer bound.

The outbound connection increase is especially bad for miners because it increases your connection service loop time, and keeps your block in the linear regime longer where  it's just your node replicating the block rather than an exponentially growing cone.  An optimized mining setup has mining nodes with a minimal number of connections connecting to multiple border nodes and relay networks (e.g. two local border nodes, one remote border node, two reliable external nodes, and one relay network). At least one of the border nodes should  be outbound only, and at least one should accept inbound (usually best to do with remote nodes, in case it attracts dos attacks).

Most of the other settings changed can just be changed with the config file and command-line, anything with "DEFAULT" in the name.

The download window changes will likely cause database corruption if you use them with pruning. The checkblocks/checklevel changes will do effectively nothing (also controllable from the commandline).  The MAX_BLOCKS_TO_ANNOUNCE will just waste your bandwidth in the event of a huge reorg.

The timeout interval change will make you easier to DOS attack, causing you to wait longer on messages that will never be answered.

sometimes it helps to pay less fee to be earlier confirmed
This is absolutely untrue. What you broadcast to has nothing to do with what fees you pay.  

static const unsigned int DEFAULT_MAX_PEER_CONNECTIONS = 512; /125/
static const size_t DEFAULT_MAXRECEIVEBUFFER = 32 * 1024; /5*1000/
static const size_t DEFAULT_MAXSENDBUFFER    = 32 * 1024; /1*1000/

I hope you have at least 32 GB of ram, because that is the peak memory usage these (commandline accessible) options imply on top of the nearly 2.5GB of other usage implied by  other settings. Smiley

Core is compiled with -Ofast flag instead of default -O2: more compiler optimizations, depends by default settings.
Which permits optimizations which may produce incorrect results... mostly which shouldn't matter for Bitcoin Core, but O3 should also be just as fast and would only suffer from compiler bugs, and not directly unsafe optimizations.

Virtually all these settings which can be safely tinkered without much danger of screwing things up and without musch understanding are command-line options.

Changing things further is great-- but you should probably take some more time to understand what you're changing, especially before inviting others to use your changes!

Work on making the rescan faster would be very welcome. The largest likely improvement there would be bypassing hash validation when reading blocks from disk.
8  Bitcoin / Development & Technical Discussion / Re: Typo in key.h on: March 16, 2017, 06:52:57 AM
In the bitcoin core file key.h there is a typo:

//! Check whether the 32-byte array pointed to be vch is valid keydata.
     bool static Check(const unsigned char* vch);

The comment should read:

//! Check whether the 32-byte array pointed to by vch is valid keydata.

I am not registered so I cannot submit bugs. Maybe somebody who works with the code base can fix it.

Thanks for pointing this out-- only takes a second to register on github... but if you don't it'll get picked up eventually.

Please feel free to report any other issues you find (though best on github!)
9  Bitcoin / Development & Technical Discussion / Re: Malleated Transactions on: March 15, 2017, 07:47:44 PM
Using a tagged format for a transaction is a one-time hard fork to upgrade the protocol and allow many more changes to be made with much lower impact on the system in the future
Nope, changes to the tags require another hardfork. So much for avoiding impact.

Where SegWit tries to adjust a static memory-format by re-purposing existing fields,
Sewit doesn't repurpose any fields, it adds fields. The transaction format isn't static.

Tagged binary formats are a repeated source of vulnerabilities, as I mentioned the one that was being used in Bitcoin-- ASN1 has caused problems even for our very narrow use of it.

I won't elaborate more because I said much of it above and all you did was simply repeat the same claims without responding to any of it.

   Where SegWit adds a huge amount of technical debt, Flexible Transactions proposal instead amortizes a good chunk of technical debt.
This is just an outright lie-- go ask any actual Bitcoin developer: Segwit makes Bitcoin much easier to use. While FT adds a pile of complexity that results in vulnerabilities (including cryptographic compromises), and has _already_ done so in Zander's own codebase.

6. If anyone becomes understandably irate with their behaviour after N repetitions of 3-5, point the finger: "See? See how unreasonable they are, they know they've lost the argument when they lose their temper"
It should be "You know you've lost the argument when complex lies and tricks are all you can do to 'win' "

Yea, it's the same crud over and over again over a ever shifting sea of nyms-- some of them probably socks, other people just weaponized innocents.  The end result is that the people that get to deal with the disinformation and are working to defend Bitcoin from it learn to recognize the repeated arguments at their first sentence and cut it off curtly -- and then you get a pile of out-of-context links  "Oh look how mean they are! that was unjustified." -- yea, unjustified unless you also saw the same lies being repeated over and over again for months. Sad
10  Bitcoin / Press / Re: [2017-03-15]Bitcoin Core Developers Attack Bitcoin Unlimited on: March 15, 2017, 03:18:05 AM
This post is a dirty fucking lie.

Every Bitcoin user should be outraged at this libel.

BU shipped vulnerable software. BU disclosed their vulnerablity in public. Random people on the internet broke their shit.

Now the BU org claims "Bitcoin Core" did it?


The only thing contributors to Bitcoin Core have done here is gone "WTF".
11  Bitcoin / Development & Technical Discussion / Re: Malleated Transactions on: March 14, 2017, 03:17:49 AM
It does this by subtly changing the meaning of the fields so that older clients think they are validating the transaction but they really are not, rather than just knowing that they aren't capable of properly validating that transaction version. Specifying a new version number for the transaction lets you be honest with old clients and you can't possibly make the mistake of misinterpreting the context (SegWit or not) resulting in application of the wrong interpretation to the field.

This is disinformation that you're peddling here.  Segwit uses an _explicit_ _intentional_ forward compatibility mechanism.  Old nodes _know_ that the segwit transaction is making use of rules they don't understand, which is why they will not relay, mine, or display unconfirmed txn using it in their wallets.

By using a tag based system, FlexTrans allows you to skip fields that are not used in the transaction, simplifying most transactions as you do not have to parse and interpret fields that that are not there.
Go look at the history of ASN1 and XML-- 'tag' based formats, they're freeking disasters in the context of cryptosystems. They result in malleability bugs and all sorts of other disaster cases-- Bitcoin itself has had several vulnerabilities related to ASN1 just being used inside signatures. The extreme complexity of FT is also revealed by the fact that it's authors reference implementation had at least three buffer overflow vulnerabilities...

The design also doesn't actually create the flexibility it claims, since changing the fields requires a hardfork. ... and a hardfork could already have done anything. So there is no reason to have an overly generic structure in advance, it simply leads to vulnerabilities and inefficiency.

This also makes the transactions smaller (and thus cheaper) than SegWit transactions.

Actually, the FT format actually increases the entropy of transactions because the ordering of fields is signature normative by not canonically mandated.  This means that it actually takes more data to make an efficient representation of FT transactions than ordinary and segwit transactions.

SegWit works by moving data into the coinbase which really isn't what the coinbase is for.
Segwit doesn't move any data into the coinbase. Perhaps you mean that it includes a *commitment* (not data) in the coinbase transaction (though not in the coinbase itself)? This is specifically an intended use of the coinbase transaction, which it has been used for since ~2011... and it's a use that Satoshi recommended-- in fact.

Kinda funny how you asked a question but then followed up with a mountain of pretty extreme misinformation.  It's especially amusing to hear you in one breath attack an idea (fields that nodes explicitly ignore) while in the next extol the same concept.  It makes it hard for me to believe that you're really asking this stuff earnestly.
12  Bitcoin / Development & Technical Discussion / Re: Who moderates bitcoin-dev mailing list? on: March 14, 2017, 03:09:59 AM
BIP16 had a full support from the miners.
No it didn't it had support from maybe about ~55%  from what I recall and was opposed by the largest pool of the day (deepbit).

If it'd have at least a support of 51% of the miners

That is just simply untrue. Damn man your dogmatic ignorance is making me want to go read up on the proposal just so I can support it.

The users of Bitcoin define what mining is, if you cross them you are not a miner.  In that sense, it is impossible for 100% of miners to not support anything that the user base has decided on...
13  Bitcoin / Development & Technical Discussion / Re: Who moderates bitcoin-dev mailing list? on: March 13, 2017, 05:03:43 PM
I don't think that list of moderators has changed.
Rusty is not a moderator. I don't know who are moderators now.

Personally I don't go anywhere near that list. It's full of abusive people like Thomas Zander who just crappost relentlessly.  It's a waste of time.

You're insane, man.
There is absolutely no way the UASF can work.

Meh. I don't know why you say that: BIP16 was flag day activated.  I haven't really been following, but some people seem to think a controversial HF should work and a flag dayed softfork-- if it's a miner compatible softfork like segwit at least-- should be strictly simpler and less risky than that even in the worst case.
14  Bitcoin / Bitcoin Discussion / Re: Segwit IS the compromise: everybody is equally unhappy with it, including me on: March 12, 2017, 08:30:48 PM
Segwit doesn't give any spammers more power than they have had before, in fact it makes them much weaker.

It improves the system by changing the limited quantity from "size" to weight because weight better reflects the true costs to the system than size.   Size is totally irrelevant for pruning nodes, with fast-block-relay-protocol, BIP152, and Fibre size is almost totally irrelevant.  It matters for non-pruned nodes, but at the current size and growth rates those are already effectively pushed out of using cheap fast storage-- e.g. you're not likely to run a node on a 256GB SSD anymore.

e.g. see the stats from Matt's public fibre network:

-- with the exception of small or effectively empty blocks that fit into a single packet, the size of a block has no real effect on its propagation time.  (Time figures are in millisecond delay over the speed-of-light time)

Though size is decreasingly important, UTXO impact remains important as we previously ignored in the past limits. Because size is blind to UTOX impact:  A spammer could create transactions that bloated the UTXO set and paid _less_ per byte than ordinary transactions.

One possible solution is multiple distinct limits but a problem there is that with multiple limits in play it is impossible for wallets to figure out appropriate fees, because the right fees would depend on the exact mixture of transactions at play when the block is created. Multiple effective limits also make creating an income optimizing block very computationally difficult-- but with one limit you simply take transaction in order of fee per limit-used.  So to avoid that the weight limit combines both witness and non-witness (utxo impacting) limits into a single limit.   Whenever this is done, improving one factor (e.g. amount of worst case UTXO bloat per byte to typical) will make another worse (e.g. worst case amount of size.).  Segwit's parameters were set to massively decrease the amount of UTXO bloat possible while only increasing the worst cast size modestly:

Green line is how many times beyond typical a UTXO Bloat block can be, red line is how many times larger than typical a "size" bloat block can be.   X is the segwit factor, which is 0.25 in the actual segwit proposal.  The pre-segwit behavior is effectively an X of 1.

Since UTXO costs are much more concerning than size on the modern network it might be arguably to set the segwit factor even lower, but the size bloat goes up hyperbolically with a lower factor.  So even though size is less important the trade-off becomes less attractive with values much lower.  The value chosen for the proposal also happens to be just about what is required to get virtually all the capacity gain from this particular restructuring, owing to the typical ration of witness to non-witness data in transactions.

All that said,

Segwit is indeed a compromise: Increasing the networks' load and capacity is a non-trivial risk that may ultimately cause harm.  Segwit does a lot to mitigate that risk, but it remains.  It offers effective the same capacity that that the hardforksers were pushing for w/ Classic & BIP109 before they moved the goalposts again after a way was found to achieve that without splitting the network.

It just isn't a compromise because malicious miners could make blocks with 4MB size-- they could, but who cares... blocks with 4x more UTXO bloat would be a _much_ greater concern. And under the constraint that there be a single limit-- needed to make block creation and fee selection tractable-- improving the one bloat attack means that that the worst case for the other, less important, one will be worse.

15  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.14.0 Released on: March 09, 2017, 07:44:30 AM
for the next release, please ... introduce the scheduled saving of mempool (like every 10 minutes or every blocks).

the node don't save mempool when ... it crash suddenly.

If your node is crashing suddenly then you have worse things to worry about.

The mempool saving was originally written so that it wrote it periodically but writing 300 MB every N minutes is not good for performance or write durability of your media.  I suggest fixing your crashes, losing your mempool state is the least of your worries. Tongue
16  Bitcoin / Development & Technical Discussion / Re: BU's "honest miner" security model on: March 01, 2017, 05:41:56 PM
In BU, nodes can validate blocks
just as they can in Bitcoin, and simply ignore blocksize as one
less constraint for validity.
Ignoring the block size would be one thing-- just an ill-advised hardfork which would erode the decentralization of the system-- but BU replaces the validation based consensus model in Bitcoin with "emergent consensus", which is radically different and not an improvement.
17  Bitcoin / Development & Technical Discussion / Re: BU's "honest miner" security model on: February 28, 2017, 11:42:56 PM
There is no maximum blocksize in the whitepaper and We BU proponents do not believe blocksize should be part of the consensus rules.
Then they should admit that what they want is a system which is different from the one Bitcoin's creator released. There is also no mention of 21 million coins -- why not 42 million-- there is no mention of Bitcoin Script, nor of 1001 other parts of the system.

18  Bitcoin / Bitcoin Discussion / Re: Johnny (of Blockstream) vs Roger Ver - Bitcoin Scaling Debate on: February 28, 2017, 05:22:13 PM
i hate this because gmaxwell loves his monero
I don't do anything with monero.

and elements/liquid,
Elements and liquid use Bitcoin (well testnet Bitcoin and Bitcoin respectively.)

not so much bitcoin.
I own a considerable amount of Bitcoin and am paid partially in Bitcoin.

i feel gmaxwell doesnt care about bitcoins survival and

I feel like you are a paid shill trying to destroy Bitcoin. I probably have more evidence of that than you have to argue about me.

yet people are following gmaxwell, because of old outdated stuff he done before he got into the bankers pockets and changed motives.

I am not paid by bankers. I am paid by a company I founded whos investors are not bankers.  And many people are excited about work I've done that was funded by this company like Confidential Transactions and sidechains.

and allowing bitcoin to change due to human emotion of trust of another human. without bothering to just read what code was wrote and what the actual codes does to the network.

The irony is that you're posting here nearly 24 hours a day arguing to change Bitcoin. I think Bitcoin is okay the way it is.
19  Bitcoin / Development & Technical Discussion / Re: BU's "honest miner" security model on: February 28, 2017, 08:07:41 AM
If the attacker is overpowering the network, as noted, they can produce any number of blocks ahead on their chain. Not just 12.
In the real world, an attack isn't a simple logic it can be done / not. There are costs.
Even now "it is possible" a 51% attack from an "attacker overpowering the network", and the only solution is a pow fork,
Are you not even reading the pieces of the whitepaper we're quoting here? An overpowering attacker making invalid blocks is simply ignored by network nodes. There is no reason to change the POW.

More work on small and easy to validate blocks? Seems good to me.
You are too vague here.
No, just more work. It doesn't matter how big or slow it is, BU will follow more work even with those changes, because it has abandoned the consensus model of Bitcoin and replaced it with strong trust in miners. Instead of having a process that guarantees consensus it is a free for all that hopes cartel activity will cause an undocumented consensus to "emerge".
20  Bitcoin / Development & Technical Discussion / Re: BU's "honest miner" security model on: February 28, 2017, 05:56:44 AM
As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network.One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, [...]
"simplified method"

The quote refers to the SPV clients, while instead we are talking about full nodes verification.

The text is also talking about full nodes. I've re-bolded to help you out.   As it nodes, an attacker might overpower the network with invalid blocks (this is not possible in the BU security model, because having more hashpower is the definition of "valid" there, and it states that this is prevented by network nodes because they validate, but in BU the network nodes trust miners instead of enforcing on their own.

There is also a big difference on "trusting the miners" and "trusting the legit miners". BU nodes trust the legit miners.
Where is the difference? Legit BU miners aren't going to blindly accept blocks bigger then their EB settings.
Because this damaging the users and belief in the Bitcoin system will damage their income.

So, the possible attacker (from the quote of the bitcoin.pdf you have reported) will just mine huge blocks that will go nowhere.

BU nodes instead (with the current default setting, that the user can freely change) aren't going to accept bigger block without 12 consecutive blocks after it. (AD setting)
If the attacker is overpowering the network, as noted, they can produce any number of blocks ahead on their chain. Not just 12.

If someone thinks that a 13 block attack is still possible ... there is also this coming:
Parallel Validation: (being developed here)
The first block downloaded and validated wins.

No: more work wins, all that change does is potentially influence the behavior on ties of equal work (and potentially enable new selfish mining strategies, while slowing down validation and making it more memory hungry). Meaning an overpowering attacker can do whatever they want. This is the BU model and it is unlike the model described in the Bitcoin whitepaper or implemented in any version of the software ever released.
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 ... 235 »
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!