Bitcoin Forum
January 21, 2019, 09:26:37 PM *
News: Latest Bitcoin Core release: 0.17.1 [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 91 ... 241 »
801  Bitcoin / Development & Technical Discussion / Re: Semi-soft-fork to decrease the risk of tx malleability on: July 29, 2015, 05:21:54 AM
we have BIP66 but there are still many forms of malleability to be fixed.
BIP66 is not about malleability, really; BIP62 is.
Is this the real reason for BIP66, which you couldn't mention in April?
(Disclosure: consensus bug indirectly solved by BIP66)
The explicitly stated goal right in the BIP62 document was a reduction in dependence on OpenSSL for consensus; which the truth and nearly the whole truth all that was missing was that the concern was less theoretical than presented.  But yes, the unstated privately known consensus vulnerability was a driving force for clearing up that ugly corner with BIP66 immediately rather than mopping it up as a side effect of BIP62. Especially due to fact that BIP62's progress has been slow-- and had grown over complicated. The fact that BIP66 accomplished one of the necessary steps will make BIP62 or its logical successor easier to move forward.

If you note from the timeline that BIP62 had already been revised to accomplish a BIP66 like goal prior to us knowing about that specific vulnerability:  We were aware of the risk class in principle before having specific knoweldge with enough concern that we thought it was worth closing off.  Knowing that it was _actually_ exposed had only an impact on timing and sequencing; and only after it was clear that BIP62 was not rapidly converging (unfortunately, in spite of much progress on BIP62 we continued to find problems with it).

It's sad, there is a vastly superior-- simpler, more comprehensive, and with secondary benefits like enabling more degrees between full and SPV-- malleability 'fix' in elements alpha but I don't have any way to get it into Bitcoin, BIP62 is disappointing by comparison (brillant ideas welcome).
802  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 28, 2015, 05:43:11 PM
i'd like to revisit that thought experiment i introduced last week.

an anonymous person hard forks the current Bitcoin code with the only change being a lifting of the limit.  he provably destroys the commit key (a Bitcoin private key) over at github thru a op_return spend.  the result being a Bitcoin source code with no core devs and thus no ability to change it going forward.  would that be enough to carry Bitcoin forward for the next century?
This message is technically incohearent-- there is no such thing as a a "commit key", and "op_return spend" doesn't destroy information if there were; achieving what you suggest simply requires people stop upgrading (which is also part of the reason that we do not use automatic 'push' upgrades)----  but I certantly get the _intent_. and it's one I've forelorely expressed multiple time myself, going back years:

That it would be philosophically ideal and achieve the highest security properites if the system were completely involatile, defined by it's own mechnical construction, and any change to it would simply be a different system which people could voluntarily move to by their own free choice. Through this the system would be immune to whilm, political control, or subterfuge in a much stronger sense.

Sadly, that result currently appears to be pratically be beyond the scope of human engineering abilities-- or at least beyond the efforts expended on any software system I'm aware of thus far.

A particular point that I couldn't disclose the time cypherdoc initially made the argument was that the software the network was running at that moment was vulnerable:

We've had a pipeline of newly discovered non-public vulnerabilties in the Bitcoin protocol running almost all the time since 2012.  I don't have a great answer to that hard questions, but sadly burying our heads in the sand cannot work-- it would just result in a regular series of potentially devistating "emergency" changes, rather than a orderly, planned, resolution.
803  Economy / Services / Re: [4 BTC] AntMiner firmware job on: July 25, 2015, 06:19:49 PM
CGMiner is GPLed software. Antminer was obligated to distribute the complete cooresponding source to their modifications under the same license. If they failed to do so then antminer would be in violation of the license.

I see nothing wrong with whats being requested here.
804  Bitcoin / Development & Technical Discussion / Re: Deleting abandoned UTXO on: July 23, 2015, 04:08:38 AM
This may be possible with UTXO set commitments of some kind.
This is the argument for TXO commitments.  But it's a storage vs bandwidth tradeoff, instead of storing a (say) 64 byte UTXO entry you need a 2.5KB proof when its spent. It takes some pretty tortued assumptions about storage vs bandwidth costs to make this win unless you assume a very low probablity of being spent and only use the proofs for accurately predicted low probablity of spend transactions.
805  Bitcoin / Development & Technical Discussion / Re: Deleting abandoned UTXO on: July 22, 2015, 06:34:09 PM
1. 0-value outputs are not spendable
This would greatly reduce the scope of functionality introducable in future soft-forks.  E.g. CT like private values could no longer deployed, soft-fork increases in coin precision, etc.
806  Other / Off-topic / Re: Increase currency divisibility with soft-fork on: July 21, 2015, 04:47:38 PM
aztecminer, I'm afraid you might be failing these excercises:
807  Bitcoin / Development & Technical Discussion / Re: One-time signatures to prevent double spends on: July 21, 2015, 02:47:02 AM
Hi Tonych, it's always good to have more crypto posts here.

This is normally called a single show signature.

If you search the #bitcoin-wizards logs for that term you'll see some instances of this proposal-- you might find it informative.

As you'll probably see in the logs, I disagree with the claims of this approach preventing doublespends. The result of it, at best, is similar to RBF scorched earth, which many people don't consider to be an improvement.

I also disagree with the claim that it in any way addresses nothing-at-stake; in particular it's already common for schemes to suggest that duplicate signatures void coins (which can be done just by system rules without a single show signature) and yet those schemes also do not solve the nothing at stake problem: you cannot punish someone who has left the system and they can produce their conflicting signatures long after leaving it.

There are some pratical concerns as well.  For example, now ephemeral data k must be securely stored and if lost result in loss of the key.  Signing devices must be carefully stateful and avoid repeated signatures.  If the user pays inadequate fees, they'll have no mechenism to revise their transaction to update them-- as even a completely benign double spend (e.g. one that pays the same destination) would result in key loss.

Less importantly, miners also have free pass to ignore the effects of this scheme and there is a simple non-trustless but private protocol possible to allow someone to have a third party privately mine their transactions. (You put up a 25 BTC bond with the miner, and give them the transaction hash you want them to mine, with a promise that you'll instantly give them the full transaction if they present you with a winning block or else forefeit your bond).

especially those that already have stealth addresses.
Stealth addresses are linearly related, and the relation is known to the paying party. So if I use the stealth address method to create two one show public keys for you and you sign with both of them, I can derrive your private key. I am not aware of a mechenism to securely generate 'stealth address' pubkeys for single show signature without bilinear groups. If not for this a single round trip schnorr treshold signature would be possible.  [I hope this point makes it clear how tricky working with an intentionally fragile cryptosystem is, as someone could have followed the suggestion in the original post without realizing that they were giving away their private keys.]

808  Bitcoin / Development & Technical Discussion / Re: You can have wallet.dat anywhere and with any name, now! on: July 20, 2015, 09:12:16 PM
This is an inconsiderate bump of a very old thread.

Interesting and I gonna to try it out later today. This will make file management easier and it seems I won't need to manually change filenames by renaming anymore.   Wink

Bitcoin Core has had the ability to set the wallet file name with -wallet= for years. There is no need to rename files, and hasn't been a reason to do so for longer than your account here has existed.  You cannot change the path because if you split the BDB recovery logs and wallet file itself onto seperate media you will end up with irreparabile data corruption if there is an unclean power off with (un)reasonable probablity.

809  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.

    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.
810  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:   (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.
811  Bitcoin / Bitcoin Discussion / Re: BurtW arrested on: July 15, 2015, 10:32:05 AM
Great news!
812  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.
813  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 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.
814  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)?

815  Bitcoin / Development & Technical Discussion / Re: The most repeated R value on the blockchain on: July 13, 2015, 03:50:32 AM
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
816  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.
817  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.
818  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.
819  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!
820  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:
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 91 ... 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!