Bitcoin Forum
January 16, 2019, 11:31:31 AM *
News: The copper membership price will increase by about 300% around Friday.
  Home Help Search Login Register More  
  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 ... 241 »
201  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.
202  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)
203  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.
204  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.
205  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.
206  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.
207  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:
208  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.
209  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)
210  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.
211  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.
212  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.
213  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.
214  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.
215  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.
216  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.
217  Bitcoin / Bitcoin Discussion / Re: ViaBTC finally read all the BIPs about Segwit on: April 24, 2017, 11:08:40 PM
Personally I liked that they were bragging that they weren't being paid, just a couple weeks after  (and with jihan already 50% owner prior to the investment).
218  Bitcoin / Development & Technical Discussion / Re: How to use properly secp256k1 library on: April 24, 2017, 03:40:35 AM
We are living in XXI century. Machine-generated and machine-verifiable codes are the way to go.
I did say unless there is a very strong validation framework.  (We have machine verified code in libsecp256k1-- but the tooling does not scale especially well, so far)

Why would use of an array preclude side-channel resistance? Use absolutely any high-level abstraction in your code,
On most modern platforms, including Intel's x86_64 parts,  accesses to an array take measurably different time based on the the value of address mod cache_line_size-- because loads are always of a full cache line, but data at the beginning of the cache-line is available first.  There are actual demonstrations of using this sidechannel to recover keys.

In the constant time parts of libsecp256k1 we use boolean operations to construct oblivious loads (which read all the data, and select the proper row with masking) whenever we need to access a table with a secret index for this reason.

use processor-dependent intrinsics.
Intrinsics do not allow you to control register allocation, and on many code the entire performance advantage of using the SIMD operations can be wiped out by unnecessary spills and loads. Compilers are getting better at it... but it's not necessarily a gain.  We've use assembly elsewhere in particular to get access to the carry chain flag, which is not otherwise easily exposed. It's not really a much of a maintenance burden since we use inline assembly that avoids having to deal with difference in the calling conventions between platforms.
219  Bitcoin / Bitcoin Discussion / Re: Fuck: SegWit, LN, Blockstream, Core, Adam Back, and GMazwell on: April 23, 2017, 06:02:31 PM
when the blockchain is lagging as hell because we cannot even get confirmations quickly ( unless you put extra-ordinary fee ) [...]
That's right, nobody will use bitcoin.
The only way that the fees will be "high as hell" is if people are using Bitcoin very heavily and highly valuing the transactions they make.
220  Bitcoin / Bitcoin Discussion / Re: Shocking: Small amount of chinese miners block 88% of segwit support by services on: April 23, 2017, 05:59:11 PM
34% of miners support Segwit
That is 34% of hashpower, it may well be 99% of miners.  That is also signaling rather than support-- there are miners that support segwit who are not signaling it due to pressure or payments from others.
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 ... 241 » is not available or authorized for sale. Do not believe any fake listings.
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!