Bitcoin Forum
February 25, 2018, 05:52:38 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
  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 ... 351 »
721  Bitcoin / Development & Technical Discussion / Re: Does replacement interact with quantum computers? on: January 21, 2016, 09:28:48 PM
If QC comes into existence, then that is a very major problem which should be fixed ASAP in any case.

From a game theory perspective it doesn't make much sense for us to wait for the day where it is public knowledge that a QC exists. Given QC attributes as crypto-breaking machines, there's a history of similar crypto-breakthroughs remaining hidden.

It seems very unlikely to me that a QC will be created, then the tech will advance to the point that real-world keys can be broken in less than years, and all of this will be kept secret until it becomes an emergency. These government agencies are full of many people, and people are bad at keeping secrets. If this does happen, it can be survived due to the QC-resistance of Bitcoin addresses, but hurrying to plan for this seems like premature optimization. Especially when the current state-of-the-art in QC-proof signatures have massively larger signatures than ECDSA, and bandwidth is currently a pretty big bottleneck.

There is a flag for disabling the RBF policy, -permitrbf=0.

IIRC the Core devs do have code prepared for adding QC-proof signatures to Bitcoin as a softfork (using a variant of Lamport signatures optimized for minimal size, especially in the scriptPubKey), though AFAIK this code isn't public.
722  Bitcoin / Development & Technical Discussion / MOVED: Bitcoin Chat on: January 21, 2016, 08:50:31 AM
This topic has been moved to Bitcoin Discussion.

https://bitcointalk.org/index.php?topic=1334299.0
723  Bitcoin / Bitcoin Discussion / MOVED: "Bitcoin Classic" NOT a classic attempt at a hostile takeover, apparently. on: January 19, 2016, 11:13:08 PM
This topic has been moved to Altcoin Discussion.

https://bitcointalk.org/index.php?topic=1333867.0
724  Bitcoin / Development & Technical Discussion / Re: RBF transactions to be enabled at the next core update on: January 19, 2016, 10:53:39 PM
In order for a 0-confirmation transaction to get double spent (assuming you have zero influence on any amount of mining hardware/pool) without RBF, as a general rule most of the network needs to have not seen the transaction, AND the transaction needs to either not have been seen by the miners' nodes or not be a transaction that the miners will generally confirm.

Exploiting policy differences is the easiest way, and I'm not sure that you can ever really eliminate it because people will always have different policies. But there are other ways:

I think that you'll have a pretty good success ratio if you send the transaction directly to the merchant and simultaneously send the double-spend directly to some miners. The merchant and the peers around him will have one version, but miners will have the other. If the merchant is not running several nodes, then he probably won't even see the the double-spend until it gets into a block, since his surrounding peers won't relay a transaction that they view as a double-spend.

And there's always the Finney attack. If you're a miner, you can (for no additional cost) continuously try to double-spend your 0-conf transactions. If you happen to mine a block while the transaction still has 0 confirmations, then you double-spend it, and nothing can stop this.

Quote
Wouldn't it be possible for someone to sign a transaction that relies on input x, and has a "high" fee, save this transaction to a text file (or wherever), then sign a separate transaction that also relies on input x and has a "low" fee, and has the appropriate flags that "enable" RBF, and broadcast this transaction. Then they could simply use "sendrawtransaction' (which is significantly easier to use then "createrawtransaction" imo) to broadcast the conflicting transaction.

The Core GUI won't let you create conflicting transactions like that. You could do it by messing around with wallet backups or something, but again, it takes a fair bit of extra effort.

With Core's implementation of opt-in RBF, you can't (from the perspective of any given network node) replace an RBF-disabled transaction with an RBF-enabled transaction, and you can't replace a transaction with one having a lower fee. You can replace an RBF-enabled transaction with an RBF-disabled transaction.

Quote
This doesn't mean that others will not write guides on how to fraudulently double spend transactions, and that people will not design wallets/programs to help people fraudulently double spend transactions.

Probably, but that can happen with non-RBF transactions as well.

Quote
I am having difficulty finding reasons why RBF is better then CPFP and/or RBF is being implemented in core while CPFP is not supported (for the most part).

AFAIK CPFP isn't ruled out for Core. It's in Luke's fork. I'm not sure why it's not in Core. Maybe there are some performance problems with the existing code or something.

I see them as being complementary. If the sender is taking responsibility for confirmation, then he should use RBF; otherwise, if the recipient is taking responsibility then the recipient can use CPFP and the sender can opt out of RBF.
725  Other / Meta / Re: Administration ignoring and erasing request to recover hacked account on: January 19, 2016, 06:37:58 AM
According to the seclog there was no password change or reset.

Changes by admins aren't logged there.
726  Bitcoin / Development & Technical Discussion / Re: RBF transactions to be enabled at the next core update on: January 19, 2016, 12:17:43 AM
Who would use it and why?

The idea is that eventually most people will use it most of the time.

I don't know if this is actually exactly how it's planned, but how I imagine it working in the future is:
- By default, you'll send transactions with RBF. Then if the transaction doesn't confirm after a long time, RBF will allow you to easily increase the fee. You'll be taking responsibility for the transaction
- If a merchant requests that you not use RBF, you won't. Likely this request will be done via the Bitcoin Payment protocol (ie. bitcoin: URIs). So when you click "pay this" (or whatever it says) on a BitPay page, your wallet will automatically send the transaction without RBF. Then the merchant is taking responsibility for the payment, and they can adjust the fee later if necessary using the child-pays-for-parent (CPFP) mechanism. I'd expect most payment processors like BitPay to do this so that customers don't have to worry about fees and they can try to do fraud detection on 0-conf transactions.
727  Bitcoin / Development & Technical Discussion / Re: RBF transactions to be enabled at the next core update on: January 18, 2016, 11:47:03 PM
Ok I know this isn't a technical question, but: What do businesses that regularly deal with Bitcoin have to say about this? And wallet developers? It still seems like a strange new feature.

As Peter Todd demonstrated with his Coinbase double-spend, it is (and always has been) very easy to double-spend 0-conf transactions even without RBF. In most cases, it is only slightly less difficult to double-spend with RBF compared to non-RBF.

I think that it's always been a hopeless effort, but some services try to predict when 0-conf transactions are high-risk using a number of network nodes listening for double-spends and other such things. For these, it's a simple matter to check for the RBF opt-in and treat these transactions as automatically high-risk.

I feel like most people are imagining that with RBF there's going to be a button in wallets that says "take back this money", but that's very unlikely. Right now you have to use createrawtransaction to send a RBF-enabled transaction, and in the future there will be a button to increase fees (or something), but I really doubt Core is ever going to provide an easy UI for fraudulently double-spending. As is the case today, 0-conf transactions will often work despite being totally insecure because a large percentage of people are honest, and of those who are dishonest, a large percentage of them haven't bothered to figure out how to double-spend.
728  Bitcoin / Development & Technical Discussion / Re: RBF transactions to be enabled at the next core update on: January 18, 2016, 11:29:49 PM
So this means that when a transaction is broadcasted it has a flag saying that RBF can be enabled, or that it can't?

If all of the inputs of a transaction have nSequence = UINT_MAX or UINT_MAX-1, then they have RBF disabled. Sending transactions with nSequence = UINT_MAX is the default for ~all wallets.
729  Bitcoin / Bitcoin Discussion / Re: Analysis and list of top big blocks shills (XT #REKT ignorers) on: January 18, 2016, 09:49:35 PM
Theymos wanted bigger blocks 2 years ago!

https://www.reddit.com/r/Bitcoin/comments/3k3kli/theymos_mike_hearns_view_is_similar_to_satoshis/cuugy1p
730  Bitcoin / Bitcoin Discussion / MOVED: POLL: How will Blockstream/Core Be Remembered? on: January 18, 2016, 02:47:46 AM
This topic has been moved to Altcoin Discussion.

https://bitcointalk.org/index.php?topic=1330583.0
731  Bitcoin / Bitcoin Discussion / MOVED: Blockstream/Core: Support of DDOS Attacks on Classic on: January 18, 2016, 02:42:40 AM
This topic has been moved to Altcoin Discussion.

https://bitcointalk.org/index.php?topic=1331325.0
732  Other / Meta / Re: Administration ignoring and erasing request to recover hacked account on: January 17, 2016, 08:31:33 PM
This doesn't verify for me: https://bitcointalk.org/index.php?topic=471166.msg5299753#msg5299753

Do you have any other proof that this PGP public key is correct?
733  Bitcoin / Development & Technical Discussion / Re: Nonce randomness on: January 17, 2016, 01:22:39 AM
They don't stop any more theymos. They scour the entire range because it's cheaper to do so in ASICs and report all nonces found rather than to abort.

Oh, OK. Then it'd depend on which one is chosen in case more than one is found, which I suppose is arbitrary.
734  Bitcoin / Development & Technical Discussion / Re: I support "Bitcoin Classic" (2MB), if the activation threshold is over 95% on: January 16, 2016, 10:14:01 PM
That's better blocks, not bigger ones.

No, it's both. The Core roadmap calls for maintaining the 1 MB "normal-blocks" for now, but then adding 3 MB "witness-blocks" (sent alongside normal blocks) where much of the data from normal blocks can go. It does roughly double transaction capacity, it's backward-compatible, and it'll be ready in only ~4 months. The Core devs are following Satoshi's footsteps by significantly prioritizing backward-compatibility: Satoshi never did a hardfork, and when he did the backward-incompatible version checksum change, he scheduled it two years in advance.
735  Bitcoin / Development & Technical Discussion / Re: Nonce randomness on: January 16, 2016, 08:48:53 PM
So you are saying the nonce is pretty much a random value now when a new block is found. And if it's not truly "random" there's no way to determine a bias anyway, making it "random".

Put it this way, if you were to bet on a nonce value, would you say 1 has as good a chance as any other value < 2^32 of being the next block's nonce?

No, I think lower values would have higher probability. Even if miners go through the range very quickly, they're going to be going 0, 1, ..., 2^32, 0, 1, ..., 2^32, ... repeatedly, and the place where they stop will almost always exclude some of the higher nonce values, making lower values more likely overall.
736  Bitcoin / Bitcoin Discussion / MOVED: Bitcoin Core #REKT on: January 16, 2016, 08:46:37 PM
This topic has been moved to Altcoin Discussion.

https://bitcointalk.org/index.php?topic=1330351.0
737  Bitcoin / Development & Technical Discussion / Re: I support "Bitcoin Classic" (2MB), if the activation threshold is over 95% on: January 16, 2016, 07:35:29 PM
There's no difference between an activation threshold of 75% (or 51%) and 95% because pro-fork miners can just start rejecting blocks from anti-fork miners to increase the percentage. Miner voting is a stupid concept for hardforks -- it's the economy that matters in a hardfork, not miners.
738  Bitcoin / Bitcoin Discussion / Re: Analysis and list of top big blocks shills (XT #REKT ignorers) on: January 16, 2016, 06:43:00 AM
Looks like Classic isn't so "democratic" after all: https://github.com/bitcoinclassic/bitcoinclassic/pull/6
739  Bitcoin / Bitcoin Discussion / Re: Hearn's "Faith in Humanity Shaken" after People Awaken to His EVIL Plan! on: January 16, 2016, 01:10:23 AM
Has anyone with high technical knowledge taken the time to deconstruct his post point-by-point? He does make some interesting points that even I (not by any means a "big blockist") feel should be addressed.

Pick out a few of the more interesting bits and I'll respond to them.

Quote
Why would Satoshi not sign his post, thus proving that it really is him? Surely that would be a big blow to the ph0rkers, no?

- Satoshi never signed his posts.
- He likely wouldn't want it to look like he was dictating Bitcoin's future.
740  Other / Archival / Re: Theymos you have 48 hours on: January 15, 2016, 10:43:13 PM
Please, do fill us all in.

As far as I know, Paraipan died and took the 250 BTC he was holding for the forum with him. I put some effort into trying to locate his family or something, but I couldn't.
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 ... 351 »
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!