<unnamed>

Public Key

npub1lf5jdpupmcelz945y09tzawew6pqs5wkkp6dppeujgxxnqltgufsmzuul6

Profile Code

nprofile1qqs056fxs7qauvl3z66z8j43whvhdqsg28ttqaxssu7fyrrfs045wycpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds9ccvsn

Publishing to

nostr.wine

nos.lol

relay.damus.io

Last Notes

2023-06-07 17:58:17 UTC

- reply

📅 Original date posted:2017-03-29
📝 Original message:I believe that as we continue to add users to the system by scaling
capacity that we will see more new nodes appear, but I'm at a bit of a loss
as to how to empirically prove it.
I do see your point on increasing load on archival nodes, but the majority
of that load is going to come from new nodes coming online, they're the
only ones going after very old blocks. I could see that as a potential
attack vector, overwhelm the archival nodes by spinning up new nodes
constantly, therefore making it difficult for a "real" new node to get up
to speed in a reasonable amount of time.
Perhaps the answer there would be a way to pay an archival node a small
amount of bitcoin in order to retrieve blocks older than a certain cutoff?
Include an IP address for the node asking for the data as metadata in the
transaction... Archival nodes could set and publish their own policy, let
the market decide what those older blocks are worth. Would also help to
incentivize running archival node, which we do need. Of course, this isn't
very user friendly.
We can take this to bitcoin-discuss, if we're getting too far off topic.
On Wed, Mar 29, 2017 at 11:25 AM David Vorick <david.vorick at gmail.com>
wrote:
>
> On Mar 29, 2017 12:20 PM, "Andrew Johnson" <andrew.johnson83 at gmail.com>
> wrote:
>
> What's stopping these users from running a pruned node? Not every node
> needs to store a complete copy of the blockchain.
>
>
> Pruned nodes are not the default configuration, if it was the default
> configuration then I think you would see far more users running a pruned
> node.
>
> But that would also substantially increase the burden on archive nodes.
>
>
> Further discussion about disk space requirements should be taken to
> another thread.
>
>
> --
Andrew Johnson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/9b48ebe3/attachment-0001.html>

2023-06-07 17:58:14 UTC

- reply

📅 Original date posted:2017-03-29
📝 Original message:What's stopping these users from running a pruned node? Not every node
needs to store a complete copy of the blockchain.
On Wed, Mar 29, 2017 at 11:18 AM David Vorick via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Perhaps you are fortunate to have a home computer that has more than a
> single 512GB SSD. Lots of consumer hardware has that little storage. Throw
> on top of it standard consumer usage, and you're often left with less than
> 200 GB of free space. Bitcoin consumes more than half of that, which feels
> very expensive, especially if it motivates you to buy another drive.
>
> I have talked to several people who cite this as the primary reason that
> they are reluctant to join the full node club.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Andrew Johnson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/a4c50e5f/attachment.html>

2023-06-07 17:57:24 UTC

- reply

📅 Original date posted:2017-03-20
📝 Original message:On Mon, Mar 20, 2017 at 10:47 AM John Hardy <john at seebitcoin.com> wrote:
> By doing this you're significantly changing the economic incentives
behind bitcoin mining. How can you reliably invest in hardware if you have
no idea when or if your profitability is going to be cut by 50-75% based on
a whim?
Of course, that's why this is a last resort, successfully activated only in
response to a contentious hard fork. If it succeeds just once it should
help prevent the same situation occurring in the future.
This seems a lot more disruptive to the network than a simple hard fork to
increase the block size. Compromise is the answer here, not taking our
ball and going home, in my humble opinion.
> You may also inadvertently create an entirely new attack vector if 50-75%
of the SHA256 hardware is taken offline and purchased by an entity who
intends to do harm to the network.
How so? If you have four proof of work methods, that 50-75% of SHA256
hashpower would equate to 13-18% of total hashpower. If you can harm the
network with this much hashpower bitcoin was DOA.
I'm assuming the difficulty on the SHA256 PoW would drop by 50-75% as
well. So not nearly as bad as it would be with a single PoW and that much
hardware were available to an adversary, you're correct.
How would you handle starting difficulty on the other 3 PoWs? Seems like
it would be a race to start with, which strikes me as another potential
attack vector until the amount of hardware and price of production balances
with the price of the coin(which is likely to be volatile during this
turbulent period). Unless you start the difficulty at a higher value, then
you're just doing centralized economic planning and hoping you got the
numbers right so that you get the right balance of security vs incentive to
do malicious things like double spends.
All the solutions that people keep positing(such as Luke's complete PoW
change) seem like they'd be a whole lot more disruptive to the network than
an EC fork would be.
Isn't the main reason that everyone is up in arms because a contentious
hard fork is dangerous? I just don't understand how any of these solutions
are safer.
At that point we've lost our claim to fame, that changes to the protocol
are hard and you can trust that your value is safe. What you're advocating
seems like it would result in a huge drop in hashing security.
------------------------------
*From:* Andrew Johnson <andrew.johnson83 at gmail.com>
*Sent:* Monday, March 20, 2017 3:38:01 PM
*To:* Bitcoin Protocol Discussion; John Hardy
*Subject:* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR
POWA): Protecting Bitcoin from malicious miners
By doing this you're significantly changing the economic incentives behind
bitcoin mining. How can you reliably invest in hardware if you have no idea
when or if your profitability is going to be cut by 50-75% based on a whim?
You may also inadvertently create an entirely new attack vector if 50-75%
of the SHA256 hardware is taken offline and purchased by an entity who
intends to do harm to the network.
Bitcoin only works if most miners are honest, this has been known since the
beginning.
On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
I’m very worried about the state of miner centralisation in Bitcoin.
I always felt the centralising effects of ASIC manufacturing would resolve
themselves once the first mover advantage had been exhausted and the
industry had the opportunity to mature.
I had always assumed initial centralisation would be harmless since miners
have no incentive to harm the network. This does not consider the risk of a
single entity with sufficient power and either poor, malicious or coerced
decision making. I now believe that such centralisation poses a huge risk
to the security of Bitcoin and preemptive action needs to be taken to
protect the network from malicious actions by any party able to exert
influence over a substantial portion of SHA256 hardware.
Inspired by UASF, I believe we should implement a Malicious miner Reactive
Proof of Work Additions (MR POWA).
This would be a hard fork activated in response to a malicious attempt by a
hashpower majority to introduce a contentious hard fork.
The activation would occur once a fork was detected violating protocol
(likely oversize blocks) with a majority of hashpower. The threshold and
duration for activation would need to be carefully considered.
I don’t think we should eliminate SHA256 as a hashing method and change POW
entirely. That would be throwing the baby out with the bathwater and hurt
the non-malicious miners who have invested in hardware, making it harder to
gain their support.
Instead I believe we should introduce multiple new proofs of work that are
already established and proven within existing altcoin implementations. As
an example we could add Scrypt, Ethash and Equihash. Much of the code and
mining infrastructure already exists. Diversification of hardware (a mix of
CPU and memory intensive methods) would also be positive for
decentralisation. Initial difficulty could simply be an estimated portion
of existing infrastructure.
This example would mean 4 proofs of work with 40 minute block target
difficulty for each. There could also be a rule that two different proofs
of work must find a block before a method can start hashing again. This
means there would only be 50% of hardware hashing at a time, and a sudden
gain or drop in hashpower from a particular method does not dramatically
impact the functioning of the network between difficulty adjustments. This
also adds protection from attacks by the malicious SHA256 hashpower which
could even be required to wait until all other methods have found a block
before being allowed to hash again.
50% hashing time would mean that the cost of electricity in relation to
hardware would fall by 50%, reducing some of the centralising impact of
subsidised or inexpensive electricity in some regions over others.
Such a hard fork could also, counter-intuitively, introduce a block size
increase since while we’re hard forking it makes sense to minimise the
number of future hard forks where possible. It could also activate SegWit
if it hasn’t already.
The beauty of this method is that it creates a huge risk to any malicious
actor trying to abuse their position. Ideally, MR POWA would just serve as
a deterrent and never activate.
If consensus were to form around a hard fork in the future nodes would be
able to upgrade and MR POWA, while automatically activating on non-upgraded
nodes, would be of no economic significance: a vestigial chain immediately
abandoned with no miner incentive.
I think this would be a great way to help prevent malicious use of
hashpower to harm the network. This is the beauty of Bitcoin: for any road
block that emerges the economic majority can always find a way around.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Andrew Johnson
--
Andrew Johnson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170320/c4a231a7/attachment-0001.html>

2023-06-07 17:57:23 UTC

- reply

📅 Original date posted:2017-03-20
📝 Original message:By doing this you're significantly changing the economic incentives behind
bitcoin mining. How can you reliably invest in hardware if you have no idea
when or if your profitability is going to be cut by 50-75% based on a whim?
You may also inadvertently create an entirely new attack vector if 50-75%
of the SHA256 hardware is taken offline and purchased by an entity who
intends to do harm to the network.
Bitcoin only works if most miners are honest, this has been known since the
beginning.
On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I’m very worried about the state of miner centralisation in Bitcoin.
>
> I always felt the centralising effects of ASIC manufacturing would resolve
> themselves once the first mover advantage had been exhausted and the
> industry had the opportunity to mature.
>
> I had always assumed initial centralisation would be harmless since miners
> have no incentive to harm the network. This does not consider the risk of a
> single entity with sufficient power and either poor, malicious or coerced
> decision making. I now believe that such centralisation poses a huge risk
> to the security of Bitcoin and preemptive action needs to be taken to
> protect the network from malicious actions by any party able to exert
> influence over a substantial portion of SHA256 hardware.
>
> Inspired by UASF, I believe we should implement a Malicious miner Reactive
> Proof of Work Additions (MR POWA).
>
> This would be a hard fork activated in response to a malicious attempt by
> a hashpower majority to introduce a contentious hard fork.
>
> The activation would occur once a fork was detected violating protocol
> (likely oversize blocks) with a majority of hashpower. The threshold and
> duration for activation would need to be carefully considered.
>
> I don’t think we should eliminate SHA256 as a hashing method and change
> POW entirely. That would be throwing the baby out with the bathwater and
> hurt the non-malicious miners who have invested in hardware, making it
> harder to gain their support.
>
> Instead I believe we should introduce multiple new proofs of work that are
> already established and proven within existing altcoin implementations. As
> an example we could add Scrypt, Ethash and Equihash. Much of the code and
> mining infrastructure already exists. Diversification of hardware (a mix of
> CPU and memory intensive methods) would also be positive for
> decentralisation. Initial difficulty could simply be an estimated portion
> of existing infrastructure.
>
> This example would mean 4 proofs of work with 40 minute block target
> difficulty for each. There could also be a rule that two different proofs
> of work must find a block before a method can start hashing again. This
> means there would only be 50% of hardware hashing at a time, and a sudden
> gain or drop in hashpower from a particular method does not dramatically
> impact the functioning of the network between difficulty adjustments. This
> also adds protection from attacks by the malicious SHA256 hashpower which
> could even be required to wait until all other methods have found a block
> before being allowed to hash again.
>
> 50% hashing time would mean that the cost of electricity in relation to
> hardware would fall by 50%, reducing some of the centralising impact of
> subsidised or inexpensive electricity in some regions over others.
>
> Such a hard fork could also, counter-intuitively, introduce a block size
> increase since while we’re hard forking it makes sense to minimise the
> number of future hard forks where possible. It could also activate SegWit
> if it hasn’t already.
>
> The beauty of this method is that it creates a huge risk to any malicious
> actor trying to abuse their position. Ideally, MR POWA would just serve as
> a deterrent and never activate.
>
> If consensus were to form around a hard fork in the future nodes would be
> able to upgrade and MR POWA, while automatically activating on non-upgraded
> nodes, would be of no economic significance: a vestigial chain immediately
> abandoned with no miner incentive.
>
> I think this would be a great way to help prevent malicious use of
> hashpower to harm the network. This is the beauty of Bitcoin: for any road
> block that emerges the economic majority can always find a way around.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Andrew Johnson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170320/8083629e/attachment.html>

2023-06-07 17:57:20 UTC

- reply

📅 Original date posted:2017-03-18
📝 Original message:I think this is an excellent idea. I consider myself to be extremely
data-driven and logical in my thinking, and have still fallen victim to
thinking "oh great, what's <person I've been annoyed by in the past> on
about now?" when seeing something posted or proposed.
And vice versa, it prevents people from being more partial to a bad or not
so great idea simply because it was posited by someone they hold in high
regard.
Simple, yet effective. I would actually even go a step further and say
that all BIPs should be done this way as a matter of procedure, I can't
think of a downside.
On Sat, Mar 18, 2017 at 10:46 AM Chris Stewart via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> As everyone in the Bitcoin space knows, there is a massive scaling debate
> going on. One side wants to increase the block size via segwit, while the
> other side wants to increase via hard fork. I have strong opinions on the
> topic but I won’t discuss them here. The point of the matter is we are
> seeing the politicization of protocol level changes. The critiques of these
> changes are slowly moving towards critiques based on who is submitting the
> BIP -- not what it actually contains. This is the worst thing that can
> happen in a meritocracy.
>
> *Avoiding politicization of technical changes in the future*
>
> I like what Tom Elvis Judor did when he submitted his MimbleWimble white
> paper to the technical community. He submitted it under a pseudonym, over
> TOR, onto a public IRC channel. No ego involved — only an extremely
> promising paper. Tom (and Satoshi) both understood that it is only a matter
> of time before who they are impedes technical progress of their system.
>
> I propose we move to a pseudonymous BIP system where it is required for
> the author submit the BIP under a pseudonym. For instance, the format could
> be something like this:
>
> BIP: 1337
>
> Author: 9458b7f9f76131f18823d73770e069d55beb271b at protonmail.com
>
> BIP content down here
>
> The hash “6f3…9cd0” is just my github username, christewart, concatenated
> with some entropy, in this case these bytes:
> 639c28f610edcaf265b47b0679986d10af3360072b56f9b0b085ffbb4d4f440b
>
> and then hashed with RIPEMD160. I checked this morning that protonmail can
> support RIPEMD160 hashes as email addresses. Unfortunately it appears it
> cannot support SHA256 hashes.
>
> There is inconvenience added here. You need to make a new email address,
> you need to make a new github account to submit the BIP. I think it is
> worth the cost -- but am interested in what others think about this. I
> don't think people submitting patches to a BIP should be required to submit
> under a pseudonym -- only the primary author. This means only one person
> has to create the pseudonym. From a quick look at the BIPs list it looks
> like the most BIPs submitted by one person is ~10. This means they would
> have had to create 10 pseudonyms over 8 years -- I think this is
> reasonable.
>
> *What does this give us?*
>
> This gives us a way to avoid politicization of BIPs. This means a BIP can
> be proposed and examined based on it’s technical merits. This levels the
> playing field — making the BIP process even more meritocratic than it
> already is.
>
> If you want to claim credit for your BIP after it is accepted, you can
> reveal the preimage of the author hash to prove that you were the original
> author of the BIP. I would need to reveal my github username and
> “639c28f610edcaf265b47b0679986d10af3360072b56f9b0b085ffbb4d4f440b”
>
> *The Future*
> Politicization of bitcoin is only going to grow in the future. We need to
> make sure we maintain principled money instead devolving to a system where
> our money is based on a democratic vote — or the votes of a select few
> elites. We need to vet claims by “authority figures” whether it is Jihan
> Wu, Adam Back, Roger Ver, or Greg Maxwell. I assure you they are human —
> and prone to mistakes — just like the rest of us. This seems like a simple
> way to level the playing field.
>
> Thoughts?
>
> -Chris
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Andrew Johnson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170318/a41a9a1a/attachment.html>

2023-06-07 17:54:51 UTC

- reply

📅 Original date posted:2016-12-11
📝 Original message:"You miss something obvious that makes this attack actually free of cost.
Nothing will "cost them more in transaction fees". A miner can create
thousands of transactions paying to himself, and not broadcast them to
the network, but hold them and include them in the blocks he mines. The
fees are collected by him because transactions are included in a block
that he mined and the left amount is in another wallet of the same
person. Repeat this continuously to fill blocks."
This is easily detectable as long as the network isn't heavily
partitioned(which is an assumption we make today in order for transaction
propagation to work reliably as well as for xThin and CompactBlocks to work
effectively to reduce block transmission time). Other miners would have an
incentive to intentionally orphan blocks that contained a large number of
transactions that their nodes were unaware of.
I don't think this sort of attack would last long. Even later when
subsidies are drastically reduced, you would still lose out on significant
genuine fee revenue if your orphan rate increased even 10%(one out of ten
of your poison blocks intentionally orphaned by another miner).
On Dec 11, 2016 11:12 AM, "s7r via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
t. khan wrote:
> Miners 'gaming' the Block75 system -
> There is no financial incentive for miners to attempt to game the
> Block75 system. Even if it were attempted and assuming the goal was to
> create bigger blocks, the maximum possible increase would be 25% over
> the previous block size. And, that size would only last for two weeks
> before readjusting down. It would cost them more in transaction fees to
> stuff the network than they could ever make up. To game the system,
> they'd have to game it forever with no possibility of profit.
>
This is an incentive, if few miners agree to create a large conglomerate
that will ultimately control the network.
You miss something obvious that makes this attack actually free of cost.
Nothing will "cost them more in transaction fees". A miner can create
thousands of transactions paying to himself, and not broadcast them to
the network, but hold them and include them in the blocks he mines. The
fees are collected by him because transactions are included in a block
that he mined and the left amount is in another wallet of the same
person. Repeat this continuously to fill blocks.
> Blocks would get too big -
> Eventually, blocks would get too big, but only if bandwidth stopped
> increasing and the cost of disk space stopped decreasing. Otherwise, the
> incremental adjustments made by Block75 (especially in combination with
> SegWit) wouldn't break anyone's connection or result in significantly
> more orphaned blocks.
>
Topology and bandwidth speed / hash rate of the network cannot be
controlled - if we make assumptions about these it might have terrible
consequences.
Even if we take in consideration that bandwidth will only grow and disk
space will only cost less (which is not something we can safely assume,
by the way) the hard limit max. block size cannot grow to unlimited
value (even if the growth happens over time). There is also a validation
cost in time for each block, for the health of the network any node
should be able to download _and_ validate a block, before next block
gets mined.
You said in another post that a permanent solution is preferred, rather
than kicking the can down the road. I fully agree, as well as many
others reading this list, but the permanent solution doesn't necessarily
have to be increasing the max block size dynamically.
If you think about it the other way around, dynamically growing the max
block size is also kicking the can down the road ... just without having
to touch it and get dust on the boot ;)
_______________________________________________
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/20161211/ba48b60f/attachment-0001.html>

2023-06-07 17:53:42 UTC

- reply

📅 Original date posted:2016-10-02
📝 Original message:The purpose of this list is highly technical discussion, not political
disagreements.
Is this particular proposal encumbered by a licensing type, patent, or
pending patent which would preclude it from being used in the bitcoin
project? If not, you're wildly off topic.
On Oct 2, 2016 12:11 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sun, Oct 02, 2016 at 02:00:01PM -0300, Sergio Demian Lerner wrote:
> > Peter, are you really going to try to down vote a decent free and
> > open-source proposal that benefits all the Bitcoin community including
> > you and your future children because a personal attack to me without any
> > logic or basis?
>
> I've suggested a way that you can rectify this situation so we can
> continue to
> collaborate: Have Rootstock adopt a legally binding patent pledge/license.
> I'd
> suggest you do as Blockstream has done and at minimum adopt the Defensive
> Patent License (DPL); I personally will be doing so in the next week or
> two for
> my own consulting company (I'm discussing exactly how to do so with my
> lawyer
> right now).
>
> If Rootstock is not planning on getting any patents for offensive purposes,
> then there is no issue with doing so - the DPL in particular is designed
> in a
> minimally intrusive way.
>
> Please fix this issue so we can in fact continue to collaborate to improve
> Bitcoin.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> 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/20161002/a23d4ab3/attachment.html>

2023-06-07 17:52:12 UTC

- reply

📅 Original date posted:2016-08-04
📝 Original message:"This is already possible. Just nLockTime your withdrawls for some future
block. Don't sign any transaction that isn't nLockTime'd at least N blocks
beyond the present tip."
This would have prevented the Bitfinex hack if BitGo did this, but it
wouldn't have helped if the Bitfinex offline key had been compromised
instead of BitGo doing the 2nd sig. In the BFX hack the TXNs were signed
by Bitfinex's hot key and BitGo's key, they required 2 of 2.
If I'm understanding correctly, what Matthew is proposing is a new type of
UTXO that is only valid to be spent as an nLockTime transaction and can be
reversed by some sort of RBF-type transaction within that time period, I
believe.
But I don't think this will work. What do you do if the keys are
compromised? What's to stop the attacker from locking the coins up
indefinitely by repeatedly broadcasting a refund transaction each time you
try to spend to an uncompromised address?
You'd need a third distinct key required for the refund TXN that's separate
from the keys used to sign the initial nLockTime TXN. And the refund TXN
would need to be able to go to a new address entirely.
On Aug 3, 2016 11:28 PM, "Luke Dashjr via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wednesday, August 03, 2016 6:16:20 PM Matthew Roberts via bitcoin-dev
> wrote:
> > In light of the recent hack: what does everyone think of the idea of
> > creating a new address type that has a reversal key and settlement layer
> > that can be used to revoke transactions?
>
> This isn't something that makes sense at the address, since it represents
> the
> recipient and not the sender. Transactions are not sent from addresses
> ever.
>
> > You could specify so that transactions "sent" from these addresses must
> > receive N confirmations before they can't be revoked, after which the
> > transaction is "settled" and the coins become redeemable from their
> > destination output. A settlement phase would also mean that a
> transaction's
> > progress was publicly visible so transparent fraud prevention and
> auditing
> > would become possible by anyone.
>
> This is already possible. Just nLockTime your withdrawls for some future
> block. Don't sign any transaction that isn't nLockTime'd at least N blocks
> beyond the present tip.
>
> Luke
> _______________________________________________
> 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/20160803/c004566c/attachment.html>