A fairly decent rework would be needed but it seems that the idea has merit
initially.
As it is now, it is not only that a utxo exists but, that the transaction it
references and the block it is within can also be fully validated.
So, if a utxo block set type existed then by consensus every s
I see what you say, however, since the proposal as I have read it says "And
this will keep happening as long as hashrate keeps rising," - what actually
happens in the case hashrate stagnates or falls?
I would prefer to see (not only with your proposal) greater bias toward
hashrate being expone
>This "reserve" part of the fee will be paid to miners if the hashrate rises.
Anticipating ongoing hashrate rise shows that you have not yet thought about
moving outside of the current greed model, a model wherein mining will consume
all available resources within the colony's objective just to
Humour me please,
Where you say "create transactions which are only valid if they are mined on
top of a specific block." - in practice, does that usually means at any height
above a specific block?
From: bitcoin-dev-boun...@lists.linuxfoundation.org
on behalf
I do understand your point, however, 'something like stuxnet' cannot be used to
create valid data without re-doing all the PoW. Provided some valid copies of
the blockchain continue to exist, the network can re-synchronise.
Unrelated, it would seem useful to have some kind of deep blockchain co
I note that Electrum v3.0.6 has an option to use multiple change addresses. It
is off by default.
Regards,
Damian Williamson
From: Eric Voskuil
Sent: Monday, 19 March 2018 5:59:28 AM
To: Evan Klitzke; Bitcoin Protocol Discussion
Cc: Damian Williamson
Subject:
Discussion
Subject: Re: [bitcoin-dev] feature: Enhance privacy by change obfuscation
Damian Williamson via bitcoin-dev
writes:
> Operation: Provide a user selectable 'Enhanced privacy' option for
> transaction creation, when true the transaction randomly distributes
> change
Application: Bitcoin Core
Feature: Enhanced privacy by change obfuscation
Operation: Provide a user selectable 'Enhanced privacy' option for transaction
creation, when true the transaction randomly distributes change across up to
twenty output addresses (minimum five?), provided each output is
That is very helpful Luke. I would not have been concerned if it was necessary
to sign multiple times for multiple utxo's on different addresses but, since it
is a feature it may as well be best usable. Signing for multiple inputs
verifying that you have the priv key for each in your wallet is c
Current implementation of sign/verify is broken for SegWit and Bech32 addresses.
Please add the following reference to the use cases:
---
# Does blockchain.info show balances for addresses that are in cold storage?
Yes.
>... is there any way for me in another country to confirm that what my
Would it be possible or desirable to add a `nBlockHeight Activated` column to
the
[README.mediawiki](https://github.com/bitcoin/bips/blob/master/README.mediawiki)
to show a specific reference to when a BIP was activated? - And/or include
such information in the BIP Header format?
Regards,
Da
>1. Introducing state checkpoints into the chain itself could make it possible
>for full nodes to skip verification of large sections of historical data when
>booting up.
What you are suggesting, unless I am mistaken, is that new full nodes should
have no way of knowing if an output is spent o
I do not know that Bitcoin's position is any weaker because of the terms that
the software is licenced under.
Cory Fields said:
>Let other projects faff about with copyright litigation and trademark dilution
>concerns
I disagree completely with any licence change. As well as allowing for the
Then you have my apology, I will not claim to be any kind of advocate or user
of Bitcoin Cash but *had* understood that segwith had been enabled. Clearly my
mistake.
Regards,
Damian Williamson
From: CANNON
Sent: Tuesday, 6 February 2018 1:08:24 PM
To: Damian
It seems in a document that I was referenced with this very question that the
unit for creating invoices on Lightning is millisatoshi. Do we really need to
invoice for 1000 millisatoshi for a 1 sat transaction?
https://github.com/ElementsProject/lightning/blob/master/README.md#sending-and-recei
cheat
means that cheating will be rife.
On Sat, Jan 20, 2018 at 8:04 AM, Damian Williamson via bitcoin-dev
mailto:bitcoin-dev@lists.linuxfoundation.org>>
wrote:
Tried a different approach for the curves, would appreciate it if someone has
the energy to work on this and help me to resolve it a
dev-boun...@lists.linuxfoundation.org
on behalf of Damian Williamson
via bitcoin-dev
Sent: Thursday, 4 January 2018 8:01:10 PM
To: Bitcoin Protocol Discussion
Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction
Priority For Ordering Transactions In Blocks
This proposal has a
Damian Williamson
via bitcoin-dev
Sent: Thursday, 4 January 2018 8:01:10 PM
To: Bitcoin Protocol Discussion
Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction
Priority For Ordering Transactions In Blocks
This proposal has a new update, mostly minor edits. Additionally, I had a
It probably could be noted, although it is well known, pools, in some views,
act as one large individual miner, not just when separately considering the
actions of pools.
Given the operation of pools, would a pool be required to mine the
new-miner-blocks, or would you propose operation in a po
The same problems exist for users of whole disk encrypted operating systems.
Once the device (or, the initial password authentication) is found, the
adversary knows that there is something to see. The objective of plausible
deniability is to present some acceptable (plausible) alternative while
(
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015485.html
) #Bitcoin #BIP
Regards,
Damian Williamson
From: bitcoin-dev-boun...@lists.linuxfoundation.org
on behalf of Damian Williamson
via bitcoin-dev
Sent: Monday, 1 January 2018 10:04 PM
To: bi
Happy New Year all.
This proposal has been further amended with several minor changes and a
few additions.
I believe that all known issues raised so far have been sufficiently
addressed. Either that or, I still have more work to do.
## BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority F
Good evening ZmnSCPxj,
That you for your considered discussion.
Am I wrong to think that any fullnode can validate blocks conform to a
probability distribution? In my understanding after adoption of the proposal,
any full node could validate all properties that a block has that they now
vali
I have needed to re-tac my intentions somewhat, there is still much
work to be done.
This is a request for assistance and further discussion of the re-
revised proposal. I am sure there are still issues to be resolved.
## BIP Proposal: UTPFOTIB - Use Transaction Priority For Ordering
Transactions
cessed quickly..
Calculating what the outputs are given a variable fee needs a new mechanism all
of it's own, but I'm sure it's possible.
The simple fact is that there is currently no known system that works as well
as the current system..
But there are other systems.
On Dec 2
nity, or describing a new feature for Bitcoin
or its ...
Luke
On Sunday 24 December 2017 2:57:38 AM Damian Williamson via bitcoin-dev wrote:
> BIP 177: UTPFOTIB - Use Transaction Priority For Ordering Transactions In
> Blocks
>
>
> This BIP proposes to address the issue of tr
If all transactions pay the proposed max then fee there are still going to be
an awful lot of never confirming transactions once the transaction bandwidth
limit is surpassed, as I suppose that it roughly is now:
https://bitinfocharts.com/comparison/bitcoin-transactions.html
This is what I have
BIP 177: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks
This BIP proposes to address the issue of transactional reliability in Bitcoin,
where valid transactions may be stuck in the mempool for extended periods.
There are two key issues to be resolved:
1. The curre
mempool at no cost.
On Dec 16, 2017, at 8:14 PM, Damian Williamson via bitcoin-dev
mailto:bitcoin-dev@lists.linuxfoundation.org>>
wrote:
I do not know why people make the leap that the proposal requires a consensus
on the transaction pool. It does not.
It may be helpful to have the disc
From: bitcoin-dev-boun...@lists.linuxfoundation.org
on behalf of Damian Williamson
via bitcoin-dev
Sent: Tuesday, 19 December 2017 6:51 PM
To: Mark Friedenbach
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use
In all seriousness, being able to sign a message is an important feature
whether it is with Bitcoin Core or, with some other method. It is a good
feature and it would be worthwhile IMHO to update it for SegWit addresses. I
don't know about renewing it altogether, I like the current simplicity.
There is no reason it should not be easily possible to develop a Bitcoin wallet
that has an integrated name to address mapping feature. It might be a good idea
for a software product, it could even be based on Bitcoin Core. There is no
specific reason that people wanting that sort of feature cou
bility, the output should conform to a
probability curve.
If someone has the necessary skill, would anyone be willing to develop the math
necessary for the proposal?
Regards,
Damian Williamson
________
From:
bitcoin-dev-boun...@lists.linuxfoundation.org<mailto:bitcoin-dev-bou
work to other attack
vectors. Perhaps you meant it a different way.
On Fri, Dec 15, 2017 at 3:59 PM, Damian Williamson via bitcoin-dev
mailto:bitcoin-dev@lists.linuxfoundation.org>>
wrote:
>
> There are really two separate problems to solve.
>
>
> How does Bitcoin scale with
sal, since the input is a probability, the output should conform to a
probability curve.
If someone has the necessary skill, would anyone be willing to develop the math
necessary for the proposal?
Regards,
Damian Williamson
From: bitcoin-dev-boun...@lists.lin
be included on a
probability curve then it is possible to verify that blocks conform to the
proposal, since the input is a probability, the output should conform to a
probability curve.
If someone has the necessary skill, would anyone be willing to develop the math
necessary for the proposal
From: bitcoin-dev-boun...@lists.linuxfoundation.org
on behalf of Damian Williamson
via bitcoin-dev
Sent: Friday, 8 December 2017 8:01 AM
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction
Priority For Ordering
Good afternoon,
The need for this proposal:
We all must learn to admit that transaction bandwidth is still lurking as a
serious issue for the operation, reliability, safety, consumer acceptance,
uptake and, for the value of Bitcoin.
I recently sent a payment which was not urgent so; I chose th
Good morning ZmnSCPxj,
Actually, there is no incentive to cheat target block size by providing a next
block size that is higher or lower than the proposal would give. Under the
proposal the transaction pool can grow quite large. A low next block size just
defers collecting transaction fees, wh
Good morning ZmnSCPxj, it must be where you are,
I suppose that we are each missing each other's point some.
I understand that nodes would not be expected to agree on the transaction pool
and do not propose validating that the correct transactions are included in a
block. I speak of probabili
adopted as some kind of "policy", what forces a miner to follow it?
Jim Renkel
On 12/2/2017 10:07 PM, Damian Williamson via bitcoin-dev wrote:
# BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In
Blocks
I admit, with my limited experience in the operat
Good afternoon ZmnSCPxj,
I have posted some discussion on the need for this proposal and, some
refinements to the proposal explanation (not changes to the intended operation)
to the bitcoin-discuss list. I didn't exactly mean to double post but thought
it could use the discussion and, not to p
# BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In
Blocks
I admit, with my limited experience in the operation of the protocol, the
section entitled 'Solution operation' may not be entirely correct but you will
get the idea. If I have it wrong, please correct it back
I also am for the idea of removing blocksize limits if it is workable, however,
would propose an alternative method for selecting transactions to be included
in a block.
Some of the issues discussed in other replies to this thread are valid.
Alternative proposal:
Provide each transaction wit
44 matches
Mail list logo
