<unnamed>

Public Key

npub1u03cz099kt69z9awg232rjvlt34azukpzkkvy5uqv64dj9j5fqtshdnn03

Profile Code

nprofile1qqsw8cup8jjm9az3z7hy9g4pex04c673wtq3ttxz2wqxd2keze2ys9cpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmv456fjw

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-08 01:05:09 CEST

- reply

📅 Original date posted:2022-03-05
📝 Original message:Hey ZmnSCPxj,
I thought about this for a few days and I think you are right. In the case
of recurring payments this is identical to nLocktime. When doing recurring
payments with this scheme, you probably want to rate limit subsequent UTXOs
_with_ nlocktimes to make sure a malicious Netflix can't withdraw 12 month
so of subscriptions by attesting with their oracle 12 times.
I think this proposal describes arbitrary lines of pre-approved credit from
a bitcoin wallet. The line can be drawn down with oracle attestations. You
can mix in locktimes on these pre-approved lines of credit if you would
like to rate limit, or ignore rate limiting and allow the full utxo to be
spent by the borrower. It really is contextual to the use case IMO.
-Chris
On Fri, Mar 4, 2022 at 2:22 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Chris,
>
> Quick question.
>
> How does this improve over just handing over `nLockTime`d transactions?
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220305/94c8f310/attachment.html>

2023-06-08 01:05:08 CEST

- reply

📅 Original date posted:2022-03-03
📝 Original message:DLCs are typically thought to be used for betting. Alice & Bob want to
speculate on an event, and have bitcoin payouts rewarded to them if they
bet correctly. The oracle determines what event occurred and produces
attestations representing that outcome.
Recently I had a conversation with a friend about implementing recurring
subscriptions with Discreet Log Contracts. At a high level, you should
think about this working like ACH. If you are purchasing a subscription
from Netflix, they will deduct $20 from your bank account every month. To
do this, you give them your credit card information.
You can do this with Discreet Log Contracts. It requires a slightly
modified DLC setup. Netflix would create an oracle representing a monthly
subscription. They require that users setup DLCs to them that will be
executed at the end of the month. Alice, a subscriber to Netflix, creates a
unilaterally funded DLC to Netflix. She creates adaptor signatures for her
payment and sends them to Netflix.
No bitcoin transaction is required to create this subscription since the
DLC is unilaterally funded. Alice can “cancel” the subscription at any time
by spending from the utxo she is using to fund the DLC.
At the end of the month, Netflix attests that it is time to charge Alice
for her subscription. Netflix takes its own attestation and decrypts
Alice’s adaptor signature to get her signature to send funds to Netflix.
Netflix publishes the settlement transaction for the DLC which pays Netflix
it’s subscription fee for the next month. Netflix also publishes a new
announcement for next month so that Alice can create a new DLC subscription.
Netflix needs to give Alice a bitcoin address to pay to.
The information Alice is required to send Netflix is
1.
Her utxo used to fund the DLC
2.
Her adaptor signature representing her monthly subscription to netflix.
Netflix must verify the adaptor signatures are correct and the utxo exists.
Why is this useful?
It's very convenient for a user to give access to withdraw a certain amount
of money from a bank account at a given time in the future. This is how
recurring payments work in tradfi. This brings the same principle to
bitcoin payments.
DLCs also give you the power to specify how much the service can withdraw.
For instance, with Netflix, they shouldn’t have the ability to withdraw
thousands of dollars worth of bitcoin. The monthly service fee is $20. With
DLCs, you can cryptographically enforce that they will only receive $20.
They cannot withdraw more or less money than they are authorized to.
There may be concerns about Netflix being both the oracle and the entity
receiving a monthly payment. I would argue this is mitigated by the fact
that the service provider could steal at most one months worth of service
fees for users of the subscription. After users get scammed once, they will
cancel their future subscription and distrust the service. The key feature
is the amount of money in the subscription is predetermined, thus the
oracle cannot withdraw excess funds if they are evil.
### QA
Does the DLC use a 2 of 2 multisig between Netflix and Alice?
No, the DLC is unilaterally funded by Alice. This allows her to create the
subscription without an onchain transaction, and also allows her to cancel
the subscription at any time. She cancels the subscription by double
spending the utxo.
Can Netflix steal all the money in the funding output?
No, Alice’s adaptor signatures allow Netflix to withdraw a specific amount
of bitcoin. The change is sent back to an address Alice controls. Both of
these outputs are protected by the adaptor signature.
Is there a perverse incentive for Netflix to be the oracle and receive the
subscription?
The most Netflix can steal in this setup is one months worth of
subscription fees across the entire customer base. In this setup, Alice is
accepting that risk for the convenience of auto withdrawals from her
bitcoin wallet. Remember, Alice can cancel the subscription at any time she
wants by spending from the funding utxo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220303/874d520f/attachment.html>

2023-06-07 20:05:19 CEST

- reply

📅 Original date posted:2017-09-05
📝 Original message:Hi ZmnSCPxj,
Basically, in case of a sidechain fork, the mainchain considers the longest
> chain to be valid if it is longer by the SPV proof required length. In the
> above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E)
> longer than the other sidechain fork that ended at d.
>
> Mainchain nodes can validate this rule because the sidechain headers are
> embedded in the mainchain block's coinbase. Thus, mainchain fullnodes can
> validate this part of the sidechain rule of "longest work chain".
>
What happens in the case that the provided merkle tree hash has a invalid
transaction in it? Wouldn't this mean that the mainchain nodes would think
the longest work chain is the valid chain, and it would kill off any
consensus valid chain that sidechain miners are trying to construct? It
seems that a malicious miner could extend the chain to whatever the SPV
proof block height is and make it impossible for the chain to reorg after
that. I guess if that is a sufficiently long block waiting period it may
not be a realistic concern, but something to think about any way.
Just a side note -- I think it should be highly recommended that the
coinbase maturity period on the sidechain to be longer than 288 (or
whatever we decide on the parameter). This incentivizes the s:miners to
work together to extend the chain by working with other s:miners (otherwise
they won't be able to claim their bribes). If they do not work together
they will not be able to spend their s:coinbase_tx outputs until they
extend their own sidechain by 288 blocks meaning they need to tie up a
large amount of capital to go rogue on their fork.
Another interesting thing might be to use the OP_WITHDRAWPROOFVERIFY op code
<https://github.com/ElementsProject/elements/blob/elements-0.14.1/src/script/interpreter.cpp#L1420>
used in the elements project. Since the cannonical merkle root hashes are
included in the mainchain, we can provide a merkle proof to the bitcoin
blockchain to initiate a withdrawl from the sidechain. I wrote up a blog
post on how OP_WPV works here
<https://medium.com/@Chris_Stewart_5/what-can-go-wrong-when-transferring-coins-into-a-sidechain-with-op-withdrawproofverify-b2f49b02ab60>.
This allows us to prove that a transaction occurred on the sidechain to
lock up those funds.
-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170905/37b0bcbe/attachment.html>

2023-06-07 20:04:11 CEST

- reply

📅 Original date posted:2017-07-11
📝 Original message:Concept ACK.
I think you are overstating the readiness of drivechains though. I think
the optimistic estimate for drivechains to be ready for bitcoin core is a
year out from today. More likely the date should be early 2018. Still a lot
of work to be done! :-)
Also I don't know if I would put a hard fork suggestion in the scaling map.
If drivechains are successful they should be viewed as the way we scale --
not hard forking the protocol. Do you still have capacity concerns if
drivechains are successful?
-Chris
On Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Summary
> =========
>
> In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
> crucial ways. One success was that it synchronized the entire Bitcoin
> community, helping to bring finality to the (endless) conversations of
> that time, and get everyone back to work. However, I feel that the Dec
> 7, 2015 roadmap is simply too old to serve this function any longer. We
> should revise it: remove what has been accomplished, introduce new
> innovations and approaches, and update deadlines and projections.
>
>
> Why We Should Update the Roadmap
> =================================
>
> In a P2P system like Bitcoin, we lack authoritative info-sources (for
> example, a "textbook" or academic journal), and as a result
> conversations tend to have a problematic lack of progress. They do not
> "accumulate", as everyone must start over. Ironically, the scaling
> conversation _itself_ has a fatal O(n^2) scaling problem.
>
> The roadmap helped solve these problems by being constant in size, and
> subjecting itself to publication, endorsement, criticism, and so forth.
> Despite the (unavoidable) nuance and complexity of each individual
> opinion, it was at least globally known that X participants endorsed Y
> set of claims.
>
> Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
> obsolete and replacing it is long overdue. For example, it highlights
> older items (CSV, compact blocks, versionbits) as being _future_
> improvements, and makes no mention of new high-likelihood improvements
> (Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
> fraud proofs). To read the old roadmap properly, one must already be a
> technical expert. For me, this defeats the entire point of having one in
> the first place.
>
> A new roadmap would be worth your attention, even if you didn't sign it,
> because a refusal to sign would still be informative (and, therefore,
> helpful)!
>
> So, with that in mind, let me present a first draft. Obviously, I am
> strongly open to edits and feedback, because I have no way of knowing
> everyone's opinions. I admit that I am partially campaigning for my
> Drivechain project, and also for this "scalability"/"capacity"
> distinction...that's because I believe in both and think they are
> helpful. But please feel free to suggest edits.
>
> I emphasized concrete numbers, and concrete dates.
>
> And I did NOT necessarily write it from my own point of view, I tried
> earnestly to capture a (useful) community view. So, let me know how I did.
>
> ==== Beginning of New ("July 2017") Roadmap Draft ====
>
> This document updates the previous roadmap [1] of Dec 2015. The older
> statement endorsed a belief that "the community is ready to deliver on
> its shared vision that addresses the needs of the system while upholding
> its values".
>
> That belief has not changed, but the shared vision has certainly grown
> sharper over the last 18 months. Below is a list of technologies which
> either increase Bitcoin's maximum tps rate ("capacity"), or which make
> it easier to process a higher volume of transactions ("scalability").
>
> First, over the past 18 months, the technical community has completed a
> number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables
> Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks
> (BIP 152) allows for much faster block propagation, as does the FIBRE
> Network [3]. Check Sequence Verify (BIP 112) allows trading partners to
> mutually update an active transaction without writing it to the
> blockchain (this helps to enable the Lightning Network).
>
> Second, Segregated Witness (BIP 141), which reorganizes data in blocks
> to handle signatures separately, has been completed and awaits
> activation (multiple BIPS). It is estimated to increase capacity by a
> factor of 2.2. It also improves scalability in many ways. First, SW
> includes a fee-policy which encourages users to minimize their impact on
> the UTXO set. Second, SW achieves linear scaling of sighash operations,
> which prevents the network from crashing when large transactions are
> broadcast. Third, SW provides an efficiency gain for everyone who is not
> verifying signatures, as these no longer need to be downloaded or
> stored. SegWit is an enabling technology for the Lightning Network,
> script versioning (specifically Schnorr signatures), and has a number of
> benefits which
> are unrelated to capacity [4].
>
> Third, the Lightning Network, which allows users to transact without
> broadcasting to the network, is complete [5, 6] and awaits the
> activation of SegWit. For those users who are able to make a single
> on-chain transaction, it is estimated to increase both capacity and
> scalability by a factor of ~1000 (although these capacity increases will
> vary with usage patterns). LN also greatly improves transaction speed
> and transaction privacy.
>
> Fourth, Transaction Compression [7], observes that Bitcoin transaction
> serialization is not optimized for storage or network communication. If
> transactions were optimally compressed (as is possible today), this
> would improve scalability, but not capacity, by roughly 20%, and in some
> cases over 30%.
>
> Fifth, Schnorr Signature Aggregation, which shrinks transactions by
> allowing many transactions to have a single shared signature, has been
> implemented [8] in draft form in libsecp256k1, and will likely be ready
> by Q4 of 2016. One analysis [9] suggests that signature aggregation
> would result in storage and bandwidth savings of at least 25%, which
> would therefore increase scalability and capacity by a factor of 1.33.
> The relative savings are even greater for multisignature transactions.
>
> Sixth, drivechain [10], which allows bitcoins to be temporarily
> offloaded to 'alternative' blockchain networks ("sidechains"), is
> currently under peer review and may be usable by end of 2017. Although
> it has no impact on scalability, it does allow users to opt-in to
> greater capacity, by moving their BTC to a new network (although, they
> will achieve less decentralization as a result). Individual drivechains
> may have different security tradeoffs (for example, a greater reliance
> on UTXO commitments, or MimbleWimble's shrinking block history) which
> may give them individually greater scalability than mainchain Bitcoin.
>
> Finally, the capacity improvements outlined above may not be sufficient.
> If so, it may be necessary to use a hard fork to increase the blocksize
> (and blockweight, sigops, etc) by a moderate amount. Such an increase
> should take advantage of the existing research on hard forks, which is
> substantial [11]. Specifically, there is some consensus that Spoonnet
> [12] is the most attractive option for such a hardfork. There is
> currently no consensus on a hard fork date, but there is a rough
> consensus that one would require at least 6 months to coordinate
> effectively, which would place it in the year 2018 at earliest.
>
> The above are only a small sample of current scaling technologies. And
> even an exhaustive list of scaling technologies, would itself only be a
> small sample of total Bitcoin innovation (which is proceeding at
> breakneck speed).
>
> Signed,
> <Names Here>
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2015-December/011865.html
> [2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
> [3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
> [4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
> [5]
> http://lightning.community/release/software/lnd/
> lightning/2017/05/03/litening/
> [6] https://github.com/ACINQ/eclair
> [7] https://people.xiph.org/~greg/compacted_txn.txt
> [8]
> https://github.com/ElementsProject/secp256k1-zkp/blob/
> d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
> [9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
> [10] http://www.drivechain.info/
> [11] https://bitcoinhardforkresearch.github.io/
> [12]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-February/013542.html
>
> ==== End of Roadmap Draft ====
>
> In short, please let me know:
>
> 1. If you agree that it would be helpful if the roadmap were updated.
> 2. To what extent, if any, you like this draft.
> 3. Edits you would make (specifically, I wonder about Drivechain
> thoughts and Hard Fork thoughts, particularly how to phrase the Hard
> Fork date).
>
> Google Doc (if you're into that kind of thing):
> https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNoc
> mCq-jjBOQSVH-A/edit?usp=sharing
>
> Cheers,
> Paul
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/8b9806dd/attachment-0001.html>

2023-06-07 20:03:44 CEST

- reply

📅 Original date posted:2017-06-30
📝 Original message:>I don't understand this part. In my scheme, a sidechain cannot reorganize
unless the mainchain reorganizes, since the consensus loop only cares about
matching the current block; it ignores splits and does not consider them
valid.
Maybe I am misunderstanding you, but isn't this a flaw not a feature? What
if a attacker pays a large fee to have his *invalid* block hash included in
the bitcoin mainchain? Would this block *have* to be included in the
sidechain's blockchain forever since *it was* included in bitcoin
blockchain?
>Do you not provide a single sidechain's h* twice in the block? Once in
the coinbase and once in the briber's separate transaction?
Yes, my BIP proposal does this.
>In my scheme at least there is no indicator byte -- the "previous block"
hash is the indicator of which sidechain it is extending. From your other
emails on this list, it seems the ratchet is for withdrawals from sidechain
to mainchain? If so, should it not only appear in only some of the
sidechains (the ones which are currently doing some withdrawal?)?
Maybe I am missing something here, but why we do *explicitly* commit to the
previous block hash? Isn't it implicitly committed to via SHA256(SHA256())?
If a drivechain node tries to sync the drivechain from bitcoin's commitment
headers, it will invalidate that block since
the block hash does not correctly reference the previous block hash. AFAICT
there is no need to explicitly specify the previous block hash in the OP_BV
output. In general, I don't think we should assume these commitment headers
dictate the strict ordering of blocks on the sidechain -- only potential
blocks that
*might* be valid. To guarantee full validity drivechain nodes will have to
download the full block and figure out if they follow all of the consensus
rules.
This is sort of like headers first sync in bitcoin core:
https://bitcoin.org/en/developer-guide#headers-first
-Chris
On Thu, Jun 29, 2017 at 11:00 PM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good Morning Paul,
>
> >It seems that, in your version, the "bribers" would react to the scheme
> >in inefficient ways, particularly when the mainchain"s tx-fee-rate (ie
> >fee per Kb) is low.
> >
> >In short, there would be many bribe-attempts (each of which would take
> >up space in mainchain blocks), almost all of which would be unsuccessful.
> >
> >In turn, miners would likely react to this, and try to improve the state
> >of affairs by offering users the privilege of occupying transaction slot
> >#2 (ie, the one right after the coinbase). Users would need to trust
> >miners for this, which introduces a cost friction which is pure
> >deadweight loss. And, it might be easier for larger/older miners to be
> >trustworthy than smaller/newer ones.
>
> I understand.
>
> >Your way is actually very similar to mine. Mine _forces_ the bribe to be
> >in the earliest txn (the coinbase) and to only occur once. Yours doesn"t
> >do anything to refund the briber, if the sidechain (but not the
> >mainchain) reorganizes (as it can easily do, if an older sidechain
> >parent is extended while the mainchain proceeds normally). This creates
> >additional risk.
>
> I don't understand this part. In my scheme, a sidechain cannot reorganize
> unless the mainchain reorganizes, since the consensus loop only cares about
> matching the current block; it ignores splits and does not consider them
> valid.
>
> But I suppose you are considering something like the Ethereum mutability
> feature, which I do not think is something you would want in a sidechain.
>
> >I think mine is also much more space-efficient. Even if ours each had
> >exactly one h* per sidechain per block, it seems that I only require one
> >hash to be communicated (plus an indicator byte, and a ~2 byte counter
> >for the ratchet), whereas you require two. Since its overhead per
> >sidechain per block, it actually might really add up.
>
> Do you not provide a single sidechain's h* twice in the block? Once in
> the coinbase and once in the briber's separate transaction?
>
> In my scheme at least there is no indicator byte -- the "previous block"
> hash is the indicator of which sidechain it is extending. From your other
> emails on this list, it seems the ratchet is for withdrawals from sidechain
> to mainchain? If so, should it not only appear in only some of the
> sidechains (the ones which are currently doing some withdrawal?)?
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170630/fdacfffe/attachment-0001.html>

2023-06-07 20:03:39 CEST

- reply

📅 Original date posted:2017-06-27
📝 Original message:<pre>
BIP: <BIP number>
Layer: Consensus (Soft fork)
Title: OP_BRIBEVERIFY
Author: Chris Stewart <chris at suredbits.com>
Status: Draft
Type: Standards Track
Created: 2017-06-27
</pre>
==Abstract==
This BIP describes a new opcode, OP_BRIBEVERIFY, for the Bitcoin
scripting system that allows for a user to bribe a miner to include a hash
in the coinbase transaction's output.
==Summary==
BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given
critical hash is included at the given vout index in the coinbase
transaction
the script evaluates to true. Otherwise, the script will fail.
This allows sidechains to be merged mined against
bitcoin without burdening bitcoin miners with extra resource requirements.
==Motivation==
The current political climate of bitcoin is extremely contentious. Many
community members
have different visions of what bitcoin is. This op code is meant to
enable [http://www.truthcoin.info/blog/blind-merged-mining/ Blind Merge
Mining].
This enables sidechains in Bitcoin. With OP_BRIBEVERIFY, sidechains miners
can
bribe bitcoin miners to to include their block hash in the bitcoin
blockchain. If their block
is included in the coinbase transaction's vout, it is assumed that block is
a mined block on the sidechain.
This will allow various factions of the community to realize their vision
on their own separate
blockchain that is interoperable with the bitcoin blockchain. This allows
those factions to use
bitcoin as a 'reserve currency' for their own network.
===Commitment Structure===
A new block rule is added which requires that the miner's coinbase reward
be at index 0 in the coinbase transaction's output vector.
It also fixes the witness commitment output to be at index 1 of the
coinbase transaction's output vector.
This is needed so we can reliably tell what vout corresponds to what
drivechain. For instance, the mimblewimble sidechain
could correspond to index 2 of the vector outputs on the coinbase
transaction.
The commitment is recorded in a <code>scriptPubKey</code> of the coinbase
transaction. It must be at least 34 bytes in size
1-byte - OP_RETURN (0x6a)
1-byte - Push the following 32 bytes (0x20)
32-byte - block hash
the 35th byte and onward have no consensus meaning.
===OP_BRIBEVERIFY op code===
This op code reads two arguments from the stack. The stack top is expected
to be a sidechain id for which this user attempting to blind merge mine for.
The next element on the stack is expected to be a block hash. This op code
looks into the coinbase transaction's output vector at the given index
(which is derived from the sidechain id) and checks
to see if the hash in the block matches the hash inside of the BRIBEVERIFY
program. If the hashes match, the OP_BRIBEVERIFY acts as an OP_NOP. If the
comparison between the two hashes fail, the script fails.
===BRIBEVERIFY program===
A standard BRIBEVERIFY program has the format:
1-byte - Push the following 32 bytes (0x20)
32-byte - block hash
1 byte - Push operation? (needed if number can't be encoded as OP_0 -
OP_16)
1 byte - sidechain id
1 byte - OP_BRIBEVERIFY op code
==Detailed Specification==
Refer to the reference implementation, reproduced below, for the precise
semantics and detailed rationale for those semantics.
case OP_NOP4:
{
//format: block_hash sidechain_id OP_BRIBEVERIFY
if (!(flags & SCRIPT_VERIFY_BRIBEVERIFY)) {
// not enabled; treat as a NOP4
if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
}
break;
}
if (stack.size() < 2)
return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
const CScriptNum scriptNumSidechainId(stacktop(-1),fRequireMinimal);
uint8_t nSidechainId;
if (!checker.CheckSidechainId(scriptNumSidechainId,nSidechainId)) {
return set_error(serror, SCRIPT_ERR_UNKNOWN_SIDECHAIN);
}
// Check block hash
bool fHashCritical =
checker.CheckCriticalHash(stacktop(-2),nSidechainId);
if (!fHashCritical) {
return set_error(serror, SCRIPT_ERR_UNSATISFIED_BRIBE);
}
break;
}
https://github.com/Christewart/bitcoin/blob/94b6f33f2278c42d4d8758a3c8ffe2078e4ec933/src/script/interpreter.cpp#L427
https://github.com/drivechain-project/bitcoin/pull/13
==Deployment==
TODO
==Credits==
Credit to Paul Sztorc for the original idea of Blind Merge Mined sidechains.
Credit to CryptAxe for writing the foundational layer of software for
drivechains so I could implement OP_BRIBEVERIFY.
==References==
Blind Merge Mined Sidechains -
http://www.truthcoin.info/blog/blind-merged-mining/
Mailing list discussion -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014408.html
==Copyright==
This document is placed in the public domain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170627/bd5730bf/attachment.html>

2023-06-07 20:00:03 CEST

- reply

📅 Original date posted:2017-04-14
📝 Original message:>Criticizing 148 without suggesting a specific alternative leaves the
community in disarray.
I really disagree with this sentiment, you don't need to provide
alternatives to criticize a technical proposal. I don't like this "active
segwit at all costs" theme that has been going around the community. I am a
fan of segwit, but we shouldn't push things through in an unsafe manner.
>If 148 causes orphaning and a fork, I don't think such really matters in
the long term. The non-SegWit miners will probably just quickly give up
their orphans once they realize that money users like being able to have
non-mutable TX IDs. If they do create a long lasting branch... well that
is good too, I'd be happy to no longer have them in our community. Good
luck to them in creating a competitive money, so that we can all enjoy
lower transaction fees.
This seems like a lot of reckless hand waving to me.
Food for thought, why are we rejecting *all* blocks that do not signal
segwit? Can't we just reject blocks that *do not* signal segwit, but *do*
contain segwit transactions? It seems silly to me that if a miner mines a
block with all pre segwit txs to reject that block. Am I missing something
here?
-Chris
On Fri, Apr 14, 2017 at 11:50 AM, praxeology_guy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Gregory Maxwell,
>
> Criticizing 148 without suggesting a specific alternative leaves the
> community in disarray.
>
> I know you are emphasizing patience. But at the same time, with your
> patience we are allowing ourselves to get dicked for longer than necessary.
>
> I think that core could easily develop code that could create a
> solid/reliable date/height based activation to allow miners to create
> SegWit block candidates and having nodes fully verify them. Shaolinfry is
> the only person Ive seen actually make such a proposal:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-April/014049.html. His makes it so that SegWit default gets
> activated at the end of the BIP9 signalling timeframe instead of default
> leaving it non-activated.
>
> I agree that 148 is is not ideal. Non-SegWit signaling blocks are not a
> Denial of Service, given that other activation methods are available.
> Someone just needs to code something up that is better that we can all use
> in a satisfying time frame. So far 148 is the most practical and reliable
> method I'm aware of.
>
> If 148 causes orphaning and a fork, I don't think such really matters in
> the long term. The non-SegWit miners will probably just quickly give up
> their orphans once they realize that money users like being able to have
> non-mutable TX IDs. If they do create a long lasting branch... well that
> is good too, I'd be happy to no longer have them in our community. Good
> luck to them in creating a competitive money, so that we can all enjoy
> lower transaction fees.
>
> SegWit has already undergone enough testing. It is time to activate it.
>
> Cheers,
> Praxeology Guy
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170414/065e4fee/attachment.html>