elimination or control acquisition; and not necessary by a national-state
government.
Chris
--- Forwarded Message ---
Von: Russell O'Connor
Datum: Am Montag, 21. August 2023 um 16:47
Betreff: Re: [bitcoin-dev] Concern about "Inscriptions"
An: martl.ch...@proton.me , Bitcoin Protocol
It is already more than a half year since the probably mayor Bitcoin script
exploit started.
These exploits are nothing new in the Bitcoin history and mostly are due to the
loose flexibility of the system in regards of processing predicatives (Bitcoin
script). The very first mayor bug; if you
>In traditional finance, front-running is defined as "entering into an
equity trade, options or future contracts with advance knowledge of a block
transaction that will influence the price of the underlying security to
capitlize on the trade" [0]. In Bitcoin/Civkit parlance, a front-running
could
Hello list,
Fidelity bonds could be used to help create trust-minimized federations
that are needed for things like chaumian ecash servers or sidechains.
From what I've seen until now, people working on chaumian ecash or
sidechains say that the federation controlling the multisig keys will
antly have to spend money on miner fees to create new UTXOs. Here's
a writeup with links to other blog posts about the whole thing:
https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b
As well as podle as mitigation, the multiple mixdepths in the joinmarket
wallet also helps a l
that specifying the exact form of the fidelity bond
certificate is a bad idea. I'll leave it more general, saying just that
wallets should be able to do SignMessage using the timelocked privkey.
And I'll leave the example signature in the test vectors.
I've made edits to this effec
for privacy, and it wouldn't be too bad. Right now there's no
cold storage solution for fidelity bonds yet JoinMarket has about 600
bitcoins locked up and advertised, which must be all on hot wallets.
Best,
CB
On 03/05/2022 06:26, ZmnSCPxj wrote:
Good morning Chris,
Hello ZmnSCPxj,
Renting out
, ZmnSCPxj wrote:
Good morning again Chris,
I wonder if there would be an incentive to *rent* out a fidelity bond, i.e. I
am interested in application A, you are interested in application B, and you
rent my fidelity bond for application B.
We can use a pay-for-signature protocol now that Taproot
application, but
JoinMarket takers are already coded to check for this, and Teleport
takers will soon as well. Using the same bond across different
applications is fine.
Best,
CB
On 01/05/2022 10:43, ZmnSCPxj wrote:
Good morning Chris,
Excellent BIP!
From a quick read-over, it seems to me
See
https://gist.github.com/chris-belcher/7257763cedcc014de2cd4239857cd36e
for the latest version of this BIP.
BIP: TBD. Preferably a two-digit number to match the bip44, bip49,
bip84, bip86 family of bips
Layer: Applications
Title: Derivation scheme for storing timelocked address
k anyone would say
that even if those 1 million people, for example, thought that we should
increase the number of bitcoins via perpetual inflation it would be a good
idea to listen to it however the vote was done whether via transaction
flags or something else. Of course they could fork off.
Chee
notes for the
1.9.1 release.
- https://github.com/discreetlogcontracts/dlcspecs
- bitcoin-s.org
- https://github.com/bitcoin-s/bitcoin-s/releases/tag/1.9.1
-Chris
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati
wrote:
> Good morning Chris,
>
> > >On the other hand, the above, where the oracle determines *when* the
> fund can be spent, can also be implemented by a simple 2-of-3, and called
> an "escrow".
> >
> > I think something that is underappreciated by prot
think this solves lightning's problems, but it is a
worthy goal to reduce interactiveness requirements with new bitcoin
applications to give better UX.
-Chris
On Sat, Mar 5, 2022 at 4:57 PM ZmnSCPxj wrote:
> Good morning Chris,
>
> > I think this proposal describes arbitrary lines of pre-app
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 wrote:
>
> Good morning Chris,
>
> Quick question.
>
> How does this improve over
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
Imagine a future where a user Alice has bitcoins and wants to send them
with maximal privacy, so she creates a special kind of transaction. For
anyone looking at the blockchain her transaction appears completely
normal with her coins seemingly going from address A to address B. But
in reality
s://github.com/bitcoin-s/bitcoin-s/releases/tag/1.8.0
You can find a demonstration video for using the wallet to enter into a DLC
over tor here:
https://www.youtube.com/watch?v=oR0I0aHxNMM
You can find the dlc spec here:
https://github.com/discreetlogco
.
As before find the latest version of this BIP here:
https://gist.github.com/chris-belcher/903feab321bf41055c91eaec46581e89
def apply_anti_fee_sniping_fields(transaction):
# bip68 requires v=2
transaction.version = 2
# always set nlocktime if any of the transaction inputs have more
Good thinking. Your point also applies to CoinJoins (both equal-output
and payjoin), and to any transaction where multiple parties contribute
inputs.
The BIP should say "at least one of the inputs of the transaction" with
a suggestion that on-chain wallets just randomly pick an input.
On
See
https://gist.github.com/chris-belcher/903feab321bf41055c91eaec46581e89
for the latest version of this BIP.
BIP: TBD
Layer: Applications
Title: Anti-fee-sniping protection with nSequence in taproot
transactions to improve privacy for off-chain protocols
Author: Chris Belcher
Hi Chris,
I apologise if I did not make it clear enough, but the 24 seed words used
to make the quantum passphrase are separate, newly generated 24 seed words,
and not the same as those for the main wallet.
With both layers (seed words + quantum passphrase) the security provided is
(2048^23
Hi Chris,
Thank you for your thoughts.
Unfortunately, your analysis is incorrect.
This is a non-destructive adaptation of the BIP39 standard, and is
certainly not "rolling your own security".
The 'quantum' passphrase is relying on the well established security of the
existing BIP3
this clarifies everything.
Regards,
Chris
On Sun, 9 May 2021, 23:54 Tobias Kaupat, wrote:
> Hi Chris,
> thanks for the clarification. It makes sense so far.
>
> About the "chicken - egg" problem:
> When you generate a BIP39 mnemonic "A" without password, you get
itcoin wallet is protected by a 'quantum' passphrase,
containing the seed words of the 2nd Bitcoin wallet; inversely, the 2nd
Bitcoin wallet is protected by a 'quantum' passphrase, containing the seed
words of the 1st Bitcoin wallet.
Thank you for your thoughts.
Regards,
Chris
On Sun, 9 May 202
string of all 24
seed words, set out using the above rules.
I welcome a productive technical discussion.
Thanks,
Chris Johnston
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
rs, miner protection is nothing something to
count on.
On 03/03/2021 17:30, yanma...@cock.li wrote:
> On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:
>> Enter flag day activation. With a flag day there can be no
>> brinksmanship. A social media blitz cant do anything except
The bitcoin world is close to total gridlock on the question of how to
activate taproot. There's no agreement on activation[1][2], and if an
agreement isn't reached then nothing happens. That would be really
terrible because we'd miss out on the benefits of taproot and
potentially other future
It is wrong to say that using miner signalling alone for activation
(LOT=false) is a bug.
As we vividly saw in the events of the 2017 UASF, the purpose of miner
signalling isn't to activate or enforce the new rules but to stop a
chain split. A majority of miners can stop a chain split by
The idea of a fully-transparent bitcoin is dead and has been for many
years. This is because of various privacy tech such as CoinJoin,
Lightning Network, PayJoin, change avoidance, avoiding address reuse,
etc, along with a few new ones like CoinSwap and WabiSabi hopefully
coming soon.
On
because it breaks the transaction graph, and even
improves the privacy of people who don't use it. CoinSwap also uses less
block space for the same privacy and therefore is cheaper in miner fees.
Links:
* Design document:
https://gist.github.com/chris-belcher/9144bd57a91c194e332fb5ca371d0964
PayJoin is an exciting bitcoin privacy technology which has the
potential to damage the ability of blockchain surveillance to spy on
bitcoin users and destroy bitcoin's fungibility. A protocol standard has
already been defined and implemented by a couple of projects such as
BTCPayServer, Wasabi
Hello list,
This email is an appendium or modification of the earlier CoinSwap
protocol published on this list. It is intended to fix the problems
found in review. (Original email quoted here too)
On 11/08/2020 13:05, Chris Belcher via bitcoin-dev wrote:
> I'm currently working on implement
/getting-started
-Chris
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Hello ZmnSCPxj,
On 03/09/2020 10:45, ZmnSCPxj wrote:
> Good morning Chris,
>
>> A big downside is that it really ruins the property of allowing coins to
>> remain unspent indefinitely. That has privacy implications: if a coin
>> remains unspent for longer than 2 weeks (o
Hello ZmnSCPxj,
On 25/08/2020 04:16, ZmnSCPxj wrote:
>
> Good morning Antoine,
>
>
>> Note, I think this is independent of picking up either relative or absolute
>> timelocks as what matters is the block delta between two links.
>
> I believe it is quite dependent on relative locktimes.
>
aim is to only fix the second
attack.
These are all the possible fixes I can think of.
Regards
Chris
On 24/08/2020 20:30, Antoine Riard wrote:
> Hello Chris,
>
> I think you might have vulnerability issues with the current design.
>
> With regards to the fee model for contra
Hello,
On 21/08/2020 05:20, ZmnSCPxj wrote:
> Good morning,
>
>
>
>> Right, so if the taker uses only a single maker then they must have more
>> than one UTXO.
>
> Spending one UTXO is fine, it is generating a transaction that has one output
> that is problematic.
>
> What needs to happen
Hello Nadav and ZmnSCPxj,
On 20/08/2020 22:38, ZmnSCPxj wrote:
> Good morning Nadav,
>
>> Hey Chris and all,
>>
>> Looking good :) I have one major concern though
>>
>>> q = EC privkey generated by maker
>>> Q = q.G = EC pubkey published b
Hello ZmnSCPxj,
Thanks for the review. My comments are inline.
On 20/08/2020 12:17, ZmnSCPxj wrote:
> Good morning Chris,
>
> Great to see this!
>
> Mostly minor comments.
>
>
>
>>
>> == Direct connections to Alice ===
>>
>> Only Alice, th
On 13/06/2020 15:06, ZmnSCPxj wrote:
> Good morning Chris,
>
>>
>> Would it be fair to summarize the idea in this way:
>>
>> CoinSwappers can slow down the CoinSwap process which will give an
>> opportunity for makers to use batching.
>
> I think so.
&g
Hello ZmnSCPxj,
On 11/06/2020 12:51, ZmnSCPxj wrote:
> Good morning Chris, and bitcoin-dev (but mostly Chris),
>
>
> I made a random comment regarding taint on bitcoin-dev recently:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017961.html
>
>>
useful for other reasons than
resisting taint analysis:
* It improves the privacy of people who do not use it.
* It helps stops censorship of privacy protocols (I.E. miners could one
day refuse to mine equal-output CoinJoin transactions but still mine
regular transactions)
* It typically uses less block space, because information is removed
from the blockchain rather than adding to the blockchain.
Regards
Chris Belcher
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On 10/06/2020 05:01, Mr. Lee Chiffre via bitcoin-dev wrote:
> I am trying to learn about payjoin. I have a couple concerns on its
> effectiveness. Are my concerns valid or am I missing something?
>
> concern 1
> If it is known to be a payjoin transaction anyone could determine the
> sender the
Hello ZmnSCPxj,
On 10/06/2020 11:58, ZmnSCPxj wrote:
> Good morning Chris,
>
>>> Let me propose an alternative: swap-on-receive+swap-on-change.
>>
>> That's an interesting point, thanks for the thought. This scheme might
>> not be appropriate for every threat m
nnis
>> (7 BTC) (4 BTC) (4 BTC)
>>| | |
>>| | |
>>v v v
>> Alice
>>
>
>
>
>
>
>
> Great work Chris and you have my respects for your contributions to
> Bi
Good morning ZmnSCPxj,
On 06/06/2020 02:40, ZmnSCPxj wrote:
> Good morning Chris,
>
>> I think I'm having trouble understanding this, does it work like this:
>>
>> Say we're in the 2-party coinswap case (Alice and Bob)
>>
>> We have Alice's funding transacti
transaction
verification is an important part of the blockchain bank. Not to say this
isn't a useful, interesting, informative, and educational discussion, but
it seems unlikely to happen. Likewise, it could lead to something related
that would be likely to occur, so full discussions like this ar
Good day ZmnSCPxj,
>>> But S6 has the mild advantage that all the funding transactions paying to
>>> 2-of-2s can appear on the same block, whereas chaining swaps will have a
>>> particular order of when the transactions appear onchain, which might be
>>> used to derive the order of swaps.
>>
Hello ZmnSCPxj,
On 31/05/2020 03:30, ZmnSCPxj via bitcoin-dev wrote:
> Good morning Ruben and Chris,
> I am not in fact convinced that PayJoin-with-CoinSwap adds *that* much
> privacy.
>
> These transactions:
>
> +---+ +---+
> Alice ---| |--
diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/scriptless-ecdsa/
- [3] https://en.bitcoin.it/wiki/Privacy#Change_address_detection
- [4] "Design for improving JoinMarket's resistance to sybil attacks
using fidelity bonds"
https://gist.github.com/chris-belcher/18e
Hello list,
This proposal is very cool. It is very useful to have a coinswap scheme
requiring only two transactions.
As well as improving the scalability of the system by saving block
space, it also improves privacy because the coins could stay unspend for
a long time, potentially indefinitely.
On 05/05/2020 16:16, Lloyd Fournier via bitcoin-dev wrote:
> On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
>>> Trust-minimization of Bitcoin security model has
Hello ZmnSCPxj,
>>> This "as long as the inputs that should be separate are not co-spent" is
>>> precisely what mixdepths protect against, which is why I think some kind of
>>> mixdepth facility will still matter in CoinSwap.
>>> Still, you have convinced me that, for the purpose of
Hello ZmnSCPxj,
On 30/04/2020 09:54, ZmnSCPxj wrote:
> Good morning CB,
>
>
>> Equal-output-coinjoins and JoinMarket also have a version of the
>> common-input-ownership-heuristic (CIOH), because its often possible to
>> separate the inputs into sets of their owners of a equal-output-coinjoin
On 24/04/2020 02:34, ZmnSCPxj via bitcoin-dev wrote:
> Good morning Germán,
>
>
>> With regards to trying to tackle the problem of value-based correlations,
>> wouldn't it be possible to try to model the solution after the
>> equal-sum-subset problem (np complete problem)(
>>
https://adiabat.github.io/dlc.pdf
[2] - https://cryptogarage.co.jp/p2pd/
[3] -
https://suredbits.com/discreet-log-contracts-part-1-what-is-a-discreet-log-contract/
[4] -
https://blockstream.com/2019/04/19/en-transacting-bitcoin-based-p2p-derivatives/
[5] - https://dci.mit.edu/smart-contracts
I've recently been playing around with descriptors, and they are very
nice to work with. They should become the standard for master public
keys IMO.
One downside is that users cant easily copypaste them to-and-fro to make
watch-only wallet. The descriptors contain parenthesis and commas which
This is an excellent idea and I hope something like this happens.
I've had the idea of using an intermediate name to make the transition
easier, for example "Bitcoin address" becomes "Bitcoin invoice address"
which after 10 years becomes "Bitcoin invoice" (or "Bitcoin invoice").
"Invoice" would
the business has decided to use this
feature, and in my OP I talk about the engineering decisions that will have
to be made support this. I'm hoping the "lazy wallet designers" -- or
perhaps people that don't follow bitcoin protocol development as rabidly as
us :-) -- can see that nuance.
-Chris
I do have some concerns about SIGHASH_NOINPUT, mainly that it does
introduce another footgun into the bitcoin protocol with address reuse.
It's common practice for bitcoin businesses to re-use addresses. Many
exchanges [1] reuse addresses for cold storage with very large sums of
money that is
Hello list,
Two points:
* The V^2 term is the only thing in the whole scheme that provides any
sybil protection. I've already gone through the reasoning in an earlier
email and the maths is clear; in a scheme with linear V honest makers
have no economic advantage over sybil attackers. This is
n-dev/2019-August/017217.html
>
> В Wed, 7 Aug 2019 01:55:41 +0500
> Dmitry Petukhov wrote:
>
>> В Mon, 5 Aug 2019 20:04:26 +0100
>> Chris Belcher wrote:
>>
>>> So what's needed is a way to make renting out TXOs impossible or
>>> very difficult.
On 07/08/2019 00:33, ZmnSCPxj wrote:
> Good morning all,
>
> It might be useful to remember that there exists pressure to pool
> proof-of-work due to tiny non-linearities caused by Proximity Premium and
> Variance Discount flaws.
> Similarly, any non-linearity in any fidelity bond scheme exerts
On 06/08/2019 02:51, Leo Wandersleb via bitcoin-dev wrote:
> On 8/6/19 7:04 AM, Chris Belcher via bitcoin-dev wrote:
>> However, there _is_ a cost to being a sybil attacker. If we define
>> honest makers as entities who run just one maker bot, and dishonest
>> makers as enti
On 02/08/2019 10:50, Dmitry Petukhov wrote:
> В Fri, 2 Aug 2019 10:21:57 +0100
> Chris Belcher wrote:
>
>> The aim of the fidelity bond scheme is to require makers
>> to sacrifice value, renting out their fidelity bond coins doesn't
>> avoid that sacrifice because the
On 31/07/2019 16:50, Dmitry Petukhov wrote:
> В Tue, 30 Jul 2019 22:39:14 +0100
> Chris Belcher via bitcoin-dev
> wrote:
>
>> This is where a sacrifice of V bitcoins creates a
>> bond of value V^2. The formula provides a strong incentive for
>> profit-motivated ma
iple makers for the purpose of
deanomyization then they will take a substantial quadratic hit in their
effectiveness. This is explored the other document "Financial
mathematics of JoinMarket fidelity bonds"
https://gist.github.com/chris-belcher/87ebbcbb
On 27/07/2019 20:34, David A. Harding wrote:
>
> Timelocking bitcoins, especially for long periods, carries some special
> risks in Bitcoin:
>
> 1. Inability to sell fork coins, also creating an inability to influence
> the price signals that help determine the outcome of chainsplits.
>
> 2.
On 7/23/19 10:47 AM, Andreas Schildbach via bitcoin-dev wrote:
3) Afaik, it enforces/encourages address re-use. This stems from the
fact that the server decides on the filter and in particular on the
false positive rate. On wallets with many addresses, a hardcoded filter
will be too blurry and
with just SPV-security.
## Links / References
[1] https://github.com/JoinMarket-Org/joinmarket-clientserver
[2] https://github.com/JoinMarket-Org/joinmarket/issues/693
[3] https://en.bitcoin.it/wiki/Fidelity_bonds
[4] https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b
Hello list,
For the last few weeks I've been working on a literature review for
bitcoin privacy:
https://en.bitcoin.it/wiki/Privacy
It aims to cover about all privacy issues in bitcoin, including
Lightning network, and has a bunch of examples to help demonstrate how
the concepts work in
Thanks for bringing our attention to this important topic.
According to (https://p2sh.info/dashboard/db/bip-69-stats) around 60% of
transaction follow bip69 (possibly just by chance).
If its useful, a bitcoin wiki page that tracks wallets which use bip69
can be created. A similar page exists for
Really like that you're moving forward with this. A few months ago I was
working on something similar as it seemed like nobody else was interested.
In regards to the specific proposal, would it make sense to offer a tx
subscription endpoint in addition to TRANSACTION_DATA_REQUEST? Such an
Do you have any thoughts on expanding this to SIGHASH_NONE? Perhaps someone
else on the dev list can enlighten me, but is there a current use case for
SIGHASH_NONE that would suffer from it being non standard?
-Chris
On Thu, May 31, 2018 at 1:53 PM, Johnson Lau via bitcoin-dev <
bitcoin-
Thanks for the summary,
It may be worth emphasizing the fungibility aspects of all this.
That summary contains ideas to possibly have separate address types,
opcodes and scriptSigs/witnesses for different feature, at least to
start with. To me this would seem bad because it may miss out on the
ow in beta release:
https://github.com/chris-belcher/electrum-personal-server
It now has all the essential features to make it practical for use;
Merkle proofs, deterministic wallets, bech32 addresses, SSL, Core's
multi-wallet support. Along with the features that were in the alpha
release of tr
This sounds like a useful idea for improving the privacy of coinswap.
Traditionally coinswap mixing had an anonymity set related to the number
of multisig transactions being used on the blockchain. With the new tech
of Schnorr, MAST and now this Taproot, with sufficient adoption
coinswap's
Regarding "problem" #2 where you say "How do we ensure that all valid
transactions are eventually included in the blockchain?": I do not believe
that all people would (a) agree this is a problem or (b) that we do want to
*ENSURE* that *ALL* valid transactions are eventually included in the
Hi,
1. If there are 16.4 million mined and 4 million are lost, that results in
12.4 million in circulation vs 14.4 million.
2. Satoshi addressed this as have numerous other people (
https://bitcointalk.org/index.php?topic=198.msg1647#msg1647 ) - lost coins
decrease supply, increasing value of the
hdrawal transactions (WT). This obviously isn't ideal because
a withdrawal will never occur from the drivechain if enough miners employ
this strategy -- which seems to be the most profitable strategy.
-Chris
On Mon, Dec 4, 2017 at 1:36 PM, Chris Pacia via bitcoin-dev <
bitcoin-dev@lists.linuxfound
ly short
> validity periods, to reduce the risks of losses after a hack. Also, using
> at
> least hour-level ensures we don't have any year 2038 problems.
>
> Thoughts?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> ___
> bitcoin-dev mailing lis
n transaction fees.
-Chris
On Fri, Sep 22, 2017 at 8:49 PM, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Good morning bitcoin-dev,
>
> I have yet another sidechain proposal: https://zmnscpxj.github.io/
> sidechain/mainstake/index.html
>
> I mak
en in reality it is two unique sidechains
competing to mine the the limited coinbase output vector space.
-Chris
On Fri, Sep 8, 2017 at 9:56 AM, ZmnSCPxj <zmnsc...@protonmail.com> wrote:
> Good morning,
>
> Chris mentioned the use of OP_WITHDRAWPROOFVERIFY. I've come to re
ow 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
__
Pooled mining in bitcoin contributes to miner centralization. P2Pool is
one solution but has bad scalability; additional hashers require the
coinbase transaction to be larger, bigger miners joining increase the
variance of payouts for everyone else, and smaller miners must pay extra
to consolidate
hat their
>> coins requires moving every once in a long while you ensure they won't do
>> stupid things or come back 50 years from now and complain their addresses
>> have been scavenged.
>>
>> --
>> Thomas
>>
>>
>> On 22/08/17 10:29 AM, Er
This seems to be drifting off into alt-coin discussion. The idea that we
can change the rules and steal coins at a later date because they are
"stale" or someone is "hoarding" is antithetical to one of the points of
bitcoin in that you can no longer control your own money ("be your own
bank")
majority bribes it may make the op code worth it.
In general though, I'm still unclear of what purpose the 'Ratchet' serves.
Can you either link to documentation about it or write something up quick?
-Chris
On Wed, Jul 12, 2017 at 7:00 PM, Paul Sztorc <truthc...@gmail.com> wrote:
> I st
n is already insecure then -- it allows anyone can
spend outputs that can be claimed by miners.
>Sure, happy to, as soon as I have it written up in detail.
I look forward to this!
-Chris
On Wed, Jul 12, 2017 at 2:24 PM, Tao Effect <cont...@taoeffect.com> wrote:
> Dear Chris,
>
> I
to me. Other designs (that I'm aware of) for sidechains had
attack vectors that weren't so obvious.
-Chris
On Tue, Jul 11, 2017 at 6:12 PM, Tao Effect via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Paul,
>
> There is a difference between replying to an email,
' so we could easily see where all of
the voting is happening for withdrawal transactions -- but that is very
much up in the air.
On Wed, Jul 12, 2017 at 1:00 PM, Chris Stewart <stewart.chris1...@gmail.com>
wrote:
> Hi Russell/ZmnSCPxj,
>
> I think you guys are right. The only pr
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-
stall* mining progress on the drivechain, but I think the same argument
can be made with a rich miner on the bitcoin blockchain as well. I think
miners have threatened to do that if BIP148 caused a chain split.
Can you link to the aforementioned pseudocode? I must have missed it on the
mailing list.
ll 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 <zmnsc...@protonmail.com> wrote:
> Good Morning Paul,
>
> >It seems that, in your version, th
new soft forks. For
instance, we would say
the mining reward must *not* be index 0 of the coinbase transaction, but
can occupy index 1 - 256. The same would apply for witness commitments.
-Chris
On Wed, Jun 28, 2017 at 5:49 PM, Russell O'Connor <rocon...@blockstream.io>
wrote:
> I h
s more, maybe some one else can come up with
something clever that exploits that fact.
On Mon, Jun 19, 2017 at 10:24 AM, Chris Stewart <stewart.chris1...@gmail.com
> wrote:
> Since the sidechain has the sidechain BMM headers that they want the LD
>> (bribe) data for, I think that th
oesn't have a
benefit over using OP_RETURNs though?
The structure could be something like:
and then in a subsequent block the miner spends that output to themselves.
I will admit I'm not super familiar with how OP_RETURNs work with the UTXO
set -- maybe this scheme doesn't have any benefit.
On 06/01/2017 06:10 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:
> One aspect which isn't in this BIP draft is direct support for unconfirmed
> transactions. I consider such a feature an important UX feature for mobile
> phones, and something which I've personally seen as an important
>
Yes I've had it working using two pushes in op_return.
op_return op_pushdata op_pushdata
Flag goes in your filter. You anonymity set is all other transactions using
that same flag.
This is fairly decent privacy but the problem is you still need filter
matches on outgoing transactions to build
1 - 100 of 157 matches
Mail list logo
