Bitcoin Forum
November 21, 2018, 07:25:16 PM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
 
  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 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 ... 239 »
781  Bitcoin / Development & Technical Discussion / Re: The most repeated R value on the blockchain on: July 12, 2015, 11:06:15 PM
f2pool uses very short signature. Why cannot I use it also?
OK, my math/programming skills are very poor. I do not understand why the G/2 produces such pretty pubkey

But seriously. If I don't personally want to facilitate someone shooting their foot of (where undoubtly some will blame me and attack my reputation), then thats my call-- not yours.  And whining about it is offtopic for this thread and subforum.
782  Bitcoin / Development & Technical Discussion / Re: Sipa what have you done ? on: July 12, 2015, 10:01:26 PM
Yes, but I don't run the DNS Seeder. The problem looking like SIPA configured a round-robin DNS on his domain that point to many other bitcoin public nodes.
There is no problem, this is how DNS seed works. There are domains that resolve to working Bitcoin nodes used to find nodes if the nodes existing knowledge isn't enough.
783  Bitcoin / Bitcoin Technical Support / Re: Bitcoin-QT 0.10.2 crashes on: July 12, 2015, 08:41:35 PM
0.11 updated QT.  You might see if it fixed the issue.

Please people; this person has a completely reasonable techsupport request.  Yes, I agree-- windows GUI is not the "right" way to do headless, but the software certantly shouldn't be crashing when run in 16 bit color mode!
784  Bitcoin / Development & Technical Discussion / Re: The most repeated R value on the blockchain on: July 12, 2015, 08:05:17 PM
Using this K value will leak your private key.

I intentionally did not publish the patch I gave F2Pool that allowed them to do this because I knew that people would use it for themselves even after being told that it would leak their private key.

SECP224K1 and SECP256K1 share the same 166 bit string doubled to produce the generator. Doubling a short string is an "obvious" enough way to choose a generator that I thought to halve the existing generator. Folklore is that some curves use SHA1 outputs to produce their generators.

As mentioned, I put up a puzzle based on this previously:  https://www.blockstream.com/half-a-puzzle/
785  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core is a broken piece of shit on: July 11, 2015, 08:21:22 PM
Description of specifics events around the crash-- crash message, possible triggers, etc.?  Nope.

Description of final events in the debug log at the time of the crash? Nope.

Specific Bitcoin Core version and origin of binaries? Nope.

Operating system and version, or if it's 32/64 bit? Nope.

Information about the hardware its running on (memory amount, type of storage) ? Nope.

Presence of possibly conflicting software such as anti-virus? Nope.

Decscription of steps taken so far to resolve the problem? Nope.

Post to an apropriate subforum (e.g. technical support) or issue tracker for getting aid with problems?  Nope.

Gratitious insults?  Yep.


Sorry-- the expirence reflected here doesn't reflect the case for most others. While no one can forbid you from being frustrated, your approach is unlikely to result in the resolution of your issues.  I suggest you take a breath, and head over to the techsupport subforum and try seeking some help and provide the above information without the insults.


786  Bitcoin / Bitcoin Discussion / Re: Gadget claims to steal encrypted keys from 19" distance. Time for Paper wallet ? on: July 11, 2015, 02:39:34 AM
If what they claim is true, no electronic storage for private keys are safe anymore. Paper wallet unaffected Smiley
None of these things effect _storage_; they potentially effect key generation and signing. When the key is at rest, no issue.  All of the "paperwallet" utilities I've seen are _highly_ vulnerable to sidechannel attacks. Worse, many are just webpages which are vulnerable to a littany of additional attacks.

Meanwhile, Bitcoin core is already hardened against this sort of thing.


It often seems to be the case that people spread FUD around fringe concerns with recommended actions that would actually make people less safe. One of the great mysteries of Bitcoin.
787  Bitcoin / Legal / Re: California Bill AB 1326 on: July 11, 2015, 01:04:16 AM
https://blockstream.com/DigitalCurrencyCASenateLetter.pdf may be of interest.
788  Bitcoin / Bitcoin Discussion / Re: The biggest single tx in the world? on: July 11, 2015, 12:45:57 AM
This is F2Pool;  see #bitcoin-dev earlier today where I gave wangchun a patch to produce unusually small, regular, and fast to verify signatures for the special case of spending a non-private private-key.
789  Bitcoin / Development & Technical Discussion / Re: Blockchain forks and proof of their age? on: July 11, 2015, 12:08:56 AM
This is exactly why it is good to verify a transaction on multiple block explorers, especially if you are only waiting for a relatively small number of confirmations.
I think too many people solely rely on 1 block explorer and still think 1 confirmation is okay
You could have checked more than four of them and wou ld have gotten the same incorrect data.
790  Bitcoin / Development & Technical Discussion / Re: Blockchain forks and proof of their age? on: July 10, 2015, 11:57:28 PM
That kind of profound confuseion is happening much more often because there are many altcoins that use centeralized blocksigning to pin the chain and prevent reorgs. Unfortunately they call this mechenism "checkpoints", though it has basically no relationship to the really narrow thing in Bitcoin by the same name.


Irony in suggesting "external sources of validation" like block explorers is that in the recent chain fork most of them were wrong.
791  Bitcoin / Bitcoin Discussion / Re: We ARE under attack.. we NEED to act... on: July 10, 2015, 12:24:37 AM
scaling blocks would be the perfect solution. but that's an infinite discussion. Undecided
One cannot address a crapflood attack by permantly accepting more crap for all time.

This is where the "Bitcoin Purists" need to admit they were wrong that "there can only be one crypto" and give credit where credit is due. Charlie (coblee) was right from 3 years ago when this spam attack happened. I remember the spam attack when it happened and the fee structure to discourage attacks has worked very nicely to date.
Are you talking about when he stopped ignoring my advice that his slavish copying of Bitcoin's code broke the existing anti-attack mechenisms and rendered them completely and totally ineffectial?-- and applied a patch I provided?  I'm surprised you'd forget that-- because

Go actually look at the litecoin repository. You'll see almost nothing but miles of them copying code from Bitcoin Core.

As mentioned above... We have almost the same protection in Bitcoin being mentioned here; but the attacker is just paying enough to avoid it (partially because it was subsiquently turned too low in anticipation of higher Bitcoin prices); and the latest volly of attack transactions  don't even involve very small payments.

I realize that you're a long time litecoin advocate; but seriously-- pick a argument that actually makes sense.  Otherwise it's just embarassing.

I traced the attacks to my alt-coin mining operation last year to Panama and Switzerland, they went to a lot of trouble to screw me out of $5 worth of doge.

Any idea where these attacks are originating from?
A big chunk of them originate from this transaction: 3bad15167c60de483cd32cb990d1e46f0a0d8ab380e3fc1cace01afc9c1bb5af  if you can figure out whos exchange withdraw this-- since this key immediately began making the attack txn itself is you may have some very concrete evidence about whos attacking here.
792  Bitcoin / Bitcoin Discussion / Re: We ARE under attack.. we NEED to act... on: July 09, 2015, 11:57:34 PM
It would be interesting to hear the reason why bitcoin developers turned down Lee's pull request to include litecoin's solution to the spam problem three years ago...
Bitcoin Core implemented something quite similar but better-- the dust limit, though it was later reduced in effectiveness by turning the limit ten times lower.  Of course, any kind of fee based discouragement for spamming isn't going to work if the fees are too low.

I say better because it actually addresses the root problem that it both were intended to address, the creation of utxo which cost the reciever more than they are worth to spend-- while the litecoin scheme leaves that attack open but makes it somewhat more costly.

Beyond seemingly forgetting the protections from Bitcoin copied into his own codebase (and disabled), Coblee seems to have forgotten history-- Litecoin's fee antispam was originally wacked; I pointed it out and posted a patch to fix it, and encouraged miners to apply it after none of the litecoin tech people seemed to care.  It was ignored until some jackass DOS attacked their network, then they blamed me for it, and applied the fix I suggested (though with lower fees).

The current attacks don't really have that much to do with low value outputs, the attacker doesn't seem to be trying to bloat the UTXO set-- actually last night the pattern changed after miner anti-attack-filter became effective at deprioritizing them, and they've been using larger amounts now.
793  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 09, 2015, 09:36:30 AM
I just want to highlight the comments here from bitcoin-dev today, which seem to indicate that these spamming attacks would have been 5.5x more expensive if a dust threshold software change had not been made. Perhaps there are deeper insights someone else has on this...?
Quote
16:53   wangchun   why can those spam get confirmed. 0.00001 BTC vout below dust threshold right?
16:54   phantomcircuit   wangchun, iirc the dust threshold is 546 satoshis
16:54   wangchun   not 5460 satoshis? changed?
16:54   aschildbach   wangchun: Yes it was cut by 10 a few months ago.
i don't think it really matters, does it?
since most of the mined blocks are filled with real demand trying to get into blocks with or without spamming,
Unfortunately, the majority in the blocks I checked earlier today have been the DOS attack-- e.g. transactions tracable from outputs of this transaction https://blockchain.info/tx/3bad15167c60de483cd32cb990d1e46f0a0d8ab380e3fc1cace01afc9c1bb5af  and a few others. ... though the attack style has been shifting to evade filtering by miners.

The change mentioned in the chat above is https://github.com/bitcoin/bitcoin/pull/3305 (you might find the comments there interesting), it's one of Mikes couple contributions to Bitcoin Core.
794  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 08, 2015, 11:26:59 PM
OK.  Provide me with your estimates for the following (and explain how you arrived at your numbers) and I'll update my table using your numbers:
1.  The cost per node to store 1 GB of additional blockchain data for 5 years, assume the outputs are spent.
2.  The cost per node to store 1 GB of additional blockchain data for 5 years, assuming the outputs are unspent.
I may be missing the context as this thread is high volume and I've not read any of the backlog...

But for a full verifying node, the on-going cost cost of 1GB of additional transactions with all outputs spent is 0; all the cost related to that 1GB of data is related to the bandwidth to get it to you and the verification cost, and for short term storage until its burried, after that it need not be stored.
The cost for unspent is some non-zero number which depends on your estimation of storage costs.


Does CreateNewBlock currently take longer to execute if there are more TXs in a miner's mempool to pick from?  If so, this would add credence to Cypherdoc's hunch that miner's are producing more empty blocks when mempool swells.  
Yep, I already pointed that out to you specifically! It's superlinear in the mempool size (well, ignoring caching)  But thats unrelated to f2pool/antpool and the other SPV miners, as they're not ever calling createnewblock in that case, as they're mining without even validating.   One can mine on a validated chain with no transactions while waiting for createnewblock (which is what eligius does, for example).  I also pointed out that this is trivially optimizable, but no one has bothered previously.

795  Other / Meta / Re: HashFast cypherdoc bankruptcy scandal : Time to clean up bitcoin on: July 08, 2015, 05:07:20 AM
Well I found it damning because he mislead me previously-- claiming he was just another customer that got some discounts and lost money w/ hashfast like many others did-- in order to get me to previously pull the negative raiting for his part in promoting something that caused large losses for a lot of people.  So finding out that he actually made an enormous profit from it was quite eye opening, no pun intended.
796  Bitcoin / Development & Technical Discussion / Re: [Crypto] Compact Confidential Transactions for Bitcoin on: July 07, 2015, 10:01:23 PM
I've been toying around with a 384 bit quadratic extension field curve that supports a four dimensional endomorphism (GLV-GLS).  The use of the quadratic extension avoids much of the bad scaling, but I'm not to a point where I can benchmark anything yet.
797  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 07, 2015, 09:12:51 PM
On the topic of block verification times, people on Reddit are saying this block (filled with one huge TX) took up to 25 seconds to verify:
yes, they're actually quoting pieter and I from #bitcoin-dev (telling the miner in advance that the transaction he was creating would take a _LONG_ time to verify). They created a huge non-standard 1MB transaction and part of the verification time is quadratic (in the number of inputs).

It's actually possible to create a block that would take many minutes to verify, though not with standard transactions-- only something contrived.
798  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 07, 2015, 03:33:50 AM
ok, i'm not getting the bolded part.  this graph shows 37 MB worth of unconf tx's, no?:
No clue, no node I have access to is seeing that much-- they may have turned off the minfee rules (not unreasonable for a metrics thing)...

Even given that, again, 37MB doesn't explain your swap.
799  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 07, 2015, 03:23:56 AM
Interesting!  
And this is why I like the empirical "block box" approach.  I don't care initially what the mechanism is.  I try to find a simple model that explains the effect, and then, later, ask what that mechanism might be.
But now why would the "latency of the mining process" depend on the size of the previous block?  That doesn't make sense to me, but we just showed empirically that F2Pool is indeed more likely to produce an empty block when the previous block is large.
It wouldn't expect the miner latency part to be size dependant: the miner can't even tell how big the prior block was.  I expect your function relating them to have a big constant term in it! (thats why I asked if you tried other regression approaches. )

I suppose there may be some dependance that is introduced by virtue of what percentage of the miners got the dummy work.  Would be pretty interesting to try to seperate that.

Another trap of empirical analysis in this kind of discussion is that we can only measure how the system is-- but then we use that to project the future;  e.g.  say we didn't have ECDSA caching today, you might then measure that it was taking >2 minutes to verify a maximum size block... and yet 100 lines of code and that cost vanishes; which is bad news if you were counting on it to maintain incentives. Smiley
800  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 07, 2015, 03:09:22 AM
as you know, even Gavin talks about this memory problem from UTXO.  and yes, i read the Reddit thread that resulted in which you participated and i'm aware that UTXO can be dynamically cached according to needs.
http://gavinandresen.ninja/utxo-uhoh

Gavin was insufficently precise. There is a reddit thread is full of people calling gavin a fool ( Sad ) for saying "memory" when he should have been saying fast storage.  https://twitter.com/petertoddbtc/status/596710423094788097

Why do you think it's prudent to argue this with me?

Okay, lets take a bet. Since you're so confident; surely you'll grant me 1000:1 odds?-- I'll give my side away to a public cause.

The question is "Is the entire UTXO set kept in ram in Bitcoin Core ever released?"

I will bet 3 BTC and, with the 1000:1 odds, if you lose you'll pay 3000 BTC (which I will to the hashfast liquidators, to return it to the forum members that it was taken from; which will also save you some money in ongoing lawsuit against you).

Sounds good?  How will we adjudicate?  If not, what is your counter-offer for the terms?

Quote
i didn't say this full block spam attack we're undergoing wasn't affecting my node at_all.  sure, i'm in swap, b/c of the huge #unconf tx's but it hasn't shut down or stressed my nodes to any degree.  one of the arguments by Cripplecoiners was that these large block attacks would shut full nodes down from destabilization resulting in centralization.  i'm not seeing that.
The highest number of unconfirmed transactions I've seen ever is about 8MB. Even if we assume the real max was 3x that this is not explaining your hundreds of megabytes of swap.   We just had half the hashpower of the network mining without validating creating multiple large forks and large reorginizations, but you don't see any destabilization. Okay.

Let me chime in hear quickly, because I think Greg and I are talking about slightly different things.  My model was considering the time between the first moment that a pool could begin hashing on a blockheader, and when the previous block had been processed, a new non-empty block template constructed, and the hashers re-assigned to work on this non-empty block.  

It looks like this time, empirically, is 15 sec (F2Pool) and 30 sec (AntPool), based on these estimates.  

Here I suspect you're suffering from an excess of empiracisism without adequately devling into the mechenism.   You can directly measure that time time from input to minable on an actual node under your control and will observe the time is hundreds of times faster than your estimate. Why?   Miners don't magically know when their pool has new work, they'll get work in the first milliseconds and then grind on it some time before submitting returning work.  Even if the pool long polls them, it takes time to replace work. So what I suspect you're actually measuring there is the latency of the mining process...  which is consistent with what we've expirenced with P2Pool (5-20 second latencies from ASIC miners are common).

I noted you posted a result of a classification, did you run the same data through a simple logistic regression with prior size as the treatment? The intercept in the model would be interesting.

But indeed, these conversations have been conflating several seperate issues (latency vs throughput, etc.). Tricky to avoid that since they're all relevant.

but you haven't verified that f2pool or Antpool has increased their minrelaytxfee have you to minimize their mempool?
I have, they'd previously cranked it down, and were producing small blocks and were flamed in public.  They've since turned it back up.

Quote
remember, this whole mempool discussion was based off you responding to Peter's mathematics post the other day where you argued that the block verification times were only 80ms for a 250 kB block b/c tx's had been pre-verified after being passed around to all nodes across the network and didn't require re-verification by miners on the relay network and was therefore a refutation of his hypothesis of increasing block verification times (16-37sec on avg) leading to SPV mining.
As PeterR points out, they only need to wait for verification to actually verify (which they're not doing today), though they may have to wait longer to include transactions---- though I point out thats not fundimental e.g. no matter how big the backlog is you can produce a template sufficient to completely fill a block while doing no more work than handling a mempool of twice the maximum block size.  (by using a tiered mempool, though no one has bothered to implement this yet-- no one has even been complaining about how long createnewblock takes, due to the ability to produce empty blocks without skipping transactions).
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 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 ... 239 »
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!