Bitcoin Forum
May 29, 2017, 02:24:20 AM *
News: If the forum does not load normally for you, please send me a traceroute.
  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 ... 237 »
1  Bitcoin / Bitcoin Discussion / Re: Why Bitcoin Core Developers won't compromise on: May 26, 2017, 08:30:34 AM
a valid block is simply by definition, that block on which miners decide to build the rest of the chain.
This directly contradicts the text of the whitepaper-- which specifically talks about an attacker overpowering with invalid blocks:

As such, the (simplified) 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 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,

But more importantly, it contradicts the behavior of every version of Bitcoin ever released, including all those released by Satoshi. It also contradicts the behavior of every blockchain like altcoin that I'm aware of.

2  Bitcoin / Development & Technical Discussion / Re: Coins of Satoshi on: May 20, 2017, 06:59:05 AM
No one has any idea what coins are Satoshi's -- except for the coins paid the the block 0 address and those left over from block 9.

People speculate about a lot of things-- but most of these speculations are provably false or are at least completely unsupported.--- they just get spread around to justify the super massive and unethical premines in systems like Ethereum.

For all we know Satoshi might only own a small amount of Bitcoin.

Regardless, you're sure as hell not going to take anyone's Bitcoin's from them.
3  Bitcoin / Development & Technical Discussion / Re: Suggestion for the bitcoin Core GUI: QR-code for easy connection to trusted node on: May 18, 2017, 01:53:43 AM
The probleme here is, that for this functionality, you need to have a listening server at your bitcoin-core and opened a specific port in your firewall, and port forwarding enabled if you have a router and want this to work over the internet (and a static IP address or dynamic DNS).
The integrated tor hidden service support could be pretty helpful here...
4  Bitcoin / Bitcoin Discussion / Re: Why Bitcoin Core Developers won't compromise on: May 18, 2017, 12:36:14 AM
AgentofCoin, Thanks. I agree with basically every point made in your last two posts.

If they had to
do it in a hardfork way, I am not sure they would have proposed it. When it was
provided as a softfork, they thought the community and miners would be thrilled.

Precisely, in fact getting many people to agree to a capacity increase at all given the current environment was very difficult.  The primary selling points was that segwit was risk reduced in many ways (e.g. lowering sighashing cost), that we had other scaling tools planned (BIP152 for example), ... and that it was worth taking some risks to satisify the demands and end the drama.  Oops.

From my perspective: the community already already compromised on the part that we thought we could compromise on.  Beyond that and it's akin to demanding 'compromise' in the form of sawing a disputed infant in half.

I think it's fine and healthy that it takes a while to sort these things out.  Internet scale protocol development doesn't happen fast-- 4Byte ASNs in BGP took about a decade, and BGP is a easier to evolve than Bitcoin in many ways.

In any case, in my view, the slogan should be:

Bitcoin will not be compromised.

5  Bitcoin / Bitcoin Discussion / Re: Why Bitcoin Core Developers won't compromise on: May 14, 2017, 08:28:14 PM
In this thread: people whining that they're unable to force third parties to compromise Bitcoin.
6  Bitcoin / Bitcoin Discussion / Re: Major crash no. 5 for BU nodes. on: May 09, 2017, 08:24:25 PM
I count about 11.

Honestly though, I don't care either way. I just want to stir the pot also.

Wow, repeating proven fraudulent claims from the BU folks, good for you.

Those ticks are spider restarts, a data artifact.  There has never been an exploited node crasher for the Bitcoin project (and AFAIR there has only been one potential one, which we fixed before it was exploited-- The BIP37 integer divide by zero bug)
7  Bitcoin / Development & Technical Discussion / Re: No inbound connections after pruning on: May 08, 2017, 01:34:05 AM
Thanks a lot achow101 Smiley

well, this is very bad. DNS seeders should not behave like that, because pruned nodes can still help a lot the network.
And you still will-- by relaying blocks to the nodes you connect out to.

what should happen is that only the nodes that are making the initial download require NODE_NETWORK service.
Right now there is no way to distinguish nodes that can serve blocks near the tip with ones that can't serve blocks at all.

And there are plenty of nodes that can serve everything, so adding more flags hasn't been the highest priority.  Though there has been recent progress on that.
8  Bitcoin / Development & Technical Discussion / Re: small blocks actually making it harder to run a node? on: May 05, 2017, 05:35:32 PM
Smaller mempool just means that unconfirmed transactions need to be dropped from the mempool sooner
And that the minimum feerate to relay and get into the mempool in the first place will go up.
9  Bitcoin / Development & Technical Discussion / Re: small blocks actually making it harder to run a node? on: May 05, 2017, 04:40:50 PM

Smaller blocks reduce memory usage, considerably.

The mempool does not increase memory usage because it has a fixed size and is shared with the dbcache. If blocks were larger the mempool would also need to be larger by an equivalent factor so would many other parts of the system.

Moreover, no matter what the blocksize was someone could inexpensively produce a bunch of transactions between blocks and make your mempool as big as you want.
10  Bitcoin / Development & Technical Discussion / Re: The case for moving from a 160 bit to a 256 bit Bitcoin address on: May 03, 2017, 11:02:38 AM
Also, It looks like the new 256 bit hash format is part of the current segwit proposal, correct?
Yes, Segwit script v0 P2WSH (the p2sh for segwit) uses 256bit SHA2; both boosting the security to 128 bits, and removing ripemd160 from the potential locations of weakness.

There is a 160 bit supported, but only for single key checksig only. Basically so that the very common single key case that gains little from the 256bit hash isn't any longer than non-segwit.
11  Bitcoin / Bitcoin Discussion / Re: Alleged Bitcoin Founder Satoshi Nakamoto creating Bitcoin Core Competitor on: May 03, 2017, 09:03:14 AM
Why do you write "alleged creator" instead of "established fraudster"?

Wright has show himself to be a fraudster beyond any doubt, and even before it there was almost nothing supporting his claims... a significant percentage of this forum has a better claim on being Satoshi than this con-man. True: they're not claiming it and he is, but they haven't been caught lying about it over and over again.

Wright has been fanning the blocksize drama all along-- it's a simple formula for separating less technical business people from competent engineers that could point out the obviousness of his fraud.

Sounds like the funding for this thing is fake too:
12  Bitcoin / Bitcoin Discussion / Re: Is diversity in bitcoin client implementations a good or a bad thing? on: May 03, 2017, 08:34:43 AM
If one implementation goes down or has a bug, then only the users of that implementation are affected.

This is true for many things but not for consensus systems.

In a consensus system with multiple major implementations if _any_ implementation has an issue everyone has an issue-- and if there is just a "disagreement" but none are objectively wrong, then there is still an issue.

The reason for this is that for a consensus system the primary purpose is to be consistent, so any inconsistency is a failure, regardless of whom is "right" vs "wrong" or even an otherwise harmless difference.  Inconsistency immediately creates an opportunity for funds theft, when you think a state is final but it really isn't and it gets reversed.

An implementation is a _precise_ definition.  A pile of paper is not, or to the extent that it is precise it's still not that relevant: if paper says X and the network does Y, then Y it is, you can't generally just undo Y later without undoing transactions that people thought were final and irreversible.  Good specs are useful to aid understanding and analysis, but cannot define the network because they cannot control its action from moment to moment.

The implications are clear to anyone who has spent a reasonable amount of time doing serious engineering for a distributed consensus system.
13  Bitcoin / Development & Technical Discussion / Re: The case for moving from a 160 bit to a 256 bit Bitcoin address on: May 03, 2017, 08:24:34 AM
My intuition is that on average it requires twice as many P2SH addresses to be generated as the "birthday problem" would (since each new address in one set is effectively a new potential match in the other set)?
You've got it.

You should generally think of birthday problem numbers as approximate in any case,  because to achieve the bound you need lots of storage.  A cost optimized solver will make some time/memory tradeoff and usually end up using a couple times more computation than the birthday number in exchange for little to no storage.  (google floyds cycle finding algorithim)

And yes, thats the risk-- that your counterparties degree of freedom in choosing part of the contract will let them find an alternative contract with only collision like work, rather than with second-preimage like work.

You can mitigate by having multiple rounds of communication with commitments, but few to no one will implement this in practice:  Each communication round is a huge software engineering and UI cost, and most people don't understand this collision vulnerability (or _any_ collision vulnerability) even after having it explained.  The longer hash should also be somewhat more secure against second preimages assuming our hash functions become weakened by attacks in the future.

[Basically _any_ time I've seen a collision come up in discussions about the protocols people-- even people who should know better-- get them wrong. Someone on Reddit just the other day argued that a 64-bit collision would take 2^64 work, so I generated one based on his message.. then he argued that I got really lucky to have managed to produce one using only a 32-bit nonce and couldn't provide another, so I did... Tongue  they're highly unintuitive to people)
14  Bitcoin / Development & Technical Discussion / Re: The case for moving from a 160 bit to a 256 bit Bitcoin address on: May 03, 2017, 12:40:04 AM
The "birthday problem" calculates the odds of ANY TWO addresses in a set matching EACH OTHER.
Unless I'm misunderstanding gmaxwell's post, he's talking about ONE address in a set (the work) matching a specific given address (the contract).

I'm sorry if I was unclear.   You are not provided with an address. You are provided with a public key.   Now you construct many possible addresses looking for a pair where one is a plausible contract and the other lets you spend all the coins.

You show your counterparty one, then spend with the other.
15  Bitcoin / Development & Technical Discussion / Re: The case for moving from a 160 bit to a 256 bit Bitcoin address on: May 01, 2017, 11:45:37 PM
how long would it take to burn through 255 addresses at only 3 TPS,

I think you haven't caught the real reason that 256 bit addresses are important.  Any N-bit address has only N/2 bits of security against collision, right?

So here is the interesting attack:  You give me your pubkey, and then I create my pubkey for a 2-of-2 (or some other more elaborate contract), and then we pay to the resulting address.

Oops.  In the background I did ~2^80 work and found a colliding address which didn't have the same policy, and I use it to steal the funds.

2^80 is a lot of work, but it isn't enough to be considered secure by current standards.

Unrelated, it's also the case that many hashes of the same vintage of ripemd160 have been significantly broken or substantially weakened.

there's a lot of other "wasting room" on the transaction, and the most important one to me is the hash of 256 bits indicating the transaction.  This is overkill.   There is also the 32-bit number indicating the "output number of the transaction" as if transactions would contain 4 billion outputs.   This is wasted space.
You are free to store transactions however you like and negoiate with your peers to send them however you like, there is no need for space to be wasted as a product of serialization.  Using a larger hash does take up more resources but the difference is pretty small compared to the rest of the transaction.
16  Bitcoin / Bitcoin Discussion / Re: "Bitcoin" Unlimited Officially #REKT on: April 26, 2017, 12:36:30 AM
his is down to G Max &
Please show how I've "kept" anything at anything, or retract your slander.
17  Bitcoin / Bitcoin Discussion / Re: "Bitcoin" Unlimited Officially #REKT on: April 26, 2017, 12:07:44 AM
um you forget the core 2013 DB event
You mean the _day one_ bug in the software Satoshi wrote?  Software prior to 0.8 would fork against _itself_.   BU _intentionally_ forks like that as part of its design, they call it "emergent consensus" because the proper term of "consensus failure" is rightfully pretty scary.

.. but wait.. core crashed 560 nodes on the 17th... hmmmm

No it didn't. You're looking at spider restarts, not actual outages. Funny that you'd make this same "mistake" Bu previously did and got called out for

Off the top of my head I can only recall exactly one straight up remotely triggerable crash that has ever existed in the Bitcoin codebase--  a divide by zero added via the bloom filtering extension that Hearn demanded be deployed far too hastily-- and it was found and fixed by the developers before any attacker every found and exploited it.
18  Bitcoin / Bitcoin Discussion / Re: Segregated Witness vs Bitcoin Unlimited vs Do Nothing on: April 25, 2017, 10:12:51 PM
It started with Core...
No it didn't.
I guess this means you know who was behind ddos attack?
The post I was responding to has someone who was claiming to be responsible.
19  Bitcoin / Bitcoin Discussion / Re: Segregated Witness vs Bitcoin Unlimited vs Do Nothing on: April 25, 2017, 07:22:35 PM
It started with Core...
No it didn't.
20  Bitcoin / Development & Technical Discussion / Re: How to use properly secp256k1 library on: April 25, 2017, 12:00:09 AM
G***it.  For Bitcoin talk moderators there is an edit button on every post right next to the quote button.  The edit screen looks almost identical to what you get when you quote a message.

After years of moderating I finally managed to reply by instead editing someone's post.  Sorry 2112. I'm going to try to get theymos to un#$@ things.   I have my reply but I don't have your original message. If by chance you have it, you could just repost. Otherwise we're stuck waiting for it to get fixed.

I am very sorry for this screwup.
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 ... 237 »
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!