The whole point is in preventing every third party, including miners, from
seeing the details of what is being spent and how. The burden of
verification is shifted to the owners of the coin (which is fair).
In fact we could have miners recognize spend proofs and check that the same
spend proof is
It wouldn't be feasible in the vast majority of cases, but I can't think of
a reason why it can't be built into the standard.
On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Would it be feasible to transmit an entire BIP21 URI as au
On Sat, Aug 06, 2016 at 07:15:22AM -0700, Chris Priest via bitcoin-dev wrote:
> If the blocksize limit is to be changed to a block output limit, the
> number the limit is set to should be roughly the amount of outputs
> that are found in 1MB blocks today. This way, the change should be
The largest
On Wed, Jul 20, 2016 at 06:17:39AM +, Luke Dashjr wrote:
> On Wednesday, July 20, 2016 5:46:54 AM Peter Todd via bitcoin-dev wrote:
> > On Tue, Jul 19, 2016 at 10:35:39PM -0600, Sean Bowe via bitcoin-dev wrote:
> > > I'm requesting feedback for Hash Time-Locked Contract (HTLC) transactions
> >
One more thought about why verification by miners may be needed.
Let's say Alice sends Bob a transaction, generating output C.
A troll, named Timothy, broadcasts a transaction with a random hash,
referencing C's output as its spend proof. The miners can't tell if it's
valid or not, and so they in
That is a good point. As you said, it puts a lot more burden on the coin
holders. One big downside would be data management. Instead of simply
backing up a single HD private key, the user would have to back up entire
histories of every output that has been sent to them if they want to secure
their
I wouldn't worry about payment requests until I built a decoder and made
the transmission a lot faster (probably adding tones and making it 5 bits
wide), which shouldn't be hard
On Mon, Aug 8, 2016 at 5:06 PM, Justin Newton via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Daniel,
Would it be feasible to transmit an entire BIP21 URI as audio? If you were
to encode any extra information (such as amount), it would be useful to
include a checksum for the entire message. This checksum could possibly be
used instead of the checksum in the address.
Trevin
On Aug 8, 2016 3:06 PM,
Sorry about the last email, I deleted the repository to get rid of the BIP
number to prevent confusion. The correct address is
https://github.com/Dako300/BIP
This is my BIP idea: a fast, robust, and standardized way for representing
Bitcoin addresses over audio. It takes the binary representation
Daniel,
Thanks for proposing this. I think this could have some useful use
cases as you state. I was wondering what you would think to adding some
additional tones to optionally denote an amount (in satoshis?).
(FYI, actual link is here: https://github.com/Dako300/BIP )
Justin
On Mon, Aug
On Mon, Aug 08, 2016 at 09:41:27PM +, James MacWhyte via bitcoin-dev wrote:
> Wouldn't you lose the ability to assume transactions in the blockchain are
> verified as valid, since miners can't see the details of what is being
> spent and how? I feel like this ability is bitcoin's greatest asset
Wouldn't you lose the ability to assume transactions in the blockchain are
verified as valid, since miners can't see the details of what is being
spent and how? I feel like this ability is bitcoin's greatest asset, and by
removing it you're creating an altcoin different enough to not be connected
t
This is my BIP idea: a fast, robust, and standardized for representing
Bitcoin addresses over audio. It takes the binary representation of the
Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
(depending on type, 2 bit only for low quality audio like american
telephone lines), a
On 08/08/2016 01:42 PM, Gregory Maxwell wrote:
On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev
wrote:
I have mixed feelings about strictly tying the identity-public-keys with a
[...]
guaranteed static IP address. The second reason is because the DNS PTR
I don't see any reason
On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev
wrote:
> I have mixed feelings about strictly tying the identity-public-keys with a
[...]
> guaranteed static IP address. The second reason is because the DNS PTR
I don't see any reason that it couldn't also accept a DNS name there.
T
On 08/08/2016 11:00 AM, Jonas Schnelli via bitcoin-dev wrote:
# ___known-peers___ contains known identity-public-keys together with a
network identifier (IP & port), similar to the "known-host" file
supported by openssh.
I have mixed feelings about strictly tying the identity-public-keys with
Hi Henning,
1. The fees are paid by the enclosing BTC transaction.
2. The hash is encoded into an OP_RETURN.
> Regarding the blinding factor, I think you could just use HMAC.
How exactly?
Tony
2016-08-08 18:47 GMT+03:00 Henning Kopp :
> Hi Tony,
>
> I see some issues in your protocol.
>
> 1.
Hi Tony,
I see some issues in your protocol.
1. How are mining fees handled?
2. Assume Alice sends Bob some Coins together with their history and
Bob checks that the history is correct. How does the hash of the txout
find its way into the blockchain?
Regarding the blinding factor, I think you c
This is a proposal about hiding the entire content of bitcoin
transactions. It goes farther than CoinJoin and ring signatures, which
only obfuscate the transaction graph, and Confidential Transactions, which
only hide the amounts.
The central idea of the proposed design is to hide the entire inpu
Hi
As already mentioned in the recent BIP151 thread
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/012826.html),
I propose the following authentication scheme to basically allow MITM
detection and rejection in conjunction with BIP151.
The proposed authentication BIP does requi
Not everyone who uses centralized exchanges are there to obtain the
currency though. A large portion are speculators who need to be able to
enter and exit complex positions in milliseconds and don't care about
decentralization, security, and often even the asset that they're buying.
Try telling ev
With channels and the exchange acting as hub, you can do instant trades
between altcoins.
This doesn't work with fiat accounts. A "100% reserve" company could issue
fiat tokens. The exchange could then trade those tokens.
This eliminates the counter-party risk for the exchange. If the exchange
I'm not convinced you need to hold people's funds to provide those
features. Maybe the millisecond thing. But 99 out of 100 traders would
accept a 100 millisecond latency in exchange for 0 counterparty risk.
___
bitcoin-dev mailing list
bitcoin-dev@list
On Mon, Aug 8, 2016 at 1:48 AM, Matthew Roberts wrote:
> Not everyone who uses centralized exchanges are there to obtain the
> currency though. A large portion are speculators who need to be able to
> enter and exit complex positions in milliseconds and don't care about
> decentralization, securi
24 matches
Mail list logo
