Let me give you an example based on how companies actually do business in the real world. When factory A's maintenance department orders supplies from Grainger, Grainger makes no assumptions at all about how that invoice will ultimately be paid. It might be paid all at once in a single payment. There might be multiple invoices outstanding and the factory cuts a single check that covers all of them. There probably will be be a many-to-many relationship between the number of invoices and the number of payments. Any accounting system that assumes a 1:1 invoice to payment relationships is hopelessly broken in the real world and should be discarded. Don't build that kind of brokenness into a protocol from the very beginning, especially when there are real negative privacy implications associated with doing so. |
|
|
|
Usually it is not the payee who generates the addresses, but the one issuing the bill. It is also natural to associate 1-1 a bill with an address, as also the payment protocol suggests. Then the payment protocol is broken and wrong from a privacy and commerce perspective, probably written by somebody with no business experience in net D billing. The person issuing the bill has no idea how many transactions and addresses the payee needs to use to make a payment and shouldn't care. |
|
|
|
They could peg it to some commodity, or even a basket of currencies, and get something that's pretty stable right off the bat. No. |
|
|
|
Assume Alice generates addresses for bills as consecutive keys of a root (or sub-root does not matter). Most bills get paid a few not.
Now Alice loses her hard drive that recorded all transactions but has the HD root stored. With an look ahead window of say 10, she would re-discover bill payments even if there are some gaps in between them in her key space.
I'm fine with configurable lookahead windows, but I don't see how that fits into your example. Alice presumably is receiving bill payments from a large number of payees. Each of those payees should be generating deposit addresses themselves from a unique xpub Alice gave each of them. If a payee does not pay a bill one month, there's absolutely no reason at all they should skip ahead. Alice should also not be specifying the addresses to which each payee should send payment for a specific bill. |
|
|
|
I think that the HD root is actually useless in absence of limiting assumption on its key use that allow efficient discovery of associated funds. I think the best default structure is a case where the root is used to produced an unlimited number of first level children (in sequence), and each child produces a linear series of payment addresses (also in in sequence). Each first-level child of the root seed is called a payment channel. Payment channel 0 is the internal use channel. It's where the client produces individual receive addresses and puts change outputs. Each subsequent payment channel is given to individual senders as an xpub. If Alice wants to receive bitcoins from Bob, she generates the next unused payment channel and gives the the appropriate xpub to Bob. Now Bob always knows how to send funds to Alice without any further key exchange (TOFU security). Bob can now tell his client "send X btc to Alice" and the client automatically does the right thing, and Alice's client already knows which addresses to expect future payments at because both clients are being sane and increment indexes monotonically. |
|
|
|
Right now the market wants to go up. The market hates being anthropomorphized. |
|
|
|
|
This never did get resolved, did it?
|
|
|
|
this "can't buy groceries with bitcoin" shittalk is just sooo much crap ... who gives a fuck if you can't buy groceries with btc??
That reminds me that I need to write up a feature request for LocalBitcoins with exactly the features they'd need to add to make it possible for people to buy groceries (or anything) with btc. |
|
|
|
What I realized is that even if a company *genuinely wants* to create a centralized-version of Bitcoin's electronic cash, they won't be able to. The reason is simply that any centralized organization would eventually succumb to the pressure to "do something."
My conclusion is that the end game for any centralized coin is something very similar to the banking system we already have. Exactly. Bitcoin is successful not because it uses cryptography nor because it's more convenient than a bank wire. Bitcoin is successful because it lacks prior restraint, remote confiscation, and arbitrary inflation. It doesn't matter what banks or governments try to do to compete with Bitcoin. Those are three features they will always in their currencies no matter what technology they build upon. |
|
|
|
|
Maybe when new users create an account on this forum the altcoin area should be added to their ignore board list by default, so they have to opt in to see it.
|
|
|
|
This happens often enough that I don't get any benefit from the changes in 0.90. I almost never have a clean shutdown. 2013-12-25 21:57 (INFO) -- armoryengine.py:10634 - Received new block. 0000000000000002183ed6df1f380c9333f32b1f779e404e60a11bff7968904c
2013-12-25 21:57 (INFO) -- ArmoryQt.py:4781 - New Block! : 276995
2013-12-25 21:57 (INFO) -- ArmoryQt.py:4805 - Current block number: 276995
2013-12-25 22:12 (INFO) -- ArmoryQt.py:4781 - New Block! : 276996
2013-12-25 22:12 (INFO) -- ArmoryQt.py:4805 - Current block number: 276996
2013-12-25 22:14 (INFO) -- armoryengine.py:10634 - Received new block. 0000000000000000f5263c79ac83062cd24f2c71692de09fc937735a0abef523
2013-12-25 22:14 (INFO) -- ArmoryQt.py:4781 - New Block! : 276997
2013-12-25 22:14 (INFO) -- ArmoryQt.py:4805 - Current block number: 276997
2013-12-25 22:33 (INFO) -- ArmoryQt.py:4781 - New Block! : 276998
2013-12-25 22:33 (INFO) -- ArmoryQt.py:4805 - Current block number: 276998
2013-12-25 22:41 (INFO) -- ArmoryQt.py:4781 - New Block! : 276999
2013-12-25 22:41 (INFO) -- ArmoryQt.py:4805 - Current block number: 276999
2013-12-25 22:48 (INFO) -- armoryengine.py:10634 - Received new block. 0000000000000001b8a1691057cd6639e56224d99f7f7d80e7b61f55be52d931
2013-12-25 22:48 (INFO) -- ArmoryQt.py:4781 - New Block! : 277000
2013-12-25 22:48 (INFO) -- ArmoryQt.py:4805 - Current block number: 277000
2013-12-25 22:49 (INFO) -- ArmoryQt.py:4781 - New Block! : 277001
2013-12-25 22:49 (INFO) -- ArmoryQt.py:4805 - Current block number: 277001
2013-12-25 22:51 (INFO) -- armoryengine.py:10634 - Received new block. 000000000000000107ddda65ee3ae1c6d67a96e0c5438e15d5567170ddd849fe
2013-12-25 22:51 (INFO) -- ArmoryQt.py:4781 - New Block! : 277002
2013-12-25 22:51 (INFO) -- ArmoryQt.py:4805 - Current block number: 277002
2013-12-25 23:00 (ERROR) -- armoryengine.py:12372 - Waiting for BDM output that didn't come after 20s.
2013-12-25 23:00 (ERROR) -- armoryengine.py:12373 - BDM state is currently: BlockchainReady
2013-12-25 23:00 (ERROR) -- armoryengine.py:12374 - Called from: armoryengine.py:12563 (94868342)
2013-12-25 23:00 (ERROR) -- armoryengine.py:12375 - BDM currently doing: ZeroConfTxToInsert (85534452)
2013-12-25 23:00 (ERROR) -- armoryengine.py:12376 - Direct traceback
2013-12-25 23:00 (ERROR) -- armoryengine.py:12378 - Traceback:
Traceback (most recent call last):
File "/usr/lib64/armory/armoryengine.py", line 12368, in waitForOutputIfNecessary
return self.outputQueue.get(True, self.mtWaitSec)
File "/usr/lib64/python2.7/Queue.py", line 176, in get
raise Empty
Empty
2013-12-25 23:00 (ERROR) -- armoryengine.py:13289 - ErrorOut var over-represented number of errors!
2013-12-25 23:00 (ERROR) -- ArmoryQt.py:4725 - Detected Bitcoin-Qt/bitcoind not synchronized
2013-12-25 23:00 (ERROR) -- ArmoryQt.py:4726 - New blocks added in last 5 sec: 277002 I don't see any evidence of problems in bitcoind's logs around the time this happened. |
|
|
|
The majority of wealthy people did not steal their wealth as mainstream media would like you believe. The majority of wealthy people earned their wealth by creating businesses such as car washes, construction firms, service industries, laundry mats, farming, inventing, etc and etc.
You likely have wealthy people living in your neighborhood even though you may not know it - because they live and act much like you. They work hard (usually far more than your typical 40-hr per week worker), take huge financial and personal risks, employ people, pay upwards of 40% in direct taxes (nearly half!), and make the world a better place for us all. If they were to leave your area (think of Detroit) you would see it fall into ruin because they truly are carrying much of the burden. The people you are talking about barely qualify as "wealthy". They are more accurately classified as upper middle class. The wealthy are mostly the fascists as you described. |
|
|
|
|
At least get enough that you can be a left-sider.
X.yyyyyyyy = left sider
0.yyyyyyyy = right sider
|
|
|
|
|
Suppose the transaction fee is split into two fees: one for the miner, and one for a node that relays it to a miner.
The person who creates a transaction would need a method to sign an input that anybody could claim, but in a way that it's only valid if their transaction makes it into a block.
|
|
|
|
Ok so I'm wrong because... I just am?
Good argument old chap.
Try having a discussion with experienced neurosurgeons about the pros and cons of different techniques without even having gone through medical school and I bet you'd get the same response. |
|
|
|
|
Show Posts
