Bitcoin Forum
September 19, 2018, 12:13:56 AM *
News: ♦♦ Bitcoin Core users must update to 0.16.3 [Torrent]. More info.
 
  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 76 77 78 79 80 81 82 83 84 85 86 87 88 ... 238 »
741  Bitcoin / Development & Technical Discussion / Re: Safe(r) Deterministic Tie Breaking on: July 16, 2015, 03:48:56 PM
50% is still much better than very low change you have on a late broadcast; I believe one of the revised selfish mining attack papers presented something similar to your suggestion (the original one was just busted).


I've thought before to use a similar rerandomization metric but include some sigmoid function of time so that the randomization is decreasingly likely to reorder the blocks the farther apart they are... but I was unable to find something that I felt I could analyize.

Quote
    Break ties in favour of the earliest header
No, the earliest received block. If the header's time were used there is trivial attack where you relay the header as fast as possible and withhold the block.
742  Bitcoin / Bitcoin Discussion / Re: The Golden Ratio Attack. Blocks more than half full lead to mining monopoly. on: July 16, 2015, 03:36:45 AM
On the facts the above desciption doesn't describe behavior in the network at the moment-- e.g. backlog isn't there, and substantial amounts of the funds that went into the DOS attack paid for outputs, not fees.

The scheme you describe is scale-free; I see you clarified in later messages that you think the "solution" is dyanmic controls rather than a removal of limit but the bold increase blocksize response in your initial is quite confusing-- more than half your text is spent spinning hyperbole, it would have been much more useful to spend that text on describing what you're actually talking about.

Perhaps most importantly, it does not make a case that the attacker produces increased income relative to his hashpower.  Consider:

Lets imagine your mine with half hashpower. Lets imagine that a block can contain 6000 transactions.  Attacker has 1/2 hashpower.  Offered load is 4000 tx/block.

Attacker crafts 2000/tx block at 1coin/tx fee level. Making the rest match him (plus episilon, which we'll disregard).

His average cost for spam is 1000 coin/block (2000 * 1-rate).
His average income is 2000 coin/block (4000 * rate).  (He doesn't get income from his spam, he saves its cost however; see prior line)
His net income is 1000 coins/block, on average.

Now consider the consolidation of other miners:
Their average cost for spam is 0.
Their average income is 3000 coin/block (6000 * (1-rate)).
Their net income is 3000 coin/block.

Both groups have 50% hashrate, so the non-attacking miner has a fee income of three times greater the attacking miner per unit hashrate!

Normalized for hashrate thats 2000 vs 6000.

----
Lets instead imagine that there is also a backlog of fees episilon beflow the attackers floor, and he mines those instead of his own and that doing this doesn't somehow eliminate the floor effect:

Attacker average cost for spam is 1000 coin/block (2000*1-rate)
Attacker income is 3000 coin/block (6000 * rate)
Attacker net income is slightly under 2000 coins/block, on average.

Honest miners cost for spam 0.
Honest miners income is 3000 coins/block (6000*(1-rate))
Their net income is 3000 coins/block.

Again doesn't work.

----
We can work this for any other size, say  and attacker with 40%:

Attacker cost for spam is 1200 coin/block (2000*(1-rate))
Attacker income is 1600 coin/block (4000*rate)
Attacker net income is 400 coin/block

Honest miners cost for spam is 0 coin/block
Honest miner income is 3600 coin/block (6000*(1-rate))
Honest miner net income is 3600 coin/block.

Normalized for rate, thats 1000 vs 6000.

---

Finally, we already know that the system is not incentive compatible when a single party (or collaborating conspiracy) has more than 1/3rd of the hashrate: http://arxiv.org/abs/1311.0243   (The results below 1/3rd require information asymetry advantages which are handwavy, but at 1/3rd or beyond no such asymetry is required)-- though such attacks are highly conspicious.


At best, this attack allows a sizable minority group of miners to engage in price fixing without running out of money, under the constraint that legitimate transactions are still wiling to pay enough to fill half the block.
Exactly, like anyone they can generate transactions to drive up fees; large miner hashpower gets a discount on fees; but they still lose funds; and everyone else shares the income.
743  Bitcoin / Bitcoin Discussion / Re: BurtW arrested on: July 15, 2015, 10:32:05 AM
Great news!
744  Bitcoin / Bitcoin Discussion / Re: Gadget claims to steal encrypted keys from 19" distance. Time for Paper wallet ? on: July 14, 2015, 03:07:20 AM
After reading this, I had a scary thought: what if hardware wallet companies made this technology easy to obtain and use, allowing anyone to compromise wallets on devices such as laptops, and in turn forcing Bitcoiners to purchase a Trevor or something similar.
Small hardware wallets tend to be more vulnerable to this sort of thing as they have much less room for adequate shielding, less CPU cycles to run hardened algorithims, and run at slower speeds that make observations easier.
745  Bitcoin / Bitcoin Discussion / Re: Gadget claims to steal encrypted keys from 19" distance. Time for Paper wallet ? on: July 13, 2015, 09:43:21 PM
Thanks for the clarification. But, it is not nice to argue that PaperWallets are unsafe just to back up electronic storage. PaperWallets are not supposed to be generated online and offline generations are quite safe. If someone dowaloads bitaddress.org source code from Github and generates PapaerWallet in an offline (which I assume is not in the vicinity of this new gadget), then what is wrong with it ?
Nothing about this attack involves online anything.  It involves radio emissions of a device while it is generating keys or signing.  Use of the "paper wallet" only dramatically increase your vulnerablity to this rather fringe attack over behavior normally-- because the sofrware used for paperwallets is (as far as I've seen) never even constant time much less reduced-emi...

It is all over for cryptos based on this technology.
All _zero_ of them?

My take is that you would have to be James Bond to pull it off.
Pretty much. There are cases where it may be relevant-- consider security procedures for commercial cold wallets, but not for most people.
746  Bitcoin / Bitcoin Technical Support / Re: RPC Bitcoin Core activate ... and it crash ! on: July 13, 2015, 07:52:53 AM
Every other P2Pool user, including myself, is using it fine-- so the issue is likely specific to your configation.

What OS? Where did you get your bitcoin Core?   How do you know it has crashed? Why do you believe it is RPC related?

Can you share your config file (without passwords, of course)?

747  Bitcoin / Development & Technical Discussion / Re: The most repeated R value on the blockchain on: July 13, 2015, 03:50:32 AM
Quote
can you clarify the f2pool patch you mentioned? Was the "patch" the small r value, ie, facilitating the large transactions to fit in a block?

And exploiting the SIGHASH single ... odd behavior, so that all the signatures past the first are just signing the value "1" instead of having to hash the transaction.

This makes the signed data after index 0 identical for all transactions, so if you compress the block data it will be MUCH MUCH smaller, perhaps only taking a few bytes per signature.

unfortunately they switched back to a scheme which creates seperate transactions for each coin, which undermines the compression gains and just takes a lot more space to begin with. Sad
748  Bitcoin / Development & Technical Discussion / Re: "SPV Mining" or mining on invalidated blocks on: July 13, 2015, 01:38:44 AM
SPV mining is safe if there is a timeout (say 1 minute).
It's not safe SPV clients; its surely less unsafe, but it still undermines the security assumptions behind SPV clients... undermines it less.
749  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.
750  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.
751  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!
752  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/
753  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.


754  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.
755  Bitcoin / Legal / Re: California Bill AB 1326 on: July 11, 2015, 01:04:16 AM
https://blockstream.com/DigitalCurrencyCASenateLetter.pdf may be of interest.
756  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.
757  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.
758  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.
759  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.
760  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.
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 ... 238 »
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!