Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > If the difficulty can be directly observed by the script language, you > would need to re-evaluate all scripts in unconfirmed transactions > whenever the difficulty changes. This

Re: [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size

Related ideas previously submitted by me; https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013885.html Title: Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) Den sön 7 apr. 2019 17:45simondev1 via bitcoin-dev <

Re: [bitcoin-dev] BIP- & SLIP-0039 -- better multi-language support

Den mån 19 nov. 2018 21:21 skrev Steven Hatzakis via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > Hi Weiji, and Everyone, > > I think this is an important topic so sharing my two cents in case in > helps: It makes sense for users to know that they can't merely just > translate a word

Re: [bitcoin-dev] Should Graftroot be optional?

Den tor 24 maj 2018 04:08Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> skrev: > > My understanding of the question is this: > > Are there any useful applications which would be impeded if a signing > party who could authorize an arbitrary transaction spending a coin had

Re: [bitcoin-dev] Should Graftroot be optional?

Den tor 24 maj 2018 01:45Gregory Maxwell skrev: > I am having a bit of difficulty understanding your example. > > If graftroot were possible it would mean that the funds were paid to a > public key. That holder(s) of the corresponding private key could > sign without constraint,

Re: [bitcoin-dev] Should Graftroot be optional?

Den tis 22 maj 2018 20:18Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> skrev: > Hello all, > > Given the recent discussions about Taproot [1] and Graftroot [2], I > was wondering if a practical deployment needs a way to explicitly > enable or disable the Graftroot

Re: [bitcoin-dev] Transition to post-quantum

Small correction, see edited quote Den 15 feb. 2018 23:44 skrev "Natanael" : Allowing expiration retains insecurity, while *NOT* allowing expiration makes it a trivial DoS target. ___ bitcoin-dev mailing list

Re: [bitcoin-dev] Transition to post-quantum

Den 15 feb. 2018 22:58 skrev "Tim Ruffing via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: Also, the miners will indeed see one valid decommitment. This decommitment may have been sent by the attacker but it's the preimage chal of the address, because otherwise it's not valid for the

Re: [bitcoin-dev] Transition to post-quantum

Den 15 feb. 2018 17:00 skrev "Tim Ruffing via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: Consensus rules === A decommitment d = chal spends a UTXO with address H_addr(chal), if there exists a commitment c in the blockchain which references the UTXO and which is the first

Re: [bitcoin-dev] Possible change to the MIT license

Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CAÑUELO via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: *** NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS THE SOFTWARE PRODUCED BY THAT

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

Den 25 jan. 2018 00:22 skrev "Tim Ruffing via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: I think you misread my second proposal. The first step is not only to publish the hash but to publish a *pair* consisting of the hash and the transaction. If the attacker changes the transaction

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

Den 24 jan. 2018 16:38 skrev "Tim Ruffing via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: Okay, I think my proposal was wrong... This looks better (feel free to break again): 1. Commit (H(classic_pk, tx), tx) to the blockchain, wait until confirmed 2. Reveal classic_pk in the

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

Den 23 jan. 2018 23:45 skrev "Gregory Maxwell via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: On Tue, Jan 23, 2018 at 10:22 PM, Anthony Towns wrote: > Hmm, at least people can choose not to reuse addresses currently -- > if everyone were using taproot and that

Re: [bitcoin-dev] Proposal to reduce mining power bill

A large miner would only need to divide his hardware setup into clusters that pretend to be different independent miners to create these "miner tokens", as explained before, to significantly raise his chances that he on nearly every single round would be able to mine. Once each individual token

Re: [bitcoin-dev] BIP Proposal: Utilization of bits denomination

Reposting /u/BashCo's post on reddit here, for visibility: ---8<--- > Before anyone says 'bits' are too confusing because it's a computer science term, here's a list of homonyms [https://en.wikipedia.org/ wiki/List_of_true_homonyms]

Re: [bitcoin-dev] Fwd: [Lightning-dev] Lightning in the setting of blockchain hardforks

Couldn't scripts like this have a standardized "hardfork unroll" mechanism, where if a hardfork is activated and signaled to its clients, then those commitments that are only meant for their original chain can be reversed and undone just on the hardfork? Then the users involved would just send an

Re: [bitcoin-dev] Full node "tip" function

Den 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: I'll soon present a solution to encourage full nodes to store the blockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS) Proving that you're holding your own copy of the

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

Den 3 maj 2017 16:05 skrev "Erik Aronesty via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: > But as you've observed, the failure probabilities are rather high, > especially if an active attacker targets nodes carrying less commonly > available blocks. Wouldn't the solution be for nodes

[bitcoin-dev] Properties of an ideal PoW algorithm & implementation

To expand on this below; Den 18 apr. 2017 00:34 skrev "Natanael" : IMHO the best option if we change PoW is an algorithm that's moderately processing heavy (we still need reasonably fast verification) and which resists partial state reuse (not fast or fully "linear" in

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

Den 17 apr. 2017 16:14 skrev "Erik Aronesty via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: It's too bad we can't make the POW somehow dynamic so that any specialized hardware is impossible, and only GPU / FPGA is possible. Maybe a variant of Keccak where the size of the sponge is

Re: [bitcoin-dev] I do not support the BIP 148 UASF

Den 15 apr. 2017 13:51 skrev "Chris Acheson via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: Not sure if you missed my previous reply to you, but I'm curious about your thoughts on this particular point. I contend that for any UASF, orphaning non-signalling blocks on the flag date is

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

My point, if you missed it, is that there's a mathematical equivalence between using two limits (and calculating the ratio) vs using one limit and a ratio. The output is fully identical. The only difference is the order of operations. Saying there's no blocksize limit with this is pretty

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Den 1 apr. 2017 16:07 skrev "Jorge Timón" : On Sat, Apr 1, 2017 at 3:15 PM, Natanael wrote: > > > Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev" > : > > Segwit replaces the 1 mb size limit with a weight

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

Den 1 apr. 2017 16:35 skrev "Eric Voskuil via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/31/2017 11:18 PM, Jared Lee Richardson wrote: >> If a typical personal computer cannot run a node there is no >> security. > > If you can't

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

Den 1 apr. 2017 01:13 skrev "Eric Voskuil via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/31/2017 02:23 PM, Rodney Morris via bitcoin-dev wrote: > If the obsession with every personal computer being able to run a > fill node

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: Segwit replaces the 1 mb size limit with a weight limit of 4 mb. That would make it a hardfork, not a softfork, if done exactly as you say. Segwit only separates out signature data. The 1 MB

Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool)

Sorry for sending a double, hit the wrong button... Den 31 mars 2017 06:14 skrev "Natanael" : > > > Den 30 mars 2017 11:34 skrev "Natanael" : > > Block size dependent difficulty scaling. Hardfork required. > > Larger blocks means greater difficulty -

Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool)

Den 30 mars 2017 11:34 skrev "Natanael" : Block size dependent difficulty scaling. Hardfork required. Larger blocks means greater difficulty - but it doesn't scale linearly, rather a little less than linearly. That means miners can take a penalty in difficulty to claim a

Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool)

Den 30 mars 2017 12:04 skrev "Luke Dashjr" : I don't see a purpose to this proposal. Miners always mine as if it's their *only* chance to get the fee, because if they don't, another miner will. Ie, after 1 block, the fee effectively drops to 0 already. I believe that with

[bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool)

I had these following ideas as I was thinking about how to allow larger blocks without incentivizing the creation of excessively large blocks. I don't know how much of this is novel, I'd appreciate if anybody could link to any relevant prior art. I'm making no claims on this, anything novel in

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

Den 25 jan. 2017 08:22 skrev "Johnson Lau" : Assuming Alice is paying Bob with an old style time-locked tx. Under your proposal, after the hardfork, Bob is still able to confirm the time-locked tx on both networks. To fulfil your new rules he just needs to send the outputs to

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

Den 25 jan. 2017 08:06 skrev "Johnson Lau" : What you describe is not a fix of replay attack. By confirming the same tx in both network, the tx has been already replayed. Their child txs do not matter. Read it again. The validation algorithm would be extended so that the

Re: [bitcoin-dev] Could a sidechain protocol create an addressable "Internet of Blockchains" and facilitate scaling?

Den 12 okt. 2016 01:33 skrev "John Hardy via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: > Sidechains seem an inevitable tool for scaling. They allow Bitcoins to be transferred from the main blockchain into external blockchains, of which there can be any number with radically different

Re: [bitcoin-dev] Bitcoin Guarantees Strong, not Eventual, Consistency.

To say that Bitcoin is strongly consistent is to say that the memory pool and the last X blocks aren't part of Bitcoin. If you want to avoid making that claim, you can at best argue that Bitcoin has both a strongly consistent component AND an eventually consistent component. The entire point of

Re: [bitcoin-dev] We need to fix the block withholding attack

Wouldn't block withhold be fixed by not letting miners in pools know which block candidates are valid before the pool knows? (Note: I haven't read any other proposals for how to fix it, this may already be known) As an example, by having the pool use the unique per-miner nonces sent to each miner

Re: [bitcoin-dev] We need to fix the block withholding attack

Den 20 dec 2015 12:38 skrev "Tier Nolan via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: > > On Sun, Dec 20, 2015 at 5:12 AM, Emin Gün Sirer < bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> An attacker pool (A) can take a certain portion of its hashpower, >> use it to mine on

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

Den 2 sep 2015 00:03 skrev "Btc Drak via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: > > I think it gets worse. Who are the copyright owners (if this actually > applies). You've got people publishing transaction messages, you've > got miners reproducing them and publishing blocks. Who

Re: [bitcoin-dev] Censorship

One last comment here on this topic; For anybody who wants to discuss decentralized communication mechanisms in general, they can come to www.reddit.com/r/p2pcomms (up until these decentralized forums have become stable and common). I've seen quite a few more of these projects lately, I want to

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

Den 7 aug 2015 23:37 skrev Sergio Demian Lerner via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org: Mark, It took you 3 minutes to respond to my e-mail. And I responded to you 4 minutes later. If you had responded to me in 10 minutes, I would be of out the office and we wouldn't have this