Chris Pacia [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-03-13 to 2018-06-06
💬 Posted a total of 31 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, BIP Proposal
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1jp0jnnq2jxcjy76nrt5dssvmpynt4f9psdelp3vxj0y0xtpxl7jqhkn8jw

Profile Code

nprofile1qqsfqhefes9frvfz0df346xcgxdsjf465jscxulsckrf8j8n9sn0lfq4cljd2

Author Public Key

npub1jp0jnnq2jxcjy76nrt5dssvmpynt4f9psdelp3vxj0y0xtpxl7jqhkn8jw

Show more details

Last Notes

2023-06-07 18:08:07

- reply

📅 Original date posted:2017-12-04
📝 Original message:I think you are missing a few things.
First of all, I think the security model for sidechains is the same as
that of every blockchain
People will say things, like "but with sidechains 51% hashrate can steal
your coins!", but as I have repeated many times, this is also true of
mainchain btc-tx. is something else?
There are substantial opportunity costs as well as a collective action
problem when it comes to re-writing the mainchain.
Is there anything similar for drivechains? As far as I can tell there is no
opportunity cost to casting a malicious vote, no repercussions, and no
collective action barrier that needs to be overcome.
Unless I'm missing something I wouldn't liken the security of a drivechain
to that of the mainchain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171204/2f0566b4/attachment.html>

2023-06-07 18:02:06

- reply

📅 Original date posted:2017-06-02
📝 Original message:On Jun 1, 2017 10:28 PM, "Gregory Maxwell" <greg at xiph.org> wrote:
Really bad for privacy.
As I mentioned the issue is the potential collision with the block filter,
but bloom filters by themselves aren't inherently bad for privacy. They
just reduce the anonymity set. The reason bip37 doesn't work for privacy is
how the filters have to be used/abused to make it work. That's not what I
mentioned above.
Data for transactions at the tip is only
14kb/s-- potentially less if segwit is in use and you're not getting
witnesses. Is that really that burdensome?
Your not running that on mobile.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170602/bace51b4/attachment.html>

2023-06-07 18:00:49

- reply

📅 Original date posted:2017-05-04
📝 Original message:Yes I've had it working using two pushes in op_return.
op_return op_pushdata <flag> op_pushdata <ephem_pubkey>
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 a functioning wallet. So it might
not be an improvement over standard bloom filters but at least you can do
stealth if you want.
On May 4, 2017 9:00 AM, "Henning Kopp via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> Recently I think a lot about combining Stealth addresses with SPV but
> I did not come to a satisfying conclusion, so I post this as a
> challenge to the wider community. Maybe you have an idea.
>
> ## Explanation of SPV
> In SPV a thin client puts his public keys in a bloom filter
> and asks a full node to give him Merkle proofs of all transactions
> whose pubkey are in the bloom filter. Since a bloom filter has a lot
> of false positives depending on the parameters, this gives privacy to
> the thin client, since the full node cannot detect if a specific
> transaction belongs to the thin client. This is cool if you want to
> use Bitcoin on your smartphone.
>
> ## Explanation of Stealth Addresses
> Stealth addresses on the other hand enable receiver privacy. The
> sender of a transaction derives a one-time pubkey to which he sends the
> money. The receiver can check if the money was sent to him and recover
> the one-time private key. This is cool, since an observer cannot
> decide if two payments belong to the same recipient. Further the
> recipient needs only to have one pubkey.
> For a more formal explanation see https://github.com/genjix/
> bips/blob/master/bip-stealth.mediawiki#Reuse_ScanPubkey
> I will use their notation in the following.
>
> ## The Problem
> My line of thought was to combine stealth addresses with spv, so that
> I can use stealth addresses on my smart phone without losing privacy.
>
> Basically to check if a payment belongs to a pubkey (Q,R), the full
> node needs to check if R' = R + H(dP)*G for each transaction. For this
> it needs the private scanning key d.
> This sucks, since when I give my d to a full node, he can link all my
> transactions. For an online-wallet this may be okay, but not for thin
> client synchronisation.
>
> ## Ideas
> In the following I detail some ideas of me which did not work.
>
> It does not suffice to have a Bloom filter and check if d is
> contained since there is no way to recompute d from the equation. If
> there were a way to recompute d, the scheme would offer no privacy,
> since anyone could compute the private scanning key d and scan for
> payments.
> So, if we modify the scheme we need to be sure that d is kept private.
>
> Multiparty computation may be possible in theory. The full node and
> the thin client could collaboratively check R' = R + H(dP)*G, where d
> is the private input of the thin client and R, R',P is provided by the
> full node. But this is costly and they need to do it for each
> transaction. It may be more costly than simply setting up a full node.
>
> I do not think that some kind of search functionality without leaking
> the search pattern (PIR?) would work, since the full node needs to compute
> on the
> data it has found. And further it needs to retrieve the whole Merkle
> proofs.
>
> Any better ideas?
>
> Best,
> Henning
>
> --
> Henning Kopp
> Institute of Distributed Systems
> Ulm University, Germany
>
> Office: O27 - 3402
> Phone: +49 731 50-24138
> Web: http://www.uni-ulm.de/in/vs/~kopp
> _______________________________________________
> 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/20170504/1b1ad9a5/attachment.html>

2023-06-07 17:57:48

- reply

📅 Original date posted:2017-03-26
📝 Original message:On Mar 25, 2017 10:38 PM, "Alex Morcos via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
As a Bitcoin user I find it abhorrent the way you are proposing to
intentionally cripple the chain and rules I want to use instead of just
peacefully splitting.
I just want to point out what appears to be doublespeak going on here.
First, I think it would seem obvious to an observer that a sizable portion
of the community (certainly greater than 5%) view segwit as preventing
"rules I want to use instead of just peacefully splitting" but no
consideration was given to these people when designing segwit as a
softfork. I believe it was Luke who went as far as saying consensus does
not matter when it comes softforks.
Furthermore, when segwit was first introduced it kicked off a round of
softfork/hardfork debate which I participated in. The primary concern that
I and other raised was precisely what is going on now.. that miners could
unilaterally impose an unpopular change to the protocol rules.
At the time I told, rather forcefully, by multiple people that miners have
an "absolute right" to softfork in whatever rules they want. Which, of
course, is absurd on it's face.
But I don't see how people can make such claims on the one hand, and then
complain when this process is used against them.
It amounts to nothing more than "When it's rules I like we get to impose
them on non-consenting users. When it's rules I don't like it's an attack
on the network".
It was completely obvious this entire time that softforks were a very
slippery slope, now we are indeed sliding down that slope.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170326/3cc00f44/attachment-0001.html>

2023-06-07 17:46:17

- reply

📅 Original date posted:2015-12-20
📝 Original message:On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 2) This reverses the useful minimization attribute of HD wallets - "just
backup the seed"
It would be nice if the bip37 filter matching algorithm was extended to
serve up the proof.
And if server-based wallets did the same it would preserve the "just backup
the seed" functionality.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/5a7f7f61/attachment.html>

2023-06-07 17:38:20

- reply

📅 Original date posted:2015-08-27
📝 Original message:On 08/27/2015 09:39 AM, prabhat via bitcoin-dev wrote:
> Fine point.
>
> So where is the solution? What to do?
How about nothing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/5eaae9a9/attachment.html>

2023-06-07 17:37:52

- reply

📅 Original date posted:2015-08-28
📝 Original message:On Aug 28, 2015 7:38 PM, "Mark Friedenbach" <mark at friedenbach.org> wrote:
>
> It is in their individual interests when the larger block that is allowed
for them grants them more fees.
And pay a difficulty penalty and lose full blocks because of it? Even if
fees are somehow high enough to compensate for the lost reward, it still
requires miners to collectively decide to raise the block size for it to
make sense individually. An individual vote will not raise the limit, but
it will cost the miner money.
>
> On Aug 28, 2015 4:35 PM, "Chris Pacia via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> When discussing this with Matt Whitlock earlier we basically concluded
the block size will never increase under this proposal do to a collective
action problem. If a miner votes for an increase and nobody else does, the
blocksize will not increase yet he will still have to pay the difficulty
penalty.
>>
>> It may be in everyone's collective interest to raise the block size but
not their individual interest.
>>
>> On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> With this proposal, how much would it cost a miner to include an
'extra' 500-byte transaction if the average block size is 900K and it costs
the miner 20BTC in electricity/capital/etc to mine a block?
>>>
>>> If my understanding of the proposal is correct, it is:
>>>
>>> 500/900000 * 20 = 0.11111 BTC
>>>
>>> ... Or $2.50 at today's exchange rate.
>>>
>>> That seems excessive.
>>>
>>> --
>>> Gavin Andresen
>>>
>>>
>>> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >
>>> > This is the best proposal I've seen yet. Allow me to summarize:
>>> >
>>> > • It addresses the problem, in Jeff Garzik's BIP 100, of miners
selling their block-size votes.
>>> > • It addresses the problem, in Gavin Andresen's BIP 101, of blindly
trying to predict future market needs versus future technological
capacities.
>>> > • It avoids a large step discontinuity in the block-size limit by
starting with a 1-MB limit.
>>> > • It throttles changes to ±10% every 2016 blocks.
>>> > • It imposes a tangible cost (higher difficulty) on miners who vote
to raise the block-size limit.
>>> > • It avoids incentivizing miners to vote to lower the block-size
limit.
>>> >
>>> > However, this proposal currently fails to answer a very important
question:
>>> >
>>> > • What is the mechanism for activation of the new consensus rule? It
is when a certain percentage of the blocks mined in a 2016-block
retargeting period contain valid block-size votes?
>>> >
>>> >
>>> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
>>> >
>>> >
>>> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev
wrote:
>>> >> Pull request: https://github.com/bitcoin/bips/pull/187
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev at lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> 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/20150828/f3f30c1b/attachment.html>

2023-06-07 17:37:51

- reply

📅 Original date posted:2015-08-28
📝 Original message:When discussing this with Matt Whitlock earlier we basically concluded the
block size will never increase under this proposal do to a collective
action problem. If a miner votes for an increase and nobody else does, the
blocksize will not increase yet he will still have to pay the difficulty
penalty.
It may be in everyone's collective interest to raise the block size but not
their individual interest.
On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> With this proposal, how much would it cost a miner to include an 'extra'
> 500-byte transaction if the average block size is 900K and it costs the
> miner 20BTC in electricity/capital/etc to mine a block?
>
> If my understanding of the proposal is correct, it is:
>
> 500/900000 * 20 = 0.11111 BTC
>
> ... Or $2.50 at today's exchange rate.
>
> That seems excessive.
>
> --
> Gavin Andresen
>
>
> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > This is the best proposal I've seen yet. Allow me to summarize:
> >
> > • It addresses the problem, in Jeff Garzik's BIP 100, of miners selling
> their block-size votes.
> > • It addresses the problem, in Gavin Andresen's BIP 101, of blindly
> trying to predict future market needs versus future technological
> capacities.
> > • It avoids a large step discontinuity in the block-size limit by
> starting with a 1-MB limit.
> > • It throttles changes to ±10% every 2016 blocks.
> > • It imposes a tangible cost (higher difficulty) on miners who vote to
> raise the block-size limit.
> > • It avoids incentivizing miners to vote to lower the block-size limit.
> >
> > However, this proposal currently fails to answer a very important
> question:
> >
> > • What is the mechanism for activation of the new consensus rule? It is
> when a certain percentage of the blocks mined in a 2016-block retargeting
> period contain valid block-size votes?
> >
> >
> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
> >
> >
> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
> >> Pull request: https://github.com/bitcoin/bips/pull/187
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> 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/20150828/a44dfde3/attachment.html>

2023-06-07 17:37:38

- reply

📅 Original date posted:2015-08-21
📝 Original message:On Aug 21, 2015 2:07 AM, "Peter Todd via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Also, as I mentioned, just look at the popularity of wallets such as
> Mycelium that are not adopting bloom filters, but going with SPV
> verification of block headers w/ lookup servers.
Related I recently had a conversation with a Mycelium employee who told me
they were considering moving to spv/bloom because of the server issues
Andreas mentioned.
I don't know any more about their plans, but I wouldn't assume the above
statement to be correct.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/95990bfa/attachment.html>

2023-06-07 17:35:59

- reply

📅 Original date posted:2015-08-17
📝 Original message:On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>From the point of view of a
> wallet, it's not very secure to use Hearn-style SPV mode, and volunteers
> running full nodes doesn't help things. Sybil attacking the IP address
> space is pretty easy in comparison to aquiring hashing power sufficient
> to create false confirmations, so any attacker able to do the former
> will likely be running the full node you're connecting too anyway.
> Ultimately, Hearn-style SPV is a close approximation to just trusting
> anyone with a non-trivial amount of hashing power. (and getting that is
> surprisingly easy, e.g. w/ SPV mining)
Can you explain how the spv node fails against an attacker with a
non-trivial amount of hash power where a full node doesn't? To attack an
spv wallet that is waiting for 6 or 10 confirmations, you would not only
need to Sybil them but also summon a massive amount of hashing power to
create a chain of headers (while forgoing the opportunity to mine valid
blocks with that hash power).
But could someone with that much hash power not Sybil a full node and give
them a chain for valid blocks (but on an orphan fork)? The failure model
doesn't seem specific to spv to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/6a9455df/attachment.html>

2023-06-07 17:33:05

- reply

📅 Original date posted:2015-08-09
📝 Original message:I'm glad Tom is bringing these points up. There seems to be an assumption
by many that LN will be automatically awesome by virtue of it being
technically feasible with having considered whether it is economically
feasible or desirable.
So much stock has been placed in LN as the solution to the block size
debate, yet it could turn out that it sucks in practice. Then what?
On Aug 9, 2015 5:27 PM, "Tom Harding via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark at friedenbach.org> wrote:
>
> > On the contrary the funds were advanced by the hub on the creation of
> the channel. There is no credit involved.
>
> That's a chuckle.
>
> As I said, nothing requires the hub to advance anything, and if it does,
> Bob can expect to pay for it.
>
> We'll see whether hubs assess a fee for depositing funds, whether the fee
> depends on the amount deposited, and whether it depends on the amount of
> time it stays there.
>
> I predict "all of the above." There is a name for these kinds of fees.
> Can you guess it?
>
> _______________________________________________
> 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/20150809/db8043fc/attachment.html>

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-06-30
📝 Original message:On 06/30/2015 12:05 PM, Peter Todd wrote:
> Well, as you know I have good reason to believe those contracts are
> being actively worked on right now.
Isn't the whole reason they are working on those contracts because a few
miners don't use first-seen in all circumstances as it is? Or as a
corollary, wouldn't full RBF just create that much more incentive for
those type of contracts?

2023-06-07 15:41:14

- reply

📅 Original date posted:2015-06-30
📝 Original message:On 06/30/2015 09:12 AM, Adam Back wrote:
> It is correct to view first-seen miner and relay policy as
> honour-based, though it is the current default.
>
>
What would be the effect of IBLT on the first seen policy? It seems that
if a miner has to broadcast extra data with his blocks because he's
using full RBF and everyone else is using first-seen then his blocks are
at a disadvantage in terms of propagation. That wouldn't make first-seen
a hard consensus rule, but rather one rational miners are likely to
follow. Or is this effect likely to be minimal?

2023-06-07 15:38:36

- reply

📅 Original date posted:2015-06-18
📝 Original message:On 06/18/2015 06:33 PM, Mark Friedenbach wrote:
>
> * Get safe forms of replace-by-fee and child-pays-for-parent
> finished and in 0.12.
> * Develop cross-platform libraries for managing micropayment
> channels, and get wallet authors to adopt
> * Use fidelity bonds, solvency proofs, and other tricks to minimize
> the risk of already deployed off-chain solutions as an interim measure
> until:
> * Deploy soft-fork changes for truly scalable solutions like
> Lightning Network.
One of my biggest concerns is that these solutions (lightning network in
particular) could end up being worse, in terms of decentralization, than
would be a bitcoin network using larger blocks. We don't exactly know
what the economies of scale are for pay hubs and could very well end up
with far fewer hubs than nodes at any conceivable block size.
Of course, it could also turn out to be fantastic, but it seems like an
enormous gamble to basically force everyone in the ecosystem to
collectively spend millions of dollars upgrading to Lightning /and then/
see whether it's actually an improvement in terms of decentralization.
To me, a much more sane approach would be to allow people to voluntarily
opt in to those other solutions after we've had an opportunity to
experiment with them and see how they actually function in practice, but
that can't happen if the network runs out of capacity first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/68c14c0e/attachment.html>

2023-06-07 15:30:47

- reply

📅 Original date posted:2015-02-21
📝 Original message:Adam seems to be making sense to me. Only querying a single node when an
address in my wallet matches the block filter seems to be pretty
efficient. The downside is it relies entirely on Tor for privacy, but
then again it's not the only aspect of spv clients that require it for
privacy (there's broadcasting for example).
And on a related note, if we eventually do end up receiving bip70
payments directly, we still need to query for block inclusion and that
would seem to be an easy way to do it.
On 02/20/2015 12:53 PM, Mike Hearn wrote:
>
> This is talking about a committed bloom filter. Not a committed
> UTXO set.
>
>
> I read the following comment to mean it requires the UTXO commitments.
> Otherwise I'm not sure how you prove absence of withholding with just
> current block structures+an extra filter included in the block:
>
> but with the bloom commitment (and UTXO trie organised commitment) he
> can verify that the positive hits are correct via the merkle path, and
> that the false positives are not being wrongly withheld by obtaining
> merkle path proof that they are not in the trie
>
>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150221/431334aa/attachment.html>

2023-06-07 15:27:30

- reply

📅 Original date posted:2014-11-18
📝 Original message:On Nov 17, 2014 7:39 AM, "Pieter Wuille" <pieter.wuille at gmail.com> wrote:
> That is inevitable for any wallet that offers any functionality beyond
> just maintaining a balance and the ability to send coins. In
> particular, anything that wishes to list previous transaction (with
> timestamps, history, metadata, messages sent using t
> What HD wallets (or any type of deterministic derivation scheme) offer
> is the fact that you can separate secret data and public data. You
> only need one safe backup of the master secret key - all the rest can
> at most result in privacy loss and not in lost coins.
>
> --
> Pieter
I agree but right now wallets not using stealth will only lose metadata,
not coins, if their computer crashes and they have the seed backed up.
But if a user wants to upgrade to stealth, they then risk losing metadata
AND coins if they either didn't manually back up after every transaction or
use a centralized cloud backup service.
That's if OP_RETURN is not utilized for storage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141118/9697503f/attachment.html>

2023-06-07 15:27:29

- reply

📅 Original date posted:2014-11-17
📝 Original message:On 11/17/2014 06:20 AM, Adam Back wrote:
> b) backup: the blockchain is not an efficient reliable generic backup
> mechanism because its broadcast. there are cheaper and relatively
> simple ways to get end2end secure backup, the main challenge of which
> is having secure keys and not forgetting them. bitcoin already has
> that covered as its a central requirement of blockchain security. If
> you want to archive your payment protocol receipts store them on some
> cloud storage service or disk encrypted with related keys. for
> example tahoe-lafs is optimised for the decentralised long-term
> storage kind of use.
>
This is my main concern in the context of stealth addresses. I intend to
start a larger discussion on stealth addresses, but I wont hijack the
tread.
Of course it's easy to send the necessary data out of band as opposed to
OP_RETURN. The problem is if you do that the transaction cannot not be
recovered from seed. We've been fairly successful in transitioning to HD
wallets and avoiding the need to make regular wallet backups.
If users wishes to use stealth addresses with out of band communication,
the benefits of HD would largely be lost and they would be back to
making regular backups ― this time after /every/ transaction rather than
every 100.
There are only a couple options in such cases:
1) The user could send the payment to an addresses that is derived from
seed, but now you're using even /more/ storage space than you would by
just using OP_RETURN.
2) The user can backup after every transaction, which nobody wants to do.
3) The user could use some form of a cloud backup service and place
trust in them that their servers wont go down and lose their coins.
None of those options are really that appealing. OP_RETURN seems like
the best alternative to me, at least for that use case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141117/1880ad89/attachment.html>

2023-06-07 15:27:22

- reply

📅 Original date posted:2014-11-08
📝 Original message:Thanks Mike I'll have to read that threshold signature paper.
I am familiar with the Princeton threshold signature but I was under the
impression a single key needed to be generated on a single device then
split and distributed.
Does this scheme work the same way?
I would have concerns about generating a key on a compromised computer.
On Nov 8, 2014 11:05 AM, "Mike Hearn" <mike at plan99.net> wrote:
> Here is a summary of current developments in the space of decentralised
> 2-factor Bitcoin wallets. I figured some people here might find it
> interesting.
>
> There has been very nice progress in the last month or two. Decentralised
> 2FA wallets run on a desktop/laptop and have a (currently always Android)
> smartphone app to go with them. Compromise of the wallet requires
> compromise of both devices.
>
> Alon Muroch and Chris Pacia have made huge progress on "Bitcoin
> Authenticator", their (HD) wallet app. The desktop side runs on
> Win/Mac/Linux and the mobile side runs on Android. Sending money from the
> desktop triggers a push notification to the mobile side, which presents the
> transaction for confirmation. Additionally the desktop wallet has a variety
> of other features like OneName integration. It's currently in alpha, but I
> suspect it will be quite popular once released due to its focus on UI and
> the simple mobile security model. I've tried it out and it worked fine.
>
> https://www.bitcoinauthenticator.org/
> https://github.com/cpacia/BitcoinAuthenticator/commits/master (mobile)
> https://github.com/negedzuregal/BitcoinAuthWallet (desktop)
>
> Bitcoin Authenticator uses P2SH/CHECKMULTISIG to provide the 2-factor
> functionality. However, this has various downsides that are well known:
> less support for the address type and larger transactions that waste block
> chain space + result in higher fees.
>
> To solve this problem Christopher Mann and Daniel Loebenberger from Uni
> Bonn have ported the efficient DSA 2-of-2 signing protocol by MacKenzie and
> Reiter to ECDSA, and implemented their own desktop/Android wallet app pair
> showing that it works and has good enough performance. This means that P2SH
> / CHECKMULTISIG is no longer required for the two factor auth case, and
> thus it's as cheap as using regular addresses.
>
> https://github.com/ChristopherMann/2FactorWallet
> https://eprint.iacr.org/2014/629.pdf
>
> Their protocol uses an interesting combination of ECDSA, Paillier
> homomorphic encryption and some zero knowledge proofs to build a working
> solution for the 2-of-2 case only. Their app bootstraps from a QR code that
> includes a TLS public key and IP address of the desktop: the mobile app
> then connects to it directly, renders the transaction and performs the
> protocol when the user confirms. The protocol is online, so both devices
> must be physically present.
>
> Their code is liberally licensed and looks easy to integrate with Alon and
> Chris' more user focused work, as both projects are built with Android and
> the latest bitcoinj. If someone is interested, merging Christopher/Daniel's
> code into the bitcoinj multisig framework would be a useful project, and
> would make it easier for wallet devs to benefit from this work. I can write
> a design doc to follow if needed.
>
> Currently, neither of these projects implement support for BIP70, so the
> screen you see when signing the transaction is hardly user friendly or
> secure: you just have to trust that the destination address you're paying
> to isn't tampered with. Support for sending a full payment request between
> devices is the clear next step once these wallets have obtained a
> reasonable user base and are stable.
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141108/b5d4844c/attachment.html>

2023-06-07 15:24:55

- reply

📅 Original date posted:2014-08-11
📝 Original message:Actually getUTXO would probably work here as well. It isn't authenticated
but it should be good enough for this purpose. The worst that would happen
is the tx doesn't confirm.
On Aug 11, 2014 2:25 AM, "Chris Pacia" <ctpacia at gmail.com> wrote:
> One issue I do see is the protocol requires participants to check the
> inputs submitted by others are valid. Lite clients (at least of the p2p
> variety) cannot perform this check.
>
> You could skip the verification part and if the inputs turn out to be
> invalid then you'll find out when it doesn't confirm. This would problem
> open the protocol up to dos attacks and prevent part of the "blame" phase
> from working properly.
>
> Alternatively you can have the participants submit the merkle proof for
> the input. This would require inputs to have at least one confirmation,
> however.
> On Aug 6, 2014 6:42 PM, "Tim Ruffing" <tim.ruffing at mmci.uni-saarland.de>
> wrote:
>
>> Hey,
>>
>> We (a group of researchers in Germany) propose a decentralized protocol
>> for
>> CoinJoin, a way to mix coins among users to improve anonymity. Our
>> protocol is
>> called CoinShuffle. We believe that CoinShuffle is a way to implement
>> CoinJoin
>> in the original spirit of Bitcoin, i.e., decentralized and without trusted
>> third parties. (If you are not familiar with CoinJoin, the idea is
>> explained
>> here: https://bitcointalk.org/index.php?topic=279249.0 )
>>
>> The protocol is essentially a clever way to create a CoinJoin transaction.
>> Recall that the idea of CoinJoin is mixing with one SINGLE transaction
>> that
>> has multiple input addresses and multiple fresh output addresses (i.e.,
>> one
>> pair of addresses per user). The advantage of CoinJoin over mixing with a
>> server or trusted party is that nobody can steal coins. Each user can
>> check if
>> the single transaction sends enough coins to his fresh output address. If
>> this
>> is not the case, the user can just refuse to sign the transaction and
>> nothing
>> (bad) happens.
>>
>> The difficulty in CoinJoin is to let the participants announce their fresh
>> output addresses without breaking anonymity: Of course, if a participant
>> of
>> the protocol just announces "I have 1 BTC at address X now" and "I would
>> like
>> to have it back at address Y", then everybody can link X and Y and mixing
>> is
>> useless. A naive approach is to send these two messages via a secure
>> channel
>> to a server that organizes the whole mixing. While the server cannot steal
>> coins, the server still has to be trusted for anonymity, because it knows
>> which input addresses belong to which output addresses.
>>
>> We present the list of CoinShuffle's features at the end of this e-mail.
>> An
>> overview over the technical details can be found on the project page:
>> http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/
>>
>> Moreover, for the full details, have a look at the research paper on
>> CoinShuffle that can be found here:
>> http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf
>>
>> The paper has been accepted at a major European academic conference on
>> security (ESORICS). We will present the idea there.
>>
>> Our Proof-of-concept Implementation
>> -----------------------------------
>> There is a proof-of-concept implementation (written in Python) available
>> on
>> our project page. It is really only a proof-of-concept and it implements
>> only
>> the announcement of the addresses, not the creation of the transaction.
>> Moreover, the code is CERTAINLY INSECURE and not well-written; our only
>> goal
>> was to demonstrate feasibility and estimate the performance of our
>> approach.
>>
>>
>> Our Future Plans
>> ----------------
>> Now we are planning a full, open-source implementation of the protocol. Of
>> course, we would like to build on top of an existing wide-spread client.
>> Since
>> we do not have much experience in the design of existing Bitcoin clients,
>> we
>> would appreciate any help in the process. In particular, we did not decide
>> which of the existing clients we would like to extend. Any hints towards
>> this
>> decisions would very helpful. Help in design and coding would be great
>> but we
>> also would like to hear your comments, criticism, and improvements for the
>> protocol itself.
>>
>> CoinShuffle Features
>> --------------------
>> CoinShuffle has the following features:
>>
>> - Decentralization / no third party:
>> There is no (trusted or untrusted) third party in a run of the protocol.
>> (Still, as in all mixing solutions, users need some way to gather together
>> before they can run the protocol. This can be done via a P2P protocol if a
>> decentralized solution is desired also for this step.)
>>
>>
>> - Unlinkability of input and output addresses:
>> Nobody, in particular no server (there is none!), can link input and
>> output
>> addresses of a mixing transaction, as long as there are at least two
>> honest
>> participants in run of the protocol.
>>
>> (This is not a weakness: If there is only one honest participant,
>> meaningful
>> mixing is just impossible, no matter how it is organized. If all the other
>> participants collude, they know all their input and output addresses and
>> can
>> immediately determine the output address of the honest participant.)
>>
>> - Security against thefts:
>> As explained above, nobody can steal coins during the mixing because of
>> the
>> CoinJoin principle.
>> Every participant can verify that his money will not be stolen.
>> Otherwise, he
>> refuses to sign the transaction and nothing will happen.
>>
>> - Robustness against denial-of-service:
>> In CoinJoin, a single malicious (or malfunctioning) client suffices to
>> stop
>> the whole protocol (e.g., by just refusing to sing the transaction
>> without a
>> proper reason.) This can easily lead to DoS attacks but these can be
>> countered
>> in CoinShuffle.
>>
>> While in case of disruption, the current run of the protocol has to stop,
>> CoinShuffle addresses this problem as follows: In case of active
>> disruption,
>> i.e., some participant sends wrong messages, the protocol provides a
>> proof of
>> this misbehavior. Then the honest protocol parties can start a new run of
>> the
>> protocol without the misbehaving participant. Also in case of passive
>> disruption, i.e., some participant does not respond (for whatever
>> reason), the
>> remaining participants can agree on starting a new run without this
>> participant. This ensures that the protocol will finally succeed even in
>> the
>> presence of malicious participant (although this can take quite a while
>> then).
>>
>> - Only public-key encryption and signatures:
>> The protocol requires only well-established cryptographic primitives.
>> Besides
>> signatures and hash functions (that are already used by Bitcoin), only
>> standard public-key encryption is necessary.
>>
>> - Efficiency:
>> A run of the protocol with 30 participants takes less than 100 seconds
>> (in a
>> setting with reasonable bandwidth and delay). This is not much, given
>> that 10
>> min (on average) are required to confirm the mixing transaction anyway.
>>
>> The costs are almost completely caused by communication. The computation
>> overhead is minimal. (This is the main achievement actually. In theory,
>> it is
>> clear that a protocol with all the properties can be built. However,
>> generic
>> constructions cannot be used in practice yet, because the computation and
>> communication costs are huge.)
>>
>> - Compatibility:
>> As CoinShuffle works on top of Bitcoin, it is fully compatible with the
>> current Bitcoin system. No changes to the Bitcoin protocol are required.
>>
>>
>> By the way: The NXT cryptocurrency picked up our idea and an
>> implementation of
>> CoinShuffle for a part of NXT is under way. (
>> https://twitter.com/comefrombeyond/status/485429369268350977 )
>>
>>
>> TL,DR:
>> Mixing is the way to improve anonymity in Bitcoin now, as it does not
>> require
>> changes to the Bitcoin protocol. We propose CoinShuffle, a decentralized
>> protocol to perform mixing in a secure way without trusted third parties,
>> see
>> http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/ for a technical
>> overview. Our next step is to implement the protocol. Help in design and
>> coding would be great but we also would like to hear your comments,
>> criticism,
>> and improvements for the protocol itself.
>>
>> Best,
>> Tim Ruffing, Pedro Moreno-Sanchez, Aniket Kate
>>
>>
>> ------------------------------------------------------------------------------
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140811/a7c006fb/attachment.html>

2023-06-07 15:24:54

- reply

📅 Original date posted:2014-08-11
📝 Original message:One issue I do see is the protocol requires participants to check the
inputs submitted by others are valid. Lite clients (at least of the p2p
variety) cannot perform this check.
You could skip the verification part and if the inputs turn out to be
invalid then you'll find out when it doesn't confirm. This would problem
open the protocol up to dos attacks and prevent part of the "blame" phase
from working properly.
Alternatively you can have the participants submit the merkle proof for the
input. This would require inputs to have at least one confirmation, however.
On Aug 6, 2014 6:42 PM, "Tim Ruffing" <tim.ruffing at mmci.uni-saarland.de>
wrote:
> Hey,
>
> We (a group of researchers in Germany) propose a decentralized protocol for
> CoinJoin, a way to mix coins among users to improve anonymity. Our
> protocol is
> called CoinShuffle. We believe that CoinShuffle is a way to implement
> CoinJoin
> in the original spirit of Bitcoin, i.e., decentralized and without trusted
> third parties. (If you are not familiar with CoinJoin, the idea is
> explained
> here: https://bitcointalk.org/index.php?topic=279249.0 )
>
> The protocol is essentially a clever way to create a CoinJoin transaction.
> Recall that the idea of CoinJoin is mixing with one SINGLE transaction that
> has multiple input addresses and multiple fresh output addresses (i.e., one
> pair of addresses per user). The advantage of CoinJoin over mixing with a
> server or trusted party is that nobody can steal coins. Each user can
> check if
> the single transaction sends enough coins to his fresh output address. If
> this
> is not the case, the user can just refuse to sign the transaction and
> nothing
> (bad) happens.
>
> The difficulty in CoinJoin is to let the participants announce their fresh
> output addresses without breaking anonymity: Of course, if a participant of
> the protocol just announces "I have 1 BTC at address X now" and "I would
> like
> to have it back at address Y", then everybody can link X and Y and mixing
> is
> useless. A naive approach is to send these two messages via a secure
> channel
> to a server that organizes the whole mixing. While the server cannot steal
> coins, the server still has to be trusted for anonymity, because it knows
> which input addresses belong to which output addresses.
>
> We present the list of CoinShuffle's features at the end of this e-mail. An
> overview over the technical details can be found on the project page:
> http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/
>
> Moreover, for the full details, have a look at the research paper on
> CoinShuffle that can be found here:
> http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf
>
> The paper has been accepted at a major European academic conference on
> security (ESORICS). We will present the idea there.
>
> Our Proof-of-concept Implementation
> -----------------------------------
> There is a proof-of-concept implementation (written in Python) available on
> our project page. It is really only a proof-of-concept and it implements
> only
> the announcement of the addresses, not the creation of the transaction.
> Moreover, the code is CERTAINLY INSECURE and not well-written; our only
> goal
> was to demonstrate feasibility and estimate the performance of our
> approach.
>
>
> Our Future Plans
> ----------------
> Now we are planning a full, open-source implementation of the protocol. Of
> course, we would like to build on top of an existing wide-spread client.
> Since
> we do not have much experience in the design of existing Bitcoin clients,
> we
> would appreciate any help in the process. In particular, we did not decide
> which of the existing clients we would like to extend. Any hints towards
> this
> decisions would very helpful. Help in design and coding would be great but
> we
> also would like to hear your comments, criticism, and improvements for the
> protocol itself.
>
> CoinShuffle Features
> --------------------
> CoinShuffle has the following features:
>
> - Decentralization / no third party:
> There is no (trusted or untrusted) third party in a run of the protocol.
> (Still, as in all mixing solutions, users need some way to gather together
> before they can run the protocol. This can be done via a P2P protocol if a
> decentralized solution is desired also for this step.)
>
>
> - Unlinkability of input and output addresses:
> Nobody, in particular no server (there is none!), can link input and output
> addresses of a mixing transaction, as long as there are at least two honest
> participants in run of the protocol.
>
> (This is not a weakness: If there is only one honest participant,
> meaningful
> mixing is just impossible, no matter how it is organized. If all the other
> participants collude, they know all their input and output addresses and
> can
> immediately determine the output address of the honest participant.)
>
> - Security against thefts:
> As explained above, nobody can steal coins during the mixing because of the
> CoinJoin principle.
> Every participant can verify that his money will not be stolen. Otherwise,
> he
> refuses to sign the transaction and nothing will happen.
>
> - Robustness against denial-of-service:
> In CoinJoin, a single malicious (or malfunctioning) client suffices to stop
> the whole protocol (e.g., by just refusing to sing the transaction without
> a
> proper reason.) This can easily lead to DoS attacks but these can be
> countered
> in CoinShuffle.
>
> While in case of disruption, the current run of the protocol has to stop,
> CoinShuffle addresses this problem as follows: In case of active
> disruption,
> i.e., some participant sends wrong messages, the protocol provides a proof
> of
> this misbehavior. Then the honest protocol parties can start a new run of
> the
> protocol without the misbehaving participant. Also in case of passive
> disruption, i.e., some participant does not respond (for whatever reason),
> the
> remaining participants can agree on starting a new run without this
> participant. This ensures that the protocol will finally succeed even in
> the
> presence of malicious participant (although this can take quite a while
> then).
>
> - Only public-key encryption and signatures:
> The protocol requires only well-established cryptographic primitives.
> Besides
> signatures and hash functions (that are already used by Bitcoin), only
> standard public-key encryption is necessary.
>
> - Efficiency:
> A run of the protocol with 30 participants takes less than 100 seconds (in
> a
> setting with reasonable bandwidth and delay). This is not much, given that
> 10
> min (on average) are required to confirm the mixing transaction anyway.
>
> The costs are almost completely caused by communication. The computation
> overhead is minimal. (This is the main achievement actually. In theory, it
> is
> clear that a protocol with all the properties can be built. However,
> generic
> constructions cannot be used in practice yet, because the computation and
> communication costs are huge.)
>
> - Compatibility:
> As CoinShuffle works on top of Bitcoin, it is fully compatible with the
> current Bitcoin system. No changes to the Bitcoin protocol are required.
>
>
> By the way: The NXT cryptocurrency picked up our idea and an
> implementation of
> CoinShuffle for a part of NXT is under way. (
> https://twitter.com/comefrombeyond/status/485429369268350977 )
>
>
> TL,DR:
> Mixing is the way to improve anonymity in Bitcoin now, as it does not
> require
> changes to the Bitcoin protocol. We propose CoinShuffle, a decentralized
> protocol to perform mixing in a secure way without trusted third parties,
> see
> http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/ for a technical
> overview. Our next step is to implement the protocol. Help in design and
> coding would be great but we also would like to hear your comments,
> criticism,
> and improvements for the protocol itself.
>
> Best,
> Tim Ruffing, Pedro Moreno-Sanchez, Aniket Kate
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140811/21009e71/attachment.html>

2023-06-07 15:21:33

- reply

📅 Original date posted:2014-05-17
📝 Original message:Since these notes have to be redeemed immediately the number of use
cases seems limited. I can't really just hand someone the note and walk
away because they have to scan it to see if it is actually valid.
Otherwise someone could just pass fake notes if they felt the recipient
wouldn't redeem them on the spot. This doesn't seem like an improvement
over just sending the coins via phone.
The use case with poor internet connection wouldn't work as well since,
presumably, the recipient would also have poor reception and couldn't
verify the note was actually loaded with bitcoins.
Also, I REALLY don't like the name bit reserve.
-Chris
On 05/17/2014 11:31 AM, Jerry Felix wrote:
> It seems to me that there's a huge need for a paper currency that is
> counterfeit-resistant, inexpensive to print, internationally
> recognized (border-less), fits in a wallet, and machine readable.
>
> I pitched this idea at the Cincinnati Bitcoin meetup last week, and I
> didn't get thrown out, so I took the time to document a proposed
> standard to accomplish this. I've put my ideas into BIP format, so
> that you can see what I have in mind, although I picked some
> BIP numbers myself that seem to be available. Call them "proposed
> proposals", or "provisional BIPs". I've numbered them provisionally
> BIP-80 to BIP-84.
>
> If you guys think that this idea has some merit, let's discuss.
>
> https://github.com/jerfelix/provisional_bips/blob/master/README.mediawiki
>
> Submitted with humility and some fear of getting laughed out of here...
> - Jerry
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140517/50728eeb/attachment.html>

2023-06-07 15:21:12

- reply

📅 Original date posted:2014-05-12
📝 Original message:Just a thought. Using the payment protocol for stealth would mean we
would likely have to return to backing up wallets all the time would it not?
The nonces cannot be derived from your wallet seed and, since they
aren't in the blockchain, would have to be stored in your wallet. I
suppose they could be stored on the server, but you would probably want
a backup for that anyway. So we would end up having to back up all the
time, something we're trying to get away from. Am I correct about this?
On 05/09/2014 02:38 PM, Pieter Wuille wrote:
> On Fri, May 9, 2014 at 8:13 PM, Peter Todd <pete at petertodd.org> wrote:
>> I don't think we're going to find that's practical unfortunately due to
>> change. Every payment I make ties up txouts, so if we try to base the
>> atomicity of payments on whether or not the payee decides to broadcast
>> the transaction the payor is stuck with txouts that they can't use until
>> the payee makes up their mind. That leads to lots and lots of nasty edge
>> cases.
> I haven't talked much about it except for on IRC, but my idea was this:
> * PaymentACK messages become signed (with the same key as the payment
> request, or using some delegation mechanism, so that the same key
> doesn't need to remain online).
> * Instead of a full Bitcoin transaction, a Payment message contains a
> scriptSig-less Bitcoin transaction + a limit on its byte size (and
> perhaps a limit on its sigop count).
> * The sender sends such a Payment to the receiver before actually
> signing the transaction (or at least, before revealing the signed
> form).
> * The receiver only ACKs if the transaction satisfies the request, is
> within time limits, isn't unlikely to confirm.
> * If the sender likes the ACK (the refund and memo fields are intact,
> the transaction isn't changed, the signature key is valid, ...), he
> either sends the full transaction (with receiver taking responsibility
> for broadcasting) or broadcasts it himself.
>
> Together, this means that a paymentACK + a confirmed matching Bitcoin
> transaction can count as proof of payment. Both parties have a chance
> to disagree with the transaction, and are certain all communicated
> data (apart from transaction signatures) in both directions happened
> correctly before committing. It would completely remove the chance
> that the Bitcoin transaction gets broadcast without the receiver
> liking it (for legitimate or illegitimate reasons), or without the
> backchannel functioning correctly.
>
> It's also compatible with doing multiple payments in one Bitcoin
> transaction - you can ask for ACKs from multiple parties before
> signing the transaction.
>
> Of course, the sender can still withhold the signed transaction (in
> which case nothing happened, but we probably need a second timeout),
> or the receiver can always claim to have never received the
> transaction. The sender can broadcast the transaction himself in order
> to prevent that, after obtaining an ACK.
>

2023-06-07 15:20:39

- reply

📅 Original date posted:2014-05-03
📝 Original message:Absent a concerted effort to move to something else other than 'bits', I
would be willing to bet the nomenclature moves in that direction anyway.
'Bits' is just a shorten word for 'millibits' (or microbits, if you
will). It's easier to say and my guess is people would tend to use it
naturally own their own. Kind of like 'bucks' for dollars.
The other synergies are:
-bit is part of the word Bitcoin. The currency unit bit is part of a
whole bitcoin.
-bit symbolically represents the tech nature of the bitcoin.
-bit used to be a unit of money way back when. This largely reclaims it.
-when used as money bit when in references to a precession metal coin.
The name 'bitcoin' references that as well as the mimicking of the gold
standard in the protocol rules.
All around I don't think there is a better fit. I doubt people will get
confused by it. The context it's used in will distinguish it from other
uses of the word.
On 05/03/2014 12:27 PM, Mike Caldwell wrote:
> I agree with the sentiment that most people don't understand either computer science or Bitcoin. The goal of getting people to understand enough about Bitcoin to use it is achievable and a goal that is "in scope" of our efforts. Getting them to understand computer science at large at the same time, less so.
>
> The fact that people routinely confuse RAM and hard drive sizes has much to do with the fact that the average lay person has little need to prioritize this as something to keep in the forefront. They don't get "horribly" confused, they just simply don't get worked up over what looks to them like a rounding error, much to the dismay of anyone who believes that everyone should be an expert at computer science. The average joe may assess (accurately from his perspective) that the distinction isn't important enough to merit significant mental resources and he is justified in not expending them that way even if someone else thinks he should.
>
> Poor understanding is precisely what a proper effort to name this would be to avoid. It is not frill or aesthetics, it is a planned targeting of language to achieve the clearest communication to the widest possible target audience using the language most likely to be understood by them in light of our objectives. It's marketing.
>
> Mike
>
> Sent from my iPhone
>
>> On May 3, 2014, at 9:49 AM, "Christophe Biocca" <christophe.biocca at gmail.com> wrote:
>>
>> Context as a disambiguator works fine when the interlocutors
>> understand the topics they're talking about.
>> Not a day goes by without me seeing "neurotypical people" get horribly
>> confused between RAM and Hard Drive sizes, because they share the same
>> units (not that that can be helped, as the units are supposed to be
>> the same, base 1000 vs 1024 notwithstanding).
>>
>> Bit (as a unit) is already really confusing for anyone who doesn't
>> deal with it on a regular basis. I think people who don't see an issue
>> are making an assumption based on their own lack of confusion. We
>> understand computer science AND Bitcoin. Most people have zero
>> understanding of either.
>>
>> Bitcoin already has a ton of issues with terrible names for things:
>>
>> - Mining (for transaction validation).
>> - Addresses (which are meant to be one-time use, and don't even really
>> exist at the network level).
>> - Wallets (which don't hold your bitcoins, can be copied, and all
>> backups can be stolen from equally).
>>
>> I end up having to make the distinctions obvious every time I explain
>> Bitcoin to someone new to it. There's an acceptable tradeoff here,
>> because there were arguably no better words to assign to these
>> concepts (although I'd argue mining is a really awful metaphor, and is
>> the one that prompts the most questions from people). Then add to the
>> pile a bunch of third parties naming themselves after parts of the
>> protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've
>> definitiely seen average people get confused between "the blockchain"
>> and "blockchain.info" (not so much Coinbase, because that name doesn't
>> come up in beginner explanations).
>>
>> It seems downright masochistic to add
>> yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile
>> for no reason other than aesthetics. Are we actively trying to confuse
>> people?
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:19:56

- reply

📅 Original date posted:2014-04-24
📝 Original message:This scheme would discourage people from attempting a Finney attack because
they would end up worse off if they did.
It would work but it's an ugly hack IMO. What do people do if they don't
have extra to pay when making a purchase? I have 200 mbtc and want to buy a
200 mbtc phone but I can't because I need 400 mbtc. Sucks for me.
I would much prefer the hassle of a green address notary than always having
to make sure I have double what I need to make a purchase.
On Apr 24, 2014 7:55 AM, "Mike Hearn" <mike at plan99.net> wrote:
> Am I missing something?
>
>
> The scheme you described does nothing about Finney attacks, which is the
> issue presently faced.
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140424/af5cd2cc/attachment.html>

2023-06-07 15:19:33

- reply

📅 Original date posted:2014-04-23
📝 Original message:What is the advantage of this proposal over just orphaning the block with
double spends?
There's currently a set of rules which government what constitutes a valid
block. Miners don't build on blocks that don't accord with those rules out
of fear that a major won't follow and they will waste hashing power.
If there was a rule supported by the majority that considered blocks with
double spends (defined in some fashion) as invalid miners wouldn't build on
them for the same reason they wouldn't build on a block with a coinbase
over 25 btc, say. It seems that would accomplish the same without the other
issues.
On Apr 23, 2014 12:04 PM, "Christophe Biocca" <christophe.biocca at gmail.com>
wrote:
> It's not necessary that this "coinbase retribution" be either
> profitable or risk-free for this scheme to work. I think we should
> separate out the different layers of the proposal:
>
> 1. Attacking the coinbase instead of orphaning allows for 100 blocks'
> time for a consensus to be reached, rather than 10 minutes. This
> allows for human verification/intervention if needed (orphaning
> decisions would almost always need to be automated, due to the short
> timeframe). This is a useful insight, and I don't think it's been
> brought up before.
>
> 2. The original specification of how it's done (redistribution, no
> cost to voting) does seem exploitable. This can be fixed by reducing
> the incentive (burning instead of redistributing) and/or adding a risk
> to the orphaning attempts (a vote that fails destroys X bitcoins'
> worth from each voting block's own coinbase). The incentives can be
> tailored to mirror those of orphaning a block, to reduce the risk of
> abuse. Then the only difference from orphaning are 1) More limited
> rewriting of history (only the coinbase, vs all transactions in the
> block), and 2) More time to coordinate a response.
>
> 3. This proposal may be used for things other than punishing
> double-spend pools. In fact it might be used to punish miners for
> doing anything a significant percentage of hashpower dislikes (large
> OP_RETURNs, large blocks, gambling transactions, transactions banned
> by a government). But we can make the threshold higher than 51%, so
> that this doesn't turn into a significant risk (if 75% of hashpower is
> willing to enforce a rule, we're already likely to see it enforced
> through orphaning).
>
> On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi <alex.mizrahi at gmail.com>
> wrote:
> >
> >>
> >> And it still would. Non-collusive miners cast votes based on the outcome
> >> of their own attempts to double spend.
> >
> >
> > Individually rational strategy is to vote for coinbase reallocation on
> every
> > block.
> >
> > Yes, in that case nobody will get reward. It is similar to prisoner's
> > dilemma: equilibrium has worst pay-off.
> > In practice that would mean that simple game-theoretic models are no
> longer
> > applicable, as they lead to absurd results.
> >
> >>
> >> I'm using it in the same sense Satoshi used it. Honest miners work to
> >> prevent double spends. That's the entire justification for their
> existence.
> >> Miners that are deliberately trying to double spend are worse than
> useless.
> >
> >
> > Miners work to get rewards.
> > It absolutely doesn't matter whether they are deliberately trying to
> > double-spend or not: they won't be able to double-spend without a
> collusion.
> >
> >
> ------------------------------------------------------------------------------
> > Start Your Social Network Today - Download eXo Platform
> > Build your Enterprise Intranet with eXo Platform Software
> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> > Get Started Now And Turn Your Intranet Into A Collaboration Platform
> > http://p.sf.net/sfu/ExoPlatform
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/48d8a89a/attachment.html>

2023-06-07 15:18:57

- reply

📅 Original date posted:2014-04-20
📝 Original message:You're correct, my impression of the term is based of what I experience in
the US. If it is more widely used in other cultures that should be a
consideration.
On Apr 20, 2014 12:27 PM, "Wladimir" <laanwj at gmail.com> wrote:
> On Sun, Apr 20, 2014 at 6:19 PM, Chris Pacia <ctpacia at gmail.com> wrote:
> > The term bit is really only overloaded for those who are techy. 95% of
> the
> > population never uses the term bit in their daily lives and I doubt most
> > could even name one use of the term.
> > Plus bit used to be a unit of money way back when, so this is kind of
> > reclaiming it. I think it's a great fit.
>
> That's a very anglocentric way of thinking.
>
> Here in the Netherlands, a "bit" is something you put in a horses's
> mouth. It's also used as imported word (in the information sense).
> We've never used the term for money.
>
> Wladimir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140420/9a876d8c/attachment.html>

2023-06-07 15:18:56

- reply

📅 Original date posted:2014-04-20
📝 Original message:The term bit is really only overloaded for those who are techy. 95% of the
population never uses the term bit in their daily lives and I doubt most
could even name one use of the term.
Plus bit used to be a unit of money way back when, so this is kind of
reclaiming it. I think it's a great fit.
On Apr 20, 2014 11:52 AM, "Alan Reiner" <etotheipi at gmail.com> wrote:
> I've been a staunch supporter of "microbitcoin" and would like to do
> anything I can to make sure that we jump directly to it if we're going to
> promote changing the default units. And I'm happy to integrate it into
> Armory as a default (with appropriate explanations and settings/options).
> I'm not so convinced about the "bits" name though -- I do like it, but I do
> also think that word is too overloaded. Though, I think we could get away
> with it.
>
> (Sadly, I still use "microbes" occasionally (as in *microb*itcoin) when
> I'm talking to coworkers, because it slips off the tongue and is actually a
> good combination of brevity and self-explanatory -- it just doesn't instill
> the right visuals...)
>
> We started integrating alternative units into Armory. But, of course,
> there were a few more loose ends than I expected, which will require some
> work. We want to put it in but not necessarily change the default right
> away. I'd *prefer* we get some commitments from some other wallet
> developers, so we can make a unified push for it. I'm happy to lead that
> and make it default as long as I'm not the only one in the world doing it.
>
> -Alan
>
>
>
> On 04/20/2014 11:05 AM, Tamas Blummer wrote:
>
> Here is an earlier reference to bits:
>
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04248.html<https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04248.html>
>
> I forgot that Alan Reiner was also supporting a unit equals to bits :
>
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04264.html<https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04264.html>
>
> and here the earlier going back to March 2013 and a poll at that time
> pushing for XBT being 1 bit
>
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04256.html<https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04256.html>
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 20.04.2014, at 16:53, Pieter Wuille <pieter.wuille at gmail.com> wrote:
>
> I told him specifically to bring it here (on a pull request for
> Bitcoin Core), as there is no point in making such convention changes
> to just one client.
>
> I wasn't aware of any discussion about the "bits" proposal here before.
>
> On Sun, Apr 20, 2014 at 4:28 PM, Tamas Blummer <tamas at bitsofproof.com>
> wrote:
>
> People on this list are mostly engineers who have no problem dealing with
> magnitudes and have rather limited empathy for people who have a problem
> with them.
> They also tend to think, that because they invented money 2.0 they would
> not
> need to care of finance's or people's current customs.
>
> The importance of their decisions in these questions will fade as people
> already use wallets other than the core.
>
> Bring this particular discussion elsewhere, to the wallet developer.
>
> BTW the topic was discussed here several times, you have my support and
> Jeff
> Garzik's.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 20.04.2014, at 15:15, Rob Golding <rob.golding at astutium.com><rob.golding at astutium.com>wrote:
>
> The average person is not going to be confident that the prefix they
> are using is the correct one,
>
>
> The use of any 'prefix' is one of choice and entirely unnecessary, and
> there
> are already established 'divisions' in u/mBTC for those that feel they need
> to use such things.
>
> people WILL send 1000x more or less than
> intended if we go down this road,
>
>
> Exceptionally unlikely - I deal every day with currencies with 0, 2 and 3
> dp's in amount ranging from 'under 1 whole unit' to tens of thousands - Not
> once in 20 years has anyone ever 'sent' more or less than intended - oh,
> they've 'intended' to underpay just fine, but never *unintended*.
>
> I propose that users are offered a preference to denominate the
> Bitcoin currency in a unit called a bit. Where one bitcoin (BTC)
> equals one million bits (bits) and one bit equals 100 satoshis.
>
>
> I propose that for people unable to understand what a bitcoin is, they can
> just use satoshi's and drop this entire proposal.
>
> Rob
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!http://p.sf.net/sfu/NeoTech
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140420/46548050/attachment.html>

2023-06-07 15:15:42

- reply

📅 Original date posted:2014-03-13
📝 Original message:I second the name 'bit' for μBTC.
On Mar 13, 2014 11:19 AM, "Tamas Blummer" <tamas at bitsofproof.com> wrote:
> Jeff's arguments are understood and supported by those who worked in
> finance.
>
> Existing financial applications have often problems dealing with more than
> 2 decimals.
> People who work in finance are used to two decimals.
>
> Neither systems nor people in finance have a problem with large numbers
> though.
>
> For above practical reasons I am also for moving to a unit that equals 100
> satoshi.
> I heard the name bit for it which I like.
>
> Regards,
>
> Tamás Blummer
> Founder, CEO
> Bits of Proof
> http://bitsofproof.com
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/2d59a175/attachment.html>