Re: [bitcoin-dev] reviving op_difficulty

2020-08-17 Thread Tier Nolan via bitcoin-dev
On Mon, Aug 17, 2020 at 6:04 AM ZmnSCPxj wrote: > Taproot MAST to the rescue. > Another option would be a binary payout You pay 64 + 32 + 16 + 8 + 4 + 2 + 1 as outputs. The outputs are enabled/disabled based on the diff value. This would require division and also binary operators. D = (int)

Re: [bitcoin-dev] reviving op_difficulty

2020-08-16 Thread Tier Nolan via bitcoin-dev
On Sun, Aug 16, 2020 at 4:50 PM Thomas Hartman via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > My understanding is that adding a single op_difficulty operation as > proposed would enable not true difficulty futures but binary options > on difficulty. > >

Re: [bitcoin-dev] Chain width expansion

2019-10-15 Thread Tier Nolan via bitcoin-dev
On Tue, Oct 15, 2019 at 7:29 AM Braydon Fuller via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > So I don't think you can use the height in the coinbase for that > purpose, as it's not possible to validate it without the previous > headers. That's common for more than just the

Re: [bitcoin-dev] Chain width expansion

2019-10-04 Thread Tier Nolan via bitcoin-dev
Are you assuming no network protocol changes? At root, the requirement is that peers can prove their total chain POW. Since each block has the height in the coinbase, a peer can send a short proof of height for a disconnected header and could assert the POW for that header. Each peer could send

Re: [bitcoin-dev] How accurate are the Bitcoin timestamps?

2018-01-29 Thread Tier Nolan via bitcoin-dev
On Mon, Jan 29, 2018 at 1:34 PM, Neiman via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > *2.* Timestamps are not necessary to avoid double-spending. A simple > ordering of blocks is sufficient, so exchanging timestamps with enumeration > would work double-spending wise.

Re: [bitcoin-dev] Merge of protocol

2018-01-24 Thread Tier Nolan via bitcoin-dev
If the communities behind two coins wanted to merge, it would be possible, but difficulty and risky. It represents a hard fork on both chains. Not only does each coin's community need to agree, the two communities need to agree with each other. They would both have to agree the join point. The

Re: [bitcoin-dev] "Compressed" headers stream

2017-12-11 Thread Tier Nolan via bitcoin-dev
On Mon, Dec 11, 2017 at 9:56 PM, Jim Posen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Omitting nBits entirely seems reasonable, I wrote up a possible > implementation here > . > The

Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?

2017-09-15 Thread Tier Nolan via bitcoin-dev
On Fri, Sep 15, 2017 at 10:14 AM, Adam Back via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > True however in principle a soft-fork can also be soft-forked out. Eg say > a publicly known soft-fork done by miners only that user node software did > not upgrade for first by opt-in

Re: [bitcoin-dev] 2 softforks to cut the blockchain and IBD time

2017-09-13 Thread Tier Nolan via bitcoin-dev
On Tue, Sep 12, 2017 at 11:58 PM, michele terzi via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Pros: > > you gain a much faster syncing for new nodes. > full non pruning nodes need a lot less HD space. > dropping old history results in more difficult future chainanalysis (at

Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0

2017-09-07 Thread Tier Nolan via bitcoin-dev
You could have a timelocked transaction that has a zero value input (and other non-zero inputs). If the SF happened, that transaction would become unspendable. The keys to the outputs may be lost or the co-signer may refuse to cooperate. There seems to be some objections to long term timelocked

Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0

2017-09-06 Thread Tier Nolan via bitcoin-dev
On Tue, Sep 5, 2017 at 10:51 PM, Jorge Timón via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Is there any reason or use case to keep allowing spendable outputs > with null amounts in them? > Someone could have created a timelocked transaction that depends on a zero value

Re: [bitcoin-dev] how to disable segwit in my build?

2017-07-14 Thread Tier Nolan via bitcoin-dev
On Fri, Jul 14, 2017 at 12:20 AM, Dan Libby via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 07/13/2017 03:50 PM, Hampus Sjöberg wrote: > > 2. Avoid any chain of transaction that contains a SegWit transaction > > sounds good, though I'm unclear on how exactly to achieve (2)

Re: [bitcoin-dev] Drivechain -- Request for Discussion

2017-05-25 Thread Tier Nolan via bitcoin-dev
On Wed, May 24, 2017 at 6:32 PM, CryptAxe via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Also the block number can only change by +1 or -1, so when a new h* is > added to the > queue it must be compared to the most recent h* in the queue. > std::abs(queue.back().nHeight -

Re: [bitcoin-dev] Drivechain -- Request for Discussion

2017-05-24 Thread Tier Nolan via bitcoin-dev
On Wed, May 24, 2017 at 9:50 AM, Tier Nolan wrote: > OP_BRIBE_VERIFY could then operate as follows > >OP_BRIBE_VERIFY > > This causes the script to fail if >does not match the block height, or >is not the hash for the sidechain with , or > there is no hash for

Re: [bitcoin-dev] Drivechain -- Request for Discussion

2017-05-24 Thread Tier Nolan via bitcoin-dev
On Tue, May 23, 2017 at 3:22 PM, Paul Sztorc wrote: > > If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is > probably the most human-readable description. > I guess I was looking for the detail you get in the code, but without having to read the code.

Re: [bitcoin-dev] Drivechain -- Request for Discussion

2017-05-23 Thread Tier Nolan via bitcoin-dev
On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc wrote: > I would replace "Bitcoins you manage to steal" with "Bitcoins you manage > to double-spend". Then, it still seems the same to me. > > With double spending, you can only get ownership of coins that you owned at some point

Re: [bitcoin-dev] Drivechain -- Request for Discussion

2017-05-22 Thread Tier Nolan via bitcoin-dev
On Mon, May 22, 2017 at 5:19 PM, Paul Sztorc via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > In the future, when there is no block subsidy, a rich attacker can also do > that in mainchain Bitcoin. > I don't think they are the same. With Bitcoin, you only get to reverse

Re: [bitcoin-dev] Treating ‘ASICBOOST’ as a Security Vulnerability

2017-05-18 Thread Tier Nolan via bitcoin-dev
On Thu, May 18, 2017 at 2:44 PM, Cameron Garnham via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 1. Significant deviations from the Bitcoin Security Model have been > acknowledged as security vulnerabilities. > > The Bitcoin Security Model assumes that every input into the

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

2017-04-18 Thread Tier Nolan via bitcoin-dev
This has been discussed before. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008101.html including a list of nice to have features by Maxwell https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008110.html You meet most of these rules, though you do have to

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-14 Thread Tier Nolan via bitcoin-dev
t; On an unrelated note, the two costs could be combined into a unified > cost. For example, a sigop could have equal cost to 250 bytes. This would > make it easier for miners to decide what to charge. > > On the other hand, CPU cost and storage/network costs are not completely > in

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-14 Thread Tier Nolan via bitcoin-dev
other hand, CPU cost and storage/network costs are not completely interchangeable. Is there anything that would need to be summed fees, raw tx size, weight and sigops that the greater or equal rule wouldn't cover? On 12 Dec 2016, at 00:40, Tier Nolan via bitcoin-dev <bitcoin-dev@lists. linuxfoundat

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-11 Thread Tier Nolan via bitcoin-dev
On Sat, Dec 10, 2016 at 9:41 PM, Luke Dashjr <l...@dashjr.org> wrote: > On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev wrote: > > Any new merkle algorithm should use a sum tree for partial validation and > > fraud proofs. > > PR welcome. > Fa

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-10 Thread Tier Nolan via bitcoin-dev
On Sun, Dec 4, 2016 at 7:34 PM, Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Something not yet done: > 1. The new merkle root algorithm described in the MMHF BIP > Any new merkle algorithm should use a sum tree for partial validation and fraud proofs. Is there

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

2016-11-17 Thread Tier Nolan via bitcoin-dev
On Thu, Nov 17, 2016 at 12:43 AM, Eric Voskuil wrote: > > This means that all future transactions will have different txids... > rules do guarantee it. > > No, it means that the chance is small, there is a difference. > I think we are mostly in agreement then? It is just

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

2016-11-16 Thread Tier Nolan via bitcoin-dev
On Thu, Nov 17, 2016 at 12:10 AM, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Both of these cases resulted from exact duplicate txs, which BIP34 now > precludes. However nothing precludes different txs from having the same > hash. > The only way to have two

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

2016-11-16 Thread Tier Nolan via bitcoin-dev
On Wed, Nov 16, 2016 at 1:58 PM, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Are checkpoints good now? Are hard forks okay now? > I think that at least one checkpoint should be included. The assumption is that no 50k re-orgs will happen, and that assumption

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

2016-08-11 Thread Tier Nolan via bitcoin-dev
On Thu, Aug 11, 2016 at 2:55 PM, Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Sorr, I thought there was some BIP for a public seed such that someone can > generate new random addresses, but cannot trivially verify whether an > address was derived from the seed.

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

2016-08-10 Thread Tier Nolan via bitcoin-dev
Have you considered CDMA? This has the nice property that it just sounds like noise. The codes would take longer to send, but you could send multiple bits at once and have the codes orthogonal. ___ bitcoin-dev mailing list

Re: [bitcoin-dev] BIP clearing house addresses

2016-08-08 Thread Tier Nolan via bitcoin-dev
With channels and the exchange acting as hub, you can do instant trades between altcoins. This doesn't work with fiat accounts. A "100% reserve" company could issue fiat tokens. The exchange could then trade those tokens. This eliminates the counter-party risk for the exchange. If the

Re: [bitcoin-dev] BIP clearing house addresses

2016-08-08 Thread Tier Nolan via bitcoin-dev
On Mon, Aug 8, 2016 at 1:48 AM, Matthew Roberts wrote: > Not everyone who uses centralized exchanges are there to obtain the > currency though. A large portion are speculators who need to be able to > enter and exit complex positions in milliseconds and don't care about >

Re: [bitcoin-dev] BIP clearing house addresses

2016-08-03 Thread Tier Nolan via bitcoin-dev
On Wed, Aug 3, 2016 at 7:16 PM, Matthew Roberts via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The reason why I bring this up is existing OP codes and TX types don't > seem suitable for a secure clearing mechanism; > I think reversing transactions is not likely to be

Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin

2016-07-26 Thread Tier Nolan via bitcoin-dev
On Tue, Jul 26, 2016 at 9:58 PM, Martijn Meijering via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Is there a reason miners would be more likely to engage in selfish > mining of sync flags than they are now with ordinary blocks? > This proposal has the same effect as adding

Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-10 Thread Tier Nolan via bitcoin-dev
The various chunks in the double SHA256 are Chunk 1: 64 bytes version previous_block_digest merkle_root[31:4] Chunk 2: 64 bytes merkle_root[3:0] nonce timestamp target Chunk 3: 64 bytes digest from first sha pass Their improvement requires that all data in Chunk 2 is identical except for the

Re: [bitcoin-dev] p2p authentication and encryption BIPs

2016-03-23 Thread Tier Nolan via bitcoin-dev
There is probably not much loss due to per message encryption. Even if a MITM determined that a message was an inv message (or bloom filter message), it wouldn't be able to extract much information. Since the hashes in those messages are fixed size, there is very little leakage. You could make

Re: [bitcoin-dev] Services bit for xthin blocks

2016-03-09 Thread Tier Nolan via bitcoin-dev
On Wed, Mar 9, 2016 at 6:11 PM, G. Andrew Stone via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Thanks for your offer Luke, but we are happy with our own process and, > regardless of historical provenance, see this mailing list and the BIP > process as very Core specific for

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

2016-03-02 Thread Tier Nolan via bitcoin-dev
On Wed, Mar 2, 2016 at 4:27 PM, Paul Sztorc via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > For example, it is theoretically possible that 100% of miners (not 50% > or 10%) will shut off their hardware. This is because it is revenue > which ~halves, not profit. It depends on

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

2016-03-02 Thread Tier Nolan via bitcoin-dev
If a hard-fork is being considered, the easiest is to just step the difficulty down by a factor of 2 when the adjustment happens. This means that miners still get paid the same minting fee per hash as before. There isn't that much risk. If the hashing power stays constant, then there will be 5

Re: [bitcoin-dev] BIP CPRKV: Check private key verify

2016-02-29 Thread Tier Nolan via bitcoin-dev
On Mon, Feb 29, 2016 at 10:58 AM, Mats Jerratsch wrote: > This is actually very useful for LN too, see relevant discussion here > > > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011827.html > Is there much demand for trying to code up a patch to the

Re: [bitcoin-dev] Fast bootstrapping with a pre-generated UTXO-set database

2016-02-29 Thread Tier Nolan via bitcoin-dev
One of the proposals was to build the UTXO set backwards. You start from the newest block and work backwards. The database contains UTXOs (unspent transaction outputs) and "UFTXI" (unfunded transaction inputs). The procedure would be For each transaction (last to first ordering) For each

Re: [bitcoin-dev] The first successful Zero-Knowledge Contingent Payment

2016-02-26 Thread Tier Nolan via bitcoin-dev
On Fri, Feb 26, 2016 at 11:45 PM, Gregory Maxwell wrote: > Why not use the single-show-signature scheme I came up with a while > back on the Bitcoin side to force the bitcoin side to reveal a private > key? > > >

Re: [bitcoin-dev] The first successful Zero-Knowledge Contingent Payment

2016-02-26 Thread Tier Nolan via bitcoin-dev
That is very interesting. There has been some recent discussion about atomic cross chain transfers between Bitcoin and legacy altcoins. For this purpose a legacy altcoin is one that has strict IsStandard() rules and none of the advanced script opcodes. It has a requirement that Bob sends Alice

Re: [bitcoin-dev] Multi-Stage Merge-Mine Headers Hard-Fork BIP

2016-02-24 Thread Tier Nolan via bitcoin-dev
You need more detail for it to be a BIP. New Header new_header.prev = hash of previous header's bitcoin header new_header.small_nonce = 4 byte nonce new_header.big_nonce = 8 byte nonce new_header (Can contain any new fields desired) Fake Block block.version = 4 block.prev =

[bitcoin-dev] Sig-Witness and legacy outputs

2016-02-18 Thread Tier Nolan via bitcoin-dev
I wrote a bip last year about extended transaction information. The idea was to include the scriptPubKey that was being spent along with transactions. https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx.mediawiki This makes it easier possible to verify the transactions locally.

Re: [bitcoin-dev] BIP CPRKV: Check private key verify

2016-02-12 Thread Tier Nolan via bitcoin-dev
On Fri, Feb 12, 2016 at 5:02 AM, wrote: > Seems it could be done without any new opcode: > The assumption was that the altcoin would only accept standard output scripts. Alice's payment in step 2 pays to a non-standard script. This is an improvement over the cut and choose, but

Re: [bitcoin-dev] Soft fork fix for block withholding attacks

2016-02-12 Thread Tier Nolan via bitcoin-dev
If clients were designed to warn their users when a soft fork happens, then it could be done reasonably safely. The reference client does this (or is it just for high POW softforks?), but many SPV clients don't. If there was a delay between version number changing and the rule activation, at

[bitcoin-dev] BIP CPRKV: Check private key verify

2016-02-11 Thread Tier Nolan via bitcoin-dev
There was some discussion on the bitcointalk forums about using CLTV for cross chain transfers. Many altcoins don't support CLTV, so transfers to those coins cannot be made secure. I created a protocol. It uses on cut and choose to allow commitments to publish private keys, but it is clunky and

Re: [bitcoin-dev] BIP CPRKV: Check private key verify

2016-02-11 Thread Tier Nolan via bitcoin-dev
On Thu, Feb 11, 2016 at 10:20 PM, Thomas Kerin wrote: > I wonder if this is possible as a soft fork without using segwit? Increasing the sigop count for a NOP would be a hard fork, but such a change would be fine with a new segwit version. It might require specific

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

2016-02-10 Thread Tier Nolan via bitcoin-dev
On Wed, Feb 10, 2016 at 6:14 AM, David Vorick via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I'm not clear on the utility of more nodes. Perhaps there is significant > concern about SPV nodes getting enough bandwidth or the network struggling > from the load? > It is

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

2016-02-07 Thread Tier Nolan via bitcoin-dev
On Sun, Feb 7, 2016 at 7:03 PM, Patrick Strateman via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I would expect that custodians who fail to produce coins on both sides > of a fork in response to depositor requests will find themselves in > serious legal trouble. > If the

Re: [bitcoin-dev] Time to worry about 80-bit collision attacks or not?

2016-01-11 Thread Tier Nolan via bitcoin-dev
On Fri, Jan 8, 2016 at 3:46 PM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > How many years until we think a 2^84 attack where the work is an ECDSA > private->public key derivation will take a reasonable amount of time? > I think the EC multiply is not

Re: [bitcoin-dev] New BIP editor, and request for information

2016-01-11 Thread Tier Nolan via bitcoin-dev
On Thu, Jan 7, 2016 at 5:10 PM, Luke Dashjr wrote: > - BIP 46 is missing from the repository, but apparently self-soft-assigned > by > Tier Nolan in > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005545.html > ; if this was later assigned official, or if he

Re: [bitcoin-dev] A new payment address format for segregated witness or not?

2015-12-21 Thread Tier Nolan via bitcoin-dev
On Mon, Dec 21, 2015 at 5:14 AM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The SW in P2SH is worse in terms of: > 1. It requires an additional push in scriptSig, which is not prunable in > transmission, and is counted as part of the core block size > "Prunable in

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

2015-12-20 Thread Tier Nolan via bitcoin-dev
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 behalf of victim pool (B), furnish partial proofs of work > to B, but discard any full blocks it discovers. > I

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

2015-12-20 Thread Tier Nolan via bitcoin-dev
On Sun, Dec 20, 2015 at 12:42 PM, Natanael wrote: > If total difficulty is X and the ratio for full blocks to candidate blocks > shared with the pool is Y, then the candidate block PoW now has to meet X/Y > while hashing the candidate block PoW + the pool's commitment hash

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

2015-12-20 Thread Tier Nolan via bitcoin-dev
This is essentially the "nuclear option". You are destroying the current chain (converting it to a chain of coinbases) and using the same POW to start the new chain. You are also giving everyone credit in the new chain equal to their credit in the old chain. It would be better if the current

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

2015-12-18 Thread Tier Nolan via bitcoin-dev
On Thu, Dec 17, 2015 at 7:44 PM, Peter Todd wrote: > If Bitcoin remains decentralized, miners have veto power over any > blocksize increases. You can always soft-fork in a blocksize reduction > in a decentralized blockchain that actually works. > The actual users of the

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

2015-12-17 Thread Tier Nolan via bitcoin-dev
On Wed, Dec 16, 2015 at 9:11 PM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > We are not avoiding a choice. We don't have the authority to make a choice. > This is really the most important question. Bitcoin is kind of like a republic where there is separation

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

2015-12-13 Thread Tier Nolan via bitcoin-dev
On Sun, Dec 13, 2015 at 6:11 PM, jl2012--- via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Back to the topic, I would like to further elaborate my proposal. > > We have 3 types of full nodes: > > Archive nodes: full nodes that store the whole blockchain > Full UTXO nodes: full

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

2015-12-08 Thread Tier Nolan via bitcoin-dev
On Tue, Dec 8, 2015 at 5:41 PM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > A far better place than the generation transaction (which I assume means > coinbase transaction?) is the last transaction in the block. That allows > you to save, on average, half of

Re: [bitcoin-dev] Dealing with OP_IF and OP_NOTIF malleability

2015-11-06 Thread Tier Nolan via bitcoin-dev
One and zero should be defined as arrays of length one. Otherwise, it is still possible to mutate the transaction by changing the length of the array. They should also be minimally encoded but that is covered by previous rules. On Fri, Nov 6, 2015 at 8:13 AM, jl2012 via bitcoin-dev <

Re: [bitcoin-dev] Dealing with OP_IF and OP_NOTIF malleability

2015-11-06 Thread Tier Nolan via bitcoin-dev
I meant not to use the OP_PUSH opcodes to do the push. Does OP_0 give a zero length byte array? Would this script return true? OP_0 OP_PUSHDATA1 (length = 1, data = 0) OP_EQUAL The easiest definition is that OP_0 and OP_1 must be used to push the data and not any other push opcodes. On Fri,

Re: [bitcoin-dev] Compatibility requirements for hard or soft forks

2015-11-01 Thread Tier Nolan via bitcoin-dev
On Mon, Nov 2, 2015 at 12:23 AM, Justus Ranvier via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Are there actually any OP_CAT scripts currently in the utxo set? > A locked transaction could pay to an OP_CAT script with the private key being lost. Even if it is only in theory,

Re: [bitcoin-dev] Compatibility requirements for hard or soft forks

2015-11-01 Thread Tier Nolan via bitcoin-dev
On Sun, Nov 1, 2015 at 5:28 PM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I think it is very important to make it clear that non-standard txs and > non-standard scripts may become invalid in the future > There can be unavoidable situations which cause locked coins

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

2015-10-19 Thread Tier Nolan via bitcoin-dev
On Mon, Oct 19, 2015 at 3:01 PM, Christian Decker via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > As with the previous version, which was using a hard-fork, the normalized > transaction ID is computed only considering the non-malleable parts of a > transaction, i.e., stripping

Re: [bitcoin-dev] Liquid

2015-10-13 Thread Tier Nolan via bitcoin-dev
It is interesting someone trying the sidechain approach. I guess having trusted third parties to manage the chain was not a short term thing? It looks like there is no POW for the Liquid sidechain. This is an area where the bitcoin could benefit by adding a way to transfer money to/from

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

2015-09-28 Thread Tier Nolan via bitcoin-dev
On Mon, Sep 28, 2015 at 11:48 AM, Mike Hearn via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 1) Drop the "everyone must agree to make changes" idea that people here > like to peddle, and do it loudly, so everyone in the community is correctly > informed > There never was a rule

Re: [bitcoin-dev] Weak block thoughts...

2015-09-27 Thread Tier Nolan via bitcoin-dev
On Sun, Sep 27, 2015 at 2:39 AM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Unless the weak block transaction list can be a superset of the block > transaction list size proportional propagation costs are not totally > eliminated. > The POW threshold could

Re: [bitcoin-dev] Torrent-style new-block propagation on Merkle trees

2015-09-24 Thread Tier Nolan via bitcoin-dev
On Thu, Sep 24, 2015 at 12:12 AM, Jonathan Toomim (Toomim Bros) via bitcoin-dev wrote: > > > As I understand it, the current block propagation algorithm is this: > > 1. A node mines a block. > 2. It notifies its peers that it has a new block with an *inv*.

Re: [bitcoin-dev] [BIP Proposal] New "sendheaders" p2p message

2015-09-24 Thread Tier Nolan via bitcoin-dev
On Thu, Sep 24, 2015 at 7:02 PM, Suhas Daftuar via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > > I'm proposing the addition of a new, optional p2p message to help improve > the way blocks are announced on the network. The draft BIP is available > here and pasted below: >

Re: [bitcoin-dev] Weak block thoughts...

2015-09-23 Thread Tier Nolan via bitcoin-dev
On Wed, Sep 23, 2015 at 4:43 PM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Imagine miners always pre-announce the blocks they're working on to their > peers, and peers validate those 'weak blocks' as quickly as they are able. > > Because weak blocks are

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

2015-09-17 Thread Tier Nolan via bitcoin-dev
On Wed, Sep 16, 2015 at 11:52 PM, Eric Lombrozo wrote: > The exact numbers (95% vs. 75% etc) don't need to be completely specified > to start working on an implementation. What really matters for now is > defining the states and trigger mechanisms. I'd rather we not argue

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

2015-09-16 Thread Tier Nolan via bitcoin-dev
On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > '''States''' > With every softfork proposal we associate a state BState, which begins > at ''defined'', and can be ''locked-in'', ''activated'', > or ''failed''. Transitions are

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

2015-09-16 Thread Tier Nolan via bitcoin-dev
On Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell wrote: > I couldn't see a use for it, since partial enforcement of a soft fork is > pretty useless. > It isn't useful for actually using the feature, but some miners might set the bit but not actually create blocks that

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

2015-09-16 Thread Tier Nolan via bitcoin-dev
On Wed, Sep 16, 2015 at 9:38 PM, Jorge Timón wrote: > No, 95% is safer and will produce less orphaned blocks. > The point of the 75% is just as a test run. Enforcement wouldn't happen until 95%. At 75%, if someone sets the bit, then they should be creating valid blocks (under

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

2015-09-16 Thread Tier Nolan via bitcoin-dev
On Wed, Sep 16, 2015 at 9:54 PM, Jorge Timón <jti...@jtimon.cc> wrote: > > On Sep 16, 2015 4:49 PM, "Tier Nolan via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > At 75%, if someone sets the bit, then they should be creating valid > bl

Re: [bitcoin-dev] BIP 100 specification

2015-09-03 Thread Tier Nolan via bitcoin-dev
On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > >1. > >hardLimit floats within the range 1-32M, inclusive. > > > Does the 32MB limit actually still exist anywhere in the code? In effect, it is re-instating a legacy limitation. The

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

2015-08-25 Thread Tier Nolan via bitcoin-dev
On Tue, Aug 25, 2015 at 11:08 PM, Mark Friedenbach via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Assuming a maximum of 1-year relative lock-times. But what is an appropriate maximum to choose? The use cases I have considered have only had lock times on the order of a few days

Re: [bitcoin-dev] Economic majority vote by splitting coins

2015-08-21 Thread Tier Nolan via bitcoin-dev
On Fri, Aug 21, 2015 at 4:22 AM, odinn odinn.cyberguerri...@riseup.net wrote: That's interesting. But in all honesty I don't see most users being able to pull off what you are describing. The idea assumes that it is a BIP + soft fork. This means that most wallets would support/recognise the

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

2015-08-19 Thread Tier Nolan via bitcoin-dev
On Wed, Aug 19, 2015 at 4:22 PM, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Will the adoption of BitcoinXT lead by miners? No, it won't. Actually, Chinese miners who control 60% of the network has already said that they would not adopt XT. So they must not be the

Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

2015-08-19 Thread Tier Nolan via bitcoin-dev
On Wed, Aug 19, 2015 at 6:25 PM, Btc Drak btcd...@gmail.com wrote: In our case for Bitcoin Core, option 2 we use nVersion=8, apply a bitmask of 0xdff8 thus: if ((block.nVersion ~0x2007) = 4 CBlockIndex::IsSuperMajority(...)) { //...} With nVersion=8, but using comparison =4

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

2015-08-17 Thread Tier Nolan via bitcoin-dev
On Mon, Aug 17, 2015 at 12:57 PM, Rodney Morris via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I haven't run any statistics or simulations, but I'm concerned that the interplay between the random distribution of transaction arrival and the random distribution of block times may

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

2015-08-17 Thread Tier Nolan via bitcoin-dev
One of the comments made by the mining pools is that they won't run XT because it is experimental. Has there been any consideration to making available a version of XT with only the blocksize changes? The least experimental version would be one that makes the absolute minimum changes to core.

Re: [bitcoin-dev] BIP draft: Hardfork bit

2015-07-23 Thread Tier Nolan via bitcoin-dev
On Thu, Jul 23, 2015 at 5:23 PM, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: 2) Full nodes and SPV nodes following original consensus rules may not be aware of the deployment of a hardfork. They may stick to an economic-minority fork and unknowingly accept devalued